Resposta curta: os recursos FHIR base são propositadamente flexíveis: quase tudo é opcional e a maioria dos códigos são apenas exemplos, para que um único padrão sirva para todos os países. Um perfil é uma StructureDefinition que aperta um recurso para um determinado uso: neste contexto, Paciente deve ter um identificador deste tipo, Observation.code deve ser um código LOINC desta lista, este elemento deve ser suportado, aquele não pode aparecer. Uma extensão adiciona um elemento que falta no recurso base, identificado por um URL e definido pela sua própria StructureDefinition. Guias de implementação (US Core, o IPS, guias nacionais) são coleções de perfis, extensões, conjuntos de valores e exemplos. Um recurso indica quais perfis afirma seguir em meta.profile, e um validador verifica-o.
O que um perfil pode alterar
Um perfil FHIR só pode alterar um recurso ao restringi-lo: apertando a cardinalidade, marcando elementos como 'must-support' (devem ser suportados), fixando valores ou padrões, associando elementos a conjuntos de valores com uma força específica, fatiando listas em partes nomeadas, restringindo tipos de escolha, adicionando invariantes FHIRPath e limitando alvos de referência. Um perfil não pode adicionar elementos, renomear nada ou afrouxar a especificação base.
| Restrição | O que faz | Exemplo |
|---|---|---|
| Cardinalidade | Torna elementos opcionais obrigatórios, ou proíbe-os | Patient.identifier 1..*; Patient.photo 0..0 |
| Deve suportar | Os recetores devem ser capazes de armazenar e exibir o elemento se for enviado | US Core marca birthDate como must-support |
| Valor fixo ou padrão | Bloqueia um elemento para um único valor | Observation.category fixo para vital-signs |
| Ligação (Binding) | Aponta um elemento para um conjunto de valores com uma força | Observation.code ligado à lista de sinais vitais, obrigatório |
| Fatiamento (Slicing) | Divide uma lista em partes nomeadas com regras próprias | Pressão arterial: componente fatiado em sistólica e diastólica |
| Restrição de tipo | Limita uma escolha | value[x] restrito a valueQuantity |
| Invariante | Uma regra FHIRPath que deve ser cumprida | "effective[x] deve estar presente" ou "value ou dataAbsentReason" |
| Alvo de referência | Limita o que uma referência pode apontar | subject apenas Paciente, e apenas pacientes que cumpram este perfil |
Um perfil só pode restringir. Não pode adicionar elementos (para isso servem as extensões), renomear nada ou alargar o base.
Força da ligação (Binding strength)
O FHIR define quatro forças de ligação. required (obrigatório): o código deve vir do conjunto de valores. extensible (extensível): use o conjunto de valores se um conceito se encaixar; caso contrário, outro código é permitido. preferred (preferencial): recomendado, mas não imposto. example (exemplo): apenas ilustrativo, que é o que a maioria dos recursos base tem. Interpretar mal extensible como required é uma fonte comum de erros de validação falsos.
Um excerto de perfil legível
Um perfil FHIR é uma StructureDefinition cujo diferencial lista apenas as restrições que diferem do recurso base, enquanto o seu 'snapshot' lista todos os elementos. O excerto legível abaixo restringe um Observation a uma pressão arterial doméstica: o código é fixado em LOINC 85354-9 e o componente é fatiado em exatamente uma parte sistólica e uma parte diastólica.
O diferencial de um perfil lista apenas o que mudou em relação ao base; o snapshot lista tudo. Este diferencial diz que uma Observation de pressão arterial deve conter LOINC 85354-9 e exatamente dois componentes:
{
"resourceType": "StructureDefinition",
"url": "https://example.org/fhir/StructureDefinition/bp-home",
"name": "HomeBloodPressure",
"status": "active",
"kind": "resource",
"abstract": false,
"type": "Observation",
"baseDefinition": "http://hl7.org/fhir/StructureDefinition/Observation",
"derivation": "constraint",
"differential": {"element": [
{"id": "Observation.code", "path": "Observation.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "85354-9"}]}},
{"id": "Observation.component", "path": "Observation.component", "min": 2, "max": "2",
"slicing": {"discriminator": [{"type": "pattern", "path": "code"}], "rules": "closed"}},
{"id": "Observation.component:systolic", "path": "Observation.component", "sliceName": "systolic", "min": 1, "max": "1"},
{"id": "Observation.component:systolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8480-6"}]}},
{"id": "Observation.component:diastolic", "path": "Observation.component", "sliceName": "diastolic", "min": 1, "max": "1"},
{"id": "Observation.component:diastolic.code", "path": "Observation.component.code",
"patternCodeableConcept": {"coding": [{"system": "http://loinc.org", "code": "8462-4"}]}}
]}
}
Perfis raramente são escritos à mão; os autores usam FHIR Shorthand (FSH) com SUSHI, ou ferramentas como Forge e Simplifier, e publicam com o IG Publisher da HL7. Os guias são distribuídos como pacotes (hl7.fhir.us.core#6.1.0, hl7.fhir.uv.ips#1.1.0) que validadores e servidores carregam.
Extensões
Uma extensão é um elemento chave-valor colocado em extension (ou modifierExtension quando altera o significado do recurso e não deve ser ignorado). O seu url é o URL canónico da sua StructureDefinition; o seu valor é um value[x] tipado, ou extensões aninhadas. O local de nascimento é uma extensão definida pela HL7 no Paciente:
{
"resourceType": "Patient",
"id": "example",
"extension": [{
"url": "http://hl7.org/fhir/StructureDefinition/patient-birthPlace",
"valueAddress": {"city": "Lyon", "country": "FR"}
}],
"name": [{"family": "Doe", "given": ["Jane"]}]
}
Regras de boas práticas: procure uma extensão existente (registo da HL7 e guias nacionais) antes de definir uma; dê-lhe um URL sob um domínio que controla; defina-a numa StructureDefinition para que outros a possam validar; nunca use uma extensão para algo que um elemento base já cobre.
meta.profile e validação
meta.profile é a lista de URLs canónicas às quais um recurso FHIR afirma conformar-se, e afirmar não é provar. Um validador verifica o recurso contra a especificação base e contra cada perfil reclamado, ou contra um perfil que você nomeie. O validador de referência HL7 é executado localmente com pacotes, e os servidores FHIR expõem uma operação $validate que aceita um parâmetro de perfil.
meta.profile lista os URLs canónicos aos quais um recurso afirma conformar-se. Afirmar não é provar: um validador verifica o recurso contra a especificação base e contra cada perfil afirmado (ou contra um perfil que lhe peça para usar). O validador de referência da HL7 (validator_cli.jar) corre localmente e carrega pacotes; os servidores oferecem POST /Observation/$validate?profile=…; o IG Publisher valida todos os exemplos num guia. Um recurso pode conformar-se a vários perfis ao mesmo tempo (um perfil nacional de Paciente e o IPS Paciente) desde que não se contradigam.
Duas regras práticas: um servidor que declara um perfil na sua CapabilityStatement deve rejeitar recursos que falhem nele; um cliente que recebe recursos não deve rejeitar extensões desconhecidas ou elementos extra que um perfil não proibiu, porque a especificação base permite-os.
Em Anpheros
A Anpheros Platform é um servidor FHIR R4 que utiliza LOINC para observações, ATC para medicamentos e SNOMED CT quando aplicável, e oferece um validador gratuito que verifica a estrutura de um recurso contra o FHIR R4. Quando uma clínica envia recursos com meta.profile definido para um perfil nacional ou IPS, a afirmação é preservada para que um sistema a jusante possa validar contra ele.
O validador gratuito encontra-se no site do programador. Para os guias em si, consulte Guias de implementação FHIR explicados.
Páginas relacionadas
- Guias de implementação FHIR explicados
- CodeableConcept e Coding em FHIR
- Recurso FHIR Observation explicado
- Recurso FHIR Patient explicado
- Servidores de terminologia explicados
- Validador FHIR (site do programador)
Fontes
- HL7 FHIR R4: Profiling FHIR
- HL7 FHIR R4: Extensibility
- HL7 FHIR R4: StructureDefinition
- HL7 FHIR R4: Terminology bindings
- HL7 FHIR Shorthand
- HL7 FHIR validator
- HL7 FHIR R4: patient-birthPlace extension
Perguntas frequentes
Um perfil pode adicionar um novo elemento a um recurso?
Não. Os perfis apenas restringem. Novos dados vão para uma extensão, que o perfil pode então exigir ou proibir como qualquer outro elemento.
O que é que "must-support" realmente exige?
O guia de implementação define-o; tipicamente, que um remetente preencha o elemento quando tem os dados e um recetor armazena e pode exibi-lo. Não torna o elemento obrigatório.
Se um recurso não tiver meta.profile, é inválido?
Não. meta.profile é uma afirmação, não um requisito. Um servidor ou guia pode exigi-lo; a especificação base não. Os validadores podem ser solicitados a verificar contra um perfil que o recurso não declara.
Como sei qual perfil usar no meu país?
Cada comunidade FHIR nacional publica um guia central (US Core, UK Core, nl-core, os Basisprofile alemães, e assim por diante); a página de guias de implementação explica como encontrá-los. Resumos transfronteiriços usam o IPS.
Experimente grátis no sandbox
Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.
Grátis · 30 pacientes sintéticos · sem cartão
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →