REST é o estilo; HTTP é o protocolo
A sessão introdutória usa REST para explicar por que uma API FHIR organiza dados como recursos endereçáveis e representações trocadas entre cliente e servidor.
| Restrição REST | Efeito prático | Pergunta de revisão |
|---|---|---|
| Interface uniforme | Operações e representações seguem convenções previsíveis | O cliente usa a semântica documentada do método e do recurso? |
| Cliente-servidor | Interface e dados evoluem com responsabilidades separadas | A regra crítica também é aplicada no backend? |
| Stateless | Cada requisição leva o contexto necessário | O servidor depende de estado oculto da chamada anterior? |
| Cache | Respostas estáveis podem evitar trabalho repetido quando permitido | O conteúdo é cacheável sem expor dado clínico ou ficar obsoleto? |
| Camadas | Gateway, mediação e backend podem ser substituídos sem mudar o cliente | A falha está na borda, na política, na mediação ou no serviço? |
| Code on demand | Extensão opcional do comportamento do cliente | Este caso realmente precisa da restrição opcional? |
Métodos como intenção
| Método | Intenção geral | Cuidado no FHIR |
|---|---|---|
| GET | Ler ou pesquisar | Parâmetros, includes, paginação e autorização mudam o resultado |
| POST | Criar ou executar operação | O endpoint e o perfil determinam a semântica |
| PUT | Substituir em endereço conhecido | Versão, concorrência e suporte precisam ser verificados |
| PATCH | Alterar parcialmente | Nem todo servidor ou recurso habilita a operação |
| DELETE | Remover logicamente ou fisicamente | Política de retenção clínica pode restringir o uso |
Do Patient à navegação do Bundle
A demonstração de 11 de setembro percorre a documentação FHIR R4, o recurso Patient, identificadores, buscas e resultados paginados.
{
"resourceType": "Patient",
"identifier": [
{
"system": "urn:sistema-de-identificacao-aprovado",
"value": "[VALOR_MASCARADO]"
}
]
}| Elemento | Uso apresentado | Ponto de atenção |
|---|---|---|
| Patient | Representar e localizar a pessoa | Correlação no MPI precede a associação clínica |
| _id / identifier | Buscar pela identidade técnica ou por identificador | Não trocar namespace por posição no JSON |
| Bundle | Agrupar resultados e metadados de navegação | Contar entry não substitui total nem seguir link next |
| Observation | Representar observações pesquisáveis por paciente e código | Categoria, terminologia e perfil delimitam o significado |
| Encounter | Representar atendimentos relacionados aos documentos | A granularidade depende do caso de uso e do mapeamento |
| DiagnosticReport | Organizar resultado/laudo de exame | Pode referenciar solicitação, observações e conteúdo anexo |
Terminologia e conformidade dão significado
Uma estrutura FHIR válida ainda pode ser semanticamente inadequada se códigos e perfis não forem os esperados pelo caso de uso.
| Artefato | Papel | Exemplo de decisão |
|---|---|---|
| CodeSystem | Define códigos e seu sistema de origem | Qual vocabulário identifica o conceito? |
| ValueSet | Seleciona os códigos permitidos para um contexto | Qual subconjunto pode preencher este campo? |
| ConceptMap | Relaciona conceitos entre sistemas | A equivalência é exata, mais ampla ou parcial? |
| Perfil | Restringe ou estende o recurso base | Quais cardinalidades, extensões e bindings são obrigatórios? |
| Guia de implementação | Agrupa perfis, terminologias e fluxos | Qual versão nacional ou institucional governa a integração? |
O repasse mostra a operação FHIR $expand como forma de materializar um ValueSet para consumo por aplicações. Também destaca que códigos locais podem coexistir com vocabulários reconhecidos enquanto a governança de mapeamento amadurece.
BR Core, perfis RNDS e IPS aparecem como referências diferentes. O material reforça uma adequação incremental: adotar FHIR não garante, por si só, conformidade com um guia nacional nem interoperabilidade semântica entre organizações.
FHIR, openEHR e MHD no mesmo fluxo
O workshop apresenta padrões complementares: modelos clínicos detalhados, recursos de troca e envelope de documentos.
- 1Modelar o conteúdo
Templates e arquétipos openEHR preservam estrutura e validações de documentos como RAC e Sumário de Alta.
- 2Transformar
O conector converte o modelo extraído para a representação clínica esperada e valida o artefato antes do envio.
- 3Envelopar
FHIR e o perfil MHD organizam metadados e transporte do documento, incluindo referências a binários quando aplicável.
- 4Persistir e consultar
Serviços FHIR, repositórios e índices tornam recursos e documentos disponíveis conforme identidade e autorização.
- 5Visualizar
Os canais compõem a experiência sem apagar a origem, o perfil e a versão dos dados.
Capítulos para revisão dirigida
Use estes pontos de entrada e volte ao Guia do repasse para abrir a gravação correspondente.
| Sessão | Timestamp | Assunto |
|---|---|---|
| 04/09 | 00:34:07 | Interoperabilidade e modelos de informação |
| 04/09 | 00:51:35 | Terminologias e ConceptMap |
| 04/09 | 02:05:30 | FHIR versus openEHR e conversão |
| 05/09 — REST | 00:05:22 | Seis restrições REST |
| 05/09 — FHIR | 00:47:54 | Serviço de terminologia |
| 05/09 — FHIR | 02:24:49 | Conformidade RNDS e BR Core |
| 11/09 | 00:38:49 | Patient |
| 11/09 | 01:07:46 | Identifiers |
| 11/09 | 02:26:26 | Paginação |
| 18/09 | 00:57:41 | Templates openEHR |
| 18/09 | 01:15:25 | Encounter |