PDF FHIR R4 S3 LEITURA

Curso de FHIR
Semana 3 – FHIR Avançado

Leitura Obrigatória
© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 1

Visão Geral do Curso
Módulo I: Introdução
Introdução ao FHIR
Recursos
Módulo II: Trabalhando com FHIR

FHIR RESTful
Pesquisando com FHIR
Módulo III: FHIR Avançado

Transações
Paradigmas
Mensagens
Documentos e CDA R2
Operações
Módulo IV: Conformidade com FHIR

Recursos de conformidade
Extensões
Perfis
Implementação

Sumário
Sumário ....................................................................................................................... 3
Conteúdo da Unidade e Objetivos de Aprendizagem .................................................... 5
Paradigmas FHIR ......................................................................................................... 6
FHIR REST + Transações ............................................................................................... 7
O problema............................................................................................................................................ 7
Receita para Bundles de Transações (Bundle Transactions) ............................................... 10
Regras para Processamento de Transações........................................................................ 11
Respostas de Transações ................................................................................................... 11
Identificação Temporária de Recursos ............................................................................... 14
Interações Condicionais ..................................................................................................... 18
Mensageria FHIR ....................................................................................................... 20
Conceitos Básicos de Mensageria FHIR .............................................................................. 20
Lista de Eventos FHIR ........................................................................................................ 20
Identificadores de Cabeçalho da Mensagem ...................................................................... 21
Receita para Mensagens FHIR............................................................................................ 21
Processamento de Mensagem ........................................................................................... 23
Recipe for FHIR Message Responses .................................................................................. 23
Mapeamento da V2 para Mensagens FHIR ........................................................................ 25
Exemplo de Mensageria FHIR ............................................................................................ 25
O Paradigma “Não amado” (The Unloved Paradigm) ......................................................... 25
Documentos FHIR ...................................................................................................... 26
Características de Documentos Clínicos ............................................................................. 26
Estrutura de um Documento FHIR ..................................................................................... 27
Receita para documentos FHIR .......................................................................................... 27
Exemplo de documento FHIR ............................................................................................. 28
Apresentação de um documento FHIR ............................................................................... 29
Transporte de documentos FHIR........................................................................................ 29
Considerações sobre a arquitetura de documentos FHIR ................................................... 30
Documentos FHIR e CDA R2 ....................................................................................... 31

Projetos relacionados de FHIR e CDA R2 no HL7 Internacional ........................................... 31
Operações FHIR ......................................................................................................... 32
Operações Estendidas na RESTFul API ............................................................................... 32
Executando Operações ...................................................................................................... 32
Parâmetros de operação ................................................................................................... 33
Resposta da Operação ....................................................................................................... 33
Operações definidas pelo FHIR .......................................................................................... 33
Operações definidas pela implementação ......................................................................... 34
Quando usar…? Quando evitar?................................................................................. 35
Orientação geral ................................................................................................................ 36
Tarefa desta semana ................................................................................................. 37
Resumo e Conclusão da Unidade ............................................................................... 38
Material de Leitura Adicional..................................................................................... 39
Informações sobre o FHIR .................................................................................................. 39

Conteúdo da Unidade e Objetivos de Aprendizagem
Essa unidade discute alguns tópicos avançados: transações, mensagens e documentos
usando FHIR, o relacionamento entre FHIR e CDA R2, e abordagens arquiteturais a FHIR:
O que devemos utilizar? Quando?
O poder do FHIR, um poder que você precisa liberar, serve para o seu caso de uso
específico e/ou cenário, você pode trocar um conjunto de recursos entre um ou mais
servidores. FHIR não se prende ao recurso, tipo, quantidade ou temporização, ou
mesmo ao tipo de transporte utilizado para a troca de dados.
Você está livre para utilizar recursos e combiná-los, e usar todos os paradigmas que
veremos nessa unidade para intercambiá-los
Essa liberdade vem com uma responsabilidade: você precisa definir respostas para
várias perguntas. Quais recursos serão intercambiados? Como esses recursos serão
combinados? Como serão relacionados? Em que momento se iniciará o
compartilhamento deles? Haverá limitação de recursos dependendo do sistema
terceiro? Quais tipos de servidores poderão publicar e quais funcionalidades eles
poderão incluir?
Nesta unidade exploraremos as opções, algumas técnicas avançadas e boas práticas,

além de revisar pelo menos um exemplo por paradigma – REST (incluindo transações),
mensagens, documento e operações.

Paradigmas FHIR
FHIR dá suporte a quatro paradigmas de interoperabilidade:
Revisaremos e compararemos nesta unidade as quatro abordagens, apresentando

ferramentas para decidir qual delas será mais apropriada para cada projeto que você
enfrentar. Não há melhor abordagem. Há abordagens mais apropriada para cada
cenário, capacidades técnicas e ainda questões menos técnicas como uma política ou
restrição orçamentária.
Os quatro paradigmas são: REST (+Transações), Documentos, Mensagens e Serviços (Ou

Operações).
Dois outros paradigmas também serão explorados: Armazenamento (Storage) e Blocos

de Dados (Bulk Data).

FHIR REST + Transações
O problema
Ao intercambiar recursos FHIR com um outro servidor em tempo real, muitas vezes você
terá que lidar com situações onde será necessário enviar um Bundle de Resources ao
invés de um único Resource.
Você pode escolher (como cliente) usar uma interação REST para cada recurso ou usar
transações FHIR.
Um exemplo disso é um laudo de exame laboratorial. Um laudo de exame laboratorial

em FHIR pode ser representado como um conjunto de recursos associados (paciente,
médico solicitante, observações, laudo do exame laboratorial em PDF, solicitação de
exame). Se você precisar transmitir esses recursos para um servidor (vamos assumir que
é o mesmo servidor nesse caso), você pode enviar os recursos um de cada vez
(conforme a figura abaixo):
Figure: Múltiplos recursos como múltiplas requisições transmitidas para o servidor SHIR.
As setas bidirecionais na figura significam, no paradigma RESTful puro, assumir que não
conhecemos a lógica do servidor terceiro para cada recurso, que precisamos executar
uma busca pelo recurso e só depois fazer a transmissão do recurso, ou modifica-lo, se
necessário.
Observação: O verdadeiro nome para a nossa solicitação de exame de acordo com o

FHIR R4 é ‘RequestGroup’ e cada item é um ‘ServiceRequest’.

Algo mais ou menos assim ocorrerá na comunicação: perguntas serão buscas em
requisições GET para o recurso mais apropriado e depois requisições PUT/POST serão
enviadas para transmitir ou atualizar dados se necessário.
Client: Você conhece um paciente com o CPF 40928383?

Server: Conheço sim! Esse paciente tem ID 338 no meu sistema.
Client: E você conhece a organização ‘Clinical Lab’ de CNPJ 333321?
Server: Infelizmente, não.
Client: Então adicione essa organização: Aqui está a informação dela: ‘Clinical Lab, 2222
One Clinical Road, Cambridge, CA 90210’
…
E assim sucessivamente para todos os recursos …
Imagine um laudo de exame laboratorial com 1 paciente, 1 organização, 1 médico, 1

pedido com 10 itens, 1 resultado de exame laboratorial com 40 observações e um PDF
anexado à requisição. Isso significa cerca de 100 interações com o servidor (entre
buscas, atualizações ou criações), ou simplesmente enviar um resultado.
Múltiplas interações requerem múltiplas transmissões entre cliente e servidor e

introduzem um risco de perda de integridade referencial se uma interação subsequente
falha (exemplo: a entrada de um índice de documento e o documento propriamente
dito com seu conteúdo).
A outra opção é enviar todos os recursos em um único “pacote” ou Bundle (lembre-se

dessa palavra mágica) em uma única transação: a transação submete um conjunto de
ações a serem executadas em um servidor através de uma única requisição HTTP
request/response, conforme mostrado na figura abaixo:

Figura: múltiplos recursos “empacotados” (Bundled) para enviar um relatório de exames
laboratoriais em uma única transação.
A responsabilidade do processamento da requisição está todo nas mãos do servidor.

Incluindo a resolução de identificadores (como o caso do CPF citado logo acima) para
identificadores locais do sistema terceiro usando Criação condicional (‘Condicional
Create’) ou Atualização Condicional (‘Condicional Update).
O cliente irá indicar se deseja que o processamento seja em lote (batch) ou por
transação.
A única diferença em FHIR entre um lote (batch) e uma transação é que uma transação
será bem sucedida se, e somente se, TODAS as operações forem bem sucedidas,
enquanto que um batch poderá ser parcialmente bem sucedido.
Você poderá misturar interações em uma transação ou lote (batch), incluindo múltiplas
interações em diferentes tipos de recursos. Servidores podem definir suas próprias
operações (e veremos isso nessa unidade).
Transações são úteis quando precisamos evitar múltiplas interações.
Para realizar uma transação em um servidor, você precisa transmitir os dados para o
servidor FHIR [base] através de uma requisição POST em um dos formatos compatíveis
(JSON/XML).
POST [base] {?_format=[mime-type]}
Lembrou da palavra mágica? A palavra mágica é Bundle, pois uma transação, para o
FHIR é só um tipo específico para um Bundle, e suas próprias regras.
O conteúdo da sua requisição POST para o servidor é um recurso Bundle.
Para transações, o Bundle.type deverá assumir o valor “transaction” e para lotes deverá
ser do tipo “batch”. Bundles são compostos por entradas (Entry). Cada Entry no seu
Bundle deverá conter um recurso e uma requisição.
O recurso são os dados – data (a informação sobre o recurso que você envia para o
servidor), a requisição é a ação - action (o que fazer com os dados). Cada ação será
processada em separado e uma resposta será gerada para cada ação (O recurso foi
criado? Qual foi a ID associada?)
Receita para Bundles de Transações (Bundle Transactions)
Lembre-se:
1. A transação deverá ser um Bundle do tipo value=”transaction”, com uma ou mais

Entries.
2. Cada Entry deverá conter um Resource ou elemento requisitado (request element).
3. O request element deverá conter dois elementos obrigatórios:
a. method = POST/PUT/DELET/GET
b. URL = O endereço para o recurso, incluindo um parâmetro de busca se
necessário (GET, DELETE, Inserts e Updates Condicionais).
Em XML:
<Bundle>
<type value="transaction"/>
<entry>
<resource>
<Patient> <-- or any other ->
... Patient Resource contents
</Patient>
</resource>
<request>
<method value="POST"></method>
<url value="patient"></url>
</request>
</entry>
... (n Entries)
</Bundle>

Regras para Processamento de Transações
• O servidor deverá ACEITAR todas as ações e emitir um Status HTTP 200 OK como
reposta ou REJEITAR todas as ações solicitadas e retornar um Status HTTP 400 ou 500
como resposta.
• Não há ordem obrigatória para as Entries (recursos) do seu Bundle, para serem
processados adequadamente. A ordem de processamento segue a seguinte: DELETE,
POST, PUT, GET. O servidor tentará excluir todos os recursos que você está solicitando
exclusão, depois criará todos os novos recursos e atualizará os recursos que você está
solicitando atualização. Finalmente, processará as buscas e GETs.
• Uma transação poderá incluir referências de um recurso para outro em um Bundle.
Algumas dessas referências devem ter um formato especial e comportamento,
discutiremos isso nas ‘Interações Condicionais’.
Respostas de Transações
O servidor sempre irá retornar um Bundle para permitir que cliente saiba os resultados
da transação solicitada.
O tipo do Bundle será “transaction-response” com as Entries e ações solicitadas pelo

cliente na mesma ordem de solicitação, contendo o código de Status do HTTP,
localização, e ETag (versão específica do recurso) no elemento de resposta.
Vamos enviar uma pequena transação e verificar como será a resposta do servidor e o
que significa. Com esse POST, nós vamos determinar 1) O formato e conteúdo da
resposta do servidor e 2) O que o servidor efetivamente faz com o Bundle.
A transação que será postada é o arquivo SmallTransaction.xml.
Você encontrará esse exemplo e outros XMLs que mencionaremos no material de

leitura no arquivo SmallExamples.zip da Semana 3.
Apenas recorte e cole o conteúdo no seu cliente REST e transmita essa requisição para o
servidor do seu curso de FHIR Fundamentos.
Lembre-se que nosso servidor base fica no endereço:

http://fhir.hl7fundamentals.org/R4

E transações são transmitidas para o endereço base do FHIR (sem uma URL específica)
então você deverá transmitir o conteúdo do arquivo para o endereço base do nosso
servidor FHIR.
Lembre-se:
• Defina no cabeçalho da sua requisição o parâmetro para que ele entenda o formato:
Content-Type: application/fhir+xml
• As IDs dos recursos para os recursos que você irá obter serão diferentes dos recursos
apresentados neste documento.
A tela que você verá será parecida com a que é apresentada na figura abaixo:
Figura: enviando uma transação Bundle para um servidor FHIR.
Vamos revisar a resposta do servidor (caso já não tenha verificado você mesmo, uma
amostra de resposta do servidor está anexada como SmallTransactionAnswer.xml)
E você também pode vê-la aqui nas Figuras 4 e 5.

Figura: cabeçalho de resposta de transação do servidor
Figura: corpo da resposta da transação do servidor:
Cabeçalhos: recebemos um HTTP Status code 200 OK, então todos os resoursos/ações
foram processados OK (lembre-se que TODAS as transações ou serão bem-sucedidas ou
falharão completamente).
Corpo: Recebemos um Bundle “transaction-response”, com uma Entry pra cada Entry
que enviamos na nossa transação. A primeira Entry nos diz que o servidor criou uma
nova Organization resource (“201 Created”), com uma ID atribuída pelo servidor de
número 17449, a um novo Patient com id atribuída pelo servidor de 17450.

Agora... Queremos que recursos sejam associados. Deveremos dizer claramente que
este Patient específico é tratado por essa outra específica Organization.
Isso pode ser feito através do recurso Patient ao referenciá-lo à ManagingOrganization.
Isso deverá ser realizado muito facilmente, apenas adicione o ID da

ManagingOrganization ao Patient.
O problema é que a ManagingOrganization requer uma referência, e essa referência

precisa apontar para uma Organization. Nós só saberemos o ID dessa organização
depois de transmiti-lo e obtermos os resultados. Então pronto, travamos? Como sair
dessa? Identificação temporária de recursos para nos salvar!
Identificação Temporária de Recursos
Esse esquema especial de identificação é usado em transações para inserir uma

referência em um servidor para um recurso que não conhecemos ainda naquele tempo
de execução.
O escopo da identificação temporária de recursos só acontece dentro de um Bundle.

Isso significa que você pode reusar identificações temporárias de uma transação para
outra, mas nunca na mesma transação.
Vamos supor que você esteja enviando, em um mesmo Bundle, um paciente e um laudo
e o laudo tem referência para esse mesmo paciente. Como você poderá fazer referência
para um recurso que você ainda não conhece ?
O recurso do tipo DiagnosticReport contém um Subject relacionando a um laudo

específico a um paciente. Esse Subject (paciente) contido em DiagnosticReport precisa
de uma referência para um Patient, por exemplo ‘www.fhirserver.org/Patient/128’.
Mas o criador:
• não conhece essa ID específica de paciente que os servidor atribuirá a esse paciente e
• não quer fazer mais do que uma interação com o servidor.
Observação: é claro que isso não é um problema quando o servidor permite que
diferentes clientes criem seus próprios IDs para os recursos. Esse não é sempre o caso.
Além disso, nem todos os servidores FHIR implementam identificação temporária de
recursos. No entanto, uma das duas opções estarão sempre disponíveis.

Há uma forma de incluir tanto a requisição para substituir a ID com uma ID atribuída
pelo servidor quanto os recursos que referenciam essa ID: identificação temporária de
recursos. O mecanismo é simples; apenas inclua uma GUID na entry do recurso
referenciado e inclua essa mesma GUID ao invés de uma referência de recurso já
conhecida, conforme figura a seguir.
<Bundle>
<type value="transaction"/>
<entry>
<fullUrl value="urn:uuid:17C7D86E-664F-4FE2-91D7-AF9A8E47311E"/>
<resource>
<Patient>
... Patient Resource contents

</Patient>
</resource>
<request>
<method value="POST"></method>
<url value="patient"></url>
</request>
</entry>
<entry>
<DiagnosticReport>
… other diagnostic report information
<subject>
<reference value=”urn:uuid:17C7D86E-664F-4FE2-91D7-AF9A8E47311E"/>
</subject>
… more diagnostic report information
</DiagnosticReport>
</entry>
... (n Entries)
</Bundle>
O servidor criará novas IDs que serão apropriadas para ele, mas honrará as referências
entre recursos preservando, portanto, os relacionamentos.
Portanto, voltando para o nosso pequeno exemplo, nos geraremos uma ID temporária
para o elemento Organization, referenciaremos ela dentro do recurso Patient, para o
elemento ManagingOrganization, conforme a abaixo:

Figura: identificação temporária de recurso e referenciamento
Você poderá verificar isso no arquivo SmallTransactionLinked.XML.
Você poderá tentar transmitir esse exemplo para o nosso servidor também. E examinar
em detalhes a resposta... Agora que você sabe como lê-la.
Vamos examinar a resposta do servidor da figura a seguir: o servidor não usou a GUID
como identificador do recurso: ele a substitui com uma nova ID gerada internamente
pelo servidor para identificar o novo recurso criado.

Figura: resposta do servidor / Identificador Temporário de Recurso
A requisição criou dois recursos. Se obtivermos o ID do Patient criado, vamos verificar o

Patient propriamente ligado ao ManagingOrganization, conforme a seguir:
Figura: referenciamento apropriado utilizando uma Identificação Temporária de Recurso
Mas... Ainda há um problema. Talvez você tenha notado. Talvez não.

Toda vez que enviamos um mesmo recurso (seja paciente ou organização) para o
servidor, o servidor criará o recurso novamente. Portanto, se utilizarmos transações
para nossos laudos de exames laboratoriais, deveremos relacionar cada paciente ao seu
laudo, mas cada paciente acabará criando um novo cadastro no servidor!
O problema persiste. Portanto, mesmo usando transações e identificadores

temporários: “Como garantimos que não vamos inserir o mesmo recurso repetidas
vezes?” Como saímos dessa? Precisamos de um novo super herói? Interações
condicionais para nos salvar!
Interações Condicionais
Interações Condicionais permitem ao cliente FHIR evitar a criação de um recurso já

existente baseado em algum critério de identificação, ao invés de um identificador
lógico. Para fazermos isso, o cliente transmite um PUT [base]/[type]/?[search
parameters]
Para inserções, quando o servidor processa interação, ele executa uma busca utilizando
suas estruturasde busca para o tipo de Resource, com o objetivo de encontrar uma
única id lógica para o Resource. A ção depende de quantos Resources forem
encontrados:
• Nenhum resultado encontrado: o servidor realiza uma criação do recurso

• Um resultado encontrado: o servidor realizar uma atualização contra o único resultado
encontrado
• Múltiplos resultados encontrados: O servidor retorna um Status HTTP 412 onde houve
uma falha de precondição indicando que os critérios fornecidos pelo cliente não foram
suficientemente seletivos
Essa variante funciona melhor com um PUT porque você pode condicionalmente
atualizar um recurso existente, mas buscando por um identificador de negócio ao invés
de utilizar uma id atribuída pelo servidor, com essa funcionalidade bônus: Você pode
atualizar o recurso em questão.
Por exemplo, um cliente atualizando um status de um laudo de exame laboratorial de

“preliminar” para “final” pode submeter o laudo final utilizando um PUT
/Observation?identifier=http://my-lab-system|123
Observação importante: create/update/delete condicionais são interações complexas e

não é esperado que cada servidor seja capaz de implementá-las. Servidores que não

suportam atualizações condicionais devem retornar um código HTTP 400 e um resultado
para a transação.
Dessa forma... como isso se aplica para nossa pequena transação... como podemos
garantir eu o servidor não criará pacientes e organizações repetidas toda vez que
enviamos um paciente ou organização dentro de uma transação?
Vamos mudar um pouco nosso pequeno arquivo de transação. As mudanças estão

disponíveis no arquivo SmallTransactionLinkedConditional.xml.
Note que não estamos utilizando os mesmos identificadores para a organização e

paciente porque desejamos obter vários resultados encontrados e o servidor retornará
um HTTP Status 442 (você mesmo pode tentar realizar essa operação).
O resultado ao transmitir esse Bundle é que o recurso será atualizado caso ele exista e
criado caso não encontrado. Os identificadores temporários serão substituídos pelo
atuais identificadores criados pelo servidor nas transação. Você obterá um Status HTTP
200 para cada recurso. Você poderá enviar essa transação diversas vezes e o servidor
nunca adicionará um recurso repetido. Os relacionamentos também serão mantidos.
Isso conclui nossa discussão sobre transações FHIR, mas revisaremos mais tipos de
Bundle relacionados a Mensagem, Documento e Paradigmas de Serviços de
Interoperabilidade.

Mensageria FHIR
Conceitos Básicos de Mensageria FHIR
No paradigma de mensageria, as interações entre servidores e clientes são definindas

conforme a família de padrões do HL7 V2.X: Há um remetente e um destinatário, há um
evento gatilho (algo que aconteceu no mundo real que iniciou a criação e comunicação
dessa mensagem específica), uma mensagem de requisição e uma mensagem de
resposta.
Uma mensagem de requisição FHIR é uma transação FHIR com algumas regras especiais:
• Uma mensagem FHIR é um Bundle com um Bundle.type=message, e o primeiro

recurso é sempre um recurso especial chamado MessageHeader
• O MessageHeader mantém os metadados da mensagem:
a. EventCoding (code element): O gatilho do evento
b. Sender (O remetente da mensagem)
c. Receiver (O destinatário que receberá a mensagem)
d. Message Identifier (Identificador único da mensagem, utilizado para trilhas de
auditoria e para atribuir a resposta de uma mensagem)
e. Date/Time (Carimbo do tempo de criação da mensagem com data e hora)
Não é necessário que o transporte seja RESTful sobre HTTP: Você pode enviar e
receber mensagens utilizando transferência de arquivos, compartilhamentto de pastas,
HTTP, MLLP, MQ ou qualquer outra aplicação de enfileiramento. O único requisito para
o transporte é garantir a entrega das mensagens e suas respostas.
Mensagens FHIR são classificadas pelo seu impacto:
• Consequence: a mensagem representa a mudança que ela deve realizar uma vez
executada. Esse tipo de mensagem receberá apenas uma única reposta.
• Notification: o conteúdo não é supostamente corrente e pode ser reprocessado. Esse
tipo de mensagem deve receber uma mensagem de resposta.
• Currency: a mensagem é resposta para uma consulta e deverá ser corrente. Sendo
uma consulta, esse tipo de mensagem pode receber múltiplas mensagens de resposta.
Lista de Eventos FHIR
A lista de eventos (lista de tipos de mensagens, eventos, além da lista de alguns dos
Bundles para cada uma dessas mensagens) está localizada em:
http://www.hl7.org/fhir/valueset-message-events.html
A lista até o momento é bem pequena comparada com a variedade de mensagens e
eventos definidos no HL7 V2.X e V3, principalmente pelo fato da maioria das
implementações FHIR escolherem outros paradigmas (RESTful, transações, documentos
ou operações), mas está aberta para feedback.
Há alguns exemplos da lista:
• diagnosticreport-provide (notification): prover ou atualizar um laudo:

DiagnosticReport, Patient, Performer, Specimen, Image
• MedicationAdministration-Update (consequence): atualizar o registro de uma
administração de medicação
• admin-notify (notification): mudança de um recurso administrativo (Device, Location,
Pacient, Practitioner)
Identificadores de Cabeçalho da Mensagem
Cada mensagem contém dois identificadores, o Bundle.id (obrigatório) e o

MessageHeader.id (obrigatório). Esses identificadores devem ser únicos para o
remetente, é recomendável que sejam globalmente únicos, usando uma OID ou UUID.
Cada vez que uma mesma mensagem seja enviada, o Bundle.id deverá mudar, mas o
Message.id deverá ser o mesmo.
Quando um destinatário processa a mensagem, deverá gerar uma resposta com um

novo Bundle, um novo Bundle.id, mantendo a mensagem, mas com um novo
Message.id e mantendo MessageHeader.id do remetente na MessageHeader.response.
Receita para Mensagens FHIR
Portanto, lembre-se:
• A transação deverá ser um Bundle do tipo value="message", com pelo menos uma
entry: MessageHeader e um ou mais entries para cada recursorequerido para o tipo de
mensagem.
• o Bundle.id é obrigatório e deve ser globalmente único.
• o MessageHeader.id é obrigatório e deverá ser globalmente único. Deverá ser usado
para associar mensagens às suas respostas.
• não há carimbo do tempo no MessageHeader, portanto deverá ser incluído um
carimbo do tempo no Bundle.timestamp (obrigatório) e representa a data/hora da
mensagem.

• o MessageHeader.source é obrigatório e representa o endpoint (terminal) do
remetente (obrigatório) e name (opcional).
• o MessageHeader.destination é opcional e representa o endpoint (terminal) do
destinatário (obrigatório) e name (opcional)
• O MessageHeader.focus é obrigatório e aponta para a primeira entrada ou focal,
aponta para o primeiro registro ou recurso de uma mensagem – lembre-se que o
MessageHeader é um metadado da mensagem, não é um descritivo do evento que
realmente aconteceu.
Em XML:
<Bundle xmlns="http://hl7.org/fhir">
<id value="a4b0eb3c-a3f3-4739-aef3-db9f718a0b15"></id>
<type value="message"> </type>
<timestamp value="2019-01-04T09:10:14Z"></timestamp>
<entry>
<resource>
<MessageHeader>
<id value="21448097-009c-4eec-b8d3-6aba818b3a74"></id>
<eventCoding>
<code value="admin-notify"></code>
</eventCoding>
<destination>
<name>RECEIVING SYSTEM</name>
<endpoint value="www.receivingsystem.com"></endpoint>
</destination>
<source>
<name>SENDING SYSTEM</name>
<endpoint value="www.sendingsystem.com"></endpoint>
</source>
<focus>
<reference value="urn:uuid:3a78d9c4-5d87-4264-b3b4-
f4d0506a373c"></reference>
</focus>
</MessageHeader>
</resource>
</entry>
<entry>
<fullUrl value="urn:uuid:3a78d9c4-5d87-4264-b3b4-f4d0506a373c"></fullUrl>
<resource>
…
</resource>
</entry>
…any other entries

</Bundle>
Processamento de Mensagem
Mensagens podem ser processadas usando a operação $process-message, somente

através da requisição POST, ou diretamente para o endereço base do servidor FHIR. Ele
aceita a mensagem, processa de acordo com a definição do evento no message header
e retorna uma ou mais mensagens de reposta. O servidor pode armazenar Resources
incluídos na transação e torná-los disponíveis ou tomar quaisquer decisões de negócio
sobre as informações contidas nos Resources. O servidor pode retornar um Status HTTP
200 OK se a mensagem for processada com sucesso.
Outros códigos de erro:
• Erros 4xx : erro no conteúdo da mensagem. Não reenviar.

• Erros 5xx: erro interno no destinatário (servidor). Favor reenviar.
Normalmente deverá haver uma mensagem de resposta para cada mensagem. A

resposta da mensagem deverá conter um status detalhado da mensagem processada.
O recurso usado para mostrar o status da mensagem processada é o

OperationOutcome.
Recipe for FHIR Message Responses
<id value="0522aa28-8cf1-4b83-a452-8f7164c76d72"></id>
<type value="message"> </type>
<timestamp value="2016-10-04T09:10:14Z"></timestamp>
<entry>
<resource>
<MessageHeader>
<id value="0522aa28-8cf1-4b83-a452-8f7164c76d72"></id>
<response>
<identifier value="efdd254b-0e09-4164-883e-35cf3871715f"/>
<code value="ok"/>

<details>
<reference value="OperationOutcome/94cee761-74c0-495c-82dd-
5e5686b0218e"/>
</details>
</response>
<source>
<name>RECEIVING SYSTEM</name>
<endpoint value="www.receivingsystem.com"></endpoint>
</source>
<destination>
<name>SENDING SYSTEM</name>
<endpoint value="www.sendingsystem.com"></endpoint>
</destination>
<focus>
<reference value="urn:uuid: e7b49eb3-64d8-40d3-a013-
c60a8df5e897"></reference>
</data>
</MessageHeader>
</resource>
</entry>
<entry>
<fullUrl value="urn:uuid:94cee761-74c0-495c-82dd-5e5686b0218e"></fullUrl>
<resource>
<OperationOutcome xmlns="http://hl7.org/fhir">
<id value="e7b49eb3-64d8-40d3-a013-c60a8df5e897"/>
<text>
<status value="generated"/>
<div xmlns="http://www.w3.org/1999/xhtml">
<p>…detail of all errors…</p>
</div>
</text>
<issue>
<severity value="…"/>
<code value="…"/>
<diagnostics value="…"/>
</issue>
</OperationOutcome>
</resource>
</entry>
</Bundle>

Mapeamento da V2 para Mensagens FHIR
Para cada mensagem na especificação, há um mapeamento de seção específico de entre

segmentos V2.X, mensagens, eventos, campos e sua mensagem FHIR equivalente.
Isso não significa que você seja automaticamente capaz de mapear mensagens HL7 V2.x,
segmentos e campos a seus recursos FHIR equivalentes. Não há um projeto HL7 que
atualmente faça isso, mas alguns projetos já tentaram cobrir no mínimo requisitos
básicos do HL7 V2.X (ADT, ORU, ORM, etc.).
Essas são leituras/visões interessantes sobre a experiência:
Dr. David Hay (New Zealand) – blog post

http://fhirblog.com/2014/10/05/mapping-hl7-version-2-to-fhir-messages/
Rene Spronk (The Netherlands) – whitepaper

http://www.ringholm.com/docs/04350_mapping_HL7v2_FHIR.htm
Simonne Heckman (Germany) - video

https://vimeo.com/128126357
Exemplo de Mensageria FHIR
Há um pequeno exemplo de mensagem FHIR no arquivo SmallMessage.xml, que

mantém informações sobre um paciente usando o evento admin-notify.
Se você pegar este arquivo para testar, experimente um POST para um servidor FHIR.
O Paradigma “Não amado” (The Unloved Paradigm)
Poucos servidores de teste FHIR dão suporte a este paradigma de mensageria, devido a
preferência de mercado por REST e Documentos.
Você poderá verificá-lo neste vídeo de Rene Spronk, da Holanda, na sua apresentação
no DevDays 2018 “Messaging, The Unloved Paradigm”, here:
https://www.youtube.com/watch?v=_ov5bYIRTpg

Documentos FHIR
Características de Documentos Clínicos
Há seis características definidas para Documentos Clínicos pelo HL7 CDA R2:
persistência, administrabilidade (stewardship), potencial para autenticação, contexto,
completude, e legibilidade humana.
• Persistência: o documento deve ser armazenado e permanecer acessível na sua forma

original (além de autenticada) por um período de retenção. FHIR não requer que
recursos sejam armazenados a medida que forem enviados, mas isso é esperado para
documentos.
• Potencial para autenticação: O documento pode ser assinado. Em FHIR, a
autenticação é de todo o conteúdo e de uma específica visualização de conteúdo para
diferentes recursos.
• Contexto: No CDA R2, é definido pelo cabeçalho (document header). No FHIR, o
contexto existe independentemente de cada recurso. No entanto, documentos indicam
um conjunto de informação que deve ser consumida em conjunto (contexto humano
versus contexto técnico). Veremos a seguir quando discutirmos a estrutura de um
documento: isso é obtido através da composição de recursos.
• Completude: autenticação e contexto se aplicam a todo o conteúdo do documento,
não somente a partes específicas.
• Legibilidade humana: A legibilidade humana é opcional para recursos, mas obrigatória
para documentos, incluindo regras de visualização específicas.
A estrutura de documentos FHIR é mais flexível que a estrutura de CDA R2. Eles seguem
uma estrutura genérica que pode ser sobre qualquer assunto (Documentos CDA R2 tem
sempre o paciente como assunto): Design de ensaios clínicos, laudos, casos de saúde
pública, etc.
Finalmente, documentos FHIR podem ser processados de maneiras que não aderem às
seis características de documentos CDA (por exemplo, você pode simplesmente
processar os recursos de um CDA sem armazenar o documento como um todo
conforme transmitido pelo seu criador).
Isso não impede que projetos específicos sejam baseados em documentos FHIR
enquanto preservando as 6 características de um documento clínico.

Figura: visão conceitual de um documento FHIR
Estrutura de um Documento FHIR
O conteúdo de uma transmissão POST para o servidor para um documento FHIR é um

Bundle.
O Bundle.type deve ser do tipo “document”. O documento deverá incluir uma lista de
Entries. Para documentos, a primeira Entry deverá ser uma Composition, e alguns
outros recursos são OBRIGATÓRIOS, seja no Bundle (recomendado para a completude)
ou externamente referenciados na Composition.
Um documento, não importa o quanto complexo e aninhado, é uma lista achatada de

Entries, com o Document header como a primera Entry. O document header (e qualquer
outro resource) inclui referências para as Entries usando referências normais para
refletir o aninhamento do documento. Deverá haver uma assinatura digital do Bundle
para comprovar o conteúdo do documento.
Receita para documentos FHIR
Portanto, lembre-se:
1. A transação deverá ser Bundle do tipo value="document", com pelo menos uma
Entry: Composition de uma ou mais Entries para cada referência interna (algumas são
obrigatórias). Essa é uma receita mínima, portanto listaremos apenas os elementos

OBRIGATÓRIOS e referências, mesmo que seu cenário específico possa incluir outros
elementos como referência também
Atributos de uma Composition:
2. Bundle.id:identificação do bundle que deve ser globalmente única

3. Composition.id: identificação da composition que deve ser globalmente única. É o
identificador do documento
4. Composition.date: data e hora de quando o documento foi criado
5. Composition.title: Tttulo humanamente legível para o documento
6. Composition.code : Document Type, conforme http://www.hl7.org/fhir/valueset-doc-
typecodes.html (que se refere a todos os códigos de classe de documento do LOINC)
7. Composition.status: status atual de um documento. Tipos: preliminary, final,
amended, entered-in-error
Composition References (Além de Entries internamente referenciadas)
8. Composition.subject: quem e/ou sobre o que é a Composition (normalmente o

paciente)
9. Composition.author: autor da Composition, podendo ser um: Practitioner, Device,
Patient ou responsável pela autoria do documento
10. Composition.attester.party: Pacient ou Pratitioner atestando a precisão da
composição
11. Composition.custodian: Organization que mantém essa Composition
12. Composition.event.detail: Descrição do evento que está sendo documentado
13. Composition.encounter: Contexto da Composition
14. Composition.section.entry: o conteúdo clínico propriamente dado o tamanho do
documento não poderemos incluí-lo neste módulo, mas pode verificar no exemplo para
ver a estrutura.
Exemplo de documento FHIR
O arquivo SmallDocument.xml é um exemplo mínimo semanticamente válido de um

documento FHIR.
Novamente, se você quer experimentar esse documento no seu servidor FHIR, você
precisará transmitir esse Bundle para o endpoint de Bundles, já que nem todos os
servidores permitem processamento de elementos Composition.
http://fhir.hl7fundamentals.org/r4/Bundle

Apresentação de um documento FHIR
O documento deve ser apresentado nesta ordem: Composition Resource Narrative,

Subject Resource Narrative, section.text Narratives, usando estilo básico para as
narrativas conforme explicação dada aqui: http://www.hl7.org/fhir/narrative.html#css
Adicionalmente, um documento pode referenciar ou conter uma ou mais folhas de

estilo a serem aplicadas a narrativa.
Isso é feito através da inclusão da referência de uma folha de estilo ao Bundle. A URI
pode ser referenciada a um arquivo provisionado em um servidor web qualquer, ou
referenciado a um recurso incluído nesse mesmo Bundle.
<link>
<relation value="stylesheet"/>
<url value="[uri]"/>
…
</Bundle>
Transporte de documentos FHIR
Há várias aternativas para enviar documentos FHIR a um servidor, através de diferentes

terminais (endpoints).
Nenhum desses é obrigatório. Documentos podem ser intercambiados de qualquer

maneira imaginável (File System, FTP, USB sticks, etc.)
• baseurl/Bundle: Funciona como um se fosse um endpoint para gestão de tipos de

recursos, mas para Bundles como um todo, por exemplo: Uma operação de READ que
obtém um Bundle, um UPDATE que obtém um bundle e um SEARCH que retorna um
Bundle de Bundles.
• baseurl/Binary: Armazena o documento como uma sequência de bytes e retorna
exatamnte essa sequência quando requisitado. Normalmente é associado com uma
Document Reference para que aplicações possam localizar e processar o documento.
• baseurl (Transaction): Ignore o fato de que um Bundle é um documento e processa
todos os recursos individualmente. Clientes não devem esperar que um servidor seja
capaz de remontar o documento fidedignamente. Mesmo se o servidor pode remontar
o documento, o resultado não pode ser esperado na mesma ordem, etc. A assinatura
desse documento provavelmente será inválida.

Considerações sobre a arquitetura de documentos FHIR
• Persistência de documentos: não há ordem definida para as Entries em um

documento além da disposição primeira mensagem enviada. Portanto, envios
sucessivos na persistência desse documento (XML/JSON ou RDF) podem produzir
diferentes ordens na composição. Mesmo com canonização, assinaturas eletrônicas
podem ser perdidas na reconstituição a partir de suas partes. Se você se importa com a
assinatura, armazene documentos em seu formato binário (binary).
• Assinatura digital: qualquer Bundle (incluindo o documento) pode ter uma assinatura
digital XML. Assinaturas não são obrigatórias para documentos FHIR – outros meios para
verificar integridade também estão ok. Um ou mais recursos em um document podem
ser assinados incluindo um recurso do tipo Provenance.
• Tags e segurança: Tags (e metadados de segurança) podem aparecer ambos nas
Entries de um recurso quanto no nível de um Bundle. Se estiver utilizando security tags,
estabeleça precedência. A forma mais segura é “most restrictive applies”, mas regras de
negócio podem ser aplicadas diferentemente. Tags dentro de Entries de documento não
podem ser modificadas sem quebrar a assinatura do documento

Documentos FHIR e CDA R2
Projetos relacionados de FHIR e CDA R2 no HL7 Internacional
Esses são os principais projetos relacionados de FHIR e CDA R2 no HL7 Internacional.
• CDA ON FHIR: Projeto que define como documentos clínicos devem aparecer em FHIR.
Incluindo: perfis do recurso Composition (veremos perfis na próxima semana),
mapeamento de cabeçalho CDA (CDA header) na Composition e mapeamento alto nível
de root Entries para recursos correspondentes em FHIR.
https://www.hl7.org/fhir/cda-intro.html
• C-CDA ON FHIR: Projeto de mapeamento do CCDA e seu FHIR equivalente, incluindo
Profiles. Visão de longo prazo é uma nova versão de CCDA com equivalentes FHIR exatos
feitos em paralelo.
http://wiki.hl7.org/index.php?title=C-CDA_on_FHIR
• Para um comparativo completo entre CDA R2 e FHIR, acesse:
https://www.hl7.org/fhir/comparison-cda.html

Operações FHIR
Operações Estendidas na RESTFul API
Quando a API RESTFul definida por FHIR é um conjunto de interações comuns

(Create/Read/Update/Delete) e conjunto de recursos identificado não é suficiente, FHIR
te permite definir operações utilizando o paradigma RPC:
• Named operations são executadas com entradas (inputs) e saídas (outputs) (Execute).
• Operações são utilizadas quando:
1. o servidor precisa exercer um papel ativo na formulação do conteúdo de
resposta.
2. o propósito é causar efeitos colaterais como a modifcação de recursos
existentes, ou criação de novos recursos.
• O FHIR define um conjunto de operações simples em um framework que, de forma
desacoplada, estende a RESTFul API, da seguinte maneira:
1. Toda operação tem um nome
2. Cada operação tem uma lista de parâmetros de entrada (in) e parâmetros de
saída (out)
3. Parâmetros podem ser Resources, Data types ou Search Parameters
4. Operações podem estar sujeitas às mesmas restrições de segurança e
requisito da RESTFul API
5. A URI do endpoint da operação pode ser baseada no esquema de endereços
da RESTFul API vigente
6. Operações podem fazer uso usar o repositório de Resources e definições
7. Operações podem ser realizadas em um Resource específico, Resource Type
ou sistema como um todo
Executando Operações
Operações são um POST em um endpoint FHIR, onde o nome da operação é prefixada

com um dólar ('$'). Por exemplo: POST
http://fhir.someserver.org/fhir/Patient/1/$everything
Operações podem ser chamadas em quatro tipos de endpoints:
• O endpoint do serviço FHIR "base" (por exemplo, http://fhir.someserver.org/fhir):

opere na escala completa do servidor. Por exemplo, "devolva-me todas as extensões
conhecidas por este servidor"
• Um tipo de recurso (por exemplo, http://fhir.someserver.org/fhir/Patient): opere em
todas as instâncias de um determinado tipo de recurso
• Uma instância do recurso (por exemplo, http://fhir.someserver.org/fhir/Patient/1):
envolva apenas uma instância de um Recurso. Exemplo: a operação $ everything.
• Uma versão específica de uma instância de recurso
(http://fhir.someserver.org/fhir/Patient/1/_history/4): Somente para permitir a
manipulação de metadados de perfil e tag de versões anteriores
Parâmetros de operação
O corpo da invocação contém um recurso de infraestrutura especial chamado

Parameters, que representa uma coleção de parâmetros nomeados como pares <key,
value>, em que o value pode ser qualquer tipo de dados primitivo ou complexo ou
mesmo um recurso completo. Também pode incluir seqüências de caracteres
formatadas como tipos de parâmetros de pesquisa.
Resposta da Operação
Após a conclusão, a operação retorna outro recurso Parameters, contendo um ou mais

parâmetros de saída. Isso significa que uma operação FHIR pode receber qualquer
parâmetro e retornar um conjunto de parâmetros de resultado. O corpo do POST e o
resultado retornado são sempre uma fonte. Se uma operação for bem-sucedida, um
código de Status HTTP 200 OK será retornado. Um código de status HTTP de 4xx ou 5xx
indica um erro e um OperationOutcome pode ser retornado.
Operações definidas pelo FHIR
A especificação FHIR define várias operações, que podem ser encontradas em

http://www.hl7.org/fhir/operations.html#defined
Duas operações importantes que usaremos são $everything (se aplica a um paciente
específico) e $validate (valida um recurso com base na definição de recurso e / ou em
um perfil específico. Veremos perfis na próxima unidade)
Você pode tentar a operação $everything em relação a qualquer um dos recursos do

paciente que você enviou para o servidor FHIR, realizando um procedimento como este,
com [id] sendo o ID atribuído ao servidor para o paciente:
http://fhir.hl7fundamentals.org/r4/Patient/[id]/$everything
Ele retornará um pacote com todos os recursos atuais armazenados no servidor

pertencentes ao paciente.

Operações definidas pela implementação
As implementações são capazes de definir suas próprias operações, além daquelas

definidas pela especificação FHIR. Isso faz parte do perfil do FHIR e iremos explorar isso
na próxima unidade.

Quando usar…? Quando evitar?
Quando usar Interações / Transações RESTful
• Interoperabilidade simples e pronta para uso
• Alavancar HTTP - protocolo que impulsiona a web
• Use apenas operações predefinidas: Criar, Ler, Atualizar, Excluir - Também: Histórico,
Versão de leitura, Pesquisa, Atualizações, Validar, Conformidade e Lote
• Arquiteturas cliente-servidor, com orquestração orientada a cliente (Mobile, PHR,
Registries)
Quando evitar interações / transações RESTful

• Orquestração complexa ou orientada a servidor
• Unidade de trabalho não é o recurso
• Não há servidor "natural"
Quando usar a Mensageria FHIR

• Fluxo de trabalho de solicitação / resposta
• Precisa de modo assíncrono
• Comportamentos mais complexos que o CRUD
• Operações CRUD em transportes diferentes de HTTP
Quando evitar a Mensageria FHIR

• Quando há outra maneira padrão de fazer isso
Quando usar Documentos FHIR

• O foco está na persistência
• Nenhum fluxo de trabalho envolvido, exceto o documento de postagem /
recuperação
• Precisa de regras rígidas sobre o conteúdo autenticado
• Deseja comunicar vários recursos com controle sobre como os dados são
apresentados
• Os dados abrangem vários recursos
Quando evitar Documentos FHIR

• Necessidade de fluxo de trabalho
• Pedido/resposta, suporte à decisão
• Os dados são dinâmicos, ou seja, desejam visualizar os dados agora, não no momento
da autoria
• Vários colaboradores ao longo do tempo
• Os recursos precisam ser acessados independentemente

Quando usar Operações ou Serviços do FHIR
• Operações diferentes de CRUD sem sobrecarga de mensagens
• Fluxo de trabalho mais complexo que solicitação/resposta
• Mistura de documentos e comportamento
Quando evitar operações ou serviços FHIR

• Precisa de controle rígido sobre a exibição de dados
• Deseja evitar a pré-negociação de comportamento
Orientação geral
Não há absolutos. Esta seção é apenas para orientação. Sua escolha talvez seja
influenciada pela preferência e pelo legado, e talvez por outras considerações não
técnicas. Não se limite a apenas uma opção: misture e combine para atender aos seus
cenários, casos de uso e parceiros de comunicação.

Tarefa desta semana
Vamos tentar criar uma transação para um dispositivo vestível [falso] e enviar/recuperar
informações de sinais vitais para o nosso repositório FHIR. É agora! Esta é a parte
divertida de lidar com FHIR!

Resumo e Conclusão da Unidade
O FHIR não fará nada por você, mas permite a construção de sistemas interoperáveis
sólidos e atualizados. Esta unidade avançada deu algumas dicas sobre os paradigmas do
FHIR e quando / como usá-los.
Vamos tentar resumir em uma página o que você aprendeu, caso alguém pergunte no
elevador o que você aprendeu esta semana.
• RESTful: somente operações CRUD. Troca de informações um recurso de cada vez

(veja se o recurso existe no servidor, PUT/POST para atualizar se/conforme necessário)
• Transações: Bundle/type=transaction. Misture e combine qualquer tipo de recurso.
Falhar ou ter sucesso como um todo. Precisa de ajuda quando os IDs do servidor não
são conhecidos (ID do recurso temporário, interações condicionais).
• Lote: Bundle/type=batch. O mesmo que transações, mas pode ter êxito parcialmente.
Recursos não estão relacionados
• Documentos: Bundle/type=document. A primeira entrada é Composition, com
metadados sobre o contexto das entradas clínicas incluídas. Alguns atributos e
referências / entradas são obrigatórios.
• Mensagem: Bundle/type=message. A primeira entrada é MessageHeader, com
metadados sobre a mensagem, remetente e destinatário. Com base no paradigma da
mensagem do evento acionador. Eventos definidos pelo HL7.
• Operações: estendendo o comportamento dos servidores para operações específicas
e complexas. Comece com o sinal de $. Pode ser aplicado a todo o servidor, tipos de
recursos específicos ou instâncias de recursos específicas.
Quando usar? Guia de Orientações

Material de Leitura Adicional
Informações sobre o FHIR
Existem vários lugares onde você pode obter informações sobre o FHIR.
• A própria especificação está disponível on-line em www.hl7.org/FHIR. É totalmente

com hiperlink e muito fácil de seguir. É altamente recomendável que você tenha acesso
à especificação enquanto lê este módulo, pois há muitas referências a ele -
particularmente para alguns dos detalhes dos aspectos mais complexos do FHIR.
• Todos os assuntos detalhados nesta unidade estão profundamente documentados na
especificação FHIR. Se você não pode explicar alguma coisa, essa deve ser a primeira
fonte de verdade.
• A página wiki HL7 raiz do FHIR pode ser encontrada em
http://wiki.hl7.org/index.php?title=FHIR. As informações aqui são mais para aqueles
que desenvolvem recursos, mas ainda são muito interessantes. Algumas informações do
wiki são mais históricas e podem não refletir a versão mais recente da especificação.
• A equipe usa o site “stack overflow” (http://stackoverflow.com/questions/tagged/hl7-
fhir) como um local para responder a perguntas relacionadas à implementação - e,
portanto, tem perguntas e respostas disponíveis para referência. Você pode usar o HL7
Help Desk se for membro.

PDF FHIR R4 S3 LEITURA

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PDF FHIR R4 S3 LEITURA

Enviado por

Direitos autorais:

Formatos disponíveis

Curso de FHIR

Semana 3 – FHIR Avançado

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 1

Módulo II: Trabalhando com FHIR

Módulo III: FHIR Avançado

Módulo IV: Conformidade com FHIR

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 2

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 3

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 4

Nesta unidade exploraremos as opções, algumas técnicas avançadas e boas práticas,

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 5

Revisaremos e compararemos nesta unidade as quatro abordagens, apresentando

Os quatro paradigmas são: REST (+Transações), Documentos, Mensagens e Serviços (Ou

Dois outros paradigmas também serão explorados: Armazenamento (Storage) e Blocos

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 6

Um exemplo disso é um laudo de exame laboratorial. Um laudo de exame laboratorial

Observação: O verdadeiro nome para a nossa solicitação de exame de acordo com o

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 7

Client: Você conhece um paciente com o CPF 40928383?

E assim sucessivamente para todos os recursos …

Imagine um laudo de exame laboratorial com 1 paciente, 1 organização, 1 médico, 1

Múltiplas interações requerem múltiplas transmissões entre cliente e servidor e

A outra opção é enviar todos os recursos em um único “pacote” ou Bundle (lembre-se

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 8

A responsabilidade do processamento da requisição está todo nas mãos do servidor.

Transações são úteis quando precisamos evitar múltiplas interações.

POST [base] {?_format=[mime-type]}

Receita para Bundles de Transações (Bundle Transactions)

1. A transação deverá ser um Bundle do tipo value=”transaction”, com uma ou mais

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 10

O tipo do Bundle será “transaction-response” com as Entries e ações solicitadas pelo

A transação que será postada é o arquivo SmallTransaction.xml.

Você encontrará esse exemplo e outros XMLs que mencionaremos no material de

Lembre-se que nosso servidor base fica no endereço:

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 11

Figura: enviando uma transação Bundle para um servidor FHIR.

E você também pode vê-la aqui nas Figuras 4 e 5.

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 12

Figura: corpo da resposta da transação do servidor:

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 13

Isso pode ser feito através do recurso Patient ao referenciá-lo à ManagingOrganization.

Isso deverá ser realizado muito facilmente, apenas adicione o ID da

O problema é que a ManagingOrganization requer uma referência, e essa referência

Identificação Temporária de Recursos

Esse esquema especial de identificação é usado em transações para inserir uma

O escopo da identificação temporária de recursos só acontece dentro de um Bundle.

O recurso do tipo DiagnosticReport contém um Subject relacionando a um laudo

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 14

... Patient Resource contents

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 15

Você poderá verificar isso no arquivo SmallTransactionLinked.XML.

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 16

A requisição criou dois recursos. Se obtivermos o ID do Patient criado, vamos verificar o

Figura: referenciamento apropriado utilizando uma Identificação Temporária de Recurso

Mas... Ainda há um problema. Talvez você tenha notado. Talvez não.

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 17

O problema persiste. Portanto, mesmo usando transações e identificadores

Interações Condicionais permitem ao cliente FHIR evitar a criação de um recurso já

• Nenhum resultado encontrado: o servidor realiza uma criação do recurso

Por exemplo, um cliente atualizando um status de um laudo de exame laboratorial de

Observação importante: create/update/delete condicionais são interações complexas e

© 2020 HL7® Brasil & HL7® International - Proibida Reprodução 18

Vamos mudar um pouco nosso pequeno arquivo de transação. As mudanças estão