PDF FHIR R4 S4 LEITURA

Curso de FHIR
Semana 4 – Conformidade e Perfis

Leitura Obrigatória
1
© 2020 HL7® Brasil & HL7® International - Proibida Reprodução
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
2
Sumário
Conteúdo da Unidade e Objetivos de Aprendizagem 5
Por que precisamos de perfis? 6

Por que criamos perfis? 7
O que pode sofrer restrição? 8
Como documentamos as restrições? 9
Recursos de conformidade FHIR 9
Conformidade: Operations (Operações) 11

CapabilityStatement (Declaração de Conformidade) 11
OperationDefinition (Definição de Operação) 12
SearchParameter (Parâmetro de Busca) 14
Conformidade: Content (Conteúdo) 16

StructureDefinition (Definição de estrutura) 16
DataElement (Elementos de dados) 19
Extensões FHIR 19
Extensões Complexas 21
Extensões Modificadas (Modifier Extensions) 21
Binding 22
Conformidade: Terminology (Terminologia) 23

CodeSystem (Sistema de códigos) 24
ValueSet (Conjunto de Valores) 25
ConceptMap (Mapa Conceitual) 27
NamingSystem 27
Conformidade: Publishing 28
ImplementationGuide (Guia de Implementação) 28
Processando o ImplementationGuide 29
Validação de Recurso em um Perfil 30

Declaração de conformidade em instâncias de recursos 30
Validação de Recursos 31
Ferramentas para criar perfis 32

3
Forge 33
Trifolia 34
Simplifier 35
clinFHIR 36
Snapper 37
Alguns perfis importantes/guias de implementação 38

Argonaut Project 38
IHE-on-FHIR 41
Smart-On-FHIR 42
Guias Oficiais de Implementação do FHIR 43
Mais informações sobre criação de perfil FHIR 44
Tarefa desta semana 45
Resumo e Conclusão da Unidade 46
Material de Leitura Adicional 47
4
Conteúdo da Unidade e Objetivos de Aprendizagem
Esta unidade discute alguns tópicos avançados sobre a criação de perfil FHIR: como definir
extensões e restrições aos recursos FHIR e como documentar essas restrições.
Esta unidade complementa o que você aprendeu na unidade da semana passada: você
pode combinar qualquer recurso e estender o FHIR livremente, mas precisa documentar
suas escolhas: deixe o mundo saber (ou pelo menos seus parceiros na troca de
informações, atuais e futuros) o que cada aplicativo deve enviar e receber e como validar
os recursos antes de ir para (ou mesmo enquanto está a caminho da) produção.
A boa notícia é que o formato da documentação está na forma de recursos FHIR.
Nota: Esta unidade é vagamente baseada na aula de 'Profiling Concepts' de Graham

Grieve, ministrada durante o FHIR DevDays 2014-2017, no tutorial 'FHIR for Specifiers' de
Michael Rutten e nas interpretações e experiências dos autores da unidade.
Os recursos de conformidade foram aumentados e renovados para o STU3, e constituem

boa parte do que se torna normativo no R4 (Nível de Maturidade 5 do FHIR).
Nosso objetivo para esta unidade NÃO é que você se torne um especialista em
Conformidade e Criação de Perfil FHIR, mas pelo menos familiarizá-lo com os recursos e
ferramentas envolvidos e com o uso esperado, além de fornecer alguns exemplos de
uso.
Também queremos chamar a sua atenção para algumas fontes importantes de guias de
implementação.
5
Por que precisamos de perfis?
FHIR é uma especificação internacional, usada em contextos múltiplos e diversos. Como
você já deve ter notado, cada servidor pode implementar um subconjunto da
especificação em termos de recursos, conteúdo, formato e mecanismos de transporte.
De fato, há muito mais discordâncias do que acordos. Leis, regulamentos, culturas,

requisitos, ferramentas e diferenças populacionais podem mudar os objetivos dos
sistemas e da troca de informações.
O mesmo conceito pode ser implementado em diferentes sistemas usando diferentes

componentes, atributos, etc.
Exemplo, como visto na Figura:
● Sistema 1: Alergia: Descrição (codificada) + Natureza da Reação

● Sistema 2: Alergia: Descrição (codificada) + Texto + Natureza da reação +
Gravidade
● Sistema 3: Alergia: Descrição (codificada) + Texto + Genérico + Classe + Molécula
● Sistema 4: Alergia: Descrição (codificada) + Comentários + Status + Data de Início
+ Reações (codificadas)
6
Figura: Diferentes abordagens de sistemas para o mesmo conceito.
Portanto, o FHIR precisa ser implementado independentemente dessas diferenças, mas

também expressando, de alguma forma, as escolhas e a implementação específica em
cada site ou região.
Durante muito tempo, os perfis no HL7 foram desenvolvidos em uma sintaxe diferente
do padrão (Schematron, grandes arquivos do Word, arquivos XML especiais e schemas,
etc.). Expressar perfis sempre foi uma reflexão tardia.
O FHIR traz uma nova visão para conformidade e validação: perfis, declarações de
conformidade e guias de implementação podem ser criados usando recursos FHIR e um
servidor FHIR pode validar instâncias de recursos com base nesses perfis, assumindo uma
das operações definidas.
Portanto, o FHIR introduz a criação de perfil embutida: um perfil é definido e verificado

usando o mesmo padrão e pelos mesmos servidores.
Podemos ver o FHIR como uma "especificação de plataforma": sempre precisaremos de

acordos adicionais. A única diferença das especificações HL7 anteriores é que esses
contratos são computáveis e até 'detectáveis': você pode perguntar a um servidor quais
serviços ele pode fornecer e agir em conformidade.
Por que criamos perfis?
1. Para comunicar aos colegas o que foi decidido ou esperado

2. Permitir comparação e verificação automáticas
3. Suportar a geração de código/descoberta em tempo de execução
7
4. Criar um ecossistema de publicação/assinatura
5. Permitir validação de conformidade
Um servidor FHIR se torna, também, uma ferramenta de extensão, perfis, guias de

implementação e registro e de validação de recursos.
O que pode sofrer restrição?
Na maioria das vezes, todos os componentes para um servidor FHIR podem sofrer
restrições. As perguntas básicas são “O que é usado?”, “O que NÃO é usado” e “O que é
estendido?”.
A premissa básica é "Não podemos anular a especificação":
1. Se algo é obrigatório no FHIR, não podemos considerá-lo opcional ou não

utilizado;
2. Se um código está vinculado a um vocabulário obrigatório no FHIR, não podemos
mudar o vocabulário.
Uma pequena lista de itens que podemos restringir:
Elementos em recursos:
● Quais elementos opcionais são obrigatórios para nós?

● Quais elementos precisam ser repetidos em nossa implementação? Como
podemos diferenciar as repetições?
Códigos em elementos codificados:
● Quais terminologias são usadas? Aplicadas a quais elementos codificados?
Comportamento:
● Quais interações específicas da API RESTful são suportadas por nossos servidores
para cada recurso que gerenciam?
● Permitimos a exclusão de recursos? Apoiamos o versionamento?
● Operações especiais: definição de operação especial não-Crud e seus parâmetros
Pesquisas:
8
● Quais parâmetros de pesquisa nossos servidores suportam?
Extensões:
● Quais extensões específicas suportamos ou exigimos? Aplicado a quais

recursos/elementos/tipos de dados?
Como documentamos as restrições?
Restrições e suas instruções de uso precisam ser:
1. De autoria estruturada
2. Publicada em um repositório
3. Usado como base para validação, código e geração de UI
Recursos de conformidade FHIR

O HL7 escolhe os recursos do FHIR a serem usados para a expressão dessas restrições.
Vamos explorar o uso de cada recurso e suas combinações, dividindo-os em quatro áreas:
9
Como você já deve ter pensado, o recurso ImplementationGuide agrupa todos os outros
recursos em um pacote para publicação e os disponibiliza para os implementadores.
Nota: Existem mais recursos de conformidade (MessageDefinition, GraphDefinition,

CompartmentDe-finition, etc.), mas focaremos neste subconjunto porque inclui os mais
amplamente utilizados.
10
Conformidade: Operations (Operações)
Esse grupo de recursos é sobre o servidor BEHAVIOR, o que o servidor pode e não pode
fazer e como isso é implementado.
CapabilityStatement (Declaração de Conformidade)
Este é o recurso mais importante neste espaço: permite ver quais chamadas específicas
da API o servidor aceitará e sobre quais tipos de recursos.
Talvez seja a primeira coisa a fazer ao implementar ou confrontar (como um cliente FHIR)
um servidor.
Você pode ver uma renderização parcial de um CapabilityStatement na figura abaixo:
Figura: Renderização parcial de uma CapabilityStatement.
Você também pode procurar a declaração de capacidade do servidor deste curso (ou
qualquer outra) colando-a no navegador da Internet ou no cliente REST (pode demorar
um pouco, seja paciente): http://fhir.hl7fundamentals.org/r4/metadata
Informações incluídas na declaração de conformidade:
● Server wide: nome e versão do software, operações especiais suportadas e seus

parâmetros, versão do FHIR e sintaxes suportadas (JSON, XML, outros).
11
● Por classe de recurso: interações CRUD suportadas, criação/atualização/exclusão
condicional para cada tipo de recurso, inclusões de pesquisa e parâmetros de
pesquisa.
OperationDefinition (Definição de Operação)
A API RESTful define um conjunto de interações comuns (leitura, atualização, pesquisa

etc.) executadas em um repositório de recursos digitados. Essa abordagem resolve muitos
casos, mas às vezes é melhor usar um paradigma semelhante ao RPC, complementando
as operações CRUD regulares.
Nesse paradigma, existem operações nomeadas, executadas com parâmetros de entrada

(recursos, dados). As operações nomeadas são chamadas nos servidores FHIR usando o
símbolo de cifrão (fhirser-ver.com/base/$operation_name).
As operações podem ser executadas em uma instância de recurso específica, em um tipo

de recurso ou em um sistema inteiro.
O recurso OperationDefinition permite fornecer uma definição legível e computável da

operação (não CRUD) definida pelo servidor personalizado.
Você pode ver essa definição no arquivo OperationDefinitionExample.xml (não incluído

aqui devido a limitações de espaço).
Este recurso inclui a descrição da operação e, para cada parâmetro, o uso (IN/OUT),
Nome, Cardinalidade, Tipo e Binding.
No exemplo, a operação é definida no recurso Composition (para usá-lo, você chamaria

http://someserver.fhir/base/Composition/222/$document).
Cada operação é definida por:
● Contexto (Context): sistema, tipo de recurso ou instância de recurso.

● Nome (Name): Um nome para a operação.
● Idempotente: a operação não altera os recursos subjacentes, portanto pode ser
usada por meio de um GET.
● Lista de parâmetros, com essas informações para cada parâmetro:
○ Nome (Name): o nome do parâmetro.
○ Uso (Use): In|Out|Both.
○ Tipo (Type): um tipo de dados ou um tipo de recurso.
12
○ Perfil (Profile): StructureDefinition que aplica restrições adicionais sobre o
recurso.
○ Documentação (Documentation) - uma descrição do uso do parâmetro.
Esta é uma representação JSON muito pequena da operação $ihe_pix definida pelo IHE
PIX Mobile Implementation Guide:
"resource":{
"resourceType":"OperationDefinition",
"name":"$ihe-pix",
"status":"draft",
"type":[
"Patient"
],
"parameter":[
{
"name":"sourceIdentifier",
"use":"in"
},
{
"name":"targetSystem",
"use":"in"
},
{
"name":"_format",
"use":"in"
}
]
},
GET[base]/Pacient/$ihe-
pix?sourceIdentifier=[token]]{&targetSystem=[uri]}{&_format=[mime-type]}
● Parâmetro 1: sourceIdentifier (1..1) Token - O parâmetro de pesquisa do

identificador do paciente que será usado pelo Patient Identifier Cross-Reference
Manager para encontrar identificadores de correspondência cruzada associados
ao recurso do paciente;
13
● Parâmetro 2: targetSystem 0..1 uri - O Patient Identifier Assigning Authority de
destino a partir da qual o identificadores retornados devem ser selecionados;
● Parâmetro 3: _format 0..1 mime-type - O formato solicitado da resposta.
Exemplo da chamada:
[base]/Pacient/$ihe-
pix?sourceIdentifier=urn:oid:1.3.6.1.4.1.21367.2010.1.2.300|NA5404
Você pode ver uma descrição completa de uma operação FHIR aqui:
https://www.hl7.org/fhir/operation-patient-match.html.
SearchParameter (Parâmetro de Busca)
Todos os parâmetros de pesquisa suportados pelos recursos padrão do FHIR são definidos
usando o recurso SearchParameter.
Inclui todas as informações necessárias sobre a maneira como essa classe de recurso
específica pode ser pesquisada dentro de um servidor FHIR:
● code (como o parâmetro é nomeado em pesquisas reais)

● type (número, sequência, token, etc.)
● target (a qual recurso é o parâmetro aplicado)
● xpath ou fhir path (em que local do recurso está esse conteúdo relacionado a este
parâmetro)
Nota: Quer saber o que é um ´fhri path´? O FHIR precisava de um equivalente ao XPath
para JSON, ou melhor ainda, de algo que pudesse se referir logicamente ao conteúdo de
um recurso, independentemente da sintaxe. Portanto, 'FHIRPath'. Se você quiser saber
mais sobre o FHIRPath, leia o seguinte: http://hl7.org/fhirpath/
Esse recurso também é usado se você deseja oferecer suporte a pesquisas não definidas
pela especificação principal. Para fazer isso, você precisa criar um novo SearchParameter
para o seu recurso e incluí-lo na declaração de conformidade do servidor e no guia de
implementação do seu projeto.
Aqui você pode encontrar um exemplo de um SearchParameter especial definido pelo

HL7 (neste caso, é ‘procurando por uma extensão’):
14
http://hl7.org/fhir/searchparameter-example-extension.html
15
Conformidade: Content (Conteúdo)
StructureDefinition (Definição de estrutura)
Visão geral
O StructureDefinition permite a criação de tipos e recursos básicos, ou seja, todos os

recursos FHIR são expressos como recursos do StructureDefinition.
Basicamente, é um cabeçalho com informações sobre a própria estrutura: versão do FHIR,

editor, base fonte, mapeamentos e contexto, além de uma lista de definições de
elementos de dados.
Uso: StructureDefinition é usado para definir perfis/restrições de recursos:
1. Limitar cardinalidade
2. Alterar mapeamentos de conjunto de valores
3. Adicionar restrições adicionais
4. Adicionar extensões
5. Definir mapeamento externo ou lógico
Lembre-se do princípio básico: ao fazer tudo isso, você não pode contradizer as definições
básicas da norma: elementos obrigatórios e codificação, etc. Um elemento com perfil
ainda é um elemento do mesmo tipo.
Perfis StructureDefinition
A lista de definições específicas de um elemento de dados é de fato duas listas possíveis:
● Diferential: uma lista de elementos que foram alterados a partir da definição

original. Isso reflete a visão humana do recurso perfilado. É escasso (contém
apenas as informações mínimas necessárias).
● Snapshot: é o resultado da aplicação do diferential na StructureDefinition de base,

na qual esta definição particular se fundamenta. Lista tudo o que é permitido no
recurso. Usado principalmente pelas ferramentas.
16
Slicing (Fatiadores) e Discriminadores
Qualquer recurso que permita mais de uma repetição pode ser perfilado usando o slicing.
Por que precisamos re(fazer) um perfil de repetições? Alguns casos de uso a seguir:
1. Exatamente dois identificadores de pacientes são necessários: identificação

nacional do paciente e identificação local.
2. Exatamente duas observações, com códigos específicos para cada uma. Exemplo:
Perfil da pressão arterial: PA sistólica + PA diastólica, conforme mostrado na
figura.
3. Não precisamos de nenhum recurso de observação, precisamos de duas
observações específicas, identificadas por seu código/valor.
Figura: exemplo de slicing: duas observações necessárias como componentes
Exemplo de slicing:
Num pequeno país fictício, o Berzerquistão, o Ministério da Saúde (MS) precisa

para seu Repositório Unificado de Assistência Médica receber um pacote com
recursos de pacientes, organizações, profissionais, encontros e condições, sempre
que uma doença específica ('doença reportável') é diagnosticado.
Os pacientes no Berzequistão são identificados pelo BNI (Identificador Nacional
do Berzequistão), mas como houve alguns problemas (repetições, designações
17
erradas etc.), o Ministério da Saúde também criou um Identificador Nacional de
Saúde (NHIB). Para o recurso do paciente, os dois identificadores são obrigatórios.
É assim que o slicing se parece. observe como dividimos o elemento identificador para
que agora sejam necessários dois elementos identificadores. Nesse caso, a fatia é baseada
no atributo identifier.system:
● O primeiro deles precisa ser avaliado como www.berzerkistan.gov/bni
● O segundo deles precisa ser avaliado como www.berzerkistan.gov/nhib
E é assim que uma instância válida se parece (a parte Patient.identifier)
<identifier>
<system value=www.berzerkistan.gov/bni/>
<value value=”73928192”>
</identifier>
<identifier>
18
<system value=www.berzerkistan.gov/nhib/>
<value value=”340323-20-09”>
</identifier>
DataElement (Elementos de dados)
Os elementos de dados descrevem as características de um dado - identificador, nome,

definição, tipo de dados, comprimento (lenght), conjunto de valores permitidos, notas de
uso etc. Eles são usados dentro do StructureDefinition como seus blocos de construção.
Extensões FHIR
Em nossa primeira unidade, você aprendeu a incluir uma extensão na sua instância de
recurso FHIR. Lembre-se: é composto por um URL e um valor, o URL apontando para a
definição de extensão.
Aqui, você aprenderá como DEFINIR extensões, sendo que uma extensão também é
definida usando um recurso StructureDefinition.
Extensão simples
Uma extensão simples é uma extensão como vimos até agora: valor único.
Vamos ver um exemplo de extensão:
No mesmo minúsculo país, o Berzerquistão, onde o Estado cobra imposto sobre

os Prestadores de Saúde Privada (PPH), as pessoas que não possuem cobertura
(“uncovered” - sem cobertura), pagam 21% de imposto sobre a fatura do serviço
de saúde privado; pessoas que escolhem uma companhia de seguros (“voluntary”
- voluntários) pagam 10,5% imposto sobre PSP; pessoas que usam os serviços dos
sindicatos (“mandated” - representados) não pagam imposto sobre PSP – isso foi
decidido depois que os sindicatos lideraram uma enorme greve nacional que
durou 6 dias em novembro de 2010 .
Esta é a tabela PatientTaxSituation de PSP do Berzerquistão:
Código PPH Descrição PPH Imposto PPH

U Uncovered/Sem cobertura 21%
V Voluntary/Voluntários 10,5%
19
M Mandated/Representados 0%
Cada paciente tem uma categoria de imposto atribuída, chamada

"PatientTaxSituation". É um elemento codificado. Como não existe esse item no
recurso Pacient, conforme definido pelo padrão HL7 FHIR, o Ministério da Saúde
decidiu criar uma extensão FHIR.
Você pode ver essa definição no arquivo que se encontra no apêndice da unidade:
SimpleExtensionExample.xml.
Alguns destaques da definição de extensão:
● Metadados sobre a extensão: nome, status, descrição, requisitos, fhirVersion.

● constrainedType: tipo de elemento. Neste caso, estamos restringindo Extension,
ou seja, definindo uma nova extensão.
● contextType: onde esse elemento é usado: em um recurso, em um datatype?
Nesse caso: recurso.
● context: a qual recurso esta extensão se aplica? No nosso caso: Patient.
Finalmente, a definição inclui o diferencial para a extensão. Extensões simples têm dois
elementos: url e value[x], sendo qualquer URL e uma escolha de valores (quantidade,
string, etc.).
Essa extensão específica (portanto, o "diferencial") tem:
1. Um URL fixo:
http://fhir.hl7fundamentals.org/berzerkistan/StructureDefinition/PatientTaxSitu
ation.
2. Um tipo de valor específico: Codificação.
Talvez você pense: “Algo falta nessa explicação! Por que o governo do Berzerquistão
cobra impostos sobre serviços de saúde?".
Essa é uma ótima questão, mas não era essa pergunta que tínhamos em mente.
Infelizmente não podemos responder a isso.
A pergunta seria “Onde está a tabela de códigos PPH? Como sabemos que estamos
usando o código correto para a situação tributária do paciente em nossa instância?”.
Há também uma parte do StructureDefinition em que podemos incluir isso e um recurso

especial a ser consultado nesta tabela, chamado ValueSet.
20
A parte da extensão (o que se aplica a qualquer elemento codificado restringido pela
especificação FHIR ou por um perfil específico) que define onde encontrar o valor definido
para validar os códigos é chamado de Binding.
O exemplo ValueSet (a tabela no formato de recurso FHIR) que extrai os valores do

sistema de codificação original está no arquivo SmallValueSetExample.xml.
Você pode encontrar mais informações na próxima seção (Terminologia) sobre ValueSets
e CodeSystems e como construí-los.
Extensões Complexas
Extensões complexas são definidas por uma URL e uma lista de elementos. De fato,
extensões complexas podem ser a base de recursos completamente novos, se nenhum
recurso FHIR atender às suas necessidades. Isso pode ser alcançado usando uma nova
entidade chamada de recurso "Básico".
Você pode estender um recurso básico com todas as extensões necessárias (consulte
https://www.hl7.org/fhir/basic.html) e criar seus próprios recursos FHIR. Um exemplo
disso está aqui http://standardhealthrecord.org/fhir/.
Na verdade, o que queremos, é deixar você avisado: isso fará pouco para a
interoperabilidade global geral. Por favor não. Não faça isso. Por favor nããão!
Extensões Modificadas (Modifier Extensions)
Modifier Extensions são extensões que os parceiros de intercâmbio em uma

implementação específica precisam entender e usar porque ALTERAM o significado do
recurso.
Exemplos disso são: gravar uma instrução para NÃO tomar um medicamento, usar o
recurso Condition para transmitir o fato de que a condição específica pertence a outra
pessoa e não ao próprio paciente, afirmar que um executante NÃO esteve envolvido em
um procedimento.
Portanto, se sua extensão modificar o conteúdo do recurso e o recurso NÃO puder ser
processado com segurança pelos aplicativos que a IGNORAM, elas merecerão o nome de
Modifier Extension.
21
Declarar uma Modifier Extension é simples: basta incluir isModifier = True na definição da
estrutura.
Todavia, a implementação de Modifier Extensions é mais difícil, uma vez que você
precisará adicionar essas informações no seu sistema e em todo o pipeline para troca com
parceiros e vice-versa.
Modifier Extensions são incluídas usando o elemento modifierExtension em vez do

elemento Extension.
Binding
Binding o é o relacionamento entre um elemento codificado e o valor definido para sua

validação.
Inclui ´strength´ (“força” – o quão rigorosa é a validação de código?) E 'valueSetReference'

(onde está a lista de códigos que podemos usar?).
As opções para Binding strength (“força de ligação”) são:
● “required”: nenhum outro código pode ser usado em uma instância

● “example”: esses códigos são apenas um exemplo
● “preferred”: preferimos esse conjunto de códigos, mas outros podem ser usados
● “extensible”: você pode adicionar seus próprios códigos a esta lista
<binding>
<strength value="required"></strength>
<description value="PPH Tax Table"></description>
<valueSetReference>
<reference
value=
"http://fhir.hl7fundamentals.org/berzerkistan/ValueSet/PatientTaxSituation">
</reference>
</valueSetReference>
</binding>
22
Conformidade: Terminology (Terminologia)
Estes são recursos relacionados à terminologia/vocabulário. O mais importante para a
implementação do perfil é o ValueSet: você pode armazenar o seu ValueSet restrito em
um servidor FHIR e referenciar as restrições de vocabulário no seu perfil contra o servidor.
Aqui estão todos os recursos terminológicos e seus relacionamentos:
A diferença disso com relação a implementação anterior de vocabulário utilizando

padrões HL7, é que as referências ao vocabulário podem "resolver", ou seja, você pode
pesquisar, realmente, o vocabulário no servidor que o contém, não sendo apenas uma
referência a um arquivo separado por vírgula que precisamos baixar e/ou importar para
o sistema.
CodeSystems, ValueSets e ConceptMaps no FHIR têm suporte para operações especiais,

destinadas a criar Serviços de Terminologia.
Nota: Deseja entender o que um serviço de terminologia faz? Por favor, leia:
https://www.hl7.org/fhir/terminology-service.html
23
CodeSystem (Sistema de códigos)
Os CodeSystems definem um conjunto de códigos com significado, bem como quais

códigos existem e como são entendidos. Também são conhecido como terminologias,
classificações, enumerações ou ontologias.
O recurso do CodeSystem possui uma URL de identificação (a qual nunca muda,

independentemente de onde o recurso está armazenado fisicamente), versão e outros
metadados. Este recurso não se destina à manutenção do CodeSystem, mas a publicar os
metadados e (opcionalmente) o conteúdo (conjunto de códigos) para suportar expansão
e validação. Os sistemas de código grandes (SNOMED CT, LOINC ICDx) têm seus próprios
métodos de publicação e distribuição.
Os sistemas de códigos publicados externamente têm uma URL especial definida para seu
uso nos artefatos FHIR. Você pode encontrar a maioria deles aqui:
https://www.hl7.org/fhir/terminologies-systems.html.
A publicação de recursos CodeSystem destina-se a sistemas de código ad-hoc menores.
Este é um exemplo de um sistema de código:
Em um pequeno país fictício, o Berzerquistão, o Ministério da Saúde (MS)

determinou que todas as organizações e profissionais cobrassem de seus
pacientes uma porcentagem das taxas pelos serviços, com base em uma
classificação criada pelo MS, denominada "Situação Fiscal do Paciente".
Você pode encontrar uma definição simples do CodeSystem para o Ministério da Saúde
do Berzerquistão, voltado para a aplicação de um imposto para assistência médica, aqui:
CodeSystemSimpleExample.json.
Você também pode encontrar este exemplo no servidor do nosso curso:

http://fhir.hl7fundamentals.org/r4/CodeSystem/17582.
Esta é a operação terminológica mais simples para uma pesquisa CodeSystem: $ (não é
apenas uma pesquisa de código, podendo implicar na recuperação e no retorno das
informações conceituais das informações subjacentes ao sistema de códigos)
[basefhir]/$lookup?system=[system]&code=[code]
Você pode experimentá-lo, procurando o código "M" neste CodeSystem:

24
http://fhir.hl7fundamentals.org/r4/CodeSystem/$lookup?system=http://fhir.hl7fundam
entals.org/berzerkistan/CodeSystem/PatientTaxSituation&code=M
ValueSet (Conjunto de Valores)
ValueSet são a maneira de expressar exatamente quais valores são aceitos para o
sistema/valor de um elemento codificado. No seu guia ou perfil de implementação, você
pode vincular cada elemento codificado a um conjunto de valores específico. Você pode
criar um conjunto de valores:
a) Enumerando os conceitos específicos de um ou mais sistemas de códigos.
Exemplo: https://www.hl7.org/FHIR/valueset-doc-section-codes.html
b) Definindo alguns critérios pelos quais os conceitos são extraídos do sistema de código
original.
Exemplo: https://www.hl7.org/FHIR/STU3/valueset-activity-reason.html. Este conjunto

de valores extrai "todos os códigos do SNOMED CT onde o conceito é-a 404684003
(achado clínico)".
25
Operações ValueSet: $expand e $validate
Não estamos discutindo detalhadamente todas as questões de vocabulário neste curso

introdutório, mas introduziremos três operações terminológicas. A primeira foi '$lookup'
para o CodeSystem. Agora vamos rever duas operações para o ValueSet: $expand e
$validate.
É claro que são mais complexas do que parecem aqui, mas vamos usá-las apenas para
mostrar o conceito de Operações e o fato de que o perfil, as restrições e o vocabulário do
seu guia de implementação, todas as operações nativas do seu servidor FHIR podem ser
aproveitadas, se implementadas, é claro.
Por uma questão de curiosidade, agora que você conhece a tabela PPH, execute essas
operações em nosso serviço, sem necessidade de usar um cliente FHIR ou REST, apenas
no seu navegador da Internet:
http://fhir.hl7fundamentals.org/r4/ValueSet/17583/$expand.
Isso deve retornar toda a tabela de impostos PPH:

http://fhir.hl7fundamentals.org/r4/ValueSet/17583/$expand?filter=MANDATED.
Isso incluirá apenas os códigos para MANDATED.
E finalmente estes dois:

http://fhir.hl7fundamentals.org/r4/ValueSet/$validate-co-
de?system=http://fhir.hl7fundamentals.org/berzerkistan/CodeSystem/PatientTaxSituati
on&code=M&display=MANDATED.
Você deve receber a mensagem "Código encontrado".
26
http://fhir.hl7fundamentals.org/r4/ValueSet/$validate-co-
de?system=http://fhir.hl7fundamentals.org/berzerkistan/CodeSystem/PatientTaxSituati
on&code=O&display=OTHER.
Você deve receber a mensagem "Código não encontrado".
ConceptMap (Mapa Conceitual)
O ConceptMap permite definir com precisão o relacionamento entre conceitos (e seus

códigos relacionados) em um determinado sistema de códigos para conceitos presentes
em outro. Esse mapeamento não é "absoluto", talvez dependa do caso de uso (é um
mapeamento para uma finalidade específica).
Este recurso inclui os metadados do mapa (origem e destino, versão, autor etc.) e uma
lista de códigos no sistema de códigos fonte e o relacionamento de cada código com um
ou mais códigos no sistema de códigos de destino.
Você pode ver um exemplo aqui, onde o tipo de amostra para HL7 V2 Tabela 0487
(Specimen type - Tipo de amostra) é mapeado para SNOMED CT:
https://www.hl7.org/fhir/conceptmap-example-specimen-type.html.
Este recurso possui uma operação especial chamada $translate, que permite ao servidor
fornecer a equivalência de um sistema de códigos aos códigos existentes em um sistema
de códigos fonte.
Este é um exemplo desta operação:
GET [base] /ConceptMap/$translate?system=http://hl7.org/fhir/composition-status

& code = preliminar & valueSet = http://hl7.org/fhir/ValueSet/composition-status
& target = http: //hl7.org/fhir/ValueSet/v3-ActStatus
NamingSystem
Esse recurso representa um espaço para nome que emite identificadores exclusivos para
conceitos (classificação, sistemas de códigos, conjuntos de valores etc.) ou entidades
(pessoas, dispositivos, organizações, pedidos, etc.).
Você usará um dos elementos uniqueId.value do NamingSystem para usar como

"sistema" em seus elementos codificados ou identificadores.
27
NamingSystem inclui o nome, tipo (sistema de código ou identificador), responsável,
editor, contexto de uso e todos os identificadores exclusivos equivalentes para o sistema.
Você pode explorar um exemplo do NamingSystem aqui:

https://www.hl7.org/fhir/namingsystem-example-
id.xml.html#DomainResource.text.div-end.
Conformidade: Publishing
ImplementationGuide (Guia de Implementação)
Um ImplementationGuide é um pacote que agrupa um conjunto de StructureDefinition,

NamingSystem, OperationDefinition, ValueSet e todos os outros recursos de
conformidade necessários, destinados à publicação. Ele contém o nome, status, versão
do FHIR em que se baseia e também as páginas HTML ou markdown com a narrativa do
guia de implementação (cenários, casos de uso, detalhes de interação etc.).
Portanto, um guia de implementação típico incluirá:
1. Título
2. Sumário
3. Informação do documento
4. Introdução ao guia
5. Princípios e antecedentes
6. Casos de uso funcionais no nível de requisitos
7. Considerações de projeto
8. Conteúdo da embalagem
9. Orientação sobre privacidade e segurança
10. Lista de todos os artefatos utilizados
Os itens de 1 a 9 são apenas páginas (html ou markdown) que você precisa criar, usando
o editor que desejar e os artefatos de formatação auxiliares (arquivos css, js, img). O item
10 é uma lista de todos os recursos restritos agrupados em pacotes. Você também pode
incluir dependências em outras diretrizes de implementação. Você pode criar um guia de
implementação com base nos recursos criados por outro guia de implementação (lembre-
se de que os guias de implementação também são recursos do FHIR, portanto, essa
dependência é realmente computável).
28
Processando o ImplementationGuide
Para criar e publicar um guia de implementação, mesmo que você tenha o recurso
ImplementationGuide, o processo ainda pode ser complicado.
Algumas opções:
● Salve todos os seus recursos e narrativa no Simplifier e peça ao Simplifier para criar
seu guia de implementação. O guia de implementação será semelhante a este
abaixo:
29
● Execute a ferramenta de publicação FHIR IG (baseada em Java/Ruby). A vantagem
desta opção é que o IG será exatamente igual aos IGs publicados pela HL7. Se você
estiver interessado em explorar esta opção, há uma página wiki explicando como
instalar/usar a ferramenta:
http://wiki.hl7.org/index.php?title=IG_Publisher_Documentation e também um
PPT com um guia passo a passo das etapas do processo: https://goo.gl/6hB1ZP.
Validação de Recurso em um Perfil
Declaração de conformidade em instâncias de recursos
Para declarar conformidade com um perfil específico em uma instância/recurso do FHIR,

é necessário incluir uma tag específica: profile na seção de metadados da instância do
recurso, referenciando o guia ou perfil de implementação.
<meta>
<profile
value= "http://fhir.server.org/ImplementationGuide/HealthCareClaim"
</meta>
30
Validação de Recursos
Em princípio, os recursos podem ser validados de acordo com a especificação original (o

padrão FHIR), com um guia de implementação (conformidade) ou com um perfil
específico (conformidade). Os recursos podem ser testados quanto à conformidade:
1. usando o Schema XML (apenas para instâncias XML), basicamente o que você fez
em nossas primeiras unidades.
2. usando o validador FHIR (é um JAR em java que você pode baixar aqui:
https://www.hl7.org/fhir/validator.zip).
3. perguntando a um servidor FHIR, usando a operação especial $validate. A maneira
mais simples de executar esta operação é postar o recurso em um servidor:
Exemplo de operação $ validate:
POST[base]/Patient/$validate?profile=http://hl7.org/fhir/StructureDefinition/daf
-patient
O recurso <patient> a ser verificado precisa estar no corpo do POST. Depois de

validar o recurso, o servidor retornará um recurso OperationOutcome com os
problemas encontrados.
Lembre-se de que nem todos os servidores suportam a operação $validate,

embora alguns servidores públicos de teste o façam. Os servidores que suportam
a operação $validate somente validarão com relação aos perfis já registrados no
servidor.
Todos esses métodos de validação estão incompletos, uma vez que só podem validar os
aspectos 'computáveis' do desempenho.
Algumas regras narrativas só podem ser verificadas pela inspeção dos recursos. O
Schema/Schematron é o menos capaz pois não verifica a terminologia.
A palavra final é sempre derivada da inspeção humana do conteúdo dos recursos e da

comparação com os requisitos relevantes dos guias de implementação.
31
Ferramentas para criar perfis
Você pode criar recursos de conformidade, assim como qualquer outro recurso FHIR,
editando XML ou JSON, mas é um processo muito complicado e complexo.
Várias ferramentas para criar recursos de conformidade com o FHIR foram desenvolvidas
(e continuam evoluido). Abaixo, seguem algumas. Nenhuma delas é a ferramenta oficial
do HL7 para criar perfis. Até pouco tempo atrás, os Workgroups do HL7 usavam para
votação de perfis e artefatos atuais uma ferramenta chamada Microsoft Excel (!).
Isenção de responsabilidade (Disclaimer): este curso não endossa nenhum produto

comercial, ferramenta ou empresa. Estamos apenas fornecendo instruções sobre como
aprender mais sobre esses assuntos e incluindo algumas capturas de tela para você ver
do que se tratam as ferramentas.
Você pode fazer o download das ferramentas e experimentá-las (ou apenas usá-las, se
forem baseadas na Web).
32
Forge
● Site da Web: https://fire.ly/forge/.

● Criado e mantido por: Firely, Holanda.
● Condições: download grátis, requer registro. É executado apenas no Windows 7+
ou no Wine, se você usa MacOS ou Linux.
● Descrição: editor de recursos de conformidade para perfis, restrições, extensões,
fatias e bindings de vocabulário. Ele pode ser conectado ao simplifier ou a
qualquer outro servidor de recursos de conformidade do FHIR (lembre-se de que
todas as restrições podem ser salvas como recursos FHIR em qualquer servidor
FHIR).
Explorador Forge e editor de Perfil:
Guia de Implementação do Explorador Forge:
33
Trifolia
● Site da Web: https://trifolia.lantanagroup.com.

● Criado e mantido por: Lantana Group, US.
● Condições: Requer registro. Gratuito para membros do HL7, baseado na web.
● Descrição: concebido originalmente para a criação dos guias de implementação
do HL7 CDA R2. Funcionalidade do FHIR adicionada em 2015. Permite a edição de
guias de implementação, modelos (perfis) e terminologia (ValueSets e
CodeSystem).
● Trifolia on FHIR: https://trifolia-fhir.lantanagroup.com/home (Editor de perfil
específico do FHIR desenvolvido pelo Lantana Group).
Navegador para perfis da Trifolia:
Visualizador/Editor de restrições da Trifolia. Uma restrição sobre um recurso de pacote

configurável:
34
Simplifier
● Site da Web: https://www.simplifier.net/.

● Criado e mantido por: Firely, Holanda.
● Descrição: pretende ser um registro global para perfis FHIR. Ele armazena todos
os tipos de recursos de conformidade e permite edição e pesquisa. Ele trabalha
em estreita colaboração com o Forge (mesmo fornecedor). É gratuito para uso em
seus projetos pessoais. O registro global (https://registry.fhir.org/) para todos os
perfis publicados do FHIR (mantidos pela HL7 International e pela FHIR
Foundation) também é desenvolvido pelo Simplifier.
35
Formulário de pesquisa de recursos:
Navegador de recursos de conformidade:
clinFHIR
● Site da Web: http://clinfhir.com/.

● Criado e mantido por: Dr. David Hay, HL7 Nova Zelândia.
● Descrição: editor de recursos para usuários não técnicos, editor e comentador de
perfil e extensão. Você pode selecionar o servidor Paciente, Perfil e Terminologia
e criar seus recursos. O clinFHIR possui vários outros recursos que você pode
testar.
36
Editor de recursos clinfhir:
Construtor/Visualizador de extensões clinfhir:
Snapper
● Site: https://ontoserver.csiro.au/snapper2/licence.html?source=author. Para uso

livre, é necessário aceitar os termos (para Autor, Mapper e SNOMED CT).
37
● Criado e mantido por: The Australian e-Health Research Centre, CSIRO.
● Descrição: Editor de terminologia e navegador FHIR (ValueSet, CodeSystem e
ConceptMap).
Você pode importar, editar e exportar ou publicar seus sistemas de códigos, conjuntos de
valores e mapas conceituais usando o Snapper!
Alguns perfis importantes/guias de implementação

Esta seção listará alguns perfis que são importantes e que você deve manter no topo da
sua mente se pensar em implementar o FHIR (e realmente se conectar a qualquer outro
por aí). Nem todos são guias de implementação tradicionais, conforme descrito nesta
unidade, mas todos são relevantes.
Novamente, não estamos recomendando nenhum produto ou empresa comercial,

apenas tentando informar o que está acontecendo e onde encontrar as coisas de que
você precisa.
Argonaut Project
Site da Web: http://argonautwiki.hl7.org/index.php?title=Main_Page.
38
Descrição: O projeto Argonaut é uma iniciativa do setor privado para desenvolver uma
API baseada em FHIR que permita o compartilhamento de registros eletrônicos de
assistência médica.
Patrocinadores: Accenture, Athenahealth, Beth Israel Deaconess Medical Center, Cerner,

Epic, Intermountain Healthcare , Mayo Clinic, MEDITECH, McKesson, Partners Healthcare
System, Boston Children’s Hospital, Surescripts, The Advisory Board Company.
Componentes: Acesso seguro através do Aplicativo Inteligente -> Consulta de

Dados/Documentos.
Guia de implementação de consulta de dados do Argonaut:

(http://hl7.org/fhir/us/core/index.html) para acesso seguro de pacientes/médicos aos
dados de saúde.
Possui perfis para permitir o acesso aos registros do paciente em qualquer hospital -
desde que o hospital tenha adotado o guia - e, em seguida, informações granulares sobre
alergias, plano de saúde, equipe de assistência, condições, dispositivos, testes e relatórios
laboratoriais, imunizações, medicamentos, procedimentos, tabagismo, sinais vitais e
documentos.
Guia de Implementação do Diretório de Provedores Argonaut:

(http://www.fhir.org/guides/argonaut/pd/) para o diretório do provedor (inclui a
pesquisa de profissionais e organizações).
Existem mais guias de implementação do Argonaut em andamento: Agendamento e CDS-

Hooks (possibilitando o suporte à decisão clínica usando recursos FHIR).
Adoção: Talvez este seja o guia mais relevante em termos de adoção. Foi adotado não
apenas pelos patrocinadores do projeto, mas pela Apple, que adotou o R2 deste guia para
seu módulo de Saúde (incorporado no IOS 11.3). A Apple alega já ter centenas de
hospitais/grupos conectados.
Uma lista atualizada pode ser obtida aqui: https://support.apple.com/en-us/HT208647.
39
Veja mais:
http://www.healthcareitnews.com/news/how-apples-health-records-could-reshape-
patient-engagement.
Também foi adotado (silenciosamente) pela Google por meio de sua subsidiária Apigee,
em um produto chamado Apigee-health-apix (Managed API for Healthcare).
Veja mais em: https://apigee.com/about/tags/argonaut.
O objetivo do Apigee-health-apix é permitir ao FHIR/Argonaut seu próprio aplicativo

através de um portal de API gerenciada do Apigee.
40
IHE-on-FHIR
Embora o IHE ainda publique seus guias de implementação como arquivos PDF gigantes,
ele está adotando o padrão FHIR para vários perfis devido ao alinhamento do setor e
talvez também porque o FHIR está finalmente 'atingindo a maioridade'.
Todos os perfis IHE baseados em FHIR estão listados aqui:

https://wiki.ihe.net/index.php/Category:FHIR. Portanto, não incluiremos os links reais
para cada um deles.
O primeiro conjunto de perfis foi uma etapa para habilitar o FHIR para os perfis 'legados'
(e mais relevantes) da IHE:
● ATNA/Consulta Restful para ATNA - Para logs de auditoria;

● Acesso móvel a documentos de assistência médica (Mobile Access to Healthcare
Documents - MHD): “XDS on FHIR”;
● Consulta de dados demográficos do paciente para mobile/Referência cruzada de
identificador de paciente para mobile (Patient Demographics Query for Mobile/
Patient Identifier Cross Ref for Mobile) - “PIX/PDQ on FHIR”;
● Consulta para dados existentes para celular (Query for Existing Data for Mobile -
QEDm) - “QED on FHIR”.
Se sua empresa investe nos perfis IHE e deseja abrir uma "porta FHIR" ou "fachada FHIR"
(é assim que é tecnicamente descrita), essas são as especificações que você estava
procurando.
Foto tirada de John Moehrke's (IHE no post do FHIR):
41
Smart-On-FHIR
Site da Web: https://smarthealthit.org.
Patrocinadores: Programa de Informática em Saúde Computacional do Hospital Infantil

de Boston e Departamento de Informática Biomédica da Harvard Medical School.
Componentes: o Smart-On-FHIR estava no início "Smart Healthcare" e tinha como

objetivo criar "uma plataforma de aplicativos para serviços de saúde". No meio do
desenvolvimento de sua API, o FHIR surgiu e a abraçou de todo o coração. A idéia principal
é conectar um mercado de Apps for Healthcare a qualquer hospital de EHR (você pode
ver a App Gallery aqui: https://apps.smarthealthit.org/).
É um conjunto de especificações para:
1. Dados estruturados: basicamente FHIR + Argonaut

2. Escopos/Permissões: oAuth2 (qual paciente/encontro/médico) está em contexto
no EHR
3. Autenticação: Login Simples por meio de OpenID
4. Integração UI: Roda internamente a widgets do navegador ou quadros
embutidos.
42
Mas o que eles fornecem é muito mais que um guia de implementação: eles criaram um
conjunto de bibliotecas de código aberto que permitem que os criadores de aplicativos
(HTML5/Javascript/iOS/Python) se conectem a servidores habilitados para FHIR. As
bibliotecas cobrem os tópicos descritos acima.
Adoção: Boston Children’s Hospital, DukeMedicine, CoxHealth, Geisinger, Hospital

Corporation of America, Intermountain Healthcare, Ochsner, Allscripts, Cerner, Epic,
Apple.
Guias Oficiais de Implementação do FHIR
Todos os guias de implementação votados e publicados oficialmente pela HL7

International podem ser encontrados aqui: http://www.fhir.org/guides/registry.
Todos os perfis (restrições de recursos, extensões, conjuntos de valores, etc.) votados e

publicados pela HL7 International podem ser encontrados aqui: https://registry.fhir.org/.
Guias públicos regionais de implementação
Guias de implementação pública regional (criada pelo Afiliado HL7, da França, Finlândia,
Noruega, Reino Unido etc.) geralmente são encontrados no Simplifier, em:
https://simplifier.net/search?category=ImplementationGuide.
Pode haver outros guias de implementação do FHIR, mas eles não são anunciados ou são
privados. Portanto, não podemos fornecer mais informações sobre eles.
43
Mais informações sobre criação de perfil FHIR
Criação de perfis em FHIR (FHIR Profiling) é um assunto complexo. Existe um bom site
para encontrar mais informações sobre isso, se você estiver interessado, publicado pela
empresa da Holanda chamada Firely, que também publicou o Simplifier e Forge.É
chamado de 'Academia de Perfis FHIR' e o link para acesso é:
https://simplifier.net/guide/ProfilingAcademy/Modules.
Alguns dos artigos se concentram em como usar o Forge para criação de perfil. Portanto,
se você não estiver usando o Forge, talvez não os considere de interesse. De qualquer
forma, eles são uma boa fonte de informações sobre o que pode ser representado ou
restringido em FHIR e como.
44
Tarefa desta semana
Nós vamos tentar:
Parte 1: validar instâncias de pacientes do Berzequistão contra um servidor FHIR.

Parte 2: crie uma extensão para informações do paciente para dispositivos UWearMe.
Se você passou por aqui, está quase terminando. Vamos lá!
45
Resumo e Conclusão da Unidade
Nesta unidade, discutimos os conceitos básicos de criação de perfil e conformidade ao
usar o FHIR.
Criamos perfis para restringir os padrões de nossos cenários e casos de uso específicos e
documentamos nossas decisões, permitindo a validação automática da conformidade
sempre que possível.
No FHIR, você pode restringir: elementos em recursos (opcionalidade, repetições),

vocabulário - códigos em elementos codificados (vocabulário específico, incluindo a
representação dos sistemas de códigos e conjuntos de valores reais), comportamento
(quais métodos CRUD/non-CRUD e/ou pesquisa nosso servidor FHIR realmente suporta),
e também quais extensões são necessárias em cada nível (tipo de dados, recurso) e se são
obrigatórias ou não.
A criação de perfil no FHIR é obtida através da criação de recursos do FHIR. Estes são
alguns dos recursos do FHIR usados para documentar restrições: ImplementationGuide,
CapabilityStatement, OperationDefinition, SearchParameter, StructureDefinition,
ConceptMap, NamingSystem, DataElement, ValueSet, CodeSystem.
Algumas das ferramentas disponíveis para criação e teste de perfis são: Trifolia, Forge,
Simplifier (restrição de registro) e clinFHIR. Nem todas as ferramentas suportam a edição
de todos os tipos de recursos de conformidade.
A validação da conformidade pode ser obtida usando o Schema XML para os recursos
(validação simples em relação ao Schema) ou usando a funcionalidade de validação dos
servidores FHIR. Também exploramos alguns Guias de Implementação amplamente
usados ou relevantes.
A criação de perfil FHIR ainda está sendo desenvolvida, mas podemos começar a sonhar
com guias de implementação computáveis e ferramentas adequadas para criá-los.
46
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 ela - particularmente
para 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 para 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
Suporte Técnico HL7, se for membro.
47

PDF FHIR R4 S4 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 S4 LEITURA

Enviado por

Direitos autorais:

Formatos disponíveis

Curso de FHIR

Semana 4 – Conformidade e Perfis

Módulo II: Trabalhando com FHIR

Módulo III: FHIR Avançado

Módulo IV: Conformidade com FHIR

Conteúdo da Unidade e Objetivos de Aprendizagem 5

Por que precisamos de perfis? 6

Recursos de conformidade FHIR 9

Conformidade: Operations (Operações) 11

Conformidade: Content (Conteúdo) 16

Conformidade: Terminology (Terminologia) 23

Validação de Recurso em um Perfil 30

Ferramentas para criar perfis 32

Alguns perfis importantes/guias de implementação 38

Tarefa desta semana 45

Resumo e Conclusão da Unidade 46

Material de Leitura Adicional 47

A boa notícia é que o formato da documentação está na forma de recursos FHIR.

Nota: Esta unidade é vagamente baseada na aula de 'Profiling Concepts' de Graham

Os recursos de conformidade foram aumentados e renovados para o STU3, e constituem

De fato, há muito mais discordâncias do que acordos. Leis, regulamentos, culturas,

O mesmo conceito pode ser implementado em diferentes sistemas usando diferentes

Exemplo, como visto na Figura:

● Sistema 1: Alergia: Descrição (codificada) + Natureza da Reação

Portanto, o FHIR precisa ser implementado independentemente dessas diferenças, mas

Portanto, o FHIR introduz a criação de perfil embutida: um perfil é definido e verificado

Podemos ver o FHIR como uma "especificação de plataforma": sempre precisaremos de

Por que criamos perfis?

1. Para comunicar aos colegas o que foi decidido ou esperado

Um servidor FHIR se torna, também, uma ferramenta de extensão, perfis, guias de

O que pode sofrer restrição?

A premissa básica é "Não podemos anular a especificação":

1. Se algo é obrigatório no FHIR, não podemos considerá-lo opcional ou não

Uma pequena lista de itens que podemos restringir:

● Quais elementos opcionais são obrigatórios para nós?

Códigos em elementos codificados:

● Quais terminologias são usadas? Aplicadas a quais elementos codificados?

● Quais extensões específicas suportamos ou exigimos? Aplicado a quais

Como documentamos as restrições?

Restrições e suas instruções de uso precisam ser:

Recursos de conformidade FHIR

Nota: Existem mais recursos de conformidade (MessageDefinition, GraphDefinition,

CapabilityStatement (Declaração de Conformidade)

Você pode ver uma renderização parcial de um CapabilityStatement na figura abaixo:

Figura: Renderização parcial de uma CapabilityStatement.

Informações incluídas na declaração de conformidade:

● Server wide: nome e versão do software, operações especiais suportadas e seus

OperationDefinition (Definição de Operação)

A API RESTful define um conjunto de interações comuns (leitura, atualização, pesquisa

Nesse paradigma, existem operações nomeadas, executadas com parâmetros de entrada

As operações podem ser executadas em uma instância de recurso específica, em um tipo

O recurso OperationDefinition permite fornecer uma definição legível e computável da

Você pode ver essa definição no arquivo OperationDefinitionExample.xml (não incluído

No exemplo, a operação é definida no recurso Composition (para usá-lo, você chamaria

Cada operação é definida por:

● Contexto (Context): sistema, tipo de recurso ou instância de recurso.

● Parâmetro 1: sourceIdentifier (1..1) Token - O parâmetro de pesquisa do

● Parâmetro 3: _format 0..1 mime-type - O formato solicitado da resposta.

SearchParameter (Parâmetro de Busca)

● code (como o parâmetro é nomeado em pesquisas reais)

Aqui você pode encontrar um exemplo de um SearchParameter especial definido pelo

StructureDefinition (Definição de estrutura)

O StructureDefinition permite a criação de tipos e recursos básicos, ou seja, todos os