O Couchbase é um banco de dados JSON que agora se tornou uma alternativa ao RDBMS tradicional. Ele conseguiu isso, não apenas fornecendo o armazenamento de chave-valor líder do setor e os mesmos recursos de consulta e tradução ACID que as organizações esperam, mas também a flexibilidade de armazenar nativamente seus dados no formato JSON. Além disso, o Couchbase também inclui armazenamento distribuído, escalabilidade multidimensional, alta disponibilidade e replicação entre datacenters (XDCR). Tudo isso em uma única plataforma de dados Couchbase que se estende até a borda com o Couchbase Mobile.
O Couchbase também está comprometido em ampliar seus recursos muito além do que é necessário em aplicativos RDBMS tradicionais. Com o Couchbase Cloud, onde tudo é totalmente gerenciado e automatizado, fornecendo um banco de dados como serviço (DBaaS) seguro que simplifica o gerenciamento de esquemas de banco de dados FHIR, implantando, gerenciando e operando o Couchbase Server em ambientes de várias nuvens com apenas alguns cliques. O Couchbase Cloud é flexível, altamente disponível e oferece uma opção econômica diferenciada para empresas que buscam reduzir as tarefas operacionais e, ao mesmo tempo, aproveitar a mais avançada tecnologia NoSQL.
Também estamos fazendo isso colaborando com muitos de nossos clientes de diferentes setores para entender suas necessidades de negócios e como o Couchbase pode ajudar com esses desafios. Esses setores incluem varejo e comércio eletrônico, viagens e hotelaria, serviços financeiros, energia e serviços públicos, além de alta tecnologia e jogos.
Neste blog, gostaria de me concentrar em como o banco de dados Couchbase pode ser usado no setor de saúde. Especificamente, o foco será a especificação Fast Healthcare Interoperability Resources (FHIR), definida por HL7 FHIR. O motivo deste blog é o nível de interesse de muitos de nossos clientes que estão atualmente planejando ou implementando seus aplicativos compatíveis com FHIR usando o banco de dados Couchbase.
Por que o FHIR com Couchbase é de seu interesse?
- As organizações buscam desenvolver aplicativos FHIR e/ou procuram aproveitar os muitos benefícios do banco de dados NoSQL, como escalabilidade distribuída, alta disponibilidade, XDCR e multidimensional.
- Os arquitetos ou desenvolvedores precisam entender como o banco de dados JSON do Couchbase pode reduzir bastante a complexidade de seus aplicativos, relegando o complexo FHIR Search [https://www.hl7.org/fhir/searchparameter-registry.html] processamento para a camada do servidor de banco de dados.
- Os analistas de dados precisam entender como aproveitar seu conhecimento de SQL para consultar dados FHIR diretamente com Couchbase N1QL e Pesquisa de texto completo.
- Você está interessado em descobrir como o Couchbase N1QL, um SQL para JSON, pode fornecer uma maneira eficiente de consultar um modelo de dados relacional, conforme definido pelo protocolo FHIR, que é de natureza hierárquica e relacional JSON.
O que é FHIR?
FHIR® - Recursos rápidos de interoperabilidade na área de saúde - é uma estrutura de padrões de última geração criada pela HL7. O FHIR (pronuncia-se "fire", fogo) combina os melhores recursos do HL7 e aproveita os mais recentes padrões da Web, aplicando um foco rígido na capacidade de implementação para trocas de informações.
Os aplicativos FHIR são baseados no conceito de "Recursos". Esses recursos são reunidos em aplicativos específicos de saúde, abrangendo desde as funções administrativas e clínicas até as funções de atendimento ao paciente. O FHIR é adequado para uso em uma ampla variedade de contextos - aplicativos para telefones celulares, comunicações em nuvem, compartilhamento de dados com base em EHR, comunicação com servidores para provedores de serviços de saúde.
Um dos principais objetivos do FHIR é especificar um padrão que possa ser adotado por diferentes aplicativos de saúde, permitindo assim a interoperabilidade entre diferentes aplicativos funcionais e, por fim, reduzindo o custo das implementações.
Consulte o Site de visão geral da FHIR Para mais informações.
O modelo de dados FHIR
No centro da FHIR está a definição comum dos diferentes tipos de recursos que englobam todos os diferentes aspectos do setor de saúde. Desde a função administrativa de Paciente, Profissional, Equipe de Atendimento, Dispositivo, Organização, Local, Serviço de Saúde, até a Clínica, Diagnóstico, Medicamentos, bem como as funções Financeiras, como Cobertura de Seguro.
Para os fins deste artigo, estou usando o conjunto de dados sintéticos de amostra disponível no Synthetic Mass que foi gerado por Sínteseuma simulação de população de pacientes de código aberto disponibilizada pela The MITRE Corporation.
Os dados foram disponibilizados como um pacote de recursos para cada paciente sintético, que foram importados para uma instância do banco de dados Couchbase 6.5.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
SELECT resourceType, COUNT(1) doc_count FROM fhir_admin WHERE resourceType IS NOT MISSING GROUP BY resourceType doc_count resourceType 567 "AllergyIntolerance" 3577 "CarePlan" 3577 "CareTeam" 52387 "Claim" 8714 "Condition" 57 "Device" 17069 "DiagnosticReport" 42019 "Encounter" 42019 "ExplanationOfBenefit" 2942 "Goal" 965 "ImagingStudy" 14982 "Immunization" 926 "MedicationAdministration" 10368 "MedicationRequest" 235332 "Observation" 1033 "Organization" 1177 "Patient" 1034 "Practitioner" 32454 "Procedure" |
Alguns pontos importantes sobre o modelo de dados FHIR
- O modelo gira em torno do objeto "paciente
- O tipo de objeto é representado pelo campo "resourceType
- A estrutura JSON suporta um conjunto mais rico de informações de saúde que podem ser mantidas sobre o paciente: nível de saúde, detalhes de contato, endereços, comunicações, etc.
- Cada objeto tem um campo "id" exclusivamente identificável.
- Os objetos estão fazendo referência uns aos outros. A maioria deles tem referências ao objeto "paciente".
Por que o Couchbase é adequado para o FHIR
Como mencionado acima, o Couchbase armazena seus dados nativamente em JSON, que é um formato de documento legível. Os aplicativos podem usar as APIs de chave-valor ou aproveitar a linguagem de consulta N1QL do Couchbase para manipular os documentos. A vantagem de armazenar os dados no formato JSON, em vez de como um tipo de coluna como em muitos RDBMS, é a facilidade com que os usuários podem acessar as informações nele contidas. Os elementos do documento JSON, como campo, objeto de matriz e objeto hierárquico, podem ser acessados diretamente do objeto pai sem a necessidade de sintaxe adicional.
Aqui está um exemplo do documento do paciente, conforme definido pelo FHIR.
O que isso significa para o aplicativo FHIR é que os usuários com experiência em RDBMS que têm um conhecimento básico de SQL podem acessar o paciente FHIR e os recursos associados exatamente da mesma forma que com o RDBMS tradicional.
Couchbase N1QL para pesquisar dados FHIR
Consultar pacientes por ID
|
1 2 3 4 |
SELECT * FROM fhir_admin res WHERE res.resourceType='Patient' AND res.id='e3ae7831-14c8-4d13-a8fb-dad68fa12bc9' |
Consulta de pacientes por faixa etária
|
1 2 3 4 5 6 7 8 9 10 |
SELECT agegroup,count(*) FROM fhir_admin p LET age=DATE_DIFF_STR(now_str(),p.birthDate,'year'), agegroup = CASE WHEN age <= 4 THEN 'A - 0-4' WHEN age <= 17 THEN 'B - 5-17' WHEN age <= 49 THEN 'C - 18-49' WHEN age <= 64 THEN 'D - 50-64' ELSE 'E - > 65' END WHERE p.resourceType='Patient' GROUP BY agegroup |
- A idade do paciente deve ser calculada a partir da data atual - DOB.
- A consulta usa a construção N1QL LET para definir "age" (idade) e agrupar a idade em "agegroup" (grupo de idade).
- Um ANSI GROUP BY e COUNT padrão retorna o número de pacientes por faixa etária.
Além disso, a capacidade de unir e unir documentos com o Couchbase N1QL permite que os usuários consultem informações relacionadas ao paciente.
Consultar pacientes e suas condições atuais não resolvidas
|
1 2 3 4 5 6 7 |
SELECT ARRAY v FOR v IN p.name WHEN v.`use`='official' END fullname , cc.display FROM fhir_admin c INNER JOIN fhir_admin p USE HASH(BUILD) ON split(c.subject.reference,':')[2] = p.id AND p.resourceType='Patient' UNNEST c.code.coding as cc WHERE c.resourceType='Condition' AND EVERY s in c.clinicalStatus.coding SATISFIES s.code != 'resolved' END |
- Um paciente pode ter vários nomes, que são representados na matriz "name". Essa consulta usa o operador ARRAY para filtrar apenas o elemento oficial da matriz 'name'.
- A consulta associa a "condição" ao objeto "paciente" usando parte do campo "subject.reference" do objeto "condição" ao "patient.id".
- Cada "paciente" pode ter várias condições, por isso a necessidade de achatar (UNNEST) a matriz "condition->code".
- Pode haver vários "clinical.status" para a "condição", mas a consulta só precisa retornar as condições que não foram resolvidas
Lista de todos os pacientes que estiveram no hospital de Beverley na semana iniciada em 2011-08-18
|
1 2 3 4 5 6 7 8 9 10 |
SELECT ARRAY v FOR v IN p.name WHEN v.`use`='official' END fullname , p.telecom phonecontact, p.address, p.communication, p.identifier FROM fhir_admin m INNER JOIN fhir_admin p ON split(m.subject.reference,':')[2] = p.id AND p.resourceType='Patient' WHERE m.resourceType='Encounter' AND DATE_FORMAT_STR(m.period.`start`, '1111-11-11') BETWEEN '2011-08-18' AND '2011-08-25' AND m.serviceProvider.display = 'BEVERLY HOSPITAL CORPORATION' |
- A consulta examina o objeto "encounter" para descobrir todos os tratamentos do "paciente" nesse hospital específico.
- O operador ARRAY é usado para obter o nome oficial do "paciente".
Lista de pacientes com detalhes de seus pedidos de indenização de seguro - serviços e custos
|
1 2 3 4 5 6 7 |
SELECT c.patient.reference, cis.display,SUM( c.total.`value`) FROM fhir_admin c INNER JOIN fhir_admin p ON split(c.patient.reference,':')[2] = p.id AND p.resourceType='Patient' UNNEST c.item as ci UNNEST ci.productOrService.coding as cis WHERE c.resourceType='Claim' GROUP by cis.display,c.patient.reference |
- O objeto "claim" é JOINED ao objeto "patient" para acessar os detalhes do paciente.
- O objeto "claim" tem uma matriz aninhada para "claim->item".
- O "claim->item" está associado a um "productOrService" com uma codificação de matriz que contém a descrição do tratamento.
- O custo está no nível da reivindicação.
Classificar a contagem de procedimentos por hospital
|
1 2 3 4 5 6 7 |
SELECT e.serviceProvider.display hospital, p.code.text treatment, RANK() OVER ( PARTITION BY e.serviceProvider.display ORDER BY COUNT(p.code.text) DESC ) serviceRank FROM fhir_admin p INNER JOIN fhir_admin e USE HASH(PROBE) ON split(p.encounter.reference,':')[2] = e.id and e.resourceType='Encounter' WHERE p.resourceType='Procedure' GROUP by e.serviceProvider.display,p.code.text |
- O objeto "procedure" é JUNTADO ao objeto "encounter" para acessar o hospital onde o procedimento foi administrado.
- A função N1QL Window RANK é usada para atribuir um valor pela contagem do procedimento.
- A dica Hash Join é usada para melhorar o desempenho do documento JOIN.
Resumo
O Couchbase é adequado para a implementação da FHIR devido à abordagem que usa para armazenar os dados no formato JSON. Sua avançada linguagem de consulta N1QL permite que os desenvolvedores com experiência em SQL naveguem no modelo de dados FHIR para realizar todas as operações CRUD que os usuários esperam ver em um banco de dados.
Com sua capacidade de realizar JOIN de documentos para o processamento avançado de objetos de matriz incorporados, a linguagem de consulta N1QL relega todas as necessidades de processamento para o Couchbase Query and Indexing Service, reduzindo assim a carga dos aplicativos FHIR que precisam realizar todas as associações de objetos.
Como acontece com qualquer aplicativo novo, sempre haverá a necessidade de realizar exames diretos dos dados subjacentes, seja pelos administradores do aplicativo ou pelos analistas de dados que podem precisar realizar pesquisas além dos recursos básicos de pesquisa do FHIR.
No próximo blog, examinarei o que é necessário para usar o REST em uma abordagem de API FHIR que possa se comunicar com o servidor Couchbase para fornecer os recursos básicos de Requisitos de pesquisa FHIR.
Recursos
- Recurso rápido de interoperabilidade na área de saúde
- SyntheticMass: "Jason Walonoski, Mark Kramer, Joseph Nichols, Andre Quina, Chris Moesel, Dylan Hall, Carlton Duffett, Kudakwashe Dube, Thomas Gallagher, Scott McLachlan, Synthea: Uma abordagem, um método e um mecanismo de software para gerar pacientes sintéticos e o registro eletrônico de saúde sintético, Jornal da Associação Americana de Informática Médica, Volume 25, Edição 3, Março de 2018, Páginas 230-238, https://doi.org/10.1093/jamia/ocx079″
- Tutorial N1QL
- Parâmetros de pesquisa FHIR
