Resposta curta: um hospital utiliza dezenas de sistemas, e a integração é o trabalho de fazê-los concordar sobre um paciente. No centro encontra-se o HIS (sistema de informação hospitalar) ou EHR, que detém a identidade do paciente, as admissões e o registo clínico. À sua volta: o sistema do laboratório (LIS), radiologia (RIS e PACS), farmácia, bloco operatório, urgência, faturação, dispositivos (monitores, bombas de infusão), e cada vez mais aplicações para pacientes, dispositivos vestíveis e telemedicina. Um motor de interface no meio recebe, transforma e encaminha mensagens, de modo a que cada sistema seja conectado uma vez em vez de a todos os outros. O tráfego é maioritariamente composto por mensagens HL7 v2 sobre MLLP para eventos (admissões, pedidos, resultados), DICOM para imagens, CDA ou PDF para documentos, e FHIR sobre REST para tudo o que for novo, voltado para o paciente ou externo.
Os sistemas e o que eles trocam
O panorama de integração de um hospital é composto pelo HIS ou EHR, que detém a identidade do doente, os encontros e o registo clínico, mais o sistema de laboratório, radiologia (RIS e PACS), farmácia, dispositivos, aplicações de doentes, telemedicina e sistemas regionais. Eles trocam mensagens HL7 v2 como ADT, ordens e resultados ORU, imagens DICOM, documentos CDA e recursos FHIR.
| Sistema | Detém | Envia | Recebe |
|---|---|---|---|
| HIS / EHR | Identidade do paciente, episódios, pedidos, o registo clínico | ADT (admissões, transferências), pedidos ORM/OML, agendamento SIU | Resultados ORU, documentos MDM, cobranças DFT |
| LIS (laboratório) | Amostras, análises, resultados, intervalos de referência | Resultados ORU^R01, respostas de pedidos ORR | Pedidos ORM/OML, ADT para dados demográficos |
| RIS / PACS | Pedidos de imagem, listas de trabalho, relatórios, imagens | Relatórios ORU, DICOM para visualizadores, SIU | Pedidos ORM/OMI, ADT; DICOM MWL para modalidades |
| Farmácia | Formulário, dispensação, stock | Dispensação RDS, administração RAS | Pedidos de medicação OMP/RDE, ADT |
| Dispositivos e monitores | Sinais vitais, formas de onda, alarmes | Observações ORU^R01 (IHE PCD), proprietário | ADT para contexto do paciente |
| Portal do paciente / aplicações | Dados inseridos pelo paciente, acesso | Observações FHIR, questionários, mensagens | Leitura FHIR de resultados, consultas, documentos |
| Telemedicina | Consultas por vídeo, monitorização remota | Episódio FHIR, Observação, ReferênciaDocumento | Consulta, contexto do paciente, início SMART |
| Sistemas regionais e nacionais | Registos partilhados, registos, prescrição eletrónica | Documentos CDA (XDS), FHIR, mensagens nacionais | Consultas, notificações |
O motor de interface
Um motor de interface é o centro de mensagens do hospital: recebe tráfego HL7 v2, FHIR, ficheiros e bases de dados de cada sistema, transforma-o e encaminha-o para todos os outros sistemas que dele necessitam, e mantém filas, novas tentativas, monitorização e auditoria. Sem um, N sistemas necessitam de até N×(N−1)/2 interfaces construídas manualmente; com um, cada sistema liga-se uma vez.
O motor (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare e IRIS for Health, Infor Cloverleaf, Qvera QIE, entre outros) fornece listeners (MLLP, HTTP, ficheiro, base de dados), transformações (mapear campos, corrigir códigos, converter v2 para FHIR), roteamento (enviar um ADT para oito sistemas com oito filtros), filas e novas tentativas, monitorização e auditoria. É também onde a identidade do doente é reconciliada quando os sistemas discordam, e onde uma fachada FHIR é frequentemente construída sobre uma base de dados legada. Ver Motores de interface explicados.
Os fluxos mais importantes
Os fluxos de integração hospitalar mais importantes são ADT (admissões, altas, transferências e atualizações demográficas propagadas a partir do HIS), ordens e resultados entre o EHR e o laboratório ou radiologia, ordens de medicação e dispensação, documentos como cartas de alta, dados de dispositivos de monitores, e troca de resultados, consultas e medições domésticas orientadas para o doente via FHIR.
- ADT: cada admissão, alta, transferência, registo e atualização demográfica (A01, A03, A02, A04, A08, A40 merge) é transmitida do HIS para todos os outros. Se o ADT for tardio ou incorreto, cada sistema a jusante arquiva dados sob o paciente ou episódio errado. Ver Mensagens HL7 v2 explicadas.
- Pedidos e resultados: ORM/OML para fora, ORU de volta, com números de colocador e preenchedor a ligá-los; LOINC e UCUM nos resultados. Ver Mensagens de pedidos HL7 v2 e Integração de um sistema laboratorial com um EHR.
- Imagem: pedidos para o RIS, listas de trabalho DICOM para os scanners, imagens para o PACS, relatórios de volta como ORU, visualizadores através de DICOMweb. Ver PACS vs RIS vs VNA.
- Medicação: pedidos para a farmácia, dispensação e administração de volta, com o ciclo fechado (código de barras junto ao leito) como objetivo de segurança.
- Documentos: cartas de alta, notas operatórias e documentos digitalizados como mensagens MDM, CDA ou PDFs num repositório de documentos, publicados em registos regionais.
- Dispositivos: monitores a alimentar sinais vitais para o registo através de perfis IHE PCD ou gateways de fornecedor, com gestão de alarmes como disciplina separada.
- Voltado para o paciente: resultados, consultas e documentos para o portal e aplicações via FHIR; questionários, medições domésticas e dados de dispositivos vestíveis de volta, com proveniência a marcá-los como reportados pelo paciente. Ver Monitorização remota de pacientes com FHIR.
Padrões que funcionam
Padrões de integração hospitalar que funcionam são: um sistema mestre para a identidade do doente, com todos os outros a subscreverem ADT; mapeamento de códigos para LOINC, SNOMED CT e ATC uma vez no motor; acusações de receção, filas e novas tentativas para cada mensagem; resultados e documentos idempotentes; uma camada FHIR para aplicações de doentes e parceiros externos; e ambientes de teste com doentes sintéticos antes do go-live.
- Um mestre para a identidade. O HIS (ou um índice mestre de pacientes) detém os identificadores; todos os outros subscrevem o ADT e nunca criam pacientes.
- Códigos na fronteira. Mapear códigos locais para LOINC, SNOMED CT, ATC no motor, uma vez, e manter o código local ao lado.
- Acusar receção, enfileirar, tentar novamente. Cada mensagem v2 recebe um ACK; o motor persiste e reproduz; ninguém perde um resultado porque um sistema estava a reiniciar.
- Idempotência. Resultados e documentos transportam identificadores; uma reprodução atualiza em vez de duplicar.
- Uma camada FHIR para tudo o que é novo. Aplicações para pacientes, telemedicina, extratos de pesquisa e parceiros externos comunicam em FHIR com uma fachada ou um servidor FHIR dedicado alimentado pelos fluxos internos, em vez de diretamente com o HIS.
- Ambientes de teste com pacientes sintéticos, e uma etapa de conformidade (perfis IHE Connectathon, conjuntos de testes nacionais) antes que algo toque na produção.
Modos de falha vistos em todo o lado
Os modos de falha vistos em quase todas as integrações hospitalares são doentes duplicados devido a erros de digitação no registo, resultados arquivados no encontro errado após uma fusão, códigos locais não mapeados, erros de fuso horário e horário de verão em carimbos de data/hora, unidades em texto livre, interfaces que param silenciosamente sem monitorização, segmentos Z de fornecedores que quebram parsers, e feeds CSV temporários que nunca são descontinuados.
Pacientes duplicados devido a erros de digitação no registo; resultados arquivados no episódio errado após uma fusão; códigos de teste locais que ninguém mapeou; fusos horários e horário de verão nos carimbos de data/hora das mensagens; unidades em texto livre; uma interface que parou silenciosamente e ninguém monitorizou; segmentos Z específicos do fornecedor que quebram os analisadores; e o feed CSV "temporário" que ainda está a funcionar dez anos depois.
Onde o FHIR está a mudar o cenário
O FHIR está a mudar a integração hospitalar nas margens em vez do núcleo. Dentro do edifício, HL7 v2 e DICOM permanecem porque analisadores, scanners e módulos legados falam-nos; o FHIR assume o acesso do doente, aplicações SMART on FHIR, suporte à decisão CDS Hooks, Subscrições, intercâmbio regional e nacional sob o EHDS e TEFCA, e extratos de investigação.
Internamente, HL7 v2 e DICOM permanecem durante anos, porque todos os analisadores, scanners e módulos legados os utilizam. O FHIR vence nas bordas: acesso do paciente, aplicações iniciadas dentro do EHR (SMART on FHIR), suporte à decisão (CDS Hooks), subscrições para integração orientada a eventos, intercâmbio regional e nacional sob o EHDS e TEFCA, e extratos de pesquisa. Muitos hospitais executam agora um servidor FHIR alimentado pelo motor como a sua camada de integração para tudo o que está fora do edifício; ver Padrões de interoperabilidade em saúde: o mapa.
Em Anpheros
A Plataforma Anpheros situa-se na margem FHIR da integração hospitalar: um registo FHIR R4 para o qual um hospital ou clínica pode escrever e do qual pode ler com o consentimento do doente, alimentado pela própria integração do hospital através do conector de laboratório (HL7 v2 ORU, CSV ou JSON), com webhooks e proveniência por fonte. Não substitui o HIS nem o motor.
A Plataforma Anpheros situa-se nessa borda: um registo FHIR R4 para o qual um hospital ou clínica pode escrever e ler com o consentimento do paciente, alimentado pela própria integração do hospital (o conector de laboratório recebe HL7 v2 ORU, CSV ou JSON), com webhooks para notificação de alterações e proveniência por fonte. Não substitui o HIS ou o motor; dá ao paciente um registo que o acompanha fora do edifício.
Páginas relacionadas
- Motores de interface explicados
- Como integrar um sistema laboratorial com um EHR
- Mensagens HL7 v2 explicadas: ADT e ORU
- PACS vs RIS vs VNA
- Monitorização remota de pacientes com FHIR
- Padrões de interoperabilidade em saúde: o mapa
- Integrar sistemas clínicos com FHIR (site para programadores)
Fontes
- Suite de produtos HL7 Version 2
- Framework técnico IHE IT Infrastructure
- Domínio IHE Devices (perfis Patient Care Device)
- HL7 FHIR R4: Messaging and workflow
- Guia de implementação HL7 v2 para FHIR
Perguntas frequentes
Um novo hospital deve integrar tudo com FHIR?
Não tudo. Analisadores, scanners e a maioria dos sistemas departamentais utilizam HL7 v2 e DICOM, e isso não mudará em breve. Utilize FHIR para integrações voltadas para o paciente, externas e novas, e um motor para fazer a ponte.
Qual é a diferença entre um HIS e um EHR?
O uso varia por país. HIS refere-se frequentemente ao sistema hospitalar administrativo e clínico em conjunto; EHR enfatiza o registo clínico. Em termos de integração, ambos são o sistema que detém a identidade, os episódios e o registo.
Quantas interfaces tem um hospital de média dimensão?
Tipicamente entre cinquenta e algumas centenas de fluxos de mensagens através do motor, contando cada direção e cada sistema recetor. O ecrã de monitorização do motor é onde as equipas de integração trabalham.
Quem é responsável pela integração num hospital?
A equipa de integração de TI do hospital, geralmente com o apoio do fornecedor do motor, e cada fornecedor departamental pelo seu lado. Programas nacionais e perfis IHE reduzem, mas não eliminam o trabalho do projeto.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →