|
|
| Linha 1: |
Linha 1: |
| === 1. Introdução === | | === 1. O que é o FHIR, em palavras simples === |
|
| |
|
| A crescente informatização dos sistemas de saúde tem vindo a expor um problema estrutural: os dados clínicos continuam, frequentemente, isolados em sistemas fechados, pouco comunicantes, desenvolvidos em tecnologias desatualizadas. Esta fragmentação prejudica o acesso oportuno à informação, compromete a continuidade dos cuidados e dificulta a inovação digital.
| | O **Fast Healthcare Interoperability Resources (FHIR)** é um standard criado pela HL7 para facilitar a troca eletrónica de dados em saúde, de forma **estruturada, segura e interoperável**. |
|
| |
|
| É neste contexto que surge o standard '''Fast Healthcare Interoperability Resources (FHIR)''', desenvolvido pela '''HL7 International'''. O FHIR propõe uma nova abordagem para a interoperabilidade em saúde, baseada em princípios modernos da web, como o uso de '''APIs RESTful''' e a representação de dados em '''JSON''' ou '''XML'''.
| | Ao contrário dos standards anteriores (HL7 v2 ou CDA), o FHIR foi desenhado para funcionar com **tecnologias web modernas**: utiliza formatos como **JSON ou XML**, é compatível com **REST APIs** e facilita a **integração entre sistemas clínicos, aplicações móveis e plataformas digitais**. |
|
| |
|
| {| class="wikitable" style="background-color:#f9f9f9"
| | Em vez de enviar documentos longos e fechados, o FHIR organiza a informação em **recursos independentes e reutilizáveis**. Cada recurso representa uma entidade clínica (ex: um utente, um exame, uma prescrição), e pode ser transmitido, modificado ou consultado de forma autónoma. |
| | '''Nota de enquadramento:'''
| |
| O FHIR é hoje considerado o standard mais promissor na construção de sistemas de saúde verdadeiramente interoperáveis, modulares e adaptáveis a múltiplos contextos — desde grandes hospitais a aplicações móveis.
| |
| |}
| |
|
| |
|
| Ao contrário dos modelos centrados em documentos pesados, o FHIR organiza a informação em '''recursos'''. Cada recurso representa uma unidade fundamental da realidade clínica ou administrativa, como um '''utente''', uma '''observação''', uma '''prescrição''' ou um '''episódio de internamento'''. Estes recursos podem ser consultados, combinados ou atualizados através de chamadas simples a partir de qualquer sistema compatível.
| | Exemplo simples de recurso FHIR do tipo Patient: |
|
| |
|
| ==== 1.1 O que se aprende nesta página ====
| |
|
| |
| Esta página foi concebida como uma introdução estruturada e acessível ao FHIR, destinada a estudantes, profissionais de saúde e técnicos que procuram compreender os fundamentos deste standard.
| |
|
| |
| No final da leitura, espera-se que o leitor:
| |
| * Conheça o contexto em que o FHIR surgiu
| |
| * Compreenda os seus princípios técnicos fundamentais
| |
| * Reconheça os principais tipos de recurso
| |
| * Visualize casos reais de aplicação
| |
| * Perceba a relevância do FHIR em Portugal e na Europa
| |
|
| |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | '''FHIR''' é um standard criado para facilitar a partilha estruturada de dados clínicos. Usa tecnologias modernas da web e organiza a informação em unidades chamadas '''recursos'''. Está a transformar a forma como os sistemas de saúde comunicam entre si.
| |
| |}
| |
|
| |
| === 2. Porquê FHIR? ===
| |
|
| |
| Os sistemas de informação em saúde evoluíram, ao longo das últimas décadas, com o objetivo de permitir a troca estruturada de dados clínicos entre diferentes instituições e plataformas. Para esse fim, foram desenvolvidos vários standards de interoperabilidade pela HL7 International, entre os quais se destacam o HL7 v2, o CDA e o HL7 v3.
| |
|
| |
| Apesar do seu valor histórico, estes standards apresentaram limitações significativas em termos de consistência, complexidade e capacidade de adaptação a novos contextos tecnológicos. O '''FHIR''' surge como uma resposta pragmática a essas limitações, propondo um novo paradigma mais próximo das tecnologias da web, e mais adequado à realidade contemporânea dos sistemas de saúde.
| |
|
| |
| ==== 2.1 O legado dos standards anteriores ====
| |
|
| |
| A tabela seguinte resume as principais características dos standards que antecederam o FHIR, destacando os seus contributos e limitações.
| |
|
| |
| {| class="wikitable"
| |
| ! Standard !! Ano !! Estrutura principal !! Força principal !! Limitações mais relevantes
| |
| |-
| |
| | HL7 v2 || 1989 || Mensagens segmentadas || Elevada difusão mundial || Ambiguidades, falta de uniformidade, difícil validação
| |
| |-
| |
| | CDA || 2001 || Documentos XML estruturados || Normalização de relatórios clínicos || Monolitismo, fraca granularidade dos dados
| |
| |-
| |
| | HL7 v3 || 2005 || Modelos rigorosos baseados em RIM || Formalismo conceptual || Complexidade elevada, fraca adoção
| |
| |-
| |
| | FHIR || 2014 || Recursos modulares e APIs RESTful || Simplicidade e flexibilidade || Requer maturidade digital dos sistemas
| |
| |}
| |
|
| |
| Apesar dos avanços, verificou-se que os standards anteriores não conseguiam responder de forma eficaz aos novos desafios da saúde digital: integração de aplicações móveis, interoperabilidade em tempo real, desenvolvimento ágil, e envolvimento de equipas multidisciplinares.
| |
|
| |
| ==== 2.2 Uma proposta mais moderna e orientada para a prática ====
| |
|
| |
| O '''FHIR''' introduz uma abordagem técnica mais acessível, baseada em tecnologias abertas amplamente utilizadas fora do setor da saúde. Utiliza chamadas HTTP (como GET, POST, PUT, DELETE) para interagir com '''recursos''', que representam unidades discretas de informação clínica ou administrativa.
| |
|
| |
| Cada recurso, como por exemplo '''Patient''', '''Observation''' ou '''Encounter''', é uma entidade autocontida que pode ser consultada, atualizada ou combinada com outros recursos, promovendo uma lógica modular e reutilizável.
| |
|
| |
| {| class="wikitable" style="background-color:#f2f2f2"
| |
| | '''Exemplo de chamada a um recurso Patient:'''
| |
| <syntaxhighlight lang="bash">
| |
| GET /fhir/Patient?name=Sousa
| |
| </syntaxhighlight>
| |
| |}
| |
|
| |
| Ao adotar este modelo, o FHIR permite acelerar a implementação de soluções interoperáveis, facilitar a integração entre sistemas distintos e abrir a porta à inovação por parte de equipas técnicas com diferentes origens, incluindo o desenvolvimento web e mobile.
| |
|
| |
| ==== 2.3 FHIR como mudança de paradigma ====
| |
|
| |
| Mais do que uma evolução técnica, o FHIR representa uma mudança de paradigma. Substitui estruturas pesadas por componentes leves e combináveis, aproxima-se da lógica da programação orientada a objetos e introduz um modelo mais compatível com os princípios da transformação digital.
| |
|
| |
| Esta arquitetura torna o FHIR particularmente relevante no contexto atual, em que se exige maior interoperabilidade entre unidades de saúde, maior transparência para os cidadãos e maior eficiência na utilização dos dados clínicos.
| |
|
| |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O '''FHIR''' representa uma resposta consciente aos limites históricos da interoperabilidade em saúde. Combina simplicidade técnica com profundidade semântica, promovendo uma nova geração de sistemas interoperáveis, modulares e centrados no utente.
| |
| |}
| |
|
| |
| === 3. Como o FHIR funciona por dentro: princípios estruturais ===
| |
|
| |
| Até aqui, vimos o FHIR como uma resposta moderna aos desafios da interoperabilidade em saúde. Mas o que torna este standard verdadeiramente inovador não é apenas a sua proposta — é a forma como foi construído.
| |
|
| |
| O FHIR não é apenas um conjunto de regras. É uma arquitectura pensada para comunicar informação clínica com elegância técnica, legibilidade semântica e flexibilidade controlada. Nesta secção, exploramos os seus princípios estruturais com uma pergunta em mente: por que razão o FHIR escolheu este caminho e não outro?
| |
|
| |
| ==== 3.1 Porquê REST, e não SOAP? ====
| |
|
| |
| Ao adotar APIs RESTful, o FHIR afasta-se das abordagens mais pesadas baseadas em SOAP (como o HL7 v3) e aproxima-se das tecnologias utilizadas em milhões de aplicações web. REST oferece simplicidade, previsibilidade e uma curva de aprendizagem muito mais suave.
| |
|
| |
| A comunicação é feita através de chamadas HTTP simples, que espelham ações básicas como consultar (GET), criar (POST), atualizar (PUT) e apagar (DELETE).
| |
|
| |
| ```wiki
| |
| <syntaxhighlight lang="bash">
| |
| GET /fhir/Patient/123
| |
| </syntaxhighlight>
| |
|
| |
| ==== 3.2 Recursos: a gramática modular da informação ====
| |
|
| |
| A unidade fundamental no FHIR é o recurso. Cada recurso representa uma entidade discreta do mundo clínico ou administrativo, com atributos bem definidos e uma estrutura consistente.
| |
|
| |
| Um recurso pode representar um utente, uma medicação, um resultado clínico ou uma intervenção. Estes recursos são autocontidos, mas podem referenciar outros. A informação torna-se assim legível, reutilizável e interconectada.
| |
|
| |
| {| class="wikitable"
| |
| |+ Exemplos de recursos FHIR
| |
| ! Nome do recurso !! O que representa
| |
| |-
| |
| | Patient || Informação de identificação do utente
| |
| |-
| |
| | Observation || Medição ou resultado clínico
| |
| |-
| |
| | Encounter || Episódio de cuidados
| |
| |-
| |
| | MedicationRequest || Prescrição de medicamento
| |
| |-
| |
| | Condition || Diagnóstico ou problema clínico
| |
| |}
| |
|
| |
| ==== 3.3 Formatos interoperáveis com intenção semântica ====
| |
|
| |
| O FHIR utiliza JSON e XML como formatos de serialização. Estes formatos são abertos, legíveis por humanos, compatíveis com múltiplas linguagens de programação e fáceis de integrar em APIs modernas.
| |
|
| |
| O exemplo seguinte mostra um recurso Patient representado em JSON, com campos identificáveis por qualquer sistema compatível.
| |
|
| |
| <syntaxhighlight lang="json">
| |
| {
| |
| "resourceType": "Patient",
| |
| "id": "example",
| |
| "name": [
| |
| {
| |
| "use": "official",
| |
| "family": "Sousa",
| |
| "given": ["Carlos"]
| |
| }
| |
| ],
| |
| "gender": "male",
| |
| "birthDate": "1990-01-01"
| |
| }
| |
| </syntaxhighlight>
| |
|
| |
| Esta estrutura assegura que os dados possam ser partilhados e processados sem perda de significado.
| |
|
| |
| ==== 3.4 Extensões: como crescer sem romper ====
| |
|
| |
| O FHIR define um conjunto base de recursos e atributos, mas permite que sejam criadas extensões adicionais, desde que estruturadas e documentadas segundo regras definidas. Um sistema que não reconhece uma extensão pode ignorá-la sem comprometer a leitura do restante conteúdo.
| |
|
| |
| Esta abordagem permite adaptar o FHIR a diferentes realidades sem fragmentar a interoperabilidade global.
| |
|
| |
| ==== 3.5 Modularidade sem redundância ====
| |
|
| |
| O desenho modular do FHIR permite representar dados clínicos diversos sem necessidade de múltiplos modelos paralelos. Um único recurso Observation pode servir tanto para uma glicemia capilar como para uma tomografia computadorizada.
| |
|
| |
| Esta lógica evita redundância, promove a reutilização e contribui para uma linguagem clínica comum entre sistemas distintos.
| |
|
| |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O FHIR organiza-se segundo cinco princípios estruturais que articulam leveza técnica e profundidade clínica. Utiliza REST como modelo de comunicação, estrutura a informação em recursos autocontenidos, adota formatos interoperáveis legíveis por humanos e máquinas, permite extensões controladas e aposta numa modularidade que favorece a reutilização.
| |
| |}
| |
|
| |
| === 4. Anatomia de um recurso FHIR ===
| |
|
| |
| Há quem olhe para um recurso FHIR como quem vê um ficheiro técnico. Mas um recurso é mais do que um bloco de dados. É uma unidade semântica que carrega significado clínico. E quando bem construído, é também uma narrativa: organizada, modular, interoperável.
| |
|
| |
| Tomemos o exemplo mais simples, mas também mais central de todos — o recurso Patient.
| |
|
| |
| ==== 4.1 Comecemos pela superfície ====
| |
|
| |
| Um recurso FHIR começa sempre por se apresentar. O seu primeiro campo é resourceType. É como se dissesse: “sou um Patient”.
| |
|
| |
| Depois, vem o seu identificador (id). Um código único dentro do sistema, que permite distinguir este recurso de todos os outros.
| |
|
| |
| E logo a seguir surgem os campos que realmente interessam ao cuidado clínico: nome, género, data de nascimento. Cada um destes atributos está estruturado, normalizado, pronto a ser compreendido por qualquer sistema que fale FHIR.
| |
|
| |
| ```wiki
| |
| <syntaxhighlight lang="json"> | | <syntaxhighlight lang="json"> |
| { | | { |
| "resourceType": "Patient", | | "resourceType": "Patient", |
| "id": "example", | | "id": "f001", |
| "name": [ | | "name": [{ |
| { | | "family": "Smith", |
| "use": "official",
| | "given": ["John"] |
| "family": "Sousa",
| | }], |
| "given": ["Carlos"]
| |
| }
| |
| ],
| |
| "gender": "male", | | "gender": "male", |
| "birthDate": "1990-01-01" | | "birthDate": "1990-01-01" |
| Linha 191: |
Linha 22: |
| </syntaxhighlight> | | </syntaxhighlight> |
|
| |
|
| ==== 4.2 Cada campo é uma decisão ====
| | Este exemplo mostra como um utente pode ser representado digitalmente com uma estrutura clara e partilhável entre sistemas diferentes. **A simplicidade e flexibilidade desta abordagem tornam o FHIR particularmente relevante para a transformação digital da saúde.** |
| | |
| No FHIR, nada é gratuito. O campo '''name''', por exemplo, é uma lista de objetos, não uma simples string. Isto permite representar múltiplos nomes com diferentes usos, como official, usual, maiden ou nickname.
| |
| | |
| O campo '''gender''' segue um conjunto fechado de valores possíveis. O formato da '''birthDate''' está normalizado segundo o padrão ISO. A tipificação protege a interoperabilidade.
| |
| | |
| Cada campo é cuidadosamente desenhado para ser validável, extensível e semanticamente inequívoco. E, acima de tudo, cada um pode ser omitido sem comprometer a integridade do recurso.
| |
| | |
| ==== 4.3 Referências: o Patient não está sozinho ====
| |
| | |
| Um recurso '''Patient''' raramente está isolado. Pode referenciar profissionais ('''Practitioner'''), episódios ('''Encounter'''), observações ('''Observation''') ou condições clínicas ('''Condition'''). A ligação entre recursos faz-se através de referências. São apontadores, não duplicações.
| |
| | |
| <syntaxhighlight lang="json">
| |
| "generalPractitioner": [
| |
| {
| |
| "reference": "Practitioner/123"
| |
| }
| |
| ]
| |
| </syntaxhighlight>
| |
| | |
| Esta referência não transporta o conteúdo do recurso '''Practitioner'''. Apenas o localiza. É uma ligação semântica, que reduz redundância e aumenta a coesão entre entidades clínicas.
| |
| | |
| ==== 4.4 Um recurso é sempre incompleto ====
| |
| | |
| O FHIR assume a incompletude como princípio. Um recurso pode conter apenas o essencial ou crescer com extensões, metadados e perfis personalizados.
| |
| | |
| Essa elasticidade permite que o mesmo modelo suporte tanto uma aplicação de registo mínimo como uma infraestrutura nacional de interoperabilidade. O núcleo mantém-se. O contexto é que se adapta.
| |
| | |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O recurso '''Patient''' ilustra a filosofia do FHIR: equilibrar simplicidade com expressividade. É um objeto estruturado, flexível e interoperável. Representa não só um utente, mas uma forma moderna de descrever dados clínicos com intenção, contexto e precisão.
| |
| |}
| |
| | |
| === 5. Recursos mais comuns no FHIR ===
| |
| | |
| Os recursos são os blocos fundamentais da arquitetura FHIR. Cada um representa uma entidade com significado clínico ou administrativo. A compreensão dos recursos mais utilizados é essencial para interpretar e construir sistemas interoperáveis baseados neste standard.
| |
| | |
| Embora o FHIR inclua mais de 150 tipos de recurso, a maioria das aplicações clínicas recorre a um subconjunto bem definido. Estes recursos podem ser agrupados segundo a sua função no ciclo de cuidados: identificação do utente, episódios clínicos, diagnósticos, intervenções, terapêutica e resultados.
| |
| | |
| {| class="wikitable"
| |
| |+ Recursos FHIR organizados por domínio clínico
| |
| ! Domínio !! Recurso !! Finalidade
| |
| |-
| |
| | Identificação || Patient || Informação demográfica e administrativa do utente
| |
| |-
| |
| | Identificação || Practitioner || Identificação de profissionais de saúde
| |
| |-
| |
| | Episódios clínicos || Encounter || Representação de um episódio de cuidados (consulta, internamento, urgência)
| |
| |-
| |
| | Diagnóstico || Condition || Representação de diagnósticos, problemas ativos ou antecedentes
| |
| |-
| |
| | Diagnóstico || Observation || Resultados de exames, sinais vitais, escalas clínicas
| |
| |-
| |
| | Intervenções || Procedure || Procedimentos realizados ou planeados
| |
| |-
| |
| | Terapêutica || MedicationRequest || Prescrições de medicamentos
| |
| |-
| |
| | Terapêutica || MedicationAdministration || Registo da administração de terapêutica
| |
| |-
| |
| | Registos complementares || DocumentReference || Referência a documentos clínicos externos
| |
| |-
| |
| | Registos complementares || AllergyIntolerance || Registo de alergias ou intolerâncias conhecidas
| |
| |}
| |
| | |
| ==== 5.1 Relações entre recursos ====
| |
| | |
| Os recursos não existem isoladamente. A riqueza do FHIR emerge das ligações entre elementos. Por exemplo, um recurso '''Observation''' pode referir um '''Patient''', um '''Practitioner''', um '''Encounter''' e uma '''Condition''', dependendo do contexto.
| |
| | |
| Esta rede de relações cria um modelo clínico distribuído, flexível e altamente expressivo.
| |
| | |
| ==== 5.2 Perfis nacionais e contextuais ====
| |
| | |
| Muitos países e instituições definem subconjuntos específicos de recursos obrigatórios, conhecidos como '''perfis'''. Estes perfis estabelecem regras adicionais, como campos obrigatórios, terminologias aceites e validações semânticas adaptadas à realidade local.
| |
| | |
| Em Portugal, a adoção formal de perfis FHIR está ainda em fase inicial, mas o alinhamento com as diretrizes do Espaço Europeu de Dados de Saúde (EHDS) prevê uma maior normalização dos recursos utilizados.
| |
| | |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O FHIR disponibiliza uma vasta biblioteca de recursos, mas a prática clínica exige sobretudo um núcleo comum que inclui Patient, Practitioner, Encounter, Condition, Observation e MedicationRequest. Estes recursos, interligados, permitem representar com precisão o percurso clínico de um utente num sistema interoperável.
| |
| |}
| |
| | |
| === 6. Operações básicas com FHIR ===
| |
| | |
| O FHIR foi desenhado para ser utilizado através de interfaces baseadas em HTTP, o mesmo protocolo usado para navegar na internet. Isso significa que interagir com dados FHIR é conceptualmente semelhante a interagir com páginas web, mas em vez de visualizar conteúdos, o objetivo é aceder, criar, modificar ou eliminar dados estruturados.
| |
| | |
| Cada tipo de operação corresponde a um verbo HTTP. A combinação do verbo com um endpoint FHIR permite realizar uma ação sobre um recurso ou um conjunto de recursos. Os sistemas que implementam o FHIR devem respeitar esta semântica.
| |
| | |
| ==== 6.1 Consulta de dados (GET) ====
| |
| | |
| A operação GET permite obter dados de um recurso específico ou pesquisar recursos com determinados critérios.
| |
| | |
| ```wiki
| |
| <syntaxhighlight lang="bash">
| |
| GET /fhir/Patient/123
| |
| </syntaxhighlight>
| |
| | |
| Esta chamada devolve o conteúdo do recurso Patient com identificador 123.
| |
| | |
| Também é possível realizar pesquisas parametrizadas:
| |
| | |
| <syntaxhighlight lang="bash">
| |
| GET /fhir/Patient?name=Sousa
| |
| </syntaxhighlight>
| |
| | |
| Esta chamada devolve todos os recursos Patient cujo nome inclua “Sousa”.
| |
| | |
| ==== 6.2 Criação de dados (POST) ====
| |
| | |
| A operação POST é utilizada para criar novos recursos. O conteúdo do recurso é enviado no corpo da chamada, geralmente em formato JSON.
| |
| | |
| ```wiki
| |
| <syntaxhighlight lang="bash">
| |
| POST /fhir/Patient
| |
| </syntaxhighlight>
| |
| | |
| O servidor responde com o recurso criado, atribuindo-lhe um identificador único.
| |
| | |
| ==== 6.3 Atualização de dados (PUT) ====
| |
| | |
| A operação PUT substitui por completo um recurso existente com uma nova versão enviada pelo cliente.
| |
| | |
| ```wiki
| |
| <syntaxhighlight lang="bash">
| |
| PUT /fhir/Patient/123
| |
| </syntaxhighlight>
| |
| | |
| A nova versão do recurso Patient com o identificador 123 irá substituir a anterior.
| |
| | |
| ==== 6.4 Remoção de dados (DELETE) ====
| |
| | |
| A operação DELETE remove um recurso do sistema, utilizando o seu identificador.
| |
| | |
| ```wiki
| |
| <syntaxhighlight lang="bash">
| |
| DELETE /fhir/Patient/123
| |
| </syntaxhighlight>
| |
| | |
| Esta ação elimina o recurso Patient com o identificador 123, caso exista.
| |
| | |
| ==== 6.5 Outras operações ====
| |
| | |
| O FHIR permite também operações mais complexas, como PATCH (atualização parcial), transações em lote, operações condicionais e invocação de operações personalizadas. Estas funcionalidades são particularmente úteis em sistemas de larga escala ou em contextos onde há múltiplas instâncias do mesmo recurso.
| |
| | |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O FHIR utiliza a semântica dos verbos HTTP para interagir com recursos. A simplicidade das operações GET, POST, PUT e DELETE permite uma implementação clara e previsível, sem comprometer a robustez das aplicações clínicas. Esta abordagem aproxima o desenvolvimento em saúde das práticas comuns no desenvolvimento web moderno.
| |
| |}
| |
| | |
| === 7. Casos de aplicação na prática clínica ===
| |
| | |
| O modelo FHIR é utilizado para representar e organizar informação clínica de forma normalizada, permitindo a interoperabilidade entre sistemas, a automação de processos e a integração de dados em diferentes pontos do ciclo de cuidados.
| |
| | |
| Em contexto hospitalar, é possível utilizar recursos como Patient, Encounter e Observation para estruturar o registo de episódios clínicos, resultados analíticos e sinais vitais. A informação é representada de forma segmentada e relacionada, facilitando a consulta e a partilha entre serviços.
| |
| | |
| Na área da prescrição, os recursos MedicationRequest e MedicationAdministration permitem documentar o que foi prescrito e o que foi efetivamente administrado. Esta distinção é útil na reconciliação terapêutica, na rastreabilidade da medicação e na prevenção de erros.
| |
| | |
| Em programas de acompanhamento remoto, os utentes podem introduzir dados em aplicações móveis. Estes dados são convertidos em recursos Observation e integrados no sistema clínico. O modelo FHIR permite assim recolher, validar e utilizar informação gerada fora da unidade de saúde.
| |
| | |
| Os sistemas de apoio à decisão clínica também recorrem ao FHIR para obter dados em tempo real. Condições clínicas, resultados laboratoriais e diagnósticos estruturados podem ser analisados automaticamente por motores de inferência. A fiabilidade do processo depende da qualidade e da consistência dos recursos envolvidos.
| |
| | |
| Em instituições diferentes, a utilização de perfis FHIR partilhados facilita a interoperabilidade. Dados clínicos podem ser transferidos entre unidades de saúde com formatos comuns, evitando redundâncias e perdas de informação.
| |
| | |
| {| class="wikitable"
| |
| |+ Em resumo
| |
| |-
| |
| | O FHIR é aplicado em diferentes níveis da prática clínica. Permite estruturar episódios, acompanhar terapêuticas, recolher dados à distância, apoiar decisões e garantir a interoperabilidade entre instituições. A sua adoção melhora a organização da informação e a continuidade dos cuidados.
| |
| |}
| |
| | |
| === 8. FHIR em Portugal e na Europa ===
| |
| | |
| O standard FHIR é oficialmente recomendado pela Comissão Europeia no âmbito da construção do Espaço Europeu de Dados de Saúde (EHDS). A sua adoção visa garantir a interoperabilidade técnica e semântica dos sistemas de informação em saúde em todos os Estados-Membros.
| |
| | |
| Em Portugal, a SPMS tem vindo a alinhar progressivamente os seus sistemas com os princípios do FHIR. Projetos como o Registo de Saúde Eletrónico, o SClínico e as Plataformas de Interoperabilidade incluem já componentes que utilizam ou planeiam utilizar perfis baseados neste standard.
| |
| | |
| A existência de perfis nacionais de FHIR ainda é limitada, mas o país integra a iniciativa [X-eHealth](https://www.x-ehealth.eu/), que tem como objetivo definir perfis comuns de interoperabilidade entre países europeus.
| |
| | |
| O desenvolvimento de soluções FHIR em Portugal decorre em diferentes níveis, incluindo hospitais públicos com equipas de transformação digital, universidades, centros de investigação e startups na área da saúde.
| |
| | |
| {| class="wikitable"
| |
| |+ Referências úteis
| |
| |-
| |
| | Documentação oficial do HL7 FHIR || [https://hl7.org/fhir/ https://hl7.org/fhir/]
| |
| |-
| |
| | Espaço Europeu de Dados de Saúde (EHDS) || [https://health.ec.europa.eu/european-health-data-space_en https://health.ec.europa.eu/european-health-data-space_en]
| |
| |-
| |
| | Iniciativa europeia X-eHealth || [https://www.x-ehealth.eu/ https://www.x-ehealth.eu/]
| |
| |-
| |
| | Repositório de exemplos FHIR (Simplifier.net) || [https://simplifier.net/ https://simplifier.net/]
| |
| |}
| |
| | |
| === 9. Para aprofundar ===
| |
| | |
| Esta secção reúne alguns termos essenciais, ligações úteis para estudo autónomo e uma proposta de exercício formativo que ajuda a consolidar os conceitos apresentados.
| |
| | |
| ==== Glossário essencial ====
| |
| | |
| {| class="wikitable"
| |
| ! Termo técnico !! Definição
| |
| |-
| |
| | Resource || Unidade modular de informação estruturada no FHIR
| |
| |-
| |
| | Bundle || Conjunto de recursos enviados ou recebidos em bloco
| |
| |-
| |
| | Extension || Mecanismo formal para adicionar novos elementos a um recurso
| |
| |-
| |
| | Profile || Conjunto de regras adicionais aplicadas a um recurso base
| |
| |-
| |
| | Reference || Ligação entre recursos distintos
| |
| |-
| |
| | RESTful API || Interface baseada em chamadas HTTP (GET, POST, PUT, DELETE)
| |
| |-
| |
| | JSON || Formato leve de serialização de dados, compatível com FHIR
| |
| |}
| |
| | |
| ==== Ligações para consulta adicional ====
| |
| | |
| - Documentação oficial HL7 FHIR: [https://hl7.org/fhir/](https://hl7.org/fhir/)
| |
| - Repositório de exemplos e perfis: [https://simplifier.net/](https://simplifier.net/)
| |
| - Ferramenta de validação de recursos: [https://validator.fhir.org/](https://validator.fhir.org/)
| |
| - Espaço Europeu de Dados de Saúde (EHDS): [https://health.ec.europa.eu/european-health-data-space_en](https://health.ec.europa.eu/european-health-data-space_en)
| |
| - X-eHealth (iniciativa europeia de interoperabilidade): [https://www.x-ehealth.eu/](https://www.x-ehealth.eu/)
| |
| | |
| ==== Proposta de desafio final ====
| |
| | |
| Escolha um cenário clínico simples, como uma consulta, uma colheita analítica ou uma prescrição. Tente identificar quais seriam os recursos FHIR necessários para representar esse episódio de forma estruturada.
| |
| Exemplo: num episódio de consulta médica, pode ser utilizado Patient, Encounter, Condition, Observation e MedicationRequest.
| |
| | |
| Este exercício pode ser feito em papel ou num editor JSON simples, com recurso à documentação oficial.
| |
