HL7 - V2.x | FHIR | V3-RIM | CDA

Integração de Sistemas com Padrões HL7®
InterOpera | improve the world’s healthcare
Paulo R. Rades, InterOpera
HL7® Brasil
Esta apresentação está disponível para download em:
www.interopera.esy.es/gs_hl7/hl7_global.pdf
Todas as marcas são de seus respectivos proprietários. HL7®, FHIR® e Flame são marcas registradas da HL7® International, Inc. 1

Agenda
1. Arquitetura de Sistemas de Informação Hospitalar
2. Interoperabilidade & Integração em Saúde
3. Necessidade da padronização de dados em Saúde
4. Organização HL7
5. Padrões: HL7 V2.x | FHIR | V3-RIM | CDA R2
6. Canal Youtube InterOpera com demonstrações práticas
INTEROPERA
COSULTORIA | CAPACITAÇÃO | DESENVOLVIMENTO 2

Sobre Mim
Formação
• Em Computação e Gestão Hospitalar
• Especializações em Sistemas de Informação, Informática em Saúde, Padrões
• Extensões Informática Biomédica, Docência, Pesquisa e Desenvolvimento
• Certificações: HL7 V2, cpTICS, MCSA, CCNA
Trabalhos Voluntários
• Ex-Secretário Geral HL7 Brasil (2014 a 2017)
• Gestão de conteúdo e sustentação websites
• HL7 Brasil, SBIS, FHIR, openEHR
Profissionalmente
• Fornece treinamentos, workshops, palestras, cursos, consultoria em projetos de integração
e interoperabilidade com padrões HL7 e openEHR
3
Paulo Rogério Rades
radespaulo@gmail.com
Skype: paulorades

Arquitetura de Sistemas de Informação Hospitalar
Contextualização
HIS – Hospital Information System
4
Sistemas Clínicos
ADM
FIN
RH
HOT
PEP LAB
FAR RAD
CAMADAS

Como foram construídos os HIS
A ENGENHARIA DE SISTEMAS HOSPITALARES NÃO IMPLEMENTA UMA CAMADA
DE SERVIÇOS DE COMUNICAÇÃO
5
GUI
REGRAS E
LOGICAS
ARMAZENA
MENTO
ILHAS DE DADOS DIGITAIS
NÃO AGREGAM VALOR
B
A
R
R
E
I
R
A
S
Esquemas Proprietários

Arquitetura dos HIS – Era monolítica
A ENGENHARIA DE SISTEMAS NÃO IMPLEMENTA UMA CAMADA DE SERVIÇOS
DE COMUNICAÇÃO
6
GUI
REGRAS DE
NEGÓCIOS E
LOGICAS
ARMAZENA
MENTO
Silos de Dados – Era Monolítica
INSATISFAÇÃO DOS USUÁRIOS

Como resolver o acesso aos ‘silos de dados’ ?
1 - IMPLEMENTANDO O HL7 V2 PARA ‘ABRIR’ OS SILOS DE DADOS DOS EHRS
7
GUI
REGRAS E
LOGICAS
ARMAZENA
MENTO
DADOS PROPRIETÁRIOS
NÃO AGREGAM VALOR
H
L
7
V
2
ORM
Ad-hoc
Ad-hoc
Artigo: HL7™ INTERFACES PONTO-A-PONTO OU MOTOR DE INTEGRAÇÃO?

2 - IMPLEMENTANDO PADRÕES MÉDICOS PARA E-SAUDE E MOTORES DE INTEGRAÇÃO
8
GUI
REGRAS E
LOGICAS
ARMAZENA
MENTO
ILHAS DE
DADOS
DIGITAIS
NÃO AGREGAM
VALOR
E
S
B
HTTP
V2.x | FHIR | V3-CDA
SOAP
DICOM
APPS/
SIS/
APPS
E
X
T
E
R
N
O
S
openEHR

3 - IMPLEMENTANDO O HL7 FHIR PARA ABRIR OS SILOS DE DADOS DOS EHRS
9
GUI
REGRAS E
LOGICAS
ARMAZENA
MENTO
ILHAS DE DADOS DIGITAIS
NÃO AGREGAM VALOR
F
H
I
R
FHIR
APIs
SERVIÇOS DE COMUNICAÇÃO E
ESTRUTURAÇÃO DE DADOS

HL7™ International e os PADRÕES HL7™
HL7™ VERSÃO 2.X
HL7 ™ FHIR ™ (STU-3 e R4)
V3 RIM - CDA™
HL7 BRASIL 10

HL7™ | HEALTH LEVEL SEVEN
HL7™ SE REFERE A ORGANIZAÇÃO (SDO) | http://www.HL7.org
• Origem do nome: emprestado do modelo ISO-OSI (por atuar na 7ª camada do modelo – camada de aplicação)
• Padrões HL7™ são: V2.X, V3-RIM™, CDA™, FHIR™, e outros
• Missão: desenvolvimento, manutenção e promoção de padrões médicos para e-saúde
• Desenvolvidos: em consenso através dos WG (organizados em Comitês)
• Representada pelo Instituto HL7™ no Brasil (Dr. Marivan Abrahão, Dr. Renato Sabbatini) | http://www.HL7.org.br
HL7™ E SEUS PADRÕES NÃO SÃO
 SOFTWARES
 HARDWARES
 SERVIÇOS
 PLUG-AND-PLAY (apesar de o FHIR ter esta proposta)
Os padrões da HL7™ International são especificações que orientam em como estruturar
logicamente dados eletrônicos em saúde para seu intercâmbio
Leia mais: O HL7
11

Dr. EdHammond
Fundador HL7International (1987)
Foto do ConselhoHL7emAgosto de1992.
Frente (esquerdapara direita): Phil Bartleson, EdHammond, SueCampbell, DaveCarlson,JohnQuinn.
Atrás: Philip Caillouet, WesRishel,Mike Glickman, David Kates,Mark McDougall.
© 2015 Health Level Seven ® International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. TM Office.

HL7´s no MEDINFO 2015 - SP

O que é o padrão HL7™ v2.x?
• Éo padrão de mensagens em saúdequesefazpresenteemMonitoresdeSV,RedesDICOM,Laboratóriose até
mesmoemseuhospital– sevocêtemMS,háumagrandechance!–consulte-nossobrecomoos integramos
 V2.x é o mais implementado globalmente:V3semsucesso(rígido)eFHIR(1a.normativaJan/19–novas implementações)
• Padroniza:
 Estrutura dasmensagense ostipos de dados
o É um grandedocumentoorganizadoem capítulos
 Codificação dasMensagens
o ER7(pipes ou|)
o XML
 Comunicação
o MLLP:recomendado por ser maiseficiente
o HTTP:utilizado quando não é possível MLLP
 Especificaqueoenviodasmensagensocorrem ápartir de um TriggerEvent(eventodedisparo)
 Fluxo de dados:Ao receber uma mensageme validá-la, respondemos com um ACKouNOACK

Organização das regras HL7 V2.x
Capítulos:Contem asregras, sintaxe abstrata dasmensagens e segmentos
Tabelas:Contém os data-values definidos pelo padrão. Osvalores pode ser localmente definidos
Apêndices:Definição de dados, protocolos de baixo nível,glossários
Explorem os capítulos,
tabelas, dicionários e
data-types
Fonte: Website VICO

Fluxo de Mensagens HL7
Triggerevent
Send
HL7message
Receive
HL7-ACK
SystemA
Receive
HL7message
SendHL7-ACK
SystemB
ACK – mensagem foi validada com sucesso – segue o fluxo
NOACK – mensagem com algum problema – interrompe o fluxo

HL7® V2.X (ER7)
HL7® FHIR ® (JSON)
Formatos HL7® Messages
HL7® V3 (XML)
17

Regras HL7 V2.x – Parte I
• As normas v2.x são compatíveis: aplicações construídas em versões maiores devem
suportar versões menores.
• Mensagens HL7 v2.x são escritas em (ASCII) e não em (XML).
• O tipo da mensagem especifica o grupo de segmentos válidos para sua construção.
• A V2 é baseada em segmentos (linhas) e delimitadores de caracteres.
• Segmentos são formados por campos e separados por ‘delimitadores’ especificados pela
norma V2.x
• Evite utilizar Segmentos do Tipo ‘Z’ (estendem o padrão..)
• Qualquer tipo de mensagem pode ter múltiplos eventos de disparo.
• Um evento de disparo está associado a somente um tipo de mensagem
Artigo: Padrões HL7®: Processo de Implementação, Desafios e Soluções 18

VICO | On-Line – Ferramenta ON-LINE para consulta aos capítulos HL7 V2.x
http://www.vico.org/HL7_V2_5/v251/std251/ch02.html
© 2017 Health Level Seven ® International. All Rights Reserved. HL7 and Health Level Seven are registered trademarks of Health Level Seven International.Reg. U.S. TM Office.

Caristix Definition | On-Line
http://hl7-definition.caristix.com:9010/

HL7 SOUP – permite escrever, validar, enviar e receber mensagens HL7 v2.x (comercial)
21

Alguns dos domínios atendidos pelo HL7
•Registrode Pacientes(PMI / PAS)
•Ordense Resultados(clinicas e logisticas)
•Consultas
•ContasMédicas (Faturamento)
•Arquivos Máster e de Índices (Pacientes,Staff)
•Controle de documentos (Sumários,Laudos,NotasEvolução)
•Agendamento e Logística(exames)
•Administração de Pessoal(intervenção sobre o paciente)
•Planosde Cuidados
•Sincronizaçãode Rede
•Automação Laboratorial
•Genomica
•Farmácia

Cardinalidade e Codificação das Mensagens
CodificaçãodasMensagens: ER7
MSH|^~&|SRC_APP|SRC_CNTR|TARGET_APP|TARGET_CNTR|201401271408||ADTÂ04ÂDT_A01|123456|T|2.5
EVN|A04|199912271300
PID|||PATID||RADES^PAULO||19700121|M|||1233 BARREIRO^^São Paulo^Brasil^11300^BR||(11)123-4567
PV1||O|BOX 1^^^DEPTO. EMERGENCIA^^ÊDIFICIO CENTRAL||||123^HOUSE^GREGORY
Aprofunde-se: HL7 PRIME – Anatomia das Mensagens HL7 v2

Codificação das Mensagens – V2 ER7
SegmentID
MSHMessageHeader
EVNEventType
PID Patient VisitInformation
AL1 Patient Allergy
Information
DG1Diagnosis
PR1 Procedures
Campos:contêminformaçõessobreopaciente,
eventoGerador,alergias,etceteras

Codificação das Mensagens V2 XML
• Engines como Mirth Connect transformaminternamente ER7emXML
• Como HAPITESTPANELpodemos ver ambascodificações
<ADT_A01xmlns="urn:hl7-org:v2xml">

Segmentos das Mensagens
• Sãoblocos de dados formados porcampos
 EmER7é um por linha e finalizados com o caractere “r” (ASCII13)<cr>
• IDSegmento: formado por 3caracteres
 MSH:cabeçalho da mensagem
 EVN:evento agendado ou ocorrido
 PID:identificação do paciente
 PV1:visita / consulta
 TQ1:especificação de tempos e frequências
 NTE:notas e/oucomentarios
 OBX:observação / resultado
 MSA:confirmação (acknowledgement)
 ERR:especificação de erro noACK
• Utilize a notação de índices para identificar oscampos dos segmentos
 MSH-1,MSH-2, MSH-3,MSH-9.1, MSH-9.2, .........
 Podemosvisualizar pelo HAPITESTPANEL– experimente!

Tipos de Mensagens Presentes nas Implementações
• ADT: Admissão,Alta, Transferência(Cap. 3)
 Informação sobre do paciente para uma consulta médica ou internação, para termina-la (alta) ou transferir o
paciente entre distintos serviços desaúde.
• ORM:MensagensdeOrdensGerais(Cap. 4)
 Ordem de execução ou solicitação de serviços e insumos para o paciente: estudos laoratoriais ou de imagens ,
prescrição de medicamentos, etc.
• ORU:Mensagemde Resultados(Cap. 7)
 Resultado dasobservações realizadas para uma ordem enviada anteriormente; Resultadosde um estudo
laboratorial.
• ACK:Mensagemde Confirmação(Cap. 2)
 Sãoenviados em resposta arecepção de mensagens para informar ao sistema emisor que amensagemfoi recibida
con êxito, ou para informar sobre algum erro na mensagem, ex. um campo obrigatório que tenha sido recebido
semum valor.

Trigger Events | Eventos de Disparo
• AsmensagenssãoenviadasquandoocorremosTriggerEvents
• Ex.para o tipo de mensagemADTsãodefinidos oseventos:
 A01:Admissão de Paciente
 A02: Transferenciade Paciente
 A03:Alta de Paciente
 A04: Registro de Paciente
 A05: Pre-admissão de Paciente
 A08:Atualización de dados do Paciente
 ...
1. O evento de disparo pode modificar aestrutura de uma mensagemdo mesmo tipo
2. O evento de disparo está no mesmo campo do tipo da mensagem: MSH-9
• Podemosutilizar o tipo damensageme evento para filtrar ou rotearmensagens
 Ex.temos 2 sistemas que recebem asmensagens em um sóponto de entrada
MSH|^~&|EPIC|EPICADT|SMS|SMSADT|201712271408||ADTÂ04|1817457|D|2.5|
PID||0493575^^^2ÎD 1|454721||BOWIE^DAVID^^^^|BOWIE^MOTHER^^^^|19580203|M||B|254 MYSTREET...
NK1||BOWIE^MARIE^^^^|SPO||(216)123-4567||EC|||||||||||||||||||||||||||
PV1||O|168 ~219~C~PMA||||277ÂLLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684...--

Encondig Characteres
• Osdelimitadores especificados pelo padrão (ENCONDINGCHARACTERS)
 EstãonosegmentoMSH
• Separadordecampo:|
• Separadordecomponente:^
• Separadorderepetições:~
• Caracteredeescape:
• SeparadordeSubcomponentes:&
• TerminadordeSegmento:<cr>
NOTA:Um campo composto é formado por subcomponentes e separadospelo delimitador de
sub-componentes, que ainda podem ter sub-sub-componentes.
MSH ^~&

Regras para Escrita das Mensagens – [2]
• Oprimeiro campo de cadasegmento é asuaidentificação – ID: 3caracteres.
 Cadasegmento contém uma categoria específica de informações.
• Todamensagemobrigatoriamente deve ter umcabeçalho:
 O primeiro segmento de toda mensagem HL7 V2.x é o MSH (message header) que inclui um campo
para identificar o tipo de mensagem.O MSHé obrigatório!
• O tipo da mensagemdetermina os tipos de segmentos esperados
Ossegmentos para o tipo da mensageméespecificado pela notação de gramática definida nasnormas
HL7(SintaxeAbstrata da Mensagem – Capítulo 2)

Sintaxe Abstrata das Mensagens V2
Segments Description
MSH Message Header
[{ SFT }] Software Segment
{ UAC } User Authentication
EVN Event Type
PID Patient Identification
[PD1] Additional Demographics
[{ ARV }] Access Restrictions
[{ ROL }] Role
[ { NK1 } ] Next of Kin /Associated Parties
PV1 Patient Visit
[ PV2 ] Patient Visit - Additional Info.
[ { ARV } ] Access Restriction
[ { ROL } ] Role
[ { DB1 } ] Disability Information
[ { OBX } ] Observation/Result
[ { AL1 } ] Allergy Information
[ { DG1 } ] Diagnosis Information
[ DRG ] Diagnosis Related Group
[ { --- PROCEDURE begin
PR1 Procedures
[{ROL}] Role
} ] --- PROCEDURE end
[ { GT1 } ] Guarantor
[ { --- INSURANCE begin
IN1 Insurance
[ IN2 ] Insurance Additional Info.
[ {IN3} ] Insurance Additional Info. - Cert.
[ {ROL} ] Role
} ] --- INSURANCE end
[ { ACC } ] Accident Information
[ { UB1 } ] Universal Bill Information
[] Opcional, ex. [AL1]Allergy
segmentoopcional
{} Repetitvo, e.g.
{AL1}repetitivo se necssário
Sem{} ou [] = Obrigatório
OsSegmentos obedecemauma ordem
específica definidopelotipo damensagem

Tabela de Definição de Segmentos
MSH|^~&|MODULAB|1|INTEROPERA|1|20181001093245||ORU^R01^ORU_R01|113445|P|2.5
Sequencia Valor OPT Detalhes
0 R SegmentID=MSH
1 (SeparadordeCampo) | R Sempreé contado como um campo noMSH
2 (encoding characters) ^~& R
3Aplicaçãodeenvio MODULAB O
4 SendingFacility 1
5 ReceivingApplication INTEROPERA
6 ReceivingFacility 1
7 Date Time of Mess 20181001093245
8 Security [empty]
MSH9 ORU^R01^ORU_R01 MessageTypeADT& Trigger EventR01
10 MessageControl ID 113445
11 ProcessingID P
12 VersionID 2.5 Versãodo HL7
ID 0 1 2 3

Tipos de Mensagens Mais Encontradas
The HL7 Version 2.5 Standard Copyright©2003 by Health Level Seven, Inc.

Tipos de Dados Comumente Utilizados
The HL7 Version 2.5 Standard Copyright©2003 by Health Level Seven, Inc.

De onde partem as mensagens HL7 ADT?
(GERENCIAMENTO DO PACIENTE)
HIS
Asmensagens sãoenviadaspara ossistemas auxiliares para update de suasbasesde
dados com informações atualizadas ápartir do HIS
Sempre á partir do sistema principal !

Protocolos
• MLLP: Minimal Lower LayerProtocol
 utilizado para transportar asmensagensHL7v2.x
• alta performance, ébasicamenteo TCP
• Atuana 6ª camadado modelo ISO-OSI
• permite processarasmensagenscom maior facilidade (permite
queidentifiquemos
exatamentequando começame terminamasmensagens)
 separadores das mensagens sobreTCP
• <SB>Start Block(ASCII 11)
• MensagemHL7
• <EB>End Block (ASCII28)
• <CR>CarriageReturn (ASCII13)
• HL7v2.x overMLLP
<SB>
MSH|^~&|A|B|C|D|199605141144||ADT^A01|20171104082400|P|2.3<CR>
EVN|A01|20031104082400.0000+0100|20031104082400<CR>
PID||""|10||Vries^Danny^D.^^de||19951202|M|<CR>
PV1||N|<CR>
<EB><CR>

Exemplo
ADT^A04
HIS
LIS
FaturamentoACK
Recepção
FTP
JDBC
Tipo de evento de disparo
da mensagem
MLLP
Radiologia
Leia: Estrutura das Mensagens de ADT

Estrutura versus Perfil da Mensagem
Definido pelo padrão
Definido pelasnecessidades

IHE – INTEGRATING HEALTHCARE ENTERPRISE
• Promover o uso coordenado de padrões estabelecidos, como o
DICOM e o HL7, para atender necessidades clínicas específicas em
apoio ao ideal atendimento ao paciente.
• Sistemas desenvolvidos de acordo com o IHE comunicam-se melhor
entre si, são mais fáceis de implementar e permite que os prestadores
de cuidados usem as informações de maneira eficaz.
TF (Technical frameworks) Harmonizam e eliminam a variabilidade das
implementações
• São um conjunto de regras a serem seguidas pelos implementadores
40

GUIAS DE IMPLEMENTAÇÃO
As IGs (Implementation Guides) são documentos que descrevem como implementar o padrão, mensagens e/ou
perfis das mensagens nos sistemas.
 Definidas pelo HL7
 Níveis municipais, estaduais e federais
 Projeto
 Sistema

Exemplo Perfil Mensagem: ADT_A01
Admissão de Paciente - internação
MSH|^~&|APP-REMOTA|FAC-
REMOTO|AXREG|ANESTECH|201705231005||ADTÂ01ÂDT_A01|201705230000001|P|2.5.1|||AL|
EVN|A01|20170523000005|
PID|1|MRN|PAT_ID^^ÂUTOR^MR~371669256^^ÛSSSA^SS||MARINO^CACIQUE^R^SR.||19700121|M||2106-
3|R.RIOGRANDEDOSUL,590^SAO
PAULO^SP^BRASIL||1142261237|||A|AGN|CONTAPACIENTE|11988732885|707002881370235||H|
NK1|1|RADESÂNA^L^SRA.|BRO|RUADASAUDE,123^SAOPAULO^SAO
PAULO^SP^09010020|01234567890||N||||||||||||||||||||||||||12312312399|
PV1|1|I||C|||777777^CHEFE^CIRUGIAO|11888732881|SP|SUR|||||||||||||||||||||||||||||||||||||||||V
|
PV1|2|I||C|||888888^CHEFEÂNESTESISTA|11988732881|SP||ANE|RQE|||||||||||||||||||||||||||1198837
4372|||||||||||V|
DG1|1||550.90|HERNIAINGUINALUNILAT|201704150100|F|
Admissão de PacienteA01:ocorre quando o médico opta por umainternação.
Uma internação é considerada quando a permanência do pacientena unidade
hospitalarfor superior a 24horase um leito necessariamentedeveser disponibilizado
para os cuidadossobreeste.

Exemplo Perfil Mensagem: ADT_A04
Registro de Paciente
MSH|^~&|HL7Soup|Instance1|HL7Soup|Instance2|201607271408||ADTÂ04|1817456|D|2.5.1|1
23456|
EVN|A04|1817456|
PID||0797675|454721||Brown^Sam^^^^^B|Smith^Mary^^^^|19780203|M||2106-3|254East
St^^HowickÔH^3252ÛSA||(216)671-4859|||S|AGN|400003603~1629086|999-8888|
NK1||Brown^Mary^^^^|MTH||(216)891-3459||EC|
PV1||O|O/R|A|||060277Âllen^Katrina^J^^^|||||||||| ||2668684|||||||||||||||||||||||||20
1407271408|
A04 – Registro dePaciente
Estetipo de mensagemserve para informar aossistemassecundários que um
pacienteaguarda por atendimento na unidade;
Consulta | Urgência | Retorno | Exames
Pode ser usada para elegibilidade do paciente para o atendimento e exames

Exemplo Perfil Mensagem: ACK
Asmensagens deACK(confirmação) devem ser enviadas como resposta ao sistema
emissor para que o fluxo de mensagens possaser contínuo e para notificação de erros.
Message ID
MSH|^~&|HL7Soup|Instance1|HL7Soup|Instance2|20170708231324||ACK^A01|0000001|P|2.5.1|
MSA|AA|0000001|
Message ID(MSH-10)
CódigoACK
MSH|^~&|HL7Soup|Instance1|HL7Soup|Instance2|20170708231827||ACK^A04|0000002|P|2.5.1|
MSA|AA|0000002|
Message ID(MSH-10)
CódigoACK

Exemplo Perfil Mensagem: NOACK
MSA-1 =Statusmensagem
AA –ApplicationAccept
AE –Application Error
AR –Application Reject
MSA-2 =Message ID MSH-10
MSH|^~&|NewSys||HIS|MCM|20061117155436||ACKÂ01ÂCK|0001|P|2.5.1|||NE
MSA|AE|0001
ERR|PV1_PatientVisitSegment^1^2^103&Table valuenot found&HL7nnnn
ERR|DRG_DiagnosisRelatedGroupSegment^1^11ûnexpecteddata found
MSH|^~&|NewSys||HIS|MCM|20061117155436||ACKÂ01ÂCK|0001|P|2.5.1|||NE
MSA|AR|0001
ERR|MSH_MessageControlId^1^2^103&DulicatedKey&MessageControlI
Aprofunde-se: HL7 PRIME Mensagens de ACK

MSH|^~&|HL7Soup|Instance1|HL7Soup|Instance2|20170709001351||ACK^O01|0000004|P|2.5.1|
MSA|AA|0000004|
MSH|^~&|HL7Soup|Instance1|HL7Soup|Instance2|20161027192020||ORM^O01|MSGID001|P|2.5.1
PID||81243|12006||ALVAREZ^D.PEDRO^DPA^^SR.||19650610|M|||RuaALAGOS,230^São
Paulo^SP^09510021^BR|||||||
PV1||E|MED^402^||||2342^Jones^Bob|||MED|||||||||2|||||||||||||||||||||||||20161027192020|
ORC|NW|20161027192020|
OBR|1|20161027192020||58410-2^HEMOGRAMA COMPLETO^LN|||20161027192018
Exemplo Perfil Mensagem:ORM_O01
HEMOGRAMA COMPLETO (ESTUDOSLABORATORIAIS)

ESTUDOS CLÍNICOS: HEMOGRAMACOMPLETO - LOINC
https://s.details.loinc.org/LOINC/58410-2.html?sections=Comprehensive

EVITAR O USO: Segmentos Z - ZPM

Esta é home page do HAPI. (interface de programação de aplicativos HL7, é um
analisador HL7 2.x código aberto e orientado a objetos Java. PARA O DEV
https://hapifhir.github.io/hapi-hl7v2/

DICAS
• Tabelasde Referência
• Data-types
• Tipos de mensagens
• Eventosde Disparo
• Estrutura dasmensagens
• CódigosdeReconhecimento
Aprofunde-se
no
Capítulo2
PRATIQUE
ACOMPANHE
FHIRGOOGLE
LINKEDIN
TWITTER
G+

QUIZZ
Teste seu HL7 v2.X no nível básico através deste QUIZZ

Fast Healthcare Interoperability Resources

Com tantos padrões, porquê o FHIR®?
1. HL7 V2.x é amplamente utilizado, porém arcaico... para as problemáticas atuais
2. Parte do fracasso do V3 é atribuído a sua complexidade: IMPÕE MODELO RÍGIDO (V3 RIM)
O FHIR se concentra no mais importante para os DEVS: FACILIDADES DE IMPLEMENTAÇÃO
 Suporte para casos de uso modernos e comuns
 Especificação amigável para o DEV
 Reaproveitamento de tecnologias Web (já utilizadas por diferentes industrias)
 Legibilidade humana como nível básico de interoperabilidade: facilita resolução de problemas/testes
 Conteúdo on-line e gratuito
 Bibliotecas e Projetos para diferentes linguagens e arquiteturas
 Comunidade real-time de fácil acesso (https://chat.fhir.org)
 Encontros presenciais: Conectathons, RoundTables, DEVDAYS, WGM
53

HL7® FHIR® |UMA ESPECIFICAÇÃO INCLUSIVA
• Clínicos e Analistas de Negócios: Modelagem recursos (ClinFhir / Simpliflier.Net)
• Engenheiros/Arquitetos: Arquitetura e Design
• Executivos: Inovação, tendências e preparada para o futuro da interoperabilidade
• Implementadores Projetos de Referência, IG´s
• Desenvolvedores HAPI FHIR® java opensource reference library
54

Onde obter suporte
• FHIR™ Foundation (comunidade fechada de implementadores)
• Forum FHIR Community (comunidade publica de implementadores)
• FHIR Chat Channels (comunidade real-time de implementadores)
• InterOpera (consultoria, cursos e treinamentos)
• HL7™ Brasil (governança, workshops, palestras e cursos internacionais)
@interopera 2018 55

Iniciando com o FHIR®
MODELO DE DADOS: RECURSOS
• São blocos flexíveis e peça-chave para construção do modelo de informação
• análogos aos segmentos V2 e os CMETs V3 (restrições sobre o V3-RIM)
• Representam conceitos do mundo real em saúde (pacientes, medicações, observações, alergias)
• + 118 recursos na R4 (outros em construção)
• 06 categorias: clínicos, identificação, fluxo de trabalho, conformidade, financeiro e infraestrutura
• Todo recurso é definido por um ‘StructureDefinition’, variando tipo e conteúdo:
• Ex: Patient, Medication, Observation
As soluções FHIR® são construídas através dos "Recursos” que facilmente são disponibilizados para solucionar problemas
clínicos e administrativos do mundo real a uma fração do preço das alternativas existentes
56

Structure Definition
Define cardinalidades, repetições,
condicionalidades,
opcionalidades, atributos, sistemas de
codificação, etc..
57

Sessões do Recurso FHIR
58
Extensions
Única Sessão Opcional
3 sessões obrigatórias
1 opcional (caso use extensões)

MODELO DE DADOS FHIR
• Data-Types: tipo de dados dos elementos dos recursos
• Primitivos: sexo, idade, string
• Complexos: OID, Identificadores, Sistemas de Códigos
• Especiais: Referências, Narrativas, Meta, Dosagem
• Perfil: usados para definir os elementos em recursos individuais, Bundle, perfil e/ou uma IG´s
• Guias de Implementação: usadas como referência para implementações a nível regional, nacional,
em determinado projeto
• Extensões: adicionam elementos não especificados como comuns no núcleo dos recursos (Regra 80x20).
Não são artefatos negativos no FHIR, mas sim, IMPORTANTES e as utilizamos para tudo....
59

EXTENSÕES
Simples de usar no FHIR (V2 – segmentos Z / V3 – namespaces)
60
Local onde está a descrição sobre como utilizar a extensão
Chave par/valor

Formatos para os Recursos
SESSÕES OBRIGATÓRIAS
61

XML JSON
SERIALIZAÇÃO DE RECURSOS NO FHIR®
62

Referência entre Recursos
Fonte: Fhir Drills
63Recurso Patient no centro do modelo

Identificadores no FHIR
• Todo recurso possui seu próprio ID atribuído pelo servidor onde está sendo
gerado
• análogo à chave primária em um banco de dados. No FHIR é chamado de Business “ID”
• GET [endpoint]/Patient/3590324
• Não confundir o identificador do recurso com os identificadores do paciente
(MRN, ID interno, CNS, etc)
• GET [endpoint]/Patient?Identifier=1045813
Aprofunde-se com este artigo: Trabalhando com Id´s no FHIR
64

ID PARA ESTE RECURSO PATIENT
IDENTIFICADOR DO PACIENTE
Metadata
Conteúdo
Estruturado
65

Conformidade no FHIR
• A especificação base do FHIR define como uma implementação válida
deve ser.
• As Guias de Implementação (IGs) baseiam-se na especificação base
para definir um conjunto de regras adicionais.
• Estão disponíveis validadores para recursos, perfis, construção das
IGs...
66

É seguro desenvolver para FHIR?
• Sim.
 A versão R4 publicada em Jan/2019 é normativa.
Mesmo em Trial for Use, as implementações FHIR já superam novas implementações
V2.x e CDA
• Riscos.
Poucos recursos ainda não atingiram nível de maturidade 5
Caso ocorra alteração em StructureDefinition necessário adequar
67

RELEASES FHIR
• A versão atual da especificação FHIR é o R4 (roadmap de releases a cada 2 anos)
• A primeira normativa R4 foi publicada em JAN/2019
• Mais de 90% dos implementadores contribuíram durante a votação
• Em caso de divergências entre implementações, devemos usar a especificação
atual como válida
• Manter-se atualizado sobre a especificação é fundamental e inteligente (evitar retrabalho)
• O nível de maturidade dos recursos orientam sobre possíveis modificações
estruturais (de 1 a 5, sendo 5, bloqueado para alterações)
68

Release R4
FHIR® Release 4 Candidate (v3.6.0-d4d5de9f) generated on Mon, Sep 10, 2018 06:13+0000
Documentação
Implementadores
Conceitos
Recursos
Bibliotecas
Sistemas de Medida
69
https://www.hl7.org/fhir/

AVANÇOS E BENEFÍCIOS COM FHIR
• APIS RESTFUL: eliminam o uso de delimitadores incomuns: pipe (v2) e ‘envelopes’ SOAP (v3)
• Reduz barreiras: para os não familiarizados com padrões para saúde (v2) pois implementa
padrões web modernos conhecidos pelos ‘web devs’ e usuários (Json, XML, Oauth, Rest, SSO, openID)
• JSON e XML: oferece suporte mais fácil para comunicação entre servidores e apps mobiles
(clients)
• JSON: oferece melhor desempenho para mobiles (memória e processamento limitados). Estamos
acompanhando a substituição do IHE-XDS (SOAP/XML) pelo IHE-MHD (acesso móvel a docs médicos)
• Documentação e Ferramentas: são amigáveis para o implementador e desenvolvedor
O FHIR® não substituirá o V2 (por décadas) porém os fornecedores o estão implementando em
seus sistemas (sob risco de perder clientes).
‘Os hospitais ‘sentem’ o valor agregado da implementação de API´s....’
70

Ex: http://localhost:6061/fhir/Patient/1
Business Identifier
71

72
Padrões WEB
conhecidos
pelos DEVS
como HTTP,
SSO, openID

PARADIGMAS DE INTEROPERABILIDADE
4 paradigmas de interoperabilidade
As implementações são capazes de realizarem a portabilidade entre paradigmas
sem prejuízo ao conteúdo intercambiado.
73
SOAP
CDAHTTP
V2.x

Padrões Arquitetônicos para FHIR®
Interoperability Interface
+ encontrada 2018Q1
FHIR Broker: converte diferentes formatos para FHIR
74
C1
C2

IMPLANTAÇÃO MISTA:
FHIR® e APIs PROPRIETÁRIAS
REPOSITÓRIO CLÍNICO LIVRE DE FORNECEDORES: VENDOR NEUTRAL
75
C3
C4

REPOSITÓRIO CLÍNICO: BASEADO EM FHIR®
FHIR® COMO HUB DE INTEGRAÇÃO
76
C5
C6

ANALYTICS BASEADO EM FHIR®
Ao invés de movermos os dados para uma solução
analítica separada, usamos o FHIR® como o modelo para
realizar a análise.
FHIR® ENDPOINTS
Mais informações77
C7
C8

Tópicos Abordados
• Interoperabilidade – Considerações
• HL7® e HL7® FHIR® Foundation
• Comunidades FHIR® e Suporte
• HL7 FHIR® – Uma especificação inclusiva
• Porque o FHIR®?
• Como é o FHIR®? – Modelo de Dados
• Como é o FHIR®? – Rest FHIR® Api´s
• Conformidade
• Releases
• Identidade dos Recursos
• Paradigmas de Interoperabilidade
• Arquiteturas
78

Java reference library for implementation
Desenvolvendo para FHIR®
79

BIBLIOTECA JAVA HAPI FHIR® - DEVs
HAPI - HL7® Application Programming Interface (“happy”)
• Biblioteca de referência (inicialmente para V2) e agora para FHIR®
• Servidor, clients, validadores, classes, parsers, exemplos e muito mais
• Excelente documentação: guiada por exemplos
• Comunidade ativa e motivada: https://groups.google.com/forum/#!forum/hapi-fhir: James Agnew (hapi v2, mirth, etc)
• Compatível com JAVA 6 [2006] (permite que aplicações mais antigas se integrem a ela). Atual JAVA 10
• Mantenedora: University Health Network (UHN); rede de hospitais de ensino em Toronto, Canadá
• Disponibiliza servidor FHIR® ON-LIVE público para testes: http://fhirtest.uhn.ca/home?encoding=null&pretty=true
• Licença Apache V2: permite o uso e distribuição de versões modificadas sem royalties
• Projeto Importante Construido usando a HAPI FHIR é o FHIR® Broker
• De código aberto, construído com o HAPI FHIR®
• Desenvolvido em parceria pelo programa Sync for Science e RSNA (Radiological Society of North America)
• Implementa ‘FHIR® broker’ para usar RESTful FHIR® APIs sobre os PACS que implementam DICOM®
• GITHUB: https://github.com/RSNA/s4s-fhir-broker
80

BIBLIOTECA HAPI FHIR - Princípios
Construída para ser flexível | Projetada para ser ÚTIL
• Use o HAPI FHIR® ‘parser e encoder’ para converter entre FHIR® e o modelo de dados do seu aplicativo
• Use o HAPI FHIR® ‘client’ em um aplicativo para recuperar ou armazenar recursos em um servidor
• Use o HAPI FHIR® ‘server’ para permitir que aplicativos externos acessem os dados de sua aplicação
• Use o HAPI JPA/Database Server para implantar um servidor FHIR® totalmente funcional (scheleton)
81

Servidor FHIR Público para Testes University Health Network
82

FHIR COMPLIANCE
• Todo servidor FHIR deve ‘emitir’ uma declaração de conformidade
(Capability Statement) descrevendo suas capacidades
• Quais Recursos?
• Quais Operações?
• Quais Interações?
• Quais Parâmetros para Queries?
• Suporta versionamento?
• Autenticação, Segurança e Privacidade
83

‘Capability Statement’ | Conformance
https://sqlonfhir-stu3.azurewebsites.net/http://localhost:6081/hapi-fhir-jpaserver-example/conformance?serverId=home&pretty=false
SQLonFHIRUHN
84

TUTORIAL PRÁTICO
Construindo servidores FHIR á partir da HAPI FHIR
85

ETAPA 1
• PRÉ-REQUISITOS
@interopera – 2018 | CBIS´18
Todas as marcas são de seus respectivos proprietários. HL7®, FHIR® e Flame são marcas registradas da HL7® International, Inc. 86

FHIR® Playground – Endpoint de Exemplo
Pré-requisitos
Java Development Kit – JDK (JRE não atende). Há duas opções JDK
• OpenJDK
• Oracle
Java Application Server (web server)
• Apache Tomcat, JBoss/Wildfly, Websphere
• Vamos usar o Tomcat Versão 8 (Win, Lin, Mac)
• Use a opção 32/64 Windows Service Installer
Home Page Apache Tomcat
java -version
87

FHIR® Playground [1]
Pré-requisitos
Apache Maven (gerenciador de pacotes Java)
• Resolve dependências do HAPI
• Incluir o sub_dir: ‘BIN’ na variável ‘PATH’
 Ex: C:Program FilesApache_Maven
 Path = C:Program FilesApache_Mavenbin
88

FHIR® Playground [2]
Pré-requisitos
Ruby.org OU (Ruby for win) e Bundler (linguagem de programação e gerenciador de pacotes para Ruby). Usados para carga do DataSet no servidor
• Use versões Ruby menores que 2.5. Testamos usando a versão 2.4-x64 WITHOUT DEVKIT.
• Após instalar Ruby instale o Bundler com o comando: gem install bundler
1
2
89

ETAPA 2
• OBTER O PROJETO
• COMPILAR E INSTALAR
• ACESSAR E TESTAR
90

Compilando e Instalando o servidor HAPI FHIR® [1]
• Documentação: http://hapifhir.io/
• Projeto HAPI FHIR: https://github.com/jamesagnew/hapi-fhir/
• HAPI FHIR SNAPSHOT 3.4.0: https://github.com/jamesagnew/hapi-fhir/releases/tag/v3.4.0
1. Baixe a versão mais recente do servidor JPA: jpaserver-example.zip
2. Descompacte. Ex: C: CBIS18hapi-fhir-server (ou no dir de sua escolha)
3. Execute no prompt : mvn install (mesmo dir) para gerar o projeto (.WAR)
1
2
3
Prints parciais
91

Compilando e Instalando o HAPI FHIR® [2]
1
2
3
pasta ‘target’ é criada e nela gerado .WAR
Este arquivo pode ser implantado no Tomcat de duas maneiras
mvn jetty:run (default 8080)
mvn -D jetty.port=12500 jetty:run
constrói e inicia o servidor1 2
3
4
92

Implantando o servidor no Tomcat [1]
• Tomcat instalado com a opção “manager webapp”
1
2
3 4
93

Implantando o servidor no Tomcat [2]
• Copiar o .WAR manualmente para pasta ‘webapps’ da instalação do Tomcat
1
2
3
Ao copiar o .WAR o Tomcat gerar
a estrutura de diretórios
94

Para acessar a interface gráfica do servidor utilize [endereço:porta/nomedoWAR]
Lembre-se de que o URL depende do seguinte:
• nome do host ou endereço IP do servidor em que você instalou o Tomcat
• porta TCP configurada para o Tomcat
• nome do arquivo.WAR
http://localhost:6080/hapi-fhir-jpaserver-example/
95

ETAPA 3
• PERSONALIZAR O SERVIDOR
96

Personalizando o Servidor [1]
0. Pare o serviço TomCat (services.msc)
1. Vá para C:Program FilesApache Software FoundationTomcat 8.5_Tomcat8_fhirwebappshapi-fhir-jpaserver-exampleWEB-INFtemplates
2. Edite o arquivo na linha que contém: <img src="img/banner_interopera.jpg" />
3. Substitua o arquivo ‘banner_interopera.jpg’ pelo nome de seu arquivo
4. Salve as alterações
5. Explore os demais templates
arquivos que compõe a UI
1
97

Personalizando o Servidor [2]
Navegue para o diretório que contém as imagens
1. C:Program FilesApache Software FoundationTomcat 8.5_Tomcat8_fhirwebappshapi-fhir-jpaserver-exampleimg
2. Copie e cole o arquivo com a nova imagem
3. Reinicie o serviço TomCat
4. Acesse o servidor
2
4
1
98

ETAPA 4
Preparando o Upload do Dataset
4.1 Visão Geral
4.2 Como esta organizado o conjunto de dados (Dataset)
4.3 Obtendo o Dataset
4.4 Preparando o Endpoint para upload dos recursos
4.5 Preparando o Dataset para upload
4.6 Upload do Dataset
99

4.1 - Visão Geral
SIIM Dataset (recursos FHIR e referências) – IP Society for Imaging Informatics in Medicine | The Cancer Imaging Archive (TCIA)
• Coleção de objetos FHIR JSON que representam pacientes fictícios e suas imagens DICOM (parte do histórico do paciente)
• Clone ou faça o download: https://github.com/ImagingInformatics/hackathon-dataset
Ao final desta etapa, este conjunto de recursos FHIR será gerado em seu servidor. Agradecimentos ao SIIM Hackathon
Você pode usar seu próprio Dataset, gerar pelo Synthea ou usar o pacientes do Smart on FHIR 100

4.2 - Organização do Dataset
FHIR
• No diretório raiz estão os diretórios com os recursos Patients, Medication, Practitioner, Organization
• São um conjunto de subpastas. Uma para cada paciente onde estão os documentos json FHIR.
DICOM
• Contém as imagens DICOM (aka part 10) identificadas pelo nome do paciente e pastas que representam os estudos.
NOTA: Estes arquivos DICOM estão em um submódulo e não são clonados automaticamente. Para recuperar estes arquivos (cerca de 1,4 GBs),
você primeiro deverá clonar ou baixar o Dataset e então ir para o diretório onde o extraiu (Ex. C:hackathon-dataset) e atualizar.
• cd hackathon-dataset
• git submodule update --init –recursive
Convenções
• Os IDs utilizados são o Numero do Registro Médico (MRN)
• Os accession numbers são usados como IDs para os recursos FHIR DiagnosticReport
1
2
101

4.3 - Obtendo o Dataset
• GitHub: https://github.com/ImagingInformatics/hackathon-dataset
NOTA: As imagens DICOM estão em um submódulo e não são clonadas automaticamente.
Para recupera-las (cerca de 1,4 GBs), você primeiro deverá clonar/baixar o Dataset e então ir
para o diretório onde o clonou/extraiu e atualizar:
C:hackathon-dataset
cd hackathon-images
git submodule update --init –recursive
102

4.4 - Preparando o Endpoint para upload do dataset
• Acesse o diretório onde extraiu os arquivos: C:hackathon-dataset
• Localize e edite o arquivo: fhir_server.yml.dist
• Atualize a ‘url’ com o endereço de seu servidor e salve o arquivo como fhir_server.yml (não use .dist)
1
2
X
Não esqueça a barra no final. O script não funcionará sem ela.
103

4.5 - Preparando o Dataset para upload
• Abra um novo ‘Prompt de Comandos’
• Navegue para o diretório onde o Dataset foi extraído (c:hackathon-dataset)
• Inicializar o script com o Ruby (baixar dependências em tempo de execução)
Execute: bundle install
1
2
3
104

4.6 - Upload do Dataset
Use o comando:
ruby upload.rb fhir_server.yml .
Atenção: incluir todo o comando
entre as aspas (em verde)
incluindo o ponto (.) do final do
comando
1
2
105

Etapa 5
• Visualizador de Pacientes
107

PATIENT VIEWER – PROJETO SMART – DISPONÍVEL GITHUB
Estes são os pacientes do SIIM Dataset
Este é o paciente que vamos criar no tutorial ...
108

Clicar sobre o paciente, expande suas informações
109

Etapa 6
TRABALHANDO COM DOCUMENTOS NO FHIR
• MHD – MOBILE HEALTHCARE DOCUMENTS
IHE TF IT Infrastructure
Mobile access to a Document Sharing Environment
Rev. 2.4 – Trial Implementation
110

MHD – MOBILE HEALTHCARE DOCUMENTS
• Serve para a interoperabilidade de documentos. Médicos e profissionais da saúde compartilham
documentos clínicos a todo momento não podendo ser diferente na saúde eletrônica.
• Padrões como V3 CDA são amplamente utilizados juntos de perfis IHE como o XDS. Já perfil IHE
Mobile Access to Health Document define uma interface HTTP REST simples para o
compartilhamento de documentos clínicos, ao contrario do perfil amplamente adotado que é o
XDS, que é mais complicado pois usa SOAP, SAML, ebRegistry e outras tecnologias mais pesadas.
• O MHD surge para simplificar o XDS e tornar o compartilhamento de documentos mais leve em
especial para dispositivos com capacidades de processamento, memória e armazenamento
reduzidos como os mobiles tablets e celulares.
• O FHIR implementa o MHD através de poucos recursos, sendo os principais, o DocumentReference
e DocumentManifest.
• Para o upload do recursos, siga as etapas para cada um dos pacientes.
111

MHD – Mobile Healthcare Document with XDS on FHIR
DocumentReference e DocumentManifest
• Médicos estão habituados a compartilharem documentos a todo momento
• TF IHE MHD define interface Rest que é mais simples e mais leve para mobiles (smartphones, tablets...)
Upload dos documentos dos pacientes (laudos) para o FHIR SERVER
• Existem três componentes no processo para o upload dos recursos MHD
• 1 script create_mhd.rb
• 2 modelos ERB para os recursos JSON
1. O ‘create_mhd.rb’ usa o diretório de pacientes como entrada. Lê os recursos relacionados
ao paciente e cria os recursos DocumentReference para os recursos DiagnosticReport e
ImagingStudy associados
2. Estão armazenados nos subdiretórios de cada paciente
3. Para criar os recursos para o MHD abra um prompt de comandos e execute
• ruby create_mhd.rb <patient_folder> (repetir para todos os pacientes) 112

MHD – Mobile Healthcare Document
trechos...
1
2
1. Acesse onde extraiu o dataset (c:hackaton-dataset)
2. Execute: ruby create_mhd.rb siim_andy_tcga-50-5072
3. Repita para os demais pacientes
113

MHD – Mobile Healthcare Document
• ruby create_mhd.rb siim_joe-tcga-17-z058
1
2
114

Concluído
• Nesta etapa abordamos:
1. Biblioteca HAPI FHIR
2. Servidores FHIR Públicos para testes
3. Instalação dos pré-requisitos (java, tomcat, maven
4. Construção de um servidor FHIR (com todas as capacidades CRUD, recursos e operações habilitadas)
5. Upload do Dataset (conjunto de recursos de amostra para testes, desenvolvimentos, pesquisas...)
6. Opcionalmente a personalização do servidor
7. Opcionalmente implementação da aplicação de visualização de pacientes
8. MHD – Documentos no FHIR
115

REST FHIR APIS
• A especificação FHIR também define a infraestrutura para o intercambio dos
dados através de API´s Rest
• Usadas para interagir com o modelo de dados (recursos) e com os servidores
• Vamos usar o Postman como cliente HTTP (pode ser insomnia ...) para as requisições
116

POSTMAN (download)
• Ajuste Content-Type e formatos na guia HEADER
117

Recuperando Pacientes
Bundle
http://localhost:6081/hapi-fhir-jpaserver-example/baseDstu3/Patient
1 2
3
4
5
118

Recuperando Pacientes pelo nome
119

Recuperando todos os recursos ‘Condition’
120
http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/Condition

Recuperar todos os recursos ‘Condition’ para o paciente ID = siimandy
121vista parcial
http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/Condition?patient=siimandy

Criar um Patient
Conteúdo do recurso
1
2
3
4
5
Use o recurso anteriormente recuperado
como modelo e edite os atributos nome e
os que mais desejar
122

Para Praticar
• Recuperar
DiagnosticReport para o ID: siimsally (experimente com outros ids)
• GET http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/DiagnosticReport/a361814883895900
Todas as Conditions Diagnosis
• GET http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/Condition
Todas as alergias
• GET http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/AllergyIntolerance
Todas as medicações
• GET http://localhost:6080/hapi-fhir-jpaserver-example/baseDstu3/Medication
123

Existem diferentes GAPS nas TICS
• Entre padrões: variedade de implementações v2, modelos informação
• Entre sistemas: privacidade e segurança, usabilidade, sistemas de medida
• Entre organizações: códigos, terminologias, identificadores
• Entre processos: diferentes regras e/ou fluxos
• E na atenção e nos cuidados: variabilidade do conhecimento médico
Somente uma tecnologia não é capaz de resolver todas as nuances e
complexidades da interoperabilidade eletrônica em saúde.
Uma pilha de padrões abertos é necessário, assim como a internet funciona
124

O momento é: Construa Pontes | Build Bridges
HIE - Heath Information Exchange são parte da solução
• Conecta diferentes Sistemas e HIEs
• Rompe limites geográficos do acesso a informação
• Conecta sistemas primários aos auxiliares e apps, com mais facilidades
• Elimina os silos de dados gerados pelos RES (EHR´s)
• .....
125

Nesta etapa abordamos
• Rest FHIR APIs
• Breve definição
• Postman
• Instalação e configuração
• Exercitamos o uso das requisições e operações no servidor FHIR
• GET, POST
• Exercícios para casa
126

HL7 V3
RIM - CDA
PARA FINALIZAR

HL7v3 - RIM
12
8
 Rápida Introdução
– HL7 v3 não é uma nova versão construída sobre a v2.x, mas sim um outro padrão
– As mensagens são baseadas em um novo modelo de dados e são escritas em XML
– Não é compatível nativamente com V2.x – exige muito suor para trocar mensagens V2/V3
– Exige um planejamento para os OIDS (etapa mais demorada até que codificar)
– Exige muito código mesmo para trocar poucos elementos de dados
– HL7 v3 RIM: Reference Information Model
– Define "dominios", similares aos "capítulos" do HL7v2.x
– Modelo extremamente complexo e rígido: motivo de seu fracasso – impõe o modelador frente ao
desenvolvedor
 http://informatica-medica.blogspot.com.uy/2011/02/hl7-normalizando-la-comunicacion-en.html

HL7v3 RIM
• 4 classes principais +2 relacionamentos
– Entity: objeto físico ouumaorganização
– Role: define a competencia de uma entidade que participa de um ato
– Participation: associação entre Role e Act
– Act: registro do que aconteceu, está acontecendo ou acontecerá
129
Principais Classes do
HL7 V3 - RIM
Classes de
Relacionamentos

HL7v3 CDA
131
• Clinical DocumentArchitecture
– É uma definição da estrutura de documentos clínicos em XML baseado no HL7 v3RIM
– Composto por cabeçalho e corpo
– 3 niveis:
• Nivel 1:corpo não éestruturado
• Nivel 2: corpo estruturado, em sessões de texto livre
• Nivel 3: corpo estruturado, com entradas codificadas
– Osdocumentospodemserelacionar
• relatedDocument: adendum, substituir outransformar
• documentationOf: documentação de um atendimento, ex: procedimento / tratamento
• inFulfillmentOf: documenta o cumprimento da atenção prestada ou de uma ordem
• authorization: consentimento que autoriza os atos contidos no documento
• componentOf: documenta parte de um encontro que está em outro documento
– OsdocumentosCDA podemserVersionados

Cabeçalho Relacionamentos Corpo
nivel 1
nivel 2
nivel 3
corpo não estruturado vs.estruturado
paciente médico
132
VISÃO SIMPLIFICADA DA ESTRUTURA DO CDA DERIVADO DO HL7 V3 - RIM
Nível
semântico
uso de
terminologias

HL7v3 CDA:Estrutura Básica
133
<ClinicalDocument ...>
... cabezal (header) ...
<component>
<structuredBody>
<component>
<section>
<title></title>
...
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
<ClinicalDocument ...>
...
<recordTarget>
... paciente
</recordTarget>
<author>
... médico
</author>
<custodian>
... Hospital que detém a custodia do doc
</custodian>
<component>
... Corpo do doc
</component>
</ClinicalDocument>
Exemplos: master/cda
Esquema: /master/cda/CDA_flat.xsd

HL7 C-CDA Viewer - First Prize Winning Entry - HL7/ONC C-CDA Rendering Tool Challenge.

Selecionar um CDA
Documento CDA em XML

Todo visualizador de documentos CDA deve permitir que as sessões possam ser reorganizadas.....

DEMONSTRAÇÕES
INSCREVA-SE NO CANAL
YOUTUBE DA INTEROPERA

Ferramentas utilizadas nesta apresentação
• CARISTIX READER - LOCAL FREE
• CARISTIX VALIDATOR - ONLINE
• HL7 SOUP – LOCAL COMERCIAL
• HAPI TEST PANEL – LOCAL FREE
• HAPI V2 JAVA API
• FHIR JAVA API
• VICO – ONLINE FREE
• MIRTH CONNECT
• HL7 C-CDA Viewer

ISTO É SÓ O
COMEÇO
PESSOAL!
Thank´s
Paulo R. Rades
radespaulo@gmail.com
11|9|8837|4372
REFERÊNCIAS
FHIR STU-3 Spec
1. Release R4 Spec
2. HAPI-FHIR Spec
3. FHIR RoundTable 2017
4. SMART on FHIR
5. HL7 V2.x Specification
140

HL7 - V2.x | FHIR | V3-RIM | CDA

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a HL7 - V2.x | FHIR | V3-RIM | CDA

Semelhante a HL7 - V2.x | FHIR | V3-RIM | CDA (20)

HL7 - V2.x | FHIR | V3-RIM | CDA