Peel2056 D

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CAMPUS FLORIANÓPOLIS
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA
Igor Oliveira Vieira
Estruturação e Implantação de um Servidor de Sistema de Informação em

Saúde Baseado no Padrão HL7 FHIR de Interoperabilidade para Aplicações em
Engenharia Biomédica
Florianópolis
2021

Dissertação submetida ao Programa de Pós-Graduação

em Engenharia Elétrica da Universidade Federal de
Santa Catarina para a obtenção do título de mestre
em Engenharia Elétrica.
Orientador: Prof. Jefferson Luiz Brum Marques, PhD
Florianópolis
2021
Ficha de identificação da obra elaborada pelo autor,
através do Programa de Geração Automática da Biblioteca Universitária da UFSC.
Vieira, Igor Oliveira

Estruturação e Implantação de um Servidor de Sistema de
Informação em Saúde Baseado no Padrão HL7 FHIR de
Interoperabilidade para Aplicações em Engenharia Biomédica
/ Igor Oliveira Vieira ; orientador, Jefferson Luiz Brum
Marques, 2022.
128 p.
Dissertação (mestrado) - Universidade Federal de Santa

Catarina, Centro Tecnológico, Programa de Pós-Graduação em
Engenharia Elétrica, Florianópolis, 2022.
Inclui referências.
1. Engenharia Elétrica. 2. Interoperabilidade. 3.

Engenharia Biomédica. 4. Pesquisa Clínica. 5. Saúde
Digital. I. Marques, Jefferson Luiz Brum. II. Universidade
Federal de Santa Catarina. Programa de Pós-Graduação em
Engenharia Elétrica. III. Título.

O presente trabalho em nível de mestrado foi avaliado e aprovado por banca

examinadora composta pelos seguintes membros:
Alexandre Savaris, Dr.

Fundação de Amparo à Pesquisa e Extensão Universitária (FAPEU)
Prof. Renato Garcia Ojeda, Dr.

Universidade Federal de Santa Catarina (UFSC)
Certificamos que esta é a versão original e final do trabalho de conclusão que foi
julgado adequado para obtenção do título de mestre em Engenharia Elétrica.
Prof. Telles Brunelli Lazzarin, Dr.

Coordenação do Programa de
Pós-Graduação
Prof. Jefferson Luiz Brum Marques, PhD

Orientador
Florianópolis, 2021.
Dedico este trabalho ao meu avô Aildo, que infelizmente
nos deixou durante este processo.
AGRADECIMENTOS
Agradeço, primeiramente, ao meu orientador, professor Dr. Jefferson Luiz Brum

Marques, pela disponibilidade, dedicação, companheirismo e por me apresentar tópi-
cos de estudo que se tornaram minha paixão nos últimos anos.
Aos meus pais, Robislei e Edivane, que nunca mediram esforços em me auxiliar,
incentivar e apoiar em todos os processos da minha vida acadêmica e nos meus
sonhos. Por vocês eu pude descobrir o valor da educação e da pesquisa.
Aos colegas e grandes amigos que pude fazer no Instituto de Engenharia Biomé-
dica (IEB-UFSC) e na Universidade Federal de Santa Catarina (UFSC), em especial à
Mariana, Karla, Rosa, Caio, Victor, Esteferson, Samuel, Mateus, Carol, André e Maicon.
Com vocês o mestrado se tornou uma fase inesquecível da minha vida.
Aos professores do IEB-UFSC, que contribuíram na minha formação e no apren-
dizado na área de engenharia biomédica, que levarei por toda a minha carreira acadê-
mica e profissional.
Aos meus amigos distantes, em especial ao Waister e a Ruth, que mesmo em
tempo de pandemia me deram todo apoio e compreensão, sendo sempre solícitos e
me fazendo sorrir quando eu realmente precisava.
Ao meu companheiro Maycon, que esteve ao meu lado durante todos os pro-
cessos do mestrado, me dando apoio, companheirismo, amor, paciência e tornando os
meus dias melhores.
À CAPES, pelo incentivo e apoio financeiro.
"I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past, I will turn the inner eye to see its path.
Where the fear has gone there will be nothing. Only I will remain."
(Frank Herbert, 1965)
PRODUÇÃO ACADÊMICA
VIEIRA, I. O.; MARQUES, J. L. B. Proposta de um Servidor de Dados em Pesquisa

Clínica Baseado no Padrão HL7 FHIR de Interoperabilidade. Anais da VIII Escola
Regional de Computação Aplicada à Saúde, p. 94-97, 2021.
VIEIRA, I. O.; FRANCISCO, M.; NETO, J. M.; OJEDA, R. G.; MARQUES, J. L. B.

Proposta de um Servidor de Interoperabilidade de Dados em Pesquisa Clínica
com Padrão HL7 FHIR. XIII Simpósio de Engenharia Biomédica, 2021.
FRANCISCO, M.; VIEIRA, I. O.; NETO, J. M.; OJEDA, R. G.; MARQUES, J. L. B. Apli-
cação Web em Saúde 4.0: Uma Plataforma Multiusuário Baseada em um Servidor
HAPI FHIR. XIII Simpósio de Engenharia Biomédica, 2021.
RESUMO
A pesquisa clínica tem um papel fundamental na geração de evidências e na melhoria

da saúde pública. Porém, o planejamento, execução e análise de dados coletados e
gerados é essencialmente complexo e envolve esforços intensivos, uma ampla varie-
dade de partes interessadas, processos e multiplicidade de tipos de dados. Tem-se
observado isso no grande volume de dados de pesquisas em saúde sendo mani-
pulados, expondo a grande deficiência de sua padronização, já que instituições de
pesquisa trabalham com dados heterogêneos em relação às aplicações externas, o
que dificulta o compartilhamento e reutilização de informações. O conceito de interope-
rabilidade apresenta uma metodologia importante para tais problemas, onde sistemas
independentes tornam-se hábeis a trocar informações estruturadas e iniciar ações e
operações em conjunto, conectando aplicações, tornando os dados compartilháveis e
gerando benefício mútuo; não sendo mais considerada uma opção tecnológica e sim
um requisito fundamental no contexto da saúde digital. Para tal, há a necessidade de
se publicar padrões de interoperabilidade abertos e acessíveis. Um padrão que tem
se tornado emergente e amplamente utilizado na última década é o Fast Healthcare
Interoperability Resources (FHIR), desenvolvido pela Health Level Seven (HL7). Esse
padrão possui extensa possibilidade de aplicação na saúde, com excelentes atribu-
tos em segurança, velocidade e padrões web. Este trabalho apresenta um modelo
implementável de um servidor de dados, em conformidade com o padrão HL7 FHIR,
com o propósito de agregar e compartilhar pesquisas acadêmicas, realizando estudos
de caso no diagnóstico e acompanhamento do diabetes mellitus e na pesquisa em
engenharia clínica pela tecnovigilância. Para a implementação, foi utilizada a biblio-
teca Java de Application Programming Interface (API) para o FHIR (HAPI), um banco
de dados PostgreSQL para persistência de informações, o mapeamento de dados
utilizando o Python e terminologias de informação em saúde para manutenção da
semântica das informações. No mapeamento de dados, foi priorizada a anonimização
de dados sensíveis de voluntários antes mesmo do armazenamento, seguindo as di-
retrizes da Lei Geral de Proteção de Dados (LGPD). Sendo assim, o uso do servidor
mostrou eficácia no armazenamento e requisição de dados de pesquisa em um banco
de dados local, proporcionando o compartilhamento dentro de uma instituição e com
outras redes, pela API e utilização do padrão FHIR. Também foi possível realizar a
validação dos dados enviados ao servidor, para verificação do modelo de dados e do
uso correto de terminologias, garantindo estruturas de interoperabilidade de sintaxe
e de semântica, sem perda de informações. Ainda foi possível agregar e estender os
serviços implementados na proposta com aplicações de código livre, para a validação
das funcionalidades do servidor, para a publicação de um Guia de Implementação e
para a segurança do servidor, sem a necessidade de computação avançada e onerosa.
A proposta complementa a premissa de que estudos clínicos não precisam ser mais
considerados uma atividade isolada e sim conduzidos em estruturas de redes com
troca contínua e reutilização de dados, para eficiência e eficácia operacional. Com
isso, a colaboração, a coerência e convergência de dados devem tornar os serviços e
as ações desenvolvidas no ecossistema de saúde mais preditivos, personalizados e
interoperáveis.
Palavras-chave: HL7 FHIR. Sistema de Informação em Saúde. Pesquisa Clínica.

Saúde Digital. Interoperabilidade. Engenharia Biomédica.
ABSTRACT
Clinical research plays a crucial role in generating evidence and improving public health.
However, the planning, execution and analysis of collected and generated data is essen-
tially complex and involves intensive efforts, a wide variety of stakeholders, processes
and multiplicity of data types. This issue has been observed in the large volume of health
research data being manipulated, exposing the significant deficiency of its standard-
ization since research institutions work with heterogeneous data concerning external
applications, which makes sharing and reusing information difficult. The concept of in-
teroperability presents an essential methodology for such problems, where independent
systems become able to exchange structured information and initiate actions and oper-
ations together, connecting applications, making data shareable and generating mutual
benefit; no longer considered a technological option, but a fundamental requirement in
the context of digital health. For this, there is a need to publish open and accessible
interoperability standards. One standard that has become emerging and widely used
over the past decade is the Fast Healthcare Interoperability Resources (FHIR), devel-
oped by Health Level Seven (HL7). This standard has extensive application possibilities
in healthcare, with excellent security, speed, and web standards attributes. This work
presents an implementable model of a data server, following the HL7 FHIR standard,
to aggregate and share academic research, tested in case studies in the diagnosis
and monitoring of diabetes mellitus and research in clinical engineering through tech-
novigilance. The Java Application Programming Interface (API) library for FHIR (HAPI),
a PostgreSQL database for information persistence, data mapping using Python and
health information terminology for semantic maintenance of information were used for
the implementation. In data mapping, priority was given to the anonymization of sen-
sitive data from volunteers before storage, following Brazil’s General Data Protection
Law (LGPD) guidelines. Thus, the use of the server proved to be effective in storing
and requesting research data in a local database, providing sharing within an institution
and with other networks through the API and use of the FHIR standard. It was also
possible to validate the data sent to the server, to verify the data model and the correct
use of terminology, ensuring that interoperability structures of syntax and semantics
work without loss of information. It was also possible to add and extend the services
implemented in the proposal with open source applications to validate server function-
alities and publish an Implementation Guide (IG) and server security without needing
advanced and costly computing. The proposal complements the premise that clinical
studies no longer need to be considered an isolated activity but instead conducted
in network structures with continuous exchange and reuse of data for efficiency and
operational effectiveness. Thus, collaboration, coherence and data convergence should
make services and actions developed in the healthcare ecosystem more predictive,
personalized and interoperable.
Keywords: HL7 FHIR. Health Information System. Clinical Research. Digital Health.
Interoperability. Biomedical Engineering.
LISTA DE FIGURAS
Figura 1 – Interfaces de comunicação de dados entre sistemas distintos sem

protocolo (a) e com protocolo de transporte (b). . . . . . . . . . . . . 24
Figura 2 – Modelo ISO/OSI no processo de comunicação entre duas aplicações. 27
Figura 3 – Exemplo do corpo de uma mensagem na versão HL7 V2 (a) e HL7
V3 (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 4 – Estrutura da documentação online do padrão HL7 FHIR. . . . . . . 36
Figura 5 – Relação das categorias que subdividem os tipos de Resources. . . 37
Figura 6 – Formatos de representação dos Resources: modelo estrutural da
documentação (a), JSON (b) e XML (c). . . . . . . . . . . . . . . . . 37
Figura 7 – Representação de um Resource no formato computacional XML (a)
e em estrutura de blocos (b). . . . . . . . . . . . . . . . . . . . . . . 39
Figura 8 – Tipos de dados primitivos e complexos envolvidos nos elementos
dos Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Figura 9 – Estrutura de um Resource Patient na tabela lógica (a) e em uma
representação em JSON (b). . . . . . . . . . . . . . . . . . . . . . . 41
Figura 10 – Exemplo do fluxo de informações de um cenário de atendimento
clínico de paciente com sintomas de COVID-19 com os devidos Re-
sources Fast Healthcare Interoperability Resources (FHIR). . . . . . 42
Figura 11 – Exemplo de um cenário de atendimento clínico de paciente com
sintomas de COVID-19 com os Resources FHIR necessários e suas
devidas referências. . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 12 – Exemplo do uso de restrições no Recurso base Patient (a) para
criação de um profile (b). . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 13 – Exemplo de um slice utilizado em um Profile de coleta de pressão
arterial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 14 – Diagrama de especificidade e volume das derivações por meio dos
Profiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 15 – Exemplo de uma URL canônica do Profile VitalSign. . . . . . . . . . 46
Figura 16 – Exemplo de uma extensão no profile Immunization utilizada pelo SUS. 46
Figura 17 – Requisição HTTP em um servidor FHIR. . . . . . . . . . . . . . . . . 48
Figura 18 – Principais estruturas do FHIR relacionadas às terminologias e seus
relacionamentos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 19 – Estrutura do relacionamento dos Recursos de conformidade de um
ImplementationGuide. . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 20 – Guia de Implementação do International Patient Summary (IPS). . . 54
Figura 21 – Diagrama dos Módulos do sistema Screening for Diabetes Compli-
cations (SDC-X). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 22 – Exemplos de módulos existentes do SDC-X: módulo de aquisição
de PPG e ECG (a), módulo de aquisição de imagens da pupila (b),
software de análise e visualização da variabilidade de frequência
cardíaca (X-CARDIO) (c) e software de análise e visualização da
variação do raio da pupila (X-EYE) (d). . . . . . . . . . . . . . . . . 60
Figura 23 – Plataforma de notificação em tecnovigilância da ANVISA. . . . . . . 61
Figura 24 – Framework NASSS para a análise da não adoção, abandono e de-
safios de disseminação, expansão e sustentabilidade de tecnologias
na saúde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 25 – Diagrama de blocos dos principais componentes do servidor HAPI
JPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figura 26 – Esquema da tabela mestre dos Resources armazenados no banco
de dados PostgreSQL pelo servidor HAPI JPA. . . . . . . . . . . . . 67
Figura 27 – Esquema da tabela de referências de Resources no banco de dados
PostgreSQL pelo servidor HAPI JPA. . . . . . . . . . . . . . . . . . . 68
Figura 28 – Diagrama de transações HTTP (requisição e resposta) do servidor. 69
Figura 29 – Diagrama de interceptações realizadas após uma requisição HTTP
ao servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 30 – Dados no formato JSON coletados por dois módulos diferentes de
aquisição do SDC-X: X-CARDIO (a) e X-EYE (b). . . . . . . . . . . 75
Figura 31 – Fluxo da coleta de informações pelo módulo X-CARDIO do SDC-X
com os respectivos Resources. . . . . . . . . . . . . . . . . . . . . . 77
Figura 32 – Cenário da coleta de dados pelo módulo X-CARDIO do SDC-X com
os respectivos Resources e suas referências. . . . . . . . . . . . . . 78
Figura 33 – Exemplo das notificações de eventos adversos e queixas técnicas
de tecnovigilância da ANVISA. . . . . . . . . . . . . . . . . . . . . . 79
Figura 34 – Fluxo das informações das notificações de tecnovigilância da AN-
VISA com os respectivos Resources. . . . . . . . . . . . . . . . . . . 79
Figura 35 – Cenário do uso das notificações de tecnovigilância da ANVISA com
os respectivos Resources e suas referências. . . . . . . . . . . . . . 80
Figura 36 – CodeSystem desenvolvido para agrupar os conceitos utilizados pela
ANVISA e que não possuem sistema canônico. . . . . . . . . . . . . 83
Figura 37 – Página de autenticação com login de usuário do servidor. . . . . . . 86
Figura 38 – Diagrama de sequência da autenticação em operações de leitura de
Recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figura 39 – Diagrama de sequência da autenticação em operações de registro
de Recursos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 40 – Página inicial da interface de usuário do servidor proposto. . . . . . 89
Figura 41 – Página do Resource com suas operações. . . . . . . . . . . . . . . 90
Figura 42 – Resposta da API com o Recurso CapabilityStatement do servidor. . 91
Figura 43 – Página da interface Swagger UI para acesso à OpenAPI do servidor. 91
Figura 44 – Requisição realizada na interface Swagger UI para criação de um
Resource ResearchStudy na OpenAPI do servidor. . . . . . . . . . 92
Figura 45 – Resposta de uma requisição realizada na interface Swagger UI para
criação de um Resource ResearchStudy na OpenAPI do servidor. . 93
Figura 46 – Resposta do servidor com OperationOutcome manifestando erro na
validação do Resource. Resposta na interface do navegador (a) e
renderizada na ferramenta Postman (b). . . . . . . . . . . . . . . . . 94
Figura 47 – Página dos Resources do projeto IEB-UFSC on FHIR na plataforma
SIMPLIFIER.NET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 48 – Página inicial do Guia de Implementação do projeto IEB-UFSC on
FHIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 49 – Página do Recurso Patient do cenário do caso de uso SDC-X do
Guia de Implementação do projeto IEB-UFSC on FHIR. . . . . . . . 97
Figura 50 – Estrutura dos bundles utilizados para envio dos dados mapeados. . 98
Figura 51 – Exemplo de um mapeamento da estrutura original dos dados adqui-
ridos dos voluntários do SDC-CARDIO para o formato FHIR. . . . . 98
Figura 52 – Exemplo de um mapeador JSON (esquerda) para JSON do FHIR
(direita) desenvolvido em Python para os dados do SDC-X. . . . . . 99
Figura 53 – Exemplo de um mapeamento da estrutura original das notificações
de tecnovigilância da ANVISA para o formato FHIR. . . . . . . . . . 100
Figura 54 – Exemplo de um mapeador CSV (esquerda) para JSON do FHIR
(direita) desenvolvido em Python para os dados de tecnovigilância
da ANVISA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figura 55 – Comparação dos testes de conformidade dos Recursos do servidor
por inteiro (a) e com os dos estudos de caso (b). . . . . . . . . . . . 102
Figura 56 – Comparação dos testes de conformidade da interface RESTful API
do servidor por inteiro (a) e com os dos estudos de caso (b). . . . . 103
LISTA DE QUADROS
Quadro 1 – Principais padrões adotados pela Tecnologia da Informação na

Saúde. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Quadro 2 – Comparação entre os padrões de comunicação HL7 FHIR e ope-
nEHR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Quadro 3 – Comparações técnicas entre as versões HL7 V2, V3 e FHIR. . . . 34
Quadro 4 – Categorias dos Recursos com suas definições e principais exemplos. 38
Quadro 5 – Relação das cardinalidades possíveis nos elementos nos Recursos. 40
Quadro 6 – Resources responsáveis pela criação de perfis em estruturas do
padrão FHIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Quadro 7 – Tipos de interações suportadas pelas interfaces RESTful API imple-
mentadas com o FHIR. . . . . . . . . . . . . . . . . . . . . . . . . . 47
Quadro 8 – Interações HTTP suportadas pelas interfaces RESTful API basea-
das no FHIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Quadro 9 – Comparação de Implementações de Servidores HL7 FHIR. . . . . 55
Quadro 10 – Domínios de complexidade do framework NASSS. . . . . . . . . . 64
Quadro 11 – Interações de requisição na interface RESTful API do servidor. . . 70
Quadro 12 – Respostas das interações de requisição na interface RESTful API
do servidor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Quadro 13 – Principais Resources utilizados nos estudos de caso e suas descri-
ções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Quadro 14 – Alguns dos termos do SNOMED CT utilizados nos estudos de caso. 82
Quadro 15 – Alguns dos termos do LOINC utilizados nos estudos de caso. . . . 82
Quadro 16 – Alguns dos termos do UCUM utilizados nos estudos de caso. . . . 82
Quadro 17 – Domínios definidos para análise da proposta pelo framework NASSS. 84
Quadro 18 – Testes de performance realizados no servidor com dados sintetizados. 96
LISTA DE ABREVIATURAS E SIGLAS
ANVISA Agência Nacional de Vigilância Sanitária

API Application Programming Interface
CEPSH Comitê de Ética em Pesquisa com Seres Humanos
COVID-19 Coronavirus Disease 2019
CPU Central Processing Unit
CSV Comma-Separated Values
cURL Client Uniform Resource Locator
DAO Data Access Objects
DATASUS Departamento de Informática do Sistema Único de Saúde do Brasil
DICOM Digital Imaging and Communications in Medicine
DM Diabetes Mellitus
DM1 Diabetes Tipo 1
DM2 Diabetes Tipo 2
ECG Eletrocardiograma
EEG Eletroencefalograma
EHR Electronic Health Record
EMG Eletromiograma
FHIR Fast Healthcare Interoperability Resources
GDPR General Data Protection Regulation
HAPI HL7 Application Programming Interface
HIPAA Health Insurance Portability and Accountability Act
HIT Health Information Technology
HL7 Health Level Seven
HTTP Hypertext Transfer Protocol
i2b2 Informatics for Integrating Biology and the Bedside
IA Inteligência Artificial
ICD International Statistical Classification of Diseases and Related He-
alth Problems
ICTRP International Clinical Trials Registry Platform
IEB-UFSC Instituto de Engenharia Biomédica
IG Implementation Guide
IHE Integrating the Healthcare Enterprise
IoT Internet of Things
IPS International Patient Summary
ISO International Standardization Organization
JPA Java Persistence API
JSON JavaScript Object Notation
LGPD Lei Geral de Proteção de Dados Pessoais
LOINC Logical Observation Identifiers, Names, and Codes
NAD Neuropatia Autonômica Diabética
NASSS Nonadoption, Abandonment, and challenges to the Scale-up,
Spread, and Sustainability
OAS OpenAPI Specification
OAuth Open Authorization
OHDSI Observational Health Data Sciences and Informatics
OMOP Observational Medical Outcomes Partnership
openEHR Open Eletronic Health Record
OSI Open Systems Interconnection
PaaS Platform-as-a-Service
PCORNet Patient Centered Outcome Research Network
PPG Fotopletismografia
RDF Resource Description Framework
ReBEC Registro Brasileiro de Ensaios Clínicos
REST Representational State Transfer
RNDS Rede Nacional de Dados em Saúde
SCTID SNOMED CT Identifier
SDC-X Screening for Diabetes Complications
SI International System of Units
SNA Sistema Nervoso Autônomo
SNOMED CT Systematized Nomenclature of Medicine Clinical Terms
SOA Service Orientated Architecture
SOAP Simple Object Access Protocol
SQL Structured Query Language
SUS Sistema Único de Saúde
TCLE Termo de Consentimento Livre e Esclarecido
UCUM The Unified Code for Units of Measure
UFSC Universidade Federal de Santa Catarina
URI Uniform Resource Identifier
URL Uniform Resource Locator
VFC Variabilidade de Frequência Cardíaca
WHO World Health Organization
WHO-ART World Health Organization - Adverse Reaction Terminology
XHTML Extensible Hypertext Markup Language
XLSX Microsoft Excel Open XML Format Spreadsheet
XML Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.1 MOTIVAÇÃO E JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . 20
1.2 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.2 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1 INTEROPERABILIDADE NA PESQUISA EM SAÚDE . . . . . . . . . 23
2.2 PARADIGMAS DE INTEROPERABILIDADE . . . . . . . . . . . . . . 25
2.2.1 Interoperabilidade de Transporte . . . . . . . . . . . . . . . . . . . 25
2.2.2 Interoperabilidade de Estrutura . . . . . . . . . . . . . . . . . . . . 25
2.2.3 Interoperabilidade de Semântica . . . . . . . . . . . . . . . . . . . 25
2.3 MODELO ISO/OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.1 Application Programming Interface . . . . . . . . . . . . . . . . . . 27
2.3.2 Representational State Transfer . . . . . . . . . . . . . . . . . . . . 28
2.4 PADRÕES DE INTEROPERABILIDADE NA SAÚDE . . . . . . . . . 29
2.5 HEALTH LEVEL SEVEN . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.1 HL7 FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.5.1.1 Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1.2 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5.1.2.1 Cenário Clínico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5.1.3 Perfilização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1.4 Extensibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.5.1.5 Operações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.5.1.6 Terminologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.5.1.7 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.5.1.7.1 Mapeamento de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5.1.7.2 Guias de Implementação . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.5.1.7.3 Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.6 PESQUISA NA SAÚDE . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.6.1 Diabetes Mellitus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.6.1.1 Screening for Diabetes Complications . . . . . . . . . . . . . . . . . . 58
2.6.2 Tecnovigilância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.6.2.1 Notificações em Tecnovigilância . . . . . . . . . . . . . . . . . . . . . 60
2.7 FRAMEWORK NASSS . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3 MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1 SERVIDOR HL7 FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.1 Servidor HAPI JPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.2 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.1.3 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.1.3.1 Arquitetura do Banco de Dados . . . . . . . . . . . . . . . . . . . . . 67
3.1.4 Interface RESTful API . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.1.5 Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.6 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.1.7 Validação do Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2 MAPEAMENTO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . 73
3.2.1 Dados Sintéticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.2.2 Screening for Diabetes Complications . . . . . . . . . . . . . . . . 74
3.2.2.1 Aspectos Éticos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.2.3 Tecnovigilância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.3 GUIA DE IMPLEMENTAÇÃO . . . . . . . . . . . . . . . . . . . . . . . 78
3.3.1 Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.3.2 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3.3 Terminologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.3.4 Implementation Guide . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.4 ANÁLISE NASSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1 SERVIDOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.1 Deploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.2 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.1.3 Interface de Usuário . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.1.4 Interface RESTful API . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.5 Validação de Recursos . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1.6 Pacote de Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.3.1 Estudos de Caso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3.1.1 Simulador Sintético de População . . . . . . . . . . . . . . . . . . . . 95
4.3.1.2 SDC-X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.3.1.3 Tecnovigilância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.4 BANCO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.5 INTERFACE RESTFUL API . . . . . . . . . . . . . . . . . . . . . . . 101
4.6 AVALIAÇÃO E VALIDAÇÃO DO SERVIDOR . . . . . . . . . . . . . . 101
5 DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1 PADRÃO HL7 FHIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2 SERVIDOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.5 INTERFACE RESTFUL API . . . . . . . . . . . . . . . . . . . . . . . 107
5.6 INTEROPERABILIDADE NA PESQUISA . . . . . . . . . . . . . . . . 107
5.7 ANÁLISE NASSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6.1 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . 111
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
APÊNDICE A – RESOURCES PRESENTES NA DOCUMENTAÇÃO
E SUAS CATEGORIAS . . . . . . . . . . . . . . . . 123
APÊNDICE B – ANÁLISE DA PROPOSTA PELO FRAMEWORK
NASSS . . . . . . . . . . . . . . . . . . . . . . . . . 124
ANEXO A – ESQUEMA DE INDEXAÇÃO PARA PESQUISA NO BANCO
DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . 127
19
1 INTRODUÇÃO
A pesquisa na saúde desempenha um papel fundamental no avanço médico e

na melhoria dos resultados clínicos. Além disso, tem se tornado claro que a agregação
e mineração de dados de saúde de múltiplas fontes são papéis importantes na medi-
cina de precisão. Esses dados precisam ser compartilhados e comparados entre si,
apoiando o conhecimento baseado em evidências e reduzindo o custo da realização
de estudos (LEROUX et al., 2017).
Tem-se observado que diversos setores vêm sendo bem-sucedidos na obtenção
de valores da integração e análise em grande escala de fontes de dados heterogêneos.
Isso se deu ao passo que a indústria descobriu que big data se torna transformador
quando conjuntos de dados dissemelhantes podem ser vinculados e utilizados em con-
junto (THE BIOMEDICAL DATA TRANSLATOR CONSORTIUM, 2019). Já nos grandes
bancos de dados biomédicos, esses dados são espalhados pelas instituições e isola-
dos de forma proposital, para a proteção e privacidade do paciente. Portanto, deve-se
enfrentar primeiro os desafios técnicos e sociais para vincular essas informações e
tirar o maior proveito delas na assistência médica (WEBER et al., 2014).
O grande volume de dados biomédicos sendo manipulados expõe uma grande
deficiência na padronização do mesmo. Órgãos de pesquisa possuem necessidades
singulares e manejam dados heterogêneos em relação a sistemas externos. São ne-
cessárias adaptações, que são longas, dispendiosas e complexas, além de qualificação
de pessoal para tal. Essas adaptações tornam essas informações aptas para sistemas
distintos as utilizarem (BENSON; GRIEVE, 2021).
A interoperabilidade surgiu como o conceito necessário para tais problemáticas.
De acordo com o Standard Computer Glossary, interoperabilidade é a habilidade de
dois ou mais sistemas ou componentes em intercambiar e utilizar as informações que
foram trocadas (IEEE, 1991). Nesse âmbito, sistemas seriam capazes de comunicarem
entre si de forma homogênea e transparente, apesar das diferenças de linguagem,
interface e plataforma de execução. Para tal, há a necessidade de se publicar padrões
de interoperabilidade abertos e acessíveis (BRAUNSTEIN, 2018a).
A interoperabilidade é essencial para que informações tenham fluxo livre, pre-
cisão, eficiência e segurança entre sistemas da tecnologia de informação da saúde
e redes que apoiam centros médicos e profissionais na prestação de cuidados ao
paciente. Esse fluxo permite que o setor da saúde alcance objetivos relacionados à
melhor gestão de saúde da população, de cuidados preventivos, de custo-benefícios e
segurança do paciente (OEMIG; SNELICK, 2016).
A Saúde 4.0, um novo conceito que aplica princípios da Indústria 4.0, integra
tecnologias de Internet of Things (IoT) para coleta de dados, o uso de Inteligência
Artificial (IA) para análise de dados, de blockchain para registros médicos de pacientes
Capítulo 1. Introdução 20
e a interoperabilidade para compartilhamento das informações. Logo, a colaboração,

coerência e convergência devem tornar a saúde mais preditiva e personalizada (CHAN-
CHAICHUJIT et al., 2019).
Pode-se observar esses novos conceitos sendo implementados em propostas
como a telemedicina e a telessaúde. A telemedicina refere-se à prestação de serviços
de saúde, informação clínica e educação à distância, por meio da telecomunicação, ou
seja, pelo transporte de dados em grande parte pela internet, enquanto a telessaúde
abrange um conceito maior e interdisciplinar, relacionando enfermagem, odontologia,
psicologia e fisioterapia, na teleconsulta, telediagnóstico, teleconsultoria e segunda
opinião formativa (MAHEU et al., 2002; MARCOLINO et al., 2013; DEPARTAMENTO
DE INFORMÁTICA DO SUS, 2020a).
O surgimento da pandemia do Coronavirus Disease 2019 (COVID-19), causada
pelo vírus SARS-CoV-2, mostrou ser um caso de uso clínico de abrangência geral,
demonstrando o quanto a interoperabilidade é de enorme importância para o bem
público. Tornou-se evidente como as instituições existem em silos e são limitadas na
troca de dados (GREENE et al., 2021). Logo, foi emergente criar novas políticas de
saúde pública no mundo, tornando a interoperabilidade uma grande aliada das novas
soluções.
O FHIR, um padrão de comunicação desenvolvido pela Health Level Seven
(HL7), tem sido o mais amplamente adotado pela comunidade da saúde e mostra
ser o candidato ideal para o desafio da interoperabilidade na pesquisa clínica. Com
isso, este trabalho propõe a implementação de um servidor de dados de pesquisa
clínica utilizando o HL7 FHIR, que é considerado um padrão emergente e um grande
candidato como ferramenta para padronização e comunicação de dados de pesquisa
em saúde (BENSON; GRIEVE, 2021). Assim, o trabalho desenvolvido tem a proposta
de automatizar uma metodologia de integração de fontes de dados de pesquisa com
uma arquitetura confiável, acelerando o processo de descobertas clínicas.
1.1 MOTIVAÇÃO E JUSTIFICATIVA
A comunidade acadêmica fornece um ecossistema de reflexão e de criação

de novas tecnologias que abordam o cuidado dos pacientes, aplicando perspectivas
críticas e as novas tecnologias (HUSSEY; MCGLINN, 2019). Contudo, há um grande
desafio em inserir o contexto da informática e da interoperabilidade no favorecimento
dessa área. Tem-se como exemplo as pesquisas relacionadas ao Diabetes Mellitus
(DM), que incorporam diversas metodologias de estudo e produzem variados tipos de
dados e resultados que sofrem dificuldades em serem compartilhados e reutilizados.
Essa problemática foi considerada pelos pesquisadores do Instituto de Engenharia Bio-
médica (IEB-UFSC) da Universidade Federal de Santa Catarina (UFSC), que realizam
pesquisas sobre diagnóstico e acompanhamento do DM e suas complicações (TERRA,
2020; UCKER et al., 2019; UCKER, 2020).

O DM engloba as doenças metabólicas resultantes da deficiência na secreção
de insulina, na sensibilidade ou ação dela, ou até mesmo ambas, causando a hiperglice-
mia no sangue (MARTINEZ et al., 2019). Além disso, o DM pode causar complicações
graves quando não controlado. Níveis elevados de glicemia por longos períodos, in-
fluenciam na degeneração progressiva de vários órgãos e em complicações crônicas.
Entre essas complicações, destaca-se a Neuropatia Autonômica Diabética (NAD), cau-
sadora de lesões nos neurônios componentes do Sistema Nervoso Autônomo (SNA),
afetando o sistema cardiovascular, gastrointestinal, geniturinário, sudomotor, metabó-
lico e oftalmológico. Para a identificação dessas disfunções, alguns testes de screening
podem ser realizados, sendo grande parte deles para disfunções no sistema cardio-
vascular, como a resposta da frequência cardíaca à manobra de Valsalva e da pressão
arterial ao levantar-se (TESFAYE; WU, J., 2018). Grande parte desses testes requerem
profissionais especializados, equipamentos onerosos e uma participação dinâmica do
paciente.
Além do diagnóstico precoce, há ainda a necessidade de acompanhamento da
doença, pois quanto maior a variedade de exames, maior a abrangência da avaliação
do SNA. Além da NAD, o diabetes pode causar outras diversas complicações, tornando
evidente a necessidade de sistemas que integrem diversas técnicas e metodologias
em realizarem avaliações mais completas de indivíduos diabéticos.
Por essa razão, está sendo desenvolvido no IEB-UFSC da UFSC, um sistema
de saúde digital ubíquo, denominado Screening for Diabetes Complications (SDC-X).
Esse sistema tem como objetivo auxiliar a detecção precoce e acompanhamento das
complicações causadas pelo DM, utilizando várias técnicas de análise (e.g., análise da
função autonômica, pupilometria dinâmica). O sistema é constituído por módulos de
aquisição de dados fisiológicos, módulos concentradores, módulo de armazenamento
e módulo de interface e análise. Os módulos de aquisição e os concentradores são
distribuídos em centros organizacionais, permitindo a coleta de dados da população
de forma descentralizada. Já o módulo de armazenamento e análise são centralizados
na nuvem.
Considerando o desenvolvimento do sistema SDC-X, do seu potencial de auxí-
lio no diagnóstico e acompanhamento de indivíduos com NAD e na necessidade de
compartilhar dados de pesquisas em engenharia biomédica para avanço médico uni-
versal, este trabalho tem como uma das motivações a implementação de um servidor
de dados interoperáveis baseado no padrão HL7 FHIR. Este servidor será incorporado
ao SDC-X como o novo módulo de armazenamento do sistema, amplificando o con-
ceito de interoperabilidade de dados na pesquisa acadêmica. Também será realizado
estudo de caso com dados de tecnovigilância de produtos médico-hospitalares, vali-
dando a proposta em uma maior abrangência nos contextos de saúde e de engenharia
biomédica.
1.2 OBJETIVOS
Nas seções abaixo estão descritos o objetivo geral e os objetivos específicos

deste trabalho.
1.2.1 Objetivo Geral
Desenvolver um servidor HL7 FHIR de interoperabilidade para apoio aos dados

de pesquisas relacionadas à saúde e incorporá-lo aos estudos sendo desenvolvidos
no IEB-UFSC e em outros contextos clínicos.
1.2.2 Objetivos Específicos
Para cumprir o objetivo geral, foram definidos os seguintes objetivos específicos:

• Projetar um servidor conformante com o padrão HL7 FHIR, o seu banco de
dados e sua interface RESTful API;
• Desenvolver um Guia de Implementação como documentação para utilização
do sistema proposto;
• Implementar o servidor em testes locais e em nuvem;
• Elaborar metodologias de mapeamento de dados de pesquisa para o padrão
FHIR;
• Avaliar e validar o sistema proposto com estudos de caso de pesquisa clínica
do Diabetes Mellitus e de tecnovigilância.
23
2 REFERENCIAL TEÓRICO
Neste capítulo é apresentada a fundamentação teórica que embasa a execução

deste trabalho. Inicialmente é abordada a importância da interoperabilidade na pequisa
em saúde, o padrão de interoperabilidade adequado à proposta do trabalho e o estado
da arte do mesmo. Logo após, são apresentadas as linhas de pesquisas que foram
utilizadas como estudos de caso e, por fim, um framework para a avaliação e validação
do trabalho proposto.
2.1 INTEROPERABILIDADE NA PESQUISA EM SAÚDE
A pesquisa clínica conduz um papel fundamental na geração de evidência, que

por fim traz melhorias à saúde pública. Porém, o planejamento, execução e análise de
dados coletados e gerados é essencialmente complexo e envolve esforços intensivos,
uma ampla variedade de partes interessadas, fluxos de trabalho, processos, multiplici-
dade de tipos de dados e diversos recursos computacionais (SHORTLIFFE; CIMINO,
2014).
Há um grande volume de dados de pesquisas em engenharia biomédica sendo
manipulados, o quê expõe uma grande deficiência na padronização do mesmo. As
instituições de pesquisa possuem necessidades singulares e trabalham com dados
heterogêneos em relação aos sistemas e pesquisas externas, o que dificulta o com-
partilhamento e reutilização dos dados gerados (BENSON; GRIEVE, 2021). Como
exemplificação, pode-se investigar essa problemática calculando o número de links
para a conexão de n sistemas diferentes em um modelo de troca completo, como
verificado na Equação (1):
n(n – 1)
links = (1)
2
Logo, se dois sistemas procuram um meio de comunicação entre si, será ne-
cessária apenas uma interface de comunicação. Porém, com o incremento de novos
sistemas, o número de links aumenta consideravelmente. Por exemplo, para a conexão
simultânea de 6 nós seriam necessárias 15 interfaces (Figura 1a) e para 50 nós seriam
necessários 1225 links, tornando-se uma explosão combinatória e uma metodologia
inviável para a problemática (BENSON; GRIEVE, 2021).
Pode-se observar essa explosão combinatória pela Figura 1a, onde cada sis-
tema deve implementar sua própria interface de conexão para cada um dos outros
sistemas. Já na Figura 1b, os sistemas recorrem a um mesmo protocolo de trans-
porte, ou seja, utilizando uma mesma interface de comunicação. Com isso, tem-se a
metodologia de interoperabilidade de dados.
A interoperabilidade apresenta um contexto importante para tais problemas, pois
com essa metodologia, os sistemas independentes tornam-se hábeis a trocar informa-
Capítulo 2. Referencial Teórico 24
Figura 1 – Interfaces de comunicação de dados entre sistemas distintos sem protocolo

(a) e com protocolo de transporte (b).
Fonte – Elaborado pelo autor (2021).
ções significativas e iniciar ações e operações em conjunto, gerando benefício mútuo

(MIRANDA et al., 2010). Na saúde, o objetivo principal desse conceito é o de conec-
tar aplicações, tornar os dados compartilháveis no ambiente de saúde e distribuídos
para equipes médicas e pacientes acessarem onde e quando necessitarem. Logo, a
interoperabilidade não é mais considerada uma opção tecnológica e sim um requisito
fundamental na prestação efetiva de cuidados e no bem estar dos pacientes (ROGERS
et al., 2010).
A gestão de dados de saúde é um domínio com várias propostas de soluções
e conhecimentos acumulados ao longo de anos de investigação. O uso de padrões,
por exemplo, é um pré-requisito em quase todos os sistemas médicos. O conjunto
de padrões HL7 é indiscutivelmente o esforço de padronização mais reconhecido no
campo da informática em saúde. O seu padrão mais recente, o HL7 FHIR, é um
protocolo aberto, moderno e líder em interoperabilidade, sendo, portanto, ideal para
atuar como fonte de inspiração e repositório das melhores práticas digitais em relação
ao domínio clínico (KILINTZIS et al., 2019).
O padrão HL7 FHIR tem o potencial de solucionar vários problemas de interope-
rabilidade, que causam o longo impedimento da informática em atingir seu impacto na
qualidade da saúde pública, na relação de custo benefício e na segurança de dados.
Isso ocorre devido à premissa de promover um acesso mais aberto e facilitado aos
dados clínicos, com devidas permissões, além de oferecer o potencial do paciente
agregar facilmente seus dados de saúde de quaisquer provedores que mantenham
eles. Assim, o usuário pode gerenciar e utilizar esses dados em aplicações de sua
preferência e na decisão de contribuir em pesquisas clínicas (BRAUNSTEIN, 2018a).
2.2 PARADIGMAS DE INTEROPERABILIDADE
A complexidade da interoperabilidade pode ser explorada em 3 paradigmas

apresentados nas seções seguintes, assim como também suas devidas utilizações na
saúde digital (BRAUNSTEIN, 2018a).
2.2.1 Interoperabilidade de Transporte
A forma mais simples e fácil de transferência de dados entre sistemas, onde

o empacotamento e transferência de dados utilizam padrões bem compreendidos e
implementados pelo sistema remetente e destinatário. Porém, o mecanismo de trans-
porte não possui conhecimento e entendimento dos dados transportados e o quê eles
significam (e.g., email, ligação telefônica) (BRAUNSTEIN, 2018a; BENSON; GRIEVE,
2021).
Na saúde digital, destaca-se a tecnologia Representational State Transfer (REST)
como aliada à interoperabilidade de transporte de prontuários eletrônicos, por exem-
plo, já que oferece uma interface de envio e recebimento padronizado pelo protocolo
Hypertext Transfer Protocol (HTTP).
2.2.2 Interoperabilidade de Estrutura
Nesse nível os dados são empacotados em formatos bem definidos, onde a iden-
tidade de cada elemento é reconhecida por todos os sistemas envolvidos, baseada na
localização na estrutura. Assim, os dados recebidos são analisados e armazenados
nos locais apropriados no sistema destinatário. Nesse nível, os padrões utilizados de-
vem identificar quais os valores que são permitidos para que os sistemas comunicantes
estejam utilizando suficientemente a mesma linguagem. Além disso, esse nível pode
também possibilitar o envio de dados anexos sem nenhuma estrutura (BRAUNSTEIN,
2018a; BENSON; GRIEVE, 2021).
Esse nível de interoperabilidade é alcançado na utilização de padrões de repre-
sentação e transferência de dados clínicos, como os protocolos desenvolvidos pela
HL7 e pela openEHR International. Com esses padrões, é possível detectar que um
campo específico de um prontuário é composto por um pré-determinado elemento ou
código, como por exemplo a informação de um teste em laboratório e seu resultado
nos campos esperados (BRAUNSTEIN, 2018b).
2.2.3 Interoperabilidade de Semântica
É o nível mais alto de interoperabilidade, onde os dados necessitam ser su-

ficientemente padronizados, a ponto de todos os sistemas envolvidos entenderem
claramente seus significados, sem possíveis ambiguidades (BRAUNSTEIN, 2018a;
BENSON; GRIEVE, 2021). Por exemplo, no apoio à decisão clínica são utilizados
dados de um paciente para a análise e recomendações de diagnósticos e tratamen-

tos específicos para o indivíduo. Sem a interoperabilidade semântica, seria impossí-
vel que um outro sistema de prontuário receptor compreendesse essas informações
com confiabilidade suficiente para tomada de decisões no atendimento do paciente
(BRAUNSTEIN, 2018b).
A interoperabilidade semântica é a mais difícil de se atingir, mas existem mé-
todos de alcançá-la, principalmente na utilização de terminologias e suas ontologias.
Na saúde, pode-se encontrar dezenas de sistemas de conceitos clínicos, laboratoriais,
classificação de doenças, dentre outras terminologias (OEMIG; SNELICK, 2016).
Logo, pode-se observar que há uma necessidade frequente e recorrente de inte-
roperabilidade de estrutura e de semântica entre sistemas de informação de pesquisas
clínicas. Essa necessidade exige o projeto, a seleção e a aplicação de padrões de
dados, assim como também a capacidade de mapear e harmonizar modelos de infor-
mação para o compartilhamento de resultados e para uma maior interação entre os
sistemas envolvidos (SHORTLIFFE; CIMINO, 2014). Antes de apresentar os padrões
emergentes utilizados na saúde, deve-se contextualizar primeiro a interoperabilidade
no transporte, apresentado na seção a seguir.
2.3 MODELO ISO/OSI
Outro aspecto importante relacionado à interoperabilidade está no chamado Mo-

delo Open Systems Interconnection (OSI) da International Standardization Organiza-
tion (ISO), que representa os processos de transformação e transporte de informações
de uma aplicação para outra. Logo, para o envio de dados, uma aplicação deve coletar
cada unidade desses dados com suas semânticas e codificá-los de acordo com um
padrão de transferência de dados subjacente, como observado na Figura 2. Assim, o
resultado é enviado para o outro sistema, que é responsável por desempacotar esse
encapsulamento e interpretá-lo (OEMIG; SNELICK, 2016).
A grande maioria das interfaces realizam todos os passos necessários das ca-
madas 5, 6 e 7 em uma única operação, devido à sequência de caracteres serem
simples, ou seja, cada elemento de dados está em sua posição pré-determinada. Po-
rém, deve-se saber que as informações codificadas e representadas nas mensagens
não são necessariamente idênticas ao dados retirados do banco de dados. A codifica-
ção e o gerenciamento dos conjuntos de caracteres são dois aspectos que devem ser
tratados de modo separado quando na transição de uma camada para outra (OEMIG;
SNELICK, 2016).
Dados clínicos são altamente estruturados e devem ser preservados quando
transportados, serializando e representando suas informações de forma que possa ser
revertida de forma determinística pelo receptor; assim, caracteres específicos nos da-
dos não devem impedir um entendimento correto pelo lado receptor. O gerenciamento
Figura 2 – Modelo ISO/OSI no processo de comunicação entre duas aplicações.
Fonte – Adaptado de Oemig e Snelick (2016).
incorreto das camadas dentro de uma interface são a origem de diversos problemas;
logo, a realização correta delas dá a pré-condição necessária para a interoperabilidade
(OEMIG; SNELICK, 2016).
A Camada de Aplicação torna-se então a fundação necessária para manuten-
ção da semântica do que é intercambiado. A HL7 mostrou-se uma grande aliada e
propagadora do conceito, aplicando-o nos dados relacionados à saúde.
2.3.1 Application Programming Interface
As especificações de interoperabilidade podem ser abordadas pelos seguintes

conceitos (BENSON; GRIEVE, 2021):
• Mensagens: conjunto de informações fixas que podem ser trocadas entre
aplicações quando um evento específico ocorre;
• Serviços: conjunto de operações que um sistema expõe para outros utiliza-
rem, juntamente com os comportamentos esperados;
• Documentos: conjunto de pacotes de informações fixas que podem ser
trocados ou armazenados para uso posterior.
Sendo assim, o conceito de interoperabilidade requer que ambos os sistemas
remetentes e destinatários conheçam o que estão trocando, além de quando e por
qual motivo. Logo, todas essas abordagens possuem o mesmo fim, sendo necessário
distinguir quais soluções são padronizadas e quais serão deixadas ao critério de quem
implementa. Portando, um sistema de mensagens vincula a descrição das informações
a um conjunto de tecnologias para a troca de dados, mas deixa aos implementado-
res decidirem quais serviços o sistema irá oferecer. Enquanto isso, as abordagens de
serviço definem quais operações serão oferecidas e quais informações serão troca-
das, deixando aos implementadores a vinculação de tecnologias (BENSON; GRIEVE,

2021).
Durante boa parte da década de 2000, a Service Orientated Architecture (SOA)
serviu como um popular meio de gerenciar coleções de sistemas distintos, principal-
mente em grandes empresas. Essa metodologia envolvia o padrão web Simple Object
Access Protocol (SOAP) para a conexão de diversos serviços dentro de um meio
empresarial. Com a evolução dos novos serviços na internet, um novo conceito, de-
nominado Application Programming Interface (API), foi introduzido nos formatos de
comunicação. Uma API é um conjunto de serviços oferecidos por uma biblioteca de
programação e que podem ser reutilizados por outros sistemas. Os sistemas opera-
cionais são construídos a partir desses serviços, mas isso pode ser estendido para
operações em toda a rede web (BENSON; GRIEVE, 2021).
Nas abordagens de especificação de interoperabilidade, as APIs são interfaces
de serviços. Logo, uma API é vinculada a uma tecnologia específica e concentra-se
em fornecer uma definição concreta de um conjunto de recursos de um sistema (BEN-
SON; GRIEVE, 2021). Para a comunicação por meio de API, a arquitetura utilizada é
apresentada a seguir.
2.3.2 Representational State Transfer
A Representational State Transfer (REST) foi primeiramente apresentada por

Fielding (2000), como um conjunto de restrições, métodos e arquiteturas de comunica-
ção em redes, com utilização de interfaces escalonáveis, confiáveis e fáceis de serem
utilizadas. A partir disso, a comunidade expandiu o conceito e atualmente a arquitetura
está presente em quase todas a tecnologias web e nas APIs.
A tecnologia REST demonstra o quanto é possível desenvolver grandes imple-
mentações e ecossistemas, com grande rapidez e escalabilidade. Isso é alcançado
baseado nos seus principais fundamentos de transporte de recursos (BENSON; GRI-
EVE, 2021):
• Interface Uniforme: os recursos são identificados por um Uniform Resource
Locator (URL) e são representados por diversos formatos (e.g., XML, JSON).
Os clientes manipulam os recursos por meio de mensagens auto-descritivas
e as hipermídias e hipertextos atuam como o mecanismo de transferência
de estado;
• Interações Sem Estado: entre as requisições, nenhum contexto do cliente
é armazenado no servidor. Logo, toda a informação necessária nas requisi-
ções estão na URL, cabeçalho e corpo das mensagens;
• Armazenável em Cache: as respostas podem se definir armazenáveis ou
não;
• Cliente e Servidor: os clientes não se preocupam com o armazenamento

de dados e o servidor não se preocupa com a interface do usuário;
• Sistema em Camadas: um cliente não pode saber se está conectado ao
servidor final ou a um intermediário (e.g., serviço de segurança).
Em comparação com o SOAP, o REST é mais leve, portanto possui mensagens
menores, análises mais rápidas e menor latência, sendo uma abordagem melhor para
implementação de aplicações. Além disso, o REST fornece acesso e respostas ágeis,
reduzindo o consumo de Central Processing Unit (CPU) e carga de serviços acessa-
dos (MALIK; KIM, 2017). Com isso, as implementações que são conformantes com
os princípios básicos da arquitetura REST são conhecidas como interfaces RESTful
(BENSON; GRIEVE, 2021).
2.4 PADRÕES DE INTEROPERABILIDADE NA SAÚDE
A Tecnologia da Informação na Saúde, Health Information Technology (HIT),

é o conceito que define o processamento de informações em hardware e software,
lidando com armazenamento, recuperação, compartilhamento e utilização de dados
do contexto da saúde, seja para comunicação ou tomada de decisões (THOMPSON;
BRAILER, 2004). Para a utilização da HIT, deve-se levar em conta que há diversas
necessidades quanto à utilização das tecnologias envolvidas, pois a coleta de dados,
a forma de utilização e como disponibilizá-los modifica de acordo com as dimensões
distintas das organizações, sejam de cunho administrativo, clínico e do próprio paciente
(LONGARAY; CASTELLI, 2020).
Para alcançar tais premissas, a HIT adota padrões de interoperabilidade em
saúde. Esses padrões são modelos desenvolvidos e aprovados por autoridades, de-
talhando as terminologias, protocolos, métodos e especificações para a coleta, com-
partilhamento, armazenamento e recuperação de informações relacionadas à saúde
(ERICKSON et al., 2003). Porém, por mais que esses padrões possuem similaridades,
existem diversas diferenças em seus métodos de utilização de terminologias, códigos,
formatos lógicos e representações técnicas. Essas diferenças tornam as transações
entre sistemas suscetíveis a perda de dados ou até mesmo do sentido deles, causando
frustração do propósito de se ter padrões interoperáveis (ALLWELL-BROWN, 2016).
O Quadro 1 apresenta os principais padrões de tecnologia de informação adotados
atualmente na saúde.
Em relação aos padrões de interoperabilidade de estrutura, os principais são
o HL7 FHIR e o Open Eletronic Health Record (openEHR). Ambos são recentes, ro-
bustos, com documentações completas para troca e persistência de dados, além de
capacidade de lidar com conjunto de dados complexos, enquanto oferecem completo
suporte à interoperabilidade semântica (HEALTH LEVEL SEVEN INTERNATIONAL,
Quadro 1 – Principais padrões adotados pela Tecnologia da Informação na Saúde.
Formato dos Dados Terminologia Conteúdo EHR Transação

XML SNOMED CT openEHR HL7 V2
JSON LOINC CIMI HL7 V3
RDF ICD-10, ICD-11 HL7 CDA HL7 FHIR
HTML UCUM
DICOM
Legenda: XML (Extensible Markup Language), JSON (JavaScript Object Notation),
RDF (Resource Description Framework ), HTML (HyperText Markup Language),
SNOMED CT (Systematized Nomenclature of Medicine Clinical Terms), LOINC
(Logical Observation Identifiers, Names and Codes), ICD (International Statistical
Classification of Diseases and Related Health Problems), UCUM (Unified Code for
Units of Measure), DICOM (Digital Imaging and Communications in Medicine),
openEHR (Open Eletronic Health Record), CIMI (Clinical Information Model Initiative),
HL7 CDA (Clinical Document Architecture), HL7 V2 (HL7 Versão 2), HL7 V3 (HL7
Versão 3) e HL7 FHIR (Fast Healthcare Interoperability Resources).
Fonte – Adaptado de Allwell-Brown (2016).
2021a; OPENEHR FOUNDATION, 2021). Em suma, os dois padrões são considera-

dos o futuro da persistência e troca de dados de saúde, pois possuem fácil acesso
às especificações detalhadas, implementações em código aberto para diversas aplica-
ções, extensa comunidade adotante e suporte ativo (ALLWELL-BROWN, 2016). Uma
comparação das principais características entre os dois padrões destacados pode ser
observada no Quadro 2.
Ambos os padrões possuem código fonte aberto, com ampla gama de ferramen-
tas para modelagem de dados, tanto para desenvolvedores, pesquisadores e entusias-
tas da área. Além disso, os dois padrões suportam uma grande variedade de tipos de
dados; bancos de dados relacionais e não-relacionais; sistemas de terminologias exter-
nas e aquelas definidas pela organização do padrão, para representação de conceitos
codificáveis; interface REST; reutilização de código para economia de tempo e cus-
tos em desenvolvimento, simplificando empacotamento, implantação e manutenção;
mecanismos de segurança; versionamento; extensibilidade e suporte de uma vasta
comunidade ativa de desenvolvedores (HEALTH LEVEL SEVEN INTERNATIONAL,
2021a; OPENEHR FOUNDATION, 2021).
Em comparações técnicas, é demonstrado que com o FHIR as consultas são
mais rápidas, curtas e simples do que as do openEHR, mesmo se elas forem mais
avançadas e detalhadas. Além disso, o openEHR é incapaz de lidar com algumas
terminologias externas e consultas REST complexas, que se tornam longas e ilegí-
veis, enquanto o FHIR prospera em consultas legíveis, compreensíveis e menores
(ALLWELL-BROWN, 2016).
Em suma, o openEHR mostra-se ser um padrão notável para as estruturas de in-
Quadro 2 – Comparação entre os padrões de comunicação HL7 FHIR e openEHR.
HL7 FHIR openEHR

Conjunto de dados com-
Filosofia Princípio de Pareto
pleto, mas exaustivo
Nível de Conceito Resource Archetype
Número de Conceitos
∼140 ∼760
Disponíveis
Línguas Suportadas ISO 639 ISO 639
Sistema de Gerencia-
mento de Banco de Da- RDBMS e NoSQL RDBMS e NoSQL
dos
Tipos primitivos e comple- Tipos primitivos e comple-
Tipos de Dados
xos xos
Terminologias Internas e externas Internas e externas
Formato de Represen-
XML e JSON XML, JSON e ADL/AOM
tação
Código Fonte Aberto Sim Sim
Suporte à Interface
Sim Sim
REST
Consulta REST Curta e simples Longa e complexa
Formalismo dos Da-
Curto Muito longo
dos
Curva de Aprendizado Fácil Difícil
Fonte – Adaptado de Health Level Seven International (2021a) e openEHR Foundation (2021).
formação da saúde, mas sua abordagem resultou em um modelo complicado, com con-
sultas complexas, problemas com terminologias externas que tornam a performance
da troca e reutilização de dados prejudicada, além de uma curva de aprendizado de
grande dificuldade para iniciantes. Já o FHIR possui uma premissa simples, leve e
rápida, demostrando que, embora fosse destinado primeiramente para mensagens de
dados do tipo Electronic Health Record (EHR), pode ser destinado efetivamente como
uma especificação autossuficiente para registro eletrônico, agregação, troca e reutiliza-
ção de dados (ALLWELL-BROWN, 2016). Portanto, o padrão HL7 FHIR mostra-se ser
o padrão apropriado para a proposta deste trabalho, sendo apresentado com maiores
detalhes nas próximas sessões.
2.5 HEALTH LEVEL SEVEN
A Health Level Seven, comumente conhecida como HL7, é uma organização

sem fins lucrativos credenciada para a criação de padrões para intercâmbio, integração,
compartilhamento e requisição de informações eletrônicas de saúde. O “Level Seven”
refere-se ao sétimo e último nível do modelo OSI, o de aplicação, sendo assim a
camada que fornece a estrutura para comunicação entre sistemas distintos. Esses
padrões apoiam a prática clínica, gestão, prestação e avaliação de serviços associados

a saúde.
Desde a sua fundação, em 1987, a HL7 desenvolveu diversos desses padrões,
sendo os mais conhecidos o V2, V3 e o FHIR. Além desses padrões de mensagens,
a HL7 também oferece padrões conceituais (e.g., HL7 RIM), padrões de documentos
(e.g., HL7 CDA) e normas para aplicações (e.g., HL7 CCOW) (HEALTH LEVEL SEVEN
INTERNATIONAL, 2021c).
A Versão 2 (HL7 V2), desenvolvida em 1989, é a mais amplamente implemen-
tada no domínio de troca de dados eletrônicos entre sistemas. Ela é focada em fornecer
suporte a um sistema central de atendimento ao paciente, como também a ambientes
distribuídos e departamentais. Mesmo sendo bem adotada em hospitais e comunida-
des locais, essa versão carece de uma ontologia formal unificada para os conceitos
que são trocados nas mensagens e interfaces. Já a Versão 3 (HL7 V3), lançada em
1995, agregou mais conjuntos de mensagens, tipos de dados e terminologias, para
implementações mais completas, porém mais complexas. Essa complexidade foi ob-
servada na implementação de vários grandes projetos e a versão não foi bem recebida
mundialmente, sendo pouco usada atualmente (HEALTH LEVEL SEVEN INTERNATI-
ONAL, 2021c; BENDER; SARTIPI, 2013). Um exemplo do corpo de uma mensagem
em HL7 V2 e HL7 V3 é apresentado na Figura 3.
Já o HL7 FHIR, lançado em 2011, veio com o conceito de fornecer transporte e
estrutura, além de certo grau de interoperabilidade semântica, abrindo grande espaço
para implementações web e melhor compartilhamento de dados relacionados à saúde,
sejam administrativos, de saúde pública e até mesmo de pesquisa (BRAUNSTEIN,
2018b; HEALTH LEVEL SEVEN INTERNATIONAL, 2021c). O Quadro 3 apresenta uma
comparação dos principais atributos entre as versões oficiais do HL7, demonstrando
os benefícios evidentes que podem ser adquiridos com a utilização do FHIR.
2.5.1 HL7 FHIR
O Fast Healthcare Interoperability Resources (FHIR), lançado em 2011, propôs

um padrão para facilitar o intercâmbio de informações combinando o melhor das ver-
sões V2 e V3. Esse novo modelo aproveita dos melhores padrões web e com foco em
implementabilidade. O FHIR foi fundado a partir de um conjunto de componentes em
módulos chamados de Resources (Recursos). Eles são as bases para a contextualiza-
ção e solução de problemas clínicos e administrativos reais, com menor complexidade
e custos de implementação (BENSON; GRIEVE, 2021).
Cada letra da sigla FHIR estende um conceito elementar do padrão (BENSON;
GRIEVE, 2021; HEALTH LEVEL SEVEN INTERNATIONAL, 2021a):
• Fast: foco em implementações rápidas e fáceis;
• Healthcare: cobre informações de saúde humana e veterinária;
Figura 3 – Exemplo do corpo de uma mensagem na versão HL7 V2 (a) e HL7 V3 (b).
Fonte – Adaptado de Health Level Seven International (2021c).
• Interoperability: adequado para uso em ampla variedade de contextos, seja

para aplicações web, móveis, nuvem, servidores, dentre outros;
• Resources: fornece os recursos base para troca de informações, podendo
ser adaptados com perfis, extensões e terminologias.
O padrão possui um conceito com quatro paradigmas bases de troca: interface
REST, documentos, mensagens e serviços. Logo, por meio de uma interface RESTful
API, ocorre o intercâmbio de documentos, pelo envio e recebimento de mensagens
que expõem e invocam serviços. A arquitetura RESTful API atua na manipulação dos
Recursos com um conjunto de interações pré-definidas (i.e., Create, Read, Update,
Delete, Search, History, Transaction, Operation), que já são amplamente utilizadas na
web (MAXHELAKU; KIKA, 2019). Já os Resources são representados em instâncias
JavaScript Object Notation (JSON) ou Extensible Markup Language (XML). Ambos são
formatos leves de troca de dados, fáceis de serem gerados e analisados por máquinas
e compreensíveis para a leitura e escrita por humanos (SOLBRIG et al., 2017).
Em suma, o padrão HL7 FHIR tem o propósito de abordar a interoperabilidade
com um modelo de dados simples, bem estruturado, expressivo e eficiente. Já em
questão arquitetural, o protocolo tem os seguintes princípios (HEALTH LEVEL SEVEN
Quadro 3 – Comparações técnicas entre as versões HL7 V2, V3 e FHIR.

Atributo HL7 V2 HL7 V3 HL7 FHIR
Ano de Lançamento 1987 1995 2011
Model Driven Archi- Iterativo e Incre-
Metodologia de Desenvolvimento Ad hoc
tecture (MDA) mental
RESTful, Docu-
Mensagens, Cam- Orientação por Mo-
Paradigmas mentos, Mensa-
pos e Registros delo
gens e Serviços
Curva de Aprendizado Médio Difícil Fácil
Ontologia Semântica Não Sim Sim
Necessidade de Ferramentas Es- Sim, compilador de
Sim, parser Não
pecializadas modelo
Diretamente Consumível Sim Não Sim
Centenas de Pági- Milhares de Pági- Centenas de Pági-
Tamanho da Documentação
nas nas nas
Documentação com Exemplos de
Sim Mínimo Sim
Implementação
Implementações de Referência
Não Não Sim
Disponibilizadas pela HL7
Suporte da Comunidade Forte Baixo Muito Forte
Adequado para Dispositivos Mó-
Não Não Sim
veis
Grau de Adoção Alto Baixo Muito Alto
Suporte à Codificação Internacio- Conceitualmente
Não, apenas ASCII Sim, UTF-8
nal Sim
Compatibilidade com outras Ver-
Não Não Sim, V2, V3 e CDA
sões do HL7
Fonte – Adaptado de Bender e Sartipi (2013) e Health Level Seven International (2021c).
INTERNATIONAL, 2021a; BENSON; GRIEVE, 2021):

• Reutilização e Composibilidade: os Recursos FHIR foram projetados ba-
seados no Princípio de Pareto, onde o foco está em 20% dos requisitos,
satisfazendo 80% das necessidades de interoperabilidade. Assim, são aten-
didos os requisitos comuns dos muitos casos de uso, evitando propagação
de muitos Recursos sobrepostos e redundantes. Os Resources ainda podem
referenciar uns aos outros, permitindo reutilização e construção de estrutu-
ras complexas e combináveis. Além disso, o padrão suporta customização e
extensibilidade para adaptação em usos específicos;
• Escalabilidade: o uso de interfaces RESTful API garantem transações com
menos sessões e uso de memória, assegurando escalabilidade horizontal;
• Performance: os Resources FHIR são sucintos e adequados para trocas
em rede. Além disso, os Recursos utilizam formatos altamente otimizados
(i.e., JSON e XML), melhorando o desempenho em transações complexas
entre múltiplos sistemas;
• Usabilidade: os Recursos são compreensíveis para especialistas técnicos e
não-técnicos. Mesmo com detalhes complexos na sintaxe de algum formato,
os seus conteúdos podem ser legíveis em qualquer navegador ou leitor de

texto;
• Fidelidade dos Dados: o FHIR é extremamente tipado, com mecanismos de
conexão a terminologias e validação sintática, mostrando o quanto o padrão
é importante para a interoperabilidade semântica;
• Implementabilidade: a documentação do padrão é facilmente compreen-
dida e prontamente implementada, utilizando tecnologias modernas e emer-
gentes.
2.5.1.1 Documentação
A especificação base do padrão está disponibilizada na internet de forma aberta

e com material sucinto, sem restrições e com uma grande gama de exemplos. A página
web da especificação oficial oferece todo o conteúdo, com definições acessíveis e de
fácil entendimento, para desenvolvedores e agentes diretos de saúde que estão criando
ou já utilizando softwares ou soluções de interoperabilidade. Porém, vale ressaltar
que as especificações FHIR não definem modelos de boa prática clínica (HEALTH
LEVEL SEVEN INTERNATIONAL, 2021c). A estrutura da documentação online do
padrão é apresentada na Figura 4, onde as especificações são subdivididas em níveis
compreensíveis e complementares.
A HL7 disponibiliza o FHIR sobre a licença Creative Commons CC0 1.0 Uni-
versal, sendo dedicada ao domínio público, seja para cópia, redistribuição e imple-
mentação em produtos relacionados, sem a permissão, mesmo para fins comerciais
(CREATIVE COMMONS, 2021). Além disso, o FHIR está em constante evolução e na
produção deste trabalho foi considerada a versão mais recente, a 4.0.1, lançada em
Outubro de 2019 e conhecida como R4 (HEALTH LEVEL SEVEN INTERNATIONAL,
2021a).
2.5.1.2 Resources
Os blocos essenciais de intercâmbio, os Resources, ou Recursos, são as re-

presentações das instâncias de algum tipo de entidade de saúde, sejam relacionados
a dados demográficos, administrativos, observações clínicas, resultados laboratoriais,
dentre centenas de outros. No momento deste trabalho, estão disponibilizados cerca
de 140 Recursos na especificação (Apêndice A), cada um com seu nível de maturidade.
Essa maturidade se dá pela evolução do padrão, podendo caracterizar um Recurso
como estável (Normative), recém lançado (Draft) ou com um certo nível de maturi-
dade, que se encontra entre 0 e 5. Quanto mais próximo de 5, maior a maturidade e
aproximação de se tornar um Recurso normativo (LACKERBAUER et al., 2018). Por
fim, os Recursos são subdivididos em 5 grandes categorias de contextos, como es-
Figura 4 – Estrutura da documentação online do padrão HL7 FHIR.
Fonte – Health Level Seven International (2021a).
quematizado na Figura 5. A descrição de cada categoria e os principais exemplos de

Resources são apresentados no Quadro 4.
Os Recursos utilizam formatos altamente otimizados para comunicação na web,
sendo representados em XML, JSON e Resource Description Framework (RDF). Os
formatos XML e JSON são os mais utilizados para aplicações na internet, já que são
facilmente elaborados, lidos e utilizados em APIs. Como o RDF possui benefícios
principalmente em torno da análise de dados, ele não é comumente utilizado no in-
tercâmbio de informações. A Figura 6 apresenta como uma determinada estrutura no
padrão FHIR pode ser representada no formato JSON e XML (HEALTH LEVEL SEVEN
INTERNATIONAL, 2021a).
Como apresentado na Figura 7, todos os Recursos possuem características em
comum, sendo alguns elementos obrigatórios e outros opcionais (HAWIG et al., 2019):
• Metadados: todo Resource possui uma identidade lógica única (ID) em
relação ao sistema que está armazenado, sendo utilizado no acesso por URL.
Também encontra-se as informações relacionadas à versão do Recurso, sua
última atualização, se é baseado em algum perfil ou outras informações
técnicas relacionadas à algum fluxo de trabalho;
Figura 5 – Relação das categorias que subdividem os tipos de Resources.
Figura 6 – Formatos de representação dos Resources: modelo estrutural da documen-

tação (a), JSON (b) e XML (c).
Fonte – Adaptado de Health Level Seven International (2021a).
• Narrativa: texto escrito em Extensible Hypertext Markup Language (XHTML)

que se torna legível quando compilado em algum sistema. Geralmente trata-
se de um resumo textual do conteúdo do Recurso;
• Extensões: suporte para estruturas criadas a partir de casos particulares e
não presentes da documentação base;
• Elementos: instâncias previamente definidas da especificação e distintas
para cada tipo de Resource. Cada elemento suporta algum tipo de dado e
Quadro 4 – Categorias dos Recursos com suas definições e principais exemplos.

Categoria Descrição Exemplos
Recursos mais rudimentares e ligados à infra-
StructureDefinition, Valu-
Foundation estrutura. Nem sempre são referenciados por
eSet, Bundle
outros Recursos
Recursos mais utilizados e, portanto, os de
maior grau de consistência e rigor arquitetô-
Patient, Practitioner, Or-
Base nico. Costumam ser referenciados por outros
ganization, Device
Recursos, mas raramente fazem referências
por conta própria
Condition, Observation,
Recursos de natureza clínica que normal-
Clinical DiagnosticReport, Pro-
mente se baseiam nos Recursos Base
cedure
Recursos de cunho financeiro que se ba- Account, Coverage,
Financial
seiam nos Recursos Clínicos e de Base Claim, PaymentNotice
Recursos especializados em casos de uso
ResearchStudy, Mea-
Specialized menos comuns e que geralmente fazem re-
sure, Questionnaire
ferência aos Recursos de Base
Fonte – Adaptado de Saripalle (2019) e Health Level Seven International (2021a).
agrega as informações de forma padronizada.

Os elementos suportam tipos de dados pré-definidos, sendo todos documen-
tados na especificação online, como apresentado na Figura 8. Esses tipos são de
extrema importância na manutenção da semântica dos dados e são subdivididos em 4
grupos (SARIPALLE, 2019):
• Tipos Primitivos: tipos simples e de um único elemento de valor primitivo
(e.g., números, caracteres, datas, valores booleanos);
• Tipos de Dados de Uso Geral: tipos compostos por conjuntos de elementos
reutilizáveis (e.g., o HumanName, ou nome humano, contém uma estrutura
com o primeiro nome, sobrenome, prefixos, dentre outros elementos do
nome de um indivíduo);
• Tipos de Metadados: dados relacionados aos metadados de um Recurso;
• Tipos de Dados de Propósito Especial: tipos específicos e definidos com
maiores detalhes na especificação (e.g., o tipo Reference estrutura a forma
de se referenciar outros Recursos, especificando qual o tipo, a URL e o
identificador do mesmo).
Como observado na Figura 9a, a documentação fornece uma tabela lógica
de cada Recurso. Essa tabela define uma árvore com a estrutura base, definindo o
nome de cada elemento, as suas flags, cardinalidade, tipo de dados e definição. As
flags possuem informações que impactam como os desenvolvedores podem manipular
tais elementos. A cardinalidade estabelece a quantidade de instâncias aceitas na
validação do elemento (e.g., o elemento gender, em Patient, pode possuir apenas
um argumento ou nenhum). O Quadro 5 apresenta a definição de cada cardinalidade
Figura 7 – Representação de um Resource no formato computacional XML (a) e em

estrutura de blocos (b).
possível. Logo após é definido qual o tipo de dado que o elemento suporta, como
apontado na Figura 8. Por fim, a tabela descreve as informações importantes sobre
os elementos e as possíveis restrições (HEALTH LEVEL SEVEN INTERNATIONAL,
2021a).
A Figura 9b apresenta uma representação real de um Patient no formato JSON.
Como observado no exemplo, o elemento resourceType define qual é o tipo de Re-
source e deve estar sempre presente no início da representação. O id estabelece a
identificação única do Recurso no sistema que ele está presente, diferente do identifier,
responsável por identificar o recurso em sistemas mais abrangentes (e.g., no exemplo,
o identificador oferece o registro único do paciente em um sistema de registros médi-
cos). Como observado, o id não está presente na tabela lógica, pois é um elemento
do tipo metadado e deve estar presente em todos os Recursos. O elemento active
fornece a informação no tipo booleano, como definido na documentação. Já o name,
por suportar um tipo complexo, recebe uma estrutura composta por mais membros e
vários tipos de dados (HEALTH LEVEL SEVEN INTERNATIONAL, 2021a).
Figura 8 – Tipos de dados primitivos e complexos envolvidos nos elementos dos Re-
sources.
Quadro 5 – Relação das cardinalidades possíveis nos elementos nos Recursos.

Cardinalidade Descrição
0..1 O atributo pode ocorrer opcionalmente apenas uma vez
0..* O atributo pode ocorrer opcionalmente
1..1 O atributo deve ocorrer exatamente uma vez
1..* O atributo deve ocorrer e pode se repetir
Fonte – Adaptado de Oemig e Snelick (2016).
2.5.1.2.1 Cenário Clínico
Como exemplificação de como o padrão é utilizado em um contexto clínico,

considera-se o seguinte cenário e os Resources empregados: um paciente (Patient)
procura um hospital (Organization) com sintomas de febre e tosse persistente (Con-
ditions). A partir disso, um enfermeiro (Practitioner ) afere a temperatura do indivíduo
(Observation) com um termômetro digital (Device) e confirma a condição de febre (Con-
dition). Por determinação do hospital durante a pandemia do COVID-19, o protocolo
determina que esse paciente passe por um exame laboratorial (Observation) realizado
por um biomédico (Practitioner ). Por meio desse exame, é detectado que o indivíduo
está infectado pelo vírus Sars-CoV-2 e com a doença do Coronavírus 2019 (Condi-
tion). Todo esse processo é documentado por meio de uma consulta (Encounter ) e
Figura 9 – Estrutura de um Resource Patient na tabela lógica (a) e em uma represen-

tação em JSON (b).
acompanhado por um médico especialista (Practitioner ). Esse fluxo de atendimento é

apresentado na Figura 10.
Esse possível cenário de atendimento é esquematizado na Figura 11, represen-
tando os Recursos utilizados e as referências entre eles.
2.5.1.3 Perfilização
Como os processos de saúde global não possuem uma jurisdição central e

são extremamente variados e com diferenças geográficas, políticas e industriais, a
HL7 oferece um padrão que pode ser personalizado e dispõe de estruturas para o
gerenciamento dessa variabilidade no FHIR. Com isso, restrições podem ser feitas e
disponibilizadas como Profiles dos Recursos base. Com essas adaptações, é possível
realizar as seguintes intervenções (BENSON; GRIEVE, 2021):
• Escolher, pela cardinalidade, quais elementos de um Recurso serão usados
ou não;
• Estabelecer elementos adicionais que não estão na especificação base;
• Estabelecer quais ferramentas de API serão utilizadas e como;
• Determinar quais terminologias serão utilizadas em alguns elementos parti-
culares;
Figura 10 – Exemplo do fluxo de informações de um cenário de atendimento clínico de

paciente com sintomas de COVID-19 com os devidos Resources FHIR.
• Descrever como elementos devem ser mapeados para requisitos e imple-

mentações locais.
As estruturas responsáveis por estabelecer esses profiles são os de tipo Con-
formance, que fazem parte do grupo Foundation, como apresentado anteriormente na
Figura 5. O Quadro 6 detalha cada um desses Resources em relação à criação de
perfis.
Por exemplo, uma determinada instituição cadastra seus pacientes em recursos
que obrigam que o elemento gender (gênero) seja sempre preenchido, diferente do
Recurso base, que possibilita o elemento ser ignorado quando necessário. Esse tipo
de restrição pode ser observada na Figura 12b, onde a cardinalidade foi alterada de
0..1 para 1..1.
Um outro exemplo seria a coleta da pressão arterial de uma pessoa adequando
ao Recurso Observation, por meio da utilização de um profile chamado VitalSign já
Figura 11 – Exemplo de um cenário de atendimento clínico de paciente com sinto-

mas de COVID-19 com os Resources FHIR necessários e suas devidas
referências.
publicado. Essa estrutura apresenta um modelo específico de como utilizar o Recurso

com os elementos corretos e a terminologia específica do procedimento (i.e., pressão
sistólica e diastólica). Nesse cenário é utilizado um artifício conhecido como slicing,
onde um elemento pode ocorrer mais de uma vez e então pode ser dividido em sub-
listas onde cada elemento tem suas próprias restrições (HEALTH LEVEL SEVEN
INTERNATIONAL, 2021a). O processo de slicing utilizado no perfil de coleta de pressão
arterial é esquematizado na Figura 13.
Profiles são mais genéricos quando mais próximos da documentação base, ou
seja, terão um volume muito grande de Resources. Diferentemente, Profiles de níveis
mais baixos serão mais específicos e terão menos Resources em conformidade com
os perfis, como demonstrado na Figura 14.
Um fato importante sobre os perfis está na obrigatoriedade de publicá-los com
uma URL canônica, que identifica o profile como único dentro de um sistema. Essa
URL é utilizada no processo de validação dos Recursos que são conformantes com o
perfil específico. Na Figura 15 é demonstrado um exemplo de URL canônica do perfil
heartrate, que define os parâmetros para elaborar um Recurso Observation com dados
de frequência cardíaca de um indivíduo.
Quadro 6 – Resources responsáveis pela criação de perfis em estruturas do padrão

FHIR.
Resource Descrição
Detalha todas as características da API utilizada, assim
CapabilityStatement
como suas restrições
Adiciona novas operações e parâmetros de pesquisa que
OperationDefinition / SearchParameter
não fazem parte da especificação base
Define como uma estrutura específica (Resource, Exten-
StructureDefinition
sion ou tipo de dado) deve ser utilizada
Reúne conjuntos de terminologias e quais códigos deles
ValueSet
serão utilizados em um elemento que é codificado
Realiza o mapeamento entre terminologias padrões e lo-
ConceptMap
cais ou outros tipos de modelos
Define os identificadores de um código ou de um sistema
NamingSystem
identificador
Figura 12 – Exemplo do uso de restrições no Recurso base Patient (a) para criação de
um profile (b).
Fonte – Adaptado de US Realm Steering Committee (2020).
2.5.1.4 Extensibilidade
As implementações específicas podem requisitar conjunto de dados que não

fazem parte da documentação, mas que podem ser incorporados pelo FHIR como
Extensions (extensões), que são basicamente novos elementos que reutilizam os tipos
de dados da especificação base (PFAFF et al., 2019).
O Sistema Único de Saúde (SUS), por exemplo, utiliza seu profile do Recurso
Immunization para registrar as imunizações de pacientes na Rede Nacional de Dados
em Saúde (RNDS). Mas o Recurso base não possui um elemento que auxilie na clas-
sificação do paciente em um grupo de atendimento (e.g., indivíduo com comorbidade,
gestante, idoso) e para isso utiliza uma extensão (grupoAtendimento) para adicionar
Figura 13 – Exemplo de um slice utilizado em um Profile de coleta de pressão arterial.
Figura 14 – Diagrama de especificidade e volume das derivações por meio dos Profi-
les.
Fonte – Adaptado de (FIRELY, 2021a).
essa informação como um novo elemento, mas reutilizando o tipo de dado complexo
CodeableConcept da documentação (Figura 16). Essa extensão ainda restringe qual
sistema de terminologia de classificação deve ser utilizado, sendo todos esses parâme-
tros levados em consideração quando validados por um servidor que seja conformante
com esses perfis. Vale ressaltar que essas estruturas devem ser sempre publicadas e
acessíveis para os sistemas que irão adotá-las.
Figura 15 – Exemplo de uma URL canônica do Profile VitalSign.
Figura 16 – Exemplo de uma extensão no profile Immunization utilizada pelo SUS.
Fonte – Adaptado de Departamento de Informática do SUS (2021b).
2.5.1.5 Operações
Como o padrão é elaborado para atender principalmente as aplicações web

existentes, o FHIR possibilita o uso de REST API para manuseio dos Recursos. As
APIs suportam reutilização de código, seja de sintaxe e semântica, fornecendo fun-
cionalidades já implementadas, reduzindo o tempo e esforço que desenvolvedores
gastam no desenvolvimento de aplicações (QIU et al., 2016). Logo, uma API garante
que o envio de uma mensagem para um sistema em um formato específico sempre
retornará uma resposta. Essa tecnologia é utilizada por bilhões de transações virtu-
ais entre diversos dispositivos, tais como computadores, smartphones e servidores
(BRAUNSTEIN, 2018b).
Baseado no paradigma REST, cada tipo de Recurso possui o mesmo conjunto

de interações definidas, podendo ser usadas para gerenciá-los de maneira altamente
granular, como apresentado no Quadro 7. Assim, as transações são todas realizadas
diretamente com o servidor por meio de solicitação e resposta em HTTP, mas não
abordam as questões de autenticação e autorização, já que o padrão não se trata de
um protocolo de segurança (HEALTH LEVEL SEVEN INTERNATIONAL, 2021a).
Quadro 7 – Tipos de interações suportadas pelas interfaces RESTful API implementa-

das com o FHIR.
Interações em Nível de Instância
read Lê o estado atual do Resource
vread Lê o estado de uma determinada versão de um Resource
update Atualiza um Resource existente pelo seu ID (ou cria um se for novo)
patch Atualiza um Resource existente postando uma série de alterações
delete Deleta um Resource
history Recupera o histórico de alterações de um Resource específico
Interações em Nível de Tipo
create Cria um novo Resource com ID atribuído pelo servidor
search Pesquisa um tipo de Resource baseado em alguns critérios de filtragem
history Recupera o histórico de alterações de um tipo de Resource específico
Interações em Todo o Sistema
capabilities Obtêm o CapabilityStatement do sistema
batch/transaction Atualiza, cria ou deleta uma série de Resources em uma única interação
history Recupera o histórico de alterações de todos os Resources
search Pesquisa todos os tipos de Resources baseados em alguns critérios de filtragem
Os servidores implementados com o FHIR podem escolher quais dessas opera-

ções serão disponibilizadas e quais os Resources que serão suportados, mas sempre
devem fornecer essas informações no Recurso CapabilityStatement do sistema (HE-
ALTH LEVEL SEVEN INTERNATIONAL, 2021a).
Uma requisição HTTP em um servidor FHIR ocorre tipicamente como o da Fi-
gura 17. Deve-se primeiro especificar o HTTP Verb que identifica a interação desejada
(i.e., GET, POST, PUT, DELETE). Logo após, tem-se a URL base do servidor, ou seja,
o endereço onde todos os Recursos definidos por uma interface estão localizados
(endpoint). Assim, adiciona-se o tipo de Resource desejado (e.g., Patient, Observation,
ResearchStudy ) e o ID existente ou que será atribuído ao Recurso na operação. Por
fim, tem-se a escolha opcional pelo formato da codificação da mensagem (i.e., XML ou
JSON) (HEALTH LEVEL SEVEN INTERNATIONAL, 2021a). As principais interações
HTTP podem ser observadas no Quadro 8.
2.5.1.6 Terminologias
Assim como toda linguagem, os termos clínicos podem fugir da formalização e

causar ambiguidade, causando problemas significativos à informação que será trans-
Figura 17 – Requisição HTTP em um servidor FHIR.
Quadro 8 – Interações HTTP suportadas pelas interfaces RESTful API baseadas no

FHIR.
Interação HTTP Verb Caminho
Create POST https://{example.com}/{path}/{resourceType}
Read GET https://{example.com}/{path}/{resourceType}/{id}
Update PUT https://{example.com}/{path}/{resourceType}/{id}
Delete DELETE https://{example.com}/{path}/{resourceType}/{id}
Search GET https://{example.com}/{path}/{resourceType}?{Parâmetros_de_Pesquisa}
History GET https://{example.com}/{path}/{resourceType}/{id}/_history
Transaction POST https://{example.com}/{path}/
Operation GET https://{example.com}/{path}/{resourceType}/{id}/${Operação}
portada. Esse problema é conhecido há mais de duzentos anos e resultou na criação

da nosologia, um ramo que trata da classificação e terminologia clínica. Com a cres-
cente implementação da computação, o padrão FHIR suporta e recomenda a utilização
de terminologias. Para isso, o protocolo fornece na sua documentação ferramentas
para representação e comunicação de dados codificados e estruturados (BENSON;
GRIEVE, 2021).
Para a utilização de terminologias na comunicação, é necessária a aplicação de
sistemas de códigos. Esses sistemas são estruturas que publicam listas de códigos ou
um conjunto de regras para a composição deles, onde cada código pode ser associado
a um conjunto de definições, para que tenham um significado conhecido, claro e único.
Existem sistemas de códigos bastante conhecidos e amplamente utilizados, como o
Systematized Nomenclature of Medicine Clinical Terms (SNOMED CT) para termos
clínicos, o Logical Observation Identifiers, Names, and Codes (LOINC) para termos
laboratoriais, o International Statistical Classification of Diseases and Related Health
Problems (ICD) para classificação de doenças, o The Unified Code for Units of Measure
(UCUM) para unidades de medidas, dentre outros (METKE-JIMENEZ et al., 2018).
Para a integração de terminologias no padrão, existem estruturas e meios de
as utilizarem. As principais estruturas e seus relacionamentos são apresentadas na Fi-

gura 18. Basicamente, um elemento dentro de um Recurso que faz referência a algum
código, deve primeiro se basear na estrutura ou perfil daquele elemento (ElementDe-
finition), esse por sua vez tem um vínculo (bind) com uma seleção de códigos com
contexto particular (ValueSet). Essa seleção é baseada em um conjunto de conceitos
e seus significados (CodeSystem), podendo também estruturar um mapeamento entre
o sistema utilizado e outros semelhantes (ConceptMap). Por fim, todos os códigos
devem fazer parte de um sistema padronizado maior (NamingSystem), como o caso
do SNOMED CT (HEALTH LEVEL SEVEN INTERNATIONAL, 2021a).
Figura 18 – Principais estruturas do FHIR relacionadas às terminologias e seus relaci-

onamentos.
2.5.1.7 Trabalhos Relacionados
Tem-se observado que o sucesso do FHIR ultrapassou as expectativas, sendo

já obrigatório para uso em larga escala em muitos países, como os Estados Unidos e
o Reino Unido. Isso se dá em decorrência de um período de mudanças tumultuosas
e impulsionadas pelas tendências de ruptura digital e das mídias sociais. A informá-
tica em saúde se encontrou bem no meio desse processo, sendo a interseção entre
gerenciamento, negócios, conhecimento clínico, processos, tecnologias e gestão de

informação (BENSON; GRIEVE, 2021).
Existem centenas de trabalhos e publicações relacionadas ao padrão HL7 FHIR,
mostrando, por exemplo, ser um grande potencial para cobrir os requisitos básicos nos
casos de uso de coleta de sinais fisiológicos, como Eletrocardiograma (ECG), Eletro-
encefalograma (EEG), Eletromiograma (EMG) e Fotopletismografia (PPG), além dos
exames de imagem do tipo Digital Imaging and Communications in Medicine (DICOM)
(SAUERMANN et al., 2017). Essa característica demonstra o quanto o padrão possui
um relacionamento forte com outras organizações importantes, tais como o Integrating
the Healthcare Enterprise (IHE), o SNOMED International, o LOINC, o DICOM e o
SMART Health (BENSON; GRIEVE, 2021).
A World Health Organization (WHO) encoraja a utilização do padrão e apre-
senta diversos casos de uso de sucesso em seu Manual das Plataformas de Saúde
Digital, como o do sistema de saúde da Noruega, que está implantando uma interface
FHIR no armazenamento e requisição dos dados (WORLD HEALTH ORGANIZATION;
INTERNATIONAL TELECOMMUNICATION UNION, 2020). Além disso, o padrão foi
reconhecido por grandes organizações como a Google, a Amazon e a Microsoft, como
um grande padrão aberto para o desbloqueio do potencial dos dados de saúde e para
fornecimento de resultados a custos mais baixos, por meio de tecnologia cloud e In-
teligência Artificial (IA) (INFORMATION TECHNOLOGY INDUSTRY COUNCIL, 2018).
Com isso, são encontrados diversos tipos de serviços e soluções para armazenamento,
segurança e análise de dados clínicos, como a API Cloud Healthcare da Google e a
Azure Healthcare APIs da Microsoft (GOOGLE, 2021; MICROSOFT, 2021).
A HL7 ainda proporciona um programa para aceleradores do padrão, auxiliando
comunidades e grupos colaborativos no espectro de saúde a adotarem as guias de
implementação de alta qualidade do FHIR, além de outros artefatos do protocolo, auxi-
liando no avanço da realização da interoperabilidade na saúde global. Nesse programa
se encontram aceleradores bastante conhecidos pela comunidade, como o Argonaut
e o Da Vinci Project, responsáveis pela iniciativa da inserção do setor privado e da
indústria no padrão; o CodeX, na pesquisa e no atendimento de pessoas com câncer;
e o Vulcan, na maximização dos recursos coletivos da comunidade em pesquisa clínica.
Todos esses aceleradores são abertos para participação, porém há uma filiação paga
com valores que podem ser onerosos para pequenas instituições (HEALTH LEVEL
SEVEN INTERNATIONAL, 2021b).
Em plena pandemia do COVID-19, o Brasil, por exemplo, lançou uma Portaria
que dispõe da obrigatoriedade da notificação ao Ministério da Saúde de todos os
resultados referentes aos testes de diagnóstico e da realização das vacinações contra
o vírus. Esse registro e envio devem ser realizados na recém criada Rede Nacional
de Dados em Saúde (RNDS), com documentação de implementação disponibilizada
abertamente para os gestores e desenvolvedores dos estabelecimentos e utilizando

o padrão FHIR (BRASIL, 2020b). Essas notificações apoiam as bases de dados de
vigilância da pandemia e como provisão ao gestores, com informações pertinentes ao
enfrentamento dela. A RNDS, por fim, propõe novos serviços da Saúde 4.0, criando
maior foco em inovação, pesquisa e desenvolvimento baseados na interoperabilidade
dos dados em saúde, tendo como plano a implantação do FHIR em diversos fluxos e
serviços de saúde no país (BRASIL, 2020a).
Em conceitos de segurança, a HL7 não define nenhum tipo de funcionalidade,
já que o padrão FHIR não agrega padronização para proteção dos dados. Porém, eles
recomendam ferramentas e métodos de segurança bastante difundidos na internet, tais
como o Open Authorization (OAuth) e o OpenID Connect, para autenticação de clients
e usuários. Também são recomendadas as políticas de gerenciamento de dados, tais
como o Health Insurance Portability and Accountability Act (HIPAA), utilizado pelos
EUA, e o General Data Protection Regulation (GDPR), empregado na Europa. Além
disso, já existem trabalhos relacionados ao uso de blockchain no potencial de promover
o compartilhamento de dados de saúde com o FHIR, mantendo a segurança das
fontes de dados originais e facilitando o acesso seguro dos pacientes com seus dados
médicos (ZHANG et al., 2018).
Atualmente, existem diversos projetos facilitadores com documentação e ferra-
mentas de código aberto para análise de dados de pesquisa em saúde, tais como
o Observational Health Data Sciences and Informatics (OHDSI) e o Informatics for
Integrating Biology and the Bedside (i2b2) (COLUMBIA UNIVERSITY, 2021b; TRANS-
MART FOUNDATION, 2021). Contudo, a grande variedade de plataformas como essas,
oferecem consequentemente padrões variados e incompatíveis. Porém, com a pan-
demia do COVID-19, algumas colaborações foram anunciadas, como entre a HL7 e
o OHDSI, na integração de seus padrões FHIR e Observational Medical Outcomes
Partnership (OMOP), no compartilhamento e rastreamento de dados nos setores de
saúde e de pesquisa (COLUMBIA UNIVERSITY, 2021a).
Além do mais, é possível encontrar centenas de aplicações de código livre na
internet para desenvolvimento com FHIR, seja para criar servidores, validar Recursos,
desenvolver aplicativos, dentre outros. Destaca-se o clinFHIR, para criação de cenários
e várias ferramentas de modelagem (LYNIATE, 2021); o Simplifier.NET e o Trifolia-on-
FHIR, para criação e publicação de profiles e guias de implementação (FIRELY, 2021b;
LANTANA CONSULTING GROUP, 2021); o Crucible, para o teste e validação de servi-
dores FHIR (MITRE CORPORATION, 2021a); e o SMART on FHIR, responsável por
fornecer uma arquitetura de como os sistemas de prontuário médico e seus aplicativos
podem ser autenticados e integrados (BOSTON CHILDREN’S HOSPITAL; HEALTH
LEVEL SEVEN INTERNATIONAL, 2021).
Portanto, esse padrão possui extensa possibilidade de aplicação, seja mobile,
comunicação em cloud e entre servidores, com grande fundamentação em segurança

e velocidade. Sendo assim, o FHIR vem se mostrando como a ponte para superação
das deficiências técnicas dos padrões existentes, favorecido pelo crescente poder da
computação ubíqua e dos serviços web (SARIPALLE, 2019).
A seguir, são apresentados os principais trabalhos nos seguimentos de ma-
peamento de dados de outros padrões para o FHIR, guias de implementação para
utilização do padrão e as principais implementações de servidores disponibilizadas
pela comunidade.
2.5.1.7.1 Mapeamento de Dados
Devido à existência de diversos outros padrões e da emergência em utilizar os

benefícios do FHIR, o padrão fornece alguns meios de mapeamento. Porém, esses
mapeamentos são informativos e são providenciados apenas para auxiliar desenvolve-
dores na conversão dos dados, seja de outras versões do FHIR ou de outros padrões.
Uma linguagem de mapeamento ainda está sendo desenvolvida pela HL7, o que fa-
cilitará a conversão de padrões existentes sem demais conversores (HEALTH LEVEL
SEVEN INTERNATIONAL, 2021a).
Existem poucas implementações para mapeamento com suporte ao padrão
FHIR, sendo grande parte softwares pagos ou com pouco suporte. Porém, há uma
grande facilidade em utilizar bibliotecas de código-aberto, como as oferecidas pela
linguagem Python (PYTHON SOFTWARE FOUNDATION, 2021a).
Logo, há uma ampla variedade de implementações de padrões em saúde e
nenhum dos mapeamentos é considerado oficial ou normativo pela HL7. Assim, os
desenvolvedores do padrão FHIR devem sempre verificar o uso de mapeadores na
produção ou conversão de dados (HEALTH LEVEL SEVEN INTERNATIONAL, 2021a).
2.5.1.7.2 Guias de Implementação
Um Guia de Implementação, ou mais conhecido como Implementation Guide

(IG), é um documento que detalha os casos de uso e requisitos que devem ser supor-
tados por sistemas quando esses adotam certos padrões (OEMIG; SNELICK, 2016).
Na documentação do FHIR, um IG é um conjunto de regras de como um problema de
interoperabilidade específico é resolvido, geralmente pelo uso de Resources (HEALTH
LEVEL SEVEN INTERNATIONAL, 2021a).
A documentação disponibiliza um Recurso específico para esse contexto, o
ImplementationGuide, que é responsável por reunir todas as partes de um IG e publicá-
lo como um documento computável e lógico. Esse Resource possui o conjunto de
regras de como os demais Recursos devem ou não ser utilizados para solucionar casos,
baseado em uma documentação que apoie e esclareça o uso. Essa implementação
pode ser publicada na internet utilizando um gerador de IG, disponibilizando páginas

de documentação e um pacote lógico com todo o conteúdo computável do guia, como
apresentado na Figura 19. Esses pacotes são importantes para uso em validadores,
já que incluem os Profiles do IG utilizado e os demais artefatos de terminologia e
operações capacitadas. Além disso, é possível desenvolver aplicações que estejam
em conformidade com vários IGs, desde que eles sejam compatíveis (HEALTH LEVEL
SEVEN INTERNATIONAL, 2021a).
Figura 19 – Estrutura do relacionamento dos Recursos de conformidade de um Imple-

mentationGuide.
Países como os Estados Unidos já aderiram ao FHIR em serviços de saúde e

possuem seus Profiles e Extensions publicados na sua página de IG (US REALM STE-
ERING COMMITTEE, 2020). O Brasil também está agregando o padrão na sua nova
plataforma de saúde digital, a RNDS, que propõe novos serviços, inovação, pesquisa
e desenvolvimento, baseados na interoperabilidade dos dados em saúde (BRASIL,
2020a).
O International Patient Summary (IPS) é um exemplo de IG publicado na internet
com o objetivo de padronizar a troca de informações de pacientes em um registro
eletrônico de saúde composto por informações essenciais, planejadas para suportar
um cenário de atendimento não planejado e além de uma única fronteira. Logo, essa
guia destina-se a ser internacional e a providenciar soluções genéricas para aplicações
globais, além de uma determinada região ou país. Assim, o IPS é um conjunto mínimo,
não exaustivo, agnóstico de especialidade e independente de condições, mas ainda

clinicamente relevante (KAY et al., 2020). Como observado na Figura 20, a página do IG
do IPS é composta por um conjunto de itens robustos, bem definidos e potencialmente
reutilizáveis além do escopo de cuidado não planejado.
Figura 20 – Guia de Implementação do International Patient Summary (IPS).
Fonte – Patient Care Work Group (2020)
Além dessas funcionalidades, os IGs ainda oferecem os pacotes com as Struc-

tureDefinitions, ValueSets, ConceptMaps, CodeSystems e demais recursos. Com a
devida implementação, os pacotes podem ser integrados e utilizados para validação
de Resources que são enviados para servidores (PATIENT CARE WORK GROUP,
2020).
A HL7 também fornece IG para a harmonização de modelos de dados utiliza-
dos em diferentes plataformas, mapeando eles para o FHIR. O Common Data Models
Harmonization IG é um grande exemplo na harmonização de modelos de dados bas-
tante utilizados em pesquisas, como o Patient Centered Outcome Research Network
(PCORNet), o OMOP e o i2b2 (HEALTH LEVEL SEVEN INTERNATIONAL, 2019).
2.5.1.7.3 Servidores
Para a implementação do servidor FHIR proposto, foi realizado um levantamento

das principais implementações existentes, levando em consideração as características
necessárias para a proposta deste trabalho: licença para uso e modificação, versões do
FHIR suportadas, integração com banco de dados, segurança e suporte à validação por
Profiles. O Quadro 9 reúne as principais implementações disponíveis e suas diferenças.
Quadro 9 – Comparação de Implementações de Servidores HL7 FHIR.

Característica HAPI FHIR Firely IBM Azure Spark
Autores Smile CDR Firely IBM Microsoft Firely
Open-source Sim Não Sim Sim Sim
Versões do DSTU2,
STU3, R4 e
FHIR suporta- STU3, R4 e R4 STU3 e R4 STU3 e R4
R5
das R5
Suportados
pelo Hiber-
Banco de SQL Server, Azure SQL
nate (e.g., Apache Derby,
dados suporta- SQLite, e Azure MongoDB
PostgreSQL, IBM Db2,
dos MongoDB, Cosmos DB
MySQL, Ora- PostgreSQL
cle) Cosmos DB
Closed-
Licença Apache 2.0 Apache 2.0 MIT License MIT License
source
Linguagem Java - Java C# C#
OAuth 2.0 e Role-based
Segurança - OpenID Con- - access con- -
nect trol (RBAC)
Encoding JSON e XML JSON e XML JSON e XML JSON e XML JSON e XML
Suporte a Pro-
Sim Sim Sim Não Sim
files
Baseado nas características buscadas, o HL7 Application Programming Inter-

face (HAPI) tem se mostrado a implementação ideal para a proposta desde trabalho.
O HAPI é uma biblioteca escrita em Java e de código aberto, desenvolvida em 2014
pela University Health Network (UHN). Sua primeira implementação foi elaborada
para trabalhar com o padrão HL7 V2, mas com o lançamento da versão FHIR, come-
çou a se focar inteiramente nela. A biblioteca HAPI oferece dezenas de aplicações
e todas sustentadas por uma comunidade ativa, extensa documentação e diversos
exemplos. Atualmente a biblioteca é mantida pela empresa Smile CDR, mantendo seu
código aberto e suporte da extensa comunidade de desenvolvedores (SMILE CDR,
2021). Além disso, essa implementação é recomendada por grandes casos de uso da
WHO (WORLD HEALTH ORGANIZATION; INTERNATIONAL TELECOMMUNICATION
UNION, 2020).
Dos diversos benefícios em seu framework, os principais destaques do HAPI
são (BENSON; GRIEVE, 2021):
• Inclui o validador FHIR oficial e ferramentas que suportam as terminologias;

• Possui os objetos modelos, analisadores e geradores de mensagens;
• Alta performance e flexibilidade, com suporte para novos interceptadores;
• Pode ser usado desde a aplicações móveis até serviços na nuvem.
2.6 PESQUISA NA SAÚDE
A saúde é um domínio complexo e com conhecimento em constante evolução.

A comunidade da informática sofre diversos desafios em projetar e criar tecnologias de
saúde que apoiam e impulsionam a inovação. Porém, o ambiente acadêmico oferece
um espaço para profissionais de saúde refletirem as abordagens de criação e as pers-
pectivas críticas dos cuidados em saúde, influenciando os resultados dos pacientes
com o uso de tecnologias emergentes (HUSSEY; MCGLINN, 2019).
Organizações e colaborações que trabalham na integração e análise de grandes
bancos de dados de pesquisa, como o programa OHDSI e o i2b2, são grandes exem-
plos de plataformas que já comportam e incentivam a utilização do FHIR em pesquisa
e inovação (PFAFF et al., 2019).
Vale ressaltar que pesquisas clínicas precisam seguir protocolos rígidos de co-
leta, armazenamento e compartilhamento de dados. A própria WHO oferece a Interna-
tional Clinical Trials Registry Platform (ICTRP), composta pelos protocolos necessários
para essa realização (WORLD HEALTH ORGANIZATION, 2021). O Brasil é um dos
fornecedores de dados que seguem essa premissa, utilizando o Registro Brasileiro
de Ensaios Clínicos (ReBEC), uma plataforma que divulga os estudos de maneira
pública, reduzindo o viés das publicações e propiciando maior interação e inserção
internacional (FUNDAÇÃO OSWALDO CRUZ, 2021).
Um outro exemplo em destaque é a plataforma OpenDATASUS, desenvolvida
pelo Departamento de Informática do Sistema Único de Saúde do Brasil (DATASUS).
Essa plataforma disponibiliza informações que podem subsidiar análises de situações
sanitárias, tomadas de decisões baseadas em evidências e elaboração de programas
de ações em saúde. Os dados podem ser adquiridos em diversos formatos, como o
Comma-Separated Values (CSV) e o Microsoft Excel Open XML Format Spreadsheet
(XLSX)), e com uma grande fundação em dados sobre o COVID-19 (DEPARTAMENTO
DE INFORMÁTICA DO SUS, 2021a). Como comentado anteriormente, esses formatos
podem ser facilmente mapeados para o FHIR.
Por fim, é necessário evidenciar a importância dessas aplicações serem de-
senvolvidas em paralelo com a Lei Geral de Proteção de Dados Pessoais (LGPD) do
Brasil, protagonizando a segurança e a privacidade das informações dos usuários e
participantes de qualquer pesquisa (BRASIL, 2018).
Este trabalho tem o propósito de demonstrar a importância da interoperabili-

dade, no contexto computacional, entre os dados de pesquisas clínicas acadêmicas
e de outros domínios. Para estudos de caso e validação da proposta, serão utiliza-
das pesquisas reais relacionadas ao diabetes mellitus e à tecnovigilância de produtos
médico-hospitalares. Logo, a abrangência do trabalho busca resultados que abordem
vários contextos da saúde.
2.6.1 Diabetes Mellitus
O Diabetes Mellitus (DM) é um grupo de doenças metabólicas resultantes de

deficiências na secreção de insulina, na sensibilidade ou ação dela, ou até mesmo
ambas, causando a hiperglicemia no sangue (MARTINEZ et al., 2019). A insulina, por
sua vez, é um hormônio importante no controle da glicose no sangue, o que garante
fonte energética ao organismo (AMERICAN DIABETES ASSOCIATION, 2006).
De acordo com a International Diabetes Federation (2019), aproximadamente
463 milhões de adultos (20-79 anos) estavam vivendo com diabetes em 2019, sendo
79% em países de média e baixa renda. Além disso, o estudo mostra que a expectativa
é que esse valor aumente para cerca de 700 milhões até 2045.
O DM ainda pode ser classificado em 4 categorias: Diabetes Tipo 1 (DM1), Di-
abetes Tipo 2 (DM2), Diabetes Gestacional e de fatores diversos (MARTINEZ et al.,
2019). O DM1 ocorre em maior número em crianças e adolescentes e é decorrente da
destruição de células nas ilhotas pancreáticas de Langerhans, causando a perda de
produção da insulina (KATSAROU et al., 2017). Já o DM2 ocorre em virtude da diminui-
ção de secreção da insulina, causado pela deficiência nas ilhotas que são associadas
ao aumento da resistência insulínica, causando a diminuição da captação periférica de
glicose ou no aumento de sua produção pelo fígado (WU, H. et al., 2018). A gestacional
pode ou não ser transitória, devido à gravidez, e as demais são consideradas raras
e causadas por falhas genéticas, doenças pancreáticas e endócrinas, ou até mesmo
pelo uso de certos medicamentos (SANZANA; DURRUTY, 2016).
Em longo prazo, o DM pode causar retinopatia, nefropatia, neuropatia e várias
outras complicações, como maior risco de desenvolver doenças cardiovasculares, arte-
riais, cerebrovasculares periférica, além de obesidade, catarata e tuberculose (WORLD
HEALTH ORGANIZATION, 2019). Logo, a doença provoca grande impacto no estado
de saúde do portador, causado pelos transtornos e complicações que interferem na
qualidade de vida do paciente (CARREIRA et al., 2010).
Existem fortes evidências de que as complicações microvasculares são reduzi-
das quando os pacientes com DM são tratados desde cedo. Essas complicações são
conhecidas por causar alta morbidade, perda de visão e função renal, mobilidade pre-
judicada, dificuldade de cognição e incapacidade de realizar tarefas cotidianas. Logo,
há um grande aumento nos custos para manutenção da qualidade de vida desses
indivíduos (VALENCIA; FLOREZ, 2017).

O DM já custou cerca de 760 bilhões de dólares em gastos na saúde, corres-
pondendo a 10% dos gastos totais com adultos. Com isso, o DM é uma das doenças
crônicas mais dispendiosas nos sistemas de saúde. Boa parte desses gastos pode-
riam ser evitados com a identificação precoce da doença e de suas complicações,
implicando em tratamentos eficientes, influenciando na qualidade de vida do paciente
e economizando nos sistema de saúde. No entanto, exames do tipo são geralmente
realizados após a manifestação de sintomas, quando a doença já está em estágios
mais avançados (INTERNATIONAL DIABETES FEDERATION, 2019).
2.6.1.1 Screening for Diabetes Complications
Tem sido desenvolvido, no IEB-UFSC, um sistema de saúde ubíqua intitulado

Screening for Diabetes Complications (SDC-X). Esse sistema tem o objetivo de auxiliar
no diagnóstico e acompanhamento das complicações relacionadas ao DM. O sistema
é capaz de utilizar redes sem fio para a comunicação entre diversos equipamentos
de coleta de dados fisiológicos, realizar diferentes análises com os dados coletados,
armazenar as informações e distribuí-las.
O SDC-X é composto por Módulos de Aquisição, Módulos Concentradores, Mó-
dulo de Armazenamento e Módulo de Análise, como apresentado na Figura 21. Os
Módulos de Aquisição são compostos pelos hardwares responsáveis pela coleta de
dados (e.g., sinais fisiológicos, questionários) e o Módulo Concentrador é responsável
pelos softwares das aquisições de dados, ambos distribuídos em centros organizaci-
onais para coleta populacional. Já o Módulo de Armazenamento é responsável pelo
banco de dados e o Módulo de Análise pela visualização e manuseio dessas informa-
ções.
Os Módulos de Aquisição e Concentradores são blocos desenvolvidos por equi-
pes decentralizadas, além de equipamentos e metodologias distintos, mas todos com
a mesma finalidade de adquirir e acompanhar dados que auxiliem no diagnóstico e
pesquisa do DM e de suas complicações. Alguns dos módulos existentes do SDC-X
são apresentados na Figura 22. A Figura 22(a) e (c) apresentam o módulo responsável
pela coleta de PPG e ECG e o software responsável pela análise e visualização da
Variabilidade de Frequência Cardíaca (VFC) baseada nesses dados. Já a Figura 22(b)
e (d) apresentam o módulo de aquisição de imagens de pupila e a aplicação para
análise e visualização da variação do raio da pupila.
O sistema possui uma arquitetura modular que facilita a adição de novos mó-
dulos de aquisição. Porém, foram identificadas deficiências quanto à padronização da
estrutura e da semântica dos dados coletados, já que cada módulo é desenvolvido sem
seguir um padrão de interoperabilidade. Logo, há uma dificuldade em utilizar esses
dados dentro do próprio sistema, para reutilização de amostras e melhores análises
Figura 21 – Diagrama dos Módulos do sistema Screening for Diabetes Complications

(SDC-X).
de evidências. Essa problemática da padronização dos dados do projeto SDC-X é um

dos estudos de caso deste trabalho.
2.6.2 Tecnovigilância
De acordo com a Agência Nacional de Vigilância Sanitária (ANVISA), tecnovigi-

lância é um sistema de vigilância de eventos adversos e queixas técnicas de produtos
relacionados à saúde após serem comercializados, com intuito de recomendar a ado-
ção de metodologias que promovem a proteção e a saúde da população. Esses pro-
dutos para a saúde englobam equipamentos, materiais, artigos médico-hospitalares,
implantes e produtos para diagnóstico de uso in-vitro (AGÊNCIA NACIONAL DE VIGI-
LÂNCIA SANITÁRIA, 2021).
Existe uma grande relação entre a complexidade tecnológica de dispositivos
Figura 22 – Exemplos de módulos existentes do SDC-X: módulo de aquisição de PPG

e ECG (a), módulo de aquisição de imagens da pupila (b), software de
análise e visualização da variabilidade de frequência cardíaca (X-CARDIO)
(c) e software de análise e visualização da variação do raio da pupila (X-
EYE) (d).
Fonte – Adaptado de Terra (2020) e Ucker (2020).
e a incidência de eventos adversos. O único meio seguro de reduzir esses eventos

está no exercício adequado da engenharia clínica nos centros de saúde. Além disso, é
essencial criar agências responsáveis pelas verificações instrumentais dos parâmetros
e requisitos técnicos desses produtos, sempre harmonizando com os padrões interna-
cionais e protocolos de certificação de especificação. Logo, a engenharia clínica é de
fundamental importância não só para a operação e manutenção dos equipamentos,
mas também na avaliação correta dos mesmos (AVENDAÑO et al., 2017).
2.6.2.1 Notificações em Tecnovigilância
A ANVISA é o órgão brasileiro responsável pela proteção da saúde pública

por meio do controle sanitário da produção e do consumo de produtos e serviços
submetidos à vigilância, sendo os insumos e tecnologias de saúde uma das verten-
tes. Na perspectiva da tecnovigilância, a ANVISA oferece uma plataforma (Figura 23)
para consultar dados públicos de notificações de eventos adversos e queixas técnicas
de produtos relacionados à saúde recebidos desde 2007 (AGÊNCIA NACIONAL DE

VIGILÂNCIA SANITÁRIA, 2021). Esse banco de dados pode auxiliar estudos que ob-
jetivam desenvolver materiais de boas práticas, elaborar procedimentos técnicos para
avaliação de desempenho e estruturar recomendações para fabricantes e usuários,
auxiliando na prevenção desses eventos (BRANDÃO et al., 2021).
Figura 23 – Plataforma de notificação em tecnovigilância da ANVISA.
Fonte – Agência Nacional de Vigilância Sanitária (2021).
O IEB-UFSC também realiza pesquisas nesse âmbito, fortalecendo a importân-

cia do ambiente acadêmico na engenharia clínica. Com isso, os dados de notificações
de tecnovigilância da ANVISA serão utilizados também como estudo de caso, ampli-
ando as possibilidades que o padrão FHIR pode oferecer, não se limitando apenas ao
contexto de atendimento e cuidados ao paciente.
2.7 FRAMEWORK NASSS
De acordo com Greenhalgh et al. (2020), as tecnologias são normalmente vistas

como novos caminhos para melhores atendimentos à saúde, além de maior segurança
e eficiência. Porém, projetos nesse âmbito raramente oferecem todos os benefícios
esperados, o que geralmente ocorre pela complexidade e pelo modo como ela é tratada,
tornando-se em futuros fracassos.
Basicamente, um sistema é definido por um conjunto de agentes que interagem

entre si. Os sistemas simples são caracterizados por poucos agentes e componentes,
enquanto que os complicados possuem muitos agentes e componentes, mas ambos
com relacionamentos estáveis e bem definidos, o que demonstra que os sistemas pos-
suem comportamentos geralmente previsíveis. Já os sistemas complexos e adaptativos
possuem elementos com limites mal-definidos e instáveis. Esses problemas podem
agir de maneiras inesperadas, onde a ação de um agente pode mudar o contexto de
outros (PLSEK; GREENHALGH, 2001).
Com essa problemática, foi desenvolvido um framework interdisciplinar e mul-
tinível conhecido como Nonadoption, Abandonment, and challenges to the Scale-up,
Spread, and Sustainability (NASSS). Esse framework foi criado para encorajar o pen-
samento complexo sobre as inovações tecnológicas no contexto da saúde. O objetivo
desse pensamento é gerar uma rica narrativa de eventos que se desenrolam no mundo
real, orientando debates reflexivos e auxiliando a gerar ideias, diferente de um chec-
klist.
Com essa arquitetura é possível realizar estudos de caso, levantando a varie-
dade de desafios das camadas de complexidade dos sistemas propostos. São conside-
rados 7 domínios principais e interligados, como abordado na Figura 24. Com isso, um
sistema pode ser definido como a junção da complexidade de condições de saúde, tec-
nologias agregadas, valor de demanda, o público adotante, as organizações envolvidas,
o sistema visto de forma ampla e a sua evolução ao longo do tempo (GREENHALGH
et al., 2017). A definição de cada domínio é apresentada no Quadro 10.
Cada um dos domínios pode ser considerado simples (i.e., direto, previsível e
com poucos componentes), complicado (i.e., ainda previsível mas com vários compo-
nentes ou problemas de interação) ou complexo (i.e., dinâmico, imprevisível e com
muitos elementos de interação). Os fenômenos simples e complicados operam de
acordo com uma lógica linear preditiva e podem ser analisados em termo dos seus
componentes, enquanto os fenômenos complexos operam com lógicas não-lineares,
onde determinadas ações nem sempre causam os mesmos efeitos (GREENHALGH,
2018; PLSEK; GREENHALGH, 2001). Os sistemas caracterizados como complica-
dos mostram-se difíceis de implementar, mas não impossíveis. Já aqueles que são
caracterizados por vários domínios complexos, raramente, ou nunca, são integrados
(GREENHALGH et al., 2017).
Essa arquitetura já foi utilizada e validada por diversos estudos de caso, tais
como a utilização de consultoria por vídeo durante o período da pandemia do COVID-
19, tecnologias para o atendimento de pessoas com esquizofrenia, para apoiar diretivas
sobre medicamentos falsificados, para suporte digital em reuniões de equipes multi-
disciplinares relacionadas ao câncer e na digitalização de serviços de histopatologia
(JAMES et al., 2021; GREENHALGH et al., 2020).
Figura 24 – Framework NASSS para a análise da não adoção, abandono e desafios

de disseminação, expansão e sustentabilidade de tecnologias na saúde.
Fonte – Adaptado de James et al. (2021).
Essa estrutura demonstra o quanto projetos de tecnologia em saúde e de assis-

tência social falham, principalmente pela ocorrência de vários tipos de complexidade
em vários domínios. Logo, desenvolvedores precisam lidar com a complexidade e in-
terromper a simplificação excessiva dos desafios e a desconsideração das incertezas
e interdependências entre eles (GREENHALGH, 2018). Com isso, essa infraestrutura
será utilizada para a validação da continuação do sistema proposto por este trabalho,
analisando não apenas suas funcionalidades, mas também sua aceitação pelo público
alvo.
Quadro 10 – Domínios de complexidade do framework NASSS.

Domínio Descrição
Engloba os aspectos clínicos e socioculturais de condições de
saúde e as comorbidades associadas, reconhecendo que nem
1. Condição
todos os indivíduos com uma determinada condição irão se be-
neficiar igualmente com a tecnologia proposta
Abrange os materiais, dados, conhecimentos e recursos tecno-
lógicos utilizados. Esse domínio não se concentra apenas nas
2. Tecnologia tecnologias físicas e nas metodologias de como utilizá-las, mas
também em como elas moldam o potencial de aumento de escala
e disseminação
Preocupa em analisar se a tecnologia vale a pena ser desenvol-
vida e introduzida aos médicos, pacientes e fornecedores. Esse
3. Proposição de Valor domínio pode influenciar o abastecimento, aceitação e conveniên-
cia na demanda da tecnologia, impactando o aumento da escala
e de disseminação
Considera os funcionários, pacientes e cuidadores e os seus
4. Adotantes
potenciais desejos de adotar e continuar utilizando as tecnologias
Considera a capacidade de uma organização em inovação, fi-
nanciamentos, prontidão para mudanças nas rotinas e na imple-
mentação das mudanças em relação a adoção das tecnologias.
5. Organizações Envolvidas Esses elementos possuem grande papel na extensão, dissemi-
nação e sustentabilidade, determinando como uma organização
responderá aos desafios emergentes e como a inovação evoluirá
paralela com as estruturas e processos organizacionais
Considera os aspectos políticos, regulatórios, profissionais e so-
6. Sistema Amplo
cioculturais da implementação das tecnologias
Concentra-se no escopo de adaptação e resiliência de uma orga-
7. Incorporação e Adaptação ao
nização perante a implementação e potencial de disseminação e
Longo do Tempo
aumento de escala
Fonte – Adaptado de Greenhalgh et al. (2017).
65
3 MATERIAIS E MÉTODOS
Neste capítulo são apresentados o desenvolvimento dos módulos do servidor

proposto, a sua interface RESTful API, as abordagens de segurança utilizadas, a
metodologia para o mapeamento de dados de pesquisa para o padrão FHIR e os
aspectos éticos da pesquisa.
3.1 SERVIDOR HL7 FHIR
Como apresentado anteriormente, uma possível implementação disponível para

a criação de servidor com padrão HL7 FHIR é o HAPI FHIR. Partindo disso, o sistema
aqui proposto foi desenvolvido utilizando os conceitos de código aberto da biblioteca
mencionada e da sua extensibilidade de deploy, em conexão com banco de dados e
adição de métodos de segurança.
3.1.1 Servidor HAPI JPA
O servidor proposto neste trabalho foi desenvolvido a partir das bibliotecas

do Java Persistence API (JPA) do HAPI FHIR. Como apresentado na Figura 25, os
principais componentes da implementação são (SMILE CDR, 2021):
a) Servidor RESTful: um provedor RESTful é fornecido para cada tipo de Re-
source, implementando todos os parâmetros de pesquisa do Recurso, que
são definidos na especificação oficial. São eles que também implementam
os métodos Create, Read, Update e Delete. Esses provedores recebem as
chamadas HTTP e repassam as solicitações para os DAOs;
b) HAPI DAOs: os Data Access Objects (DAO) são as lógicas de tráfego do
banco de dados, implementadas para o armazenamento, indexação e requi-
sição dos Recursos FHIR usando a API JPA;
c) Provedor Hibernate JPA: biblioteca JPA implementada pela Hibernate para
o mapeamento objeto-relacional na linguagem Java;
d) Banco de Dados: banco de dados suportado pela Hibernate (e.g., MySQL,
PostgreSQL).
3.1.2 Deploy
O deploy é uma fase final de implantação de uma aplicação, onde é oferecido

o produto final para uso. Para este trabalho, foram implantados versões de teste em
máquina local e em serviços na nuvem, ambos utilizando imagem Docker.
Capítulo 3. Materiais e Métodos 66
Figura 25 – Diagrama de blocos dos principais componentes do servidor HAPI JPA.
Fonte – Adaptado de Smile CDR (2021).
A máquina local, utilizada para os testes, foi um computador Apple MacBook

Pro, com processador 2,7 GHz Intel i5 Dual-Core, memória RAM de 8 GB (1867 MHz
DDR3) e sistema operacional macOS Big Sur versão 11.6.
Foram realizados testes de deploy com a tecnologia de container. Os contai-
ners são unidades de software que empacotam código e todas as suas dependências
para que uma aplicação seja executada de um ambiente de computação para outro,
de forma rápida e confiável. Essas estruturas podem ser desenvolvidas, distribuídas
e executadas por meio de imagens, utilizando o serviço Docker. Essas imagens são
pacotes leves, autônomos e executáveis que incluem toda a estrutura necessária para
o funcionamento da aplicação: código, tempo de execução, ferramentas do sistema,
bibliotecas e configurações (DOCKER, 2021; RAD et al., 2017). Além disso, os custos
podem ser reduzidos na substituição de máquinas virtuais por containers Docker, por
serem mais rápidos, menos sobrecarregados e independentes de sistemas operacio-
nais (RAD et al., 2017).
Para a implantação da imagem Docker na nuvem, foram utilizados as Platform-
as-a-Service (PaaS) da Heroku e do Google Cloud Platform. Essas PaaS oferecem
sistemas operacionais gerenciados, servidores de aplicações e middleware para exe-
cução de aplicativos na web de forma escalonável, livres de aspectos operacionais,
como dimensionamento, atualização de sistema e configurações de rede (GESSERT
et al., 2020).
3.1.3 Banco de Dados
Das diversas possibilidades de banco de dados suportados pela Hibernate,

optou-se pelo PostgreSQL, para armazenamento dos recursos, histórico, indexações,
tags e demais dados. Esse sistema gerenciador de bases de dados relacionais é um
projeto de código aberto, com forte reputação em confiabilidade, robustez de recursos,
desempenho, extensibilidade, segurança, internacionalização e variedade de tipos de
dados (POSTGRESQL GLOBAL DEVELOPMENT GROUP, 2021).
3.1.3.1 Arquitetura do Banco de Dados
O servidor HAPI JPA possui um esquema de banco de dados esquematizado

na Figura 26. A HFJ_RESOURCE é a tabela mestre de Resources, onde cada linha
representa todas as versões de um único Recurso. A tabela HFJ_RES_VER armazena
todas as versões dos Resources, seus respectivos conteúdos e métodos de codifica-
ção. Já a tabela HFJ_FORCED_ID é utilizada para armazenar os IDs de Recursos
atribuídos pelo cliente e não pelo servidor (SMILE CDR, 2021).
Figura 26 – Esquema da tabela mestre dos Resources armazenados no banco de

dados PostgreSQL pelo servidor HAPI JPA.
Todos os Recursos criados no banco de dados são indexados para pesquisa,

mesmo quando atualizados ou com referências uns aos outros. Para isso, é disponibili-
zada a tabela HFJ_RES_LINK para as devidas referências (Figura 27).
As indexações para pesquisa são distribuídas em tabelas do tipo HFJ_SPIDX,
representadas no Anexo A. Existem tabelas dedicadas para datas, números, quantida-
des, strings, tokens e Uniform Resource Identifier (URI)s.
Figura 27 – Esquema da tabela de referências de Resources no banco de dados Post-

greSQL pelo servidor HAPI JPA.
3.1.4 Interface RESTful API
Com o servidor implementado, sua interface trabalhará basicamente com um

padrão de transações de requisição e resposta. Essas podem ser de uma única carga
útil (single payload) ou como um lote (batch). Cada requisição e resposta possui um
cabeçalho (header ) e o conteúdo da mensagem com o(s) Recurso(s) interessado(s)
dentro de um Bundle, um contêiner para coleção de Resources. Quando alguma ope-
ração RESTful falha, o servidor retorna como resposta um OperationOutcome, com
detalhes do erro e possíveis correções. O esquema REST aceito pelo servidor pode ser
observado na Figura 28, onde são detalhados os corpos e cabeçalhos de requisições
e respostas.
O servidor fornece assim uma interface com serviços RESTful, aceitando ope-
rações HTTP, tais como GET, POST, PUT, DELETE, para a leitura (read), criação
(create), atualização (update), remoção (delete), pesquisa (search), dentre diversas
outras operações com Recursos, como apresentado na Quadro 11. O acesso sempre
se dá pelo uso do endpoint definido para o servidor e o caminho específico dado pela
operação. Já como retorno das interações HTTP realizadas, o servidor é capaz de
retornar as respostas descritas pelo Quadro 12.
Os cabeçalhos (headers) que podem ser utilizados são os seguintes (NIELSEN
et al., 1999):
• Content-Type: indica o tipo de arquivo do corpo da mensagem enviada;
• ETag: fornece o valor atual da tag da entidade para a variante requisitada;
• If-Match: o servidor irá retornar o recurso requisitado somente se ele corres-
ponder a uma das ETags solicitadas;
• If-Modified-Since: é usado com um método condicional, sendo que se a
Figura 28 – Diagrama de transações HTTP (requisição e resposta) do servidor.
Fonte – Adaptado de Health Level Seven International (2021c).
variante solicitada não estiver modificada desde o tempo especificado neste

campo, uma entidade não será retornada do servidor; em vez disso, uma
resposta de "not modified" será retornada sem qualquer corpo de mensa-
gem;
• If-None-Match: o servidor irá retornar o recurso requisitado somente se ele
não tiver um ETag correspondendo as tags dadas pela solicitação;
• Last-Modified: indica a data e horário em que a variante foi modificada pela
última vez;
• Location: indica para qual URL o destinatário deve ser redirecionado.
Os códigos de status das respostas esperadas são os definidos pelo protocolo
HTTP (NIELSEN et al., 1999):
• 200 (OK ): a requisição foi bem sucedida;
• 201 (Created): a requisição foi atendida e resultou na criação de um novo
recurso;
Quadro 11 – Interações de requisição na interface RESTful API do servidor.

Interação Caminho HTTP Content-type Body Conditional
Opcional:
read /[type]/[id] GET - - ETag,
If-Modified-Since,
If-None-Match
vread /[type]/[id]/_history/[vid] GET - - -
update /[type]/[id] PUT Obrigatório Resource O: If-Match
Obrigatório
patch /[type]/[id] PATCH (pode ser do Patch O: If-Match
tipo patch)
delete /[type]/[id] DELETE - - -
create /[type] POST Obrigatório Resource O: If-None-Exist
/[type]? GET - - -
search
application/x-
/[type]/_search? POST www-form- form data -
urlencoded
search-all ? GET - - -
capabilities /metadata GET - - -
transaction / POST Obrigatório Bundle -
history /[type]/[id]/_history GET - - -
history-
/[type]/_history GET - - -
type
history-all /_history GET - - -
/$[name] POST Obrigatório Parameters -
(operação) /[type]/$[name] GET - - -
/[type]/[id]/$[name] application/x-
POST www-form- form data -
urlencoded
• 202 (Accepted): a requisição foi aceita para processamento, mas o mesmo

ainda não foi concluído;
• 204 (No Content): não há conteúdo para enviar nessa requisição, porém os
cabeçalhos podem ser úteis;
• 400 (Bad Request): a requisição não pôde ser compreendida pelo servidor
devido à uma sintaxe incorreta;
• 401 (Unauthorized): a requisição necessita de autenticação de usuário;
• 404 (Not Found): o servidor não encontrou o recurso requisitado;
• 405 (Method Not Allowed): o método especificado na requisição não está
permitido para o recurso solicitado;
• 409 (Conflict): a requisição não pôde ser concluída devido à um conflito
com o atual estado do recurso;
• 412 (Precondition Failed): a pré-condição fornecida no cabeçalho da requi-
sição não é atendida pelo servidor;
Quadro 12 – Respostas das interações de requisição na interface RESTful API do

servidor.
Interação Content-type Body Controle de Versão Códigos de Status
Obrigatório: ETag,
read Obrigatório Obrigatório: Resource 200, 404, 410
Last-Modified
Obrigatório: ETag,
vread Obrigatório Obrigatório: Resource 200, 404
Last-Modified
Obrigatório
Obrigatório: ETag, 200, 201, 400, 404,
update (se houver Opcional: Resource
Last-Modified 405, 409, 412, 422
body)
Obrigatório
patch (se houver Opcional: Resource
Last-Modified 405, 409, 412, 422
body)
Obrigatório
Opcional: Operatio- 200, 202, 204, 404,
delete (se houver -
nOutcome 405, 409, 412
body)
Obrigatório
create (se houver Opcional: Resource
Last-Modified 422
body)
search Obrigatório Obrigatório: Bundle - 200, 401
search-all Obrigatório Obrigatório: Bundle - 200, 401
Obrigatório: Capabi-
capabilities Obrigatório - 200, 404
lityStatement
200, 400, 404, 405,
transaction Obrigatório Obrigatório: Bundle -
409, 412, 422
history Obrigatório Obrigatório: Bundle - 200
history-
Obrigatório Obrigatório: Bundle - 200
type
history-all Obrigatório Obrigatório: Bundle - 200
Obrigatório: Parâme-
(operação) Obrigatório - 200
tros/Resource
• 422 (Unprocessable Entity): a requisição está bem formada mas inabilitada

a ser processada devido a erros semânticos.
O diagrama das interceptações realizadas durante uma requisição HTTP é
apresento na Figura 29. Basicamente, o servidor JPA analisa se a requisição é do
tipo read ou write, buscando, atualizando ou criando uma nova entidade no banco de
dados, quando necessário, e confirmando essa ação.
Vale ressaltar que toda a interface REST do servidor segue as especificações
do OpenAPI Specification (OAS), um padrão que define interfaces RESTful APIs que
permitem humanos e máquinas descobrirem e entenderem as capacidades dos servi-
ços sem o acesso ao código-fonte, documentação ou por meio de inspeção do tráfego
de rede do mesmo, indiferente das linguagens utilizadas. Com isso, os consumidores
podem interagir com os serviços remotos com o mínimo de implementações (SMART-
BEAR SOFTWARE, 2021).
Figura 29 – Diagrama de interceptações realizadas após uma requisição HTTP ao

servidor.
3.1.5 Interface Web
A implementação HAPI JPA ainda oferece uma interface web personalizável,

podendo ser acessada em navegador, para melhor compreensão e visualização dos
dados e operações suportadas pelo servidor.
Como a implementação segue as especificações do OAS, foi possível disponibi-
lizar a API do servidor implementando também as ferramentas Swagger, que facilitam
o consumo dos recursos da implementação de forma neutra, portátil e aberta (SMART-
BEAR SOFTWARE, 2021).
3.1.6 Segurança
De acordo com a LGPD (Lei Nº 13.709/2018), todo dado referente à saúde

vinculado a uma pessoa deve ser considerado um dado pessoal sensível. Mais além,
a utilização desses dados na realização de estudos em saúde pública devem ser
tratados exclusivamente dentro do órgão e apenas para a finalidade de pesquisa e
estudo, mantidos em ecossistema controlado e seguro, incluindo sempre que possível
a anonimização ou pseudonimização desses dados (BRASIL, 2018).
Baseado na premissa da LGPD, foi utilizada a ferramenta Tools for Health Data
Anonymization para a anonimização dos dados tratados, antes mesmo de serem envia-
dos ao servidor e armazenados no banco de dados. Essa ferramenta de código aberto
oferece métodos de anonimato para diferentes elementos de dados dos Recursos
FHIR, alterando os parâmetros desejados em suas configurações. Também é possível
remover, criptografar e substituir elementos, além também de mudar datas e perturbar
valores com adição de ruídos aleatórios (MICROSOFT HEALTHCARE, 2021).
Já para a segurança dos serviços realizados pelo servidor, foi utilizado a ferra-
menta Keycloak como um interceptador de autenticação. Essa aplicação é um gerencia-
dor de identidade e acesso em Java (RED HAT, 2021). Portanto, haverá a necessidade
do cadastro de usuários no sistema, com aprovação de uma entidade administradora,
para o acesso autenticado à API do servidor.
3.1.7 Validação do Servidor
Para a validação técnica do servidor, foi utilizada a ferramenta open source

Crucible, resposnsável por realizar testes de conformidade com o padrão FHIR e
pontuar as principais funcionalidades das implementações em relação aos Resources
e operações HTTP. A ferramenta é bastante utilizada pela comunidade, seja para
avaliação de aplicações e correção de performances (MITRE CORPORATION, 2021a).
3.2 MAPEAMENTO DE DADOS
Como discutido anteriormente, a HL7 não disponibiliza nenhuma ferramenta de

mapeamento de dados para o padrão FHIR. Logo, fica a cargo dos desenvolvedores
utilizarem conversores do mercado ou implementados diretamente para os sistemas
propostos. Como verificado, a linguagem de programação Python oferece excelentes
bibliotecas de mapeamento de dados para os formatos mais comuns, como o XML, o
JSON e o CSV (PYTHON SOFTWARE FOUNDATION, 2021b). Sendo assim, o Python
foi utilizado como ferramenta de conversão de dados para o padrão, considerando uma
metodologia onde a semântica dos dados não são perdidas.
A criação dos cenários de coleta de dados foi baseada nos principais conceitos
do Guia de Implementação do IPS, tendo como objetivo soluções genéricas para
aplicações globais. Adicionalmente, foram anonimizados todos os dados sensíveis dos
arquivos, eliminando nomes, endereços, identificadores pessoais e outros elementos
de identificação indireta, satisfazendo as premissas da LGPD.
Para a realização do estudo de mapeamento de dados para o servidor proposto,
foram utilizados dados sintéticos, dados coletados pelas pesquisas do SDC-X e notifi-
cações de tecnovigilância disponibilizadas pela ANVISA. Esses dados são melhores
descritos nas próximas seções.
Por fim, para os estudos de envio dos dados mapeados neste trabalho, foram
utilizadas a ferramenta Postman, para as requisições HTTP na API do servidor, o

formato JSON para o corpo das mensagens e a versão mais recente do FHIR, a R4.
3.2.1 Dados Sintéticos
Como primeiro estudo de caso, foram utilizados dados sintéticos, já que há

uma grande ausência de registros de saúde de distribuição gratuita para a área de
inovação de tecnologias em saúde. Para isso, foi utilizado a ferramenta open-source
Synthea, responsável pela criação de registros de saúde de pacientes falsos que si-
mulam desde o nascimento até o falecimento dos indivíduos, modelando doenças,
consultas hospitalares, cuidados médicos, medicamentos, alergias, exames, vacina-
ções, dentre diversos outros parâmetros que podem ser configurados para a geração
dos dados (WALONOSKI et al., 2018).
Com esses dados gerados, foi possível trabalhar e validar o servidor com o
envio em massa de requisições, livre de restrições legais, de privacidade, segurança
e propriedade intelectual. Além disso, a ferramenta possui mapeamento automático
para diversos formatos, sendo um deles o padrão HL7 FHIR (WALONOSKI et al., 2018;
MITRE CORPORATION, 2021b). Também foi utilizado um gerador de pacientes com
diagnósticos, estudos e imagens médicas no formato DICOM, relacionadas à histó-
ria de indivíduos sintéticos (SOCIETY FOR IMAGING INFORMATICS IN MEDICINE,
2021).
3.2.2 Screening for Diabetes Complications
O sistema SDC-X, desenvolvido pelas equipes de pesquisa do IEB-UFSC, pos-

sui módulos descentralizados; logo, cada módulo possui sua arquitetura única de
coletar, tratar e armazenar os dados adquiridos (TERRA, 2020; UCKER et al., 2019;
UCKER, 2020). Essa modularidade trouxe a problemática de dissociação de estrutura
e semântica das informações e tornando complexa a reutilização e colaboração desses
grupos organizacionais com um maior número de amostras e evidências.
Para a utilização dos dados já coletados anteriormente, foi necessário primeiro
analisar seus formatos e estruturas. Como observado na Figura 30, dois módulos
diferentes do SDC-X realizaram coleta de dados de um mesmo paciente em diferentes
datas e armazenaram essas informações no banco de dados no formato JSON. É
possível observar a inconsistência nas duas estruturas armazenadas pelas seguintes
características:
• O identificador único (id_user ) é diferente entre as duas estruturas, mesmo
se tratando do mesmo indivíduo;
• O nome do indivíduo é armazenado de maneira diferente e em elementos
distintos (name e Name);
Figura 30 – Dados no formato JSON coletados por dois módulos diferentes de aquisi-
ção do SDC-X: X-CARDIO (a) e X-EYE (b).
• A data de nascimento é armazenada em elementos distintos (date_birth e

Date_birth) e em formato que não é reconhecido internacionalmente (mês/dia/ano);
• O elemento idade é armazenado com número em (a) e como string em
(b). Além disso, é um dado geralmente desnecessário, já que sistemas são
capazes de identificar automaticamente a idade pela data de nascimento;
• O elemento gênero também é armazenado de forma distinta (Male e male);
• Os elementos duration_diabetes, type_diabetes e eye color armazenam da-
dos em diferentes línguas e sem descrição de quais terminologias foram
utilizadas para definição dos valores;
• Os elementos altura (height) e peso (weight) são armazenados como nú-
mero em (a) e como string em (b). Além disso, é impossível identificar por
essa estrutura qual a unidade desses valores (e.g., metros ou quilogramas).
A partir desse estudo preliminar, foi possível delinear a similaridade entre os
elementos de mesma semântica, definindo suas unidades, suas terminologias e suas
estruturas corretas. Esse delineamento tornou possível elaborar o mapeador dos dados
já coletados para o FHIR e definir os melhores métodos de embarcar o mapeador nos
módulos existentes para as aquisições futuras.
A Figura 31 apresenta o cenário com o fluxo elaborado para a aquisição de
dados pelo módulo X-CARDIO, com o uso dos Recursos FHIR e as devidas referên-
cias necessárias para a estrutura ser íntegra. Basicamente, um paciente (Patient) é
participante (ResearchSubject) da pesquisa (ResearchStudy ) e em conformidade com
um termo de consentimento (Consent) da instituição envolvida (Organization). Esse
paciente é então envolvido em um protocolo de preenchimento de um questionário
padronizado (QuestionnaireResponse) e de condições de saúde (Condition), além de
participar de uma série de exames (Observation) realizados por dispositivos de leituras
fisiológicas (Device), com auxílio de um profissional capacitado (Practitioner ). Por fim,
todos esses procedimentos são datados como um encontro (Encounter ) na instituição.
A Figura 32 apresenta o mesmo cenário, mas com as devidas referências entre
os Recursos FHIR utilizados.
3.2.2.1 Aspectos Éticos
Todas as coletas de dados fisiológicos relacionadas à pesquisa do DM foram

realizadas nas dependências do IEB-UFSC, mediante autorização do Comitê de Ética
em Pesquisa com Seres Humanos (CEPSH) da UFSC. O título desse projeto aprovado
é “Verificação de Alterações Precoces no Sistema Neuromotor em Indivíduos com
Neuropatia Diabética Periférica” (CAAE: 58989616.1.0000.0121; Parecer nº 3.326.385).
Além disso, todos os participantes assinaram um Termo de Consentimento Livre e
Esclarecido (TCLE) antes da realização do protocolo de aquisição de dados.
3.2.3 Tecnovigilância
Para ampliação e demonstração dos benefícios adquiridos pelo padrão FHIR

em contextos diversos, foram utilizados dados fornecidos pela plataforma pública de
notificações de tecnovigilância da ANVISA e abrangendo um contexto de pesquisa em
engenharia clínica. Essas informações são de extrema importância para os levantamen-
tos e estudos realizados por equipes do IEB-UFSC, que planejam novas metodologias
de adoção de segurança e de qualidade nas tecnologias de saúde (BRANDÃO et al.,
2021).
Como demonstrado na Figura 33, esses dados englobam notificações adquiri-
Figura 31 – Fluxo da coleta de informações pelo módulo X-CARDIO do SDC-X com os

respectivos Resources.
das pela agência desde 2007 até os tempos atuais, detalhando o tipo da notificação
(Evento Adverso ou Queixa Técnica), a classe do risco, a condição clínica causada
(padronizado pelo World Health Organization - Adverse Reaction Terminology (WHO-
ART)), detalhes da ocorrência e o produto médico-hospitalar envolvido. O arquivo
adquirido possui 8695 notificações disponibilizadas pela ANVISA no formato XLSX
(AGÊNCIA NACIONAL DE VIGILÂNCIA SANITÁRIA, 2021).
A Figura 34 apresenta o cenário com o fluxo definido para a utilização desses
dados na criação de um banco de dados de pesquisa para a engenharia clínica. Em
suma, o evento (AdverseEvent) que registra um episódio adverso ou de queixa técnica,
fará parte de alguma pesquisa no contexto (ResearchStudy ), que analisa acontecimen-
tos (Encounter ) onde foram realizados procedimentos clínicos (Procedure), com uso
de algum produto médico-hospitalar (Device) que causou alguma condição adversa
(Condition) em indivíduos participantes.
A Figura 35 apresenta o mesmo cenário, mas com as devidas referências entre
os Recursos pelo padrão FHIR.
Figura 32 – Cenário da coleta de dados pelo módulo X-CARDIO do SDC-X com os

respectivos Resources e suas referências.
3.3 GUIA DE IMPLEMENTAÇÃO
Com o levantamento das informações e detalhes dos dados de pesquisa, foi

elaborado um repositório com os Recursos, perfis e extensões apropriadas para utili-
zação no servidor, além dá página do Guia de Implementação da proposta, discutido
nas próximas seções.
3.3.1 Resources
Após análise e estudo dos dados de pesquisa apresentados anteriormente, foi

possível destacar os principais Resources para utilização neste trabalho. Vale ressaltar
que nenhuma informação importante foi perdida por ausência de Recurso ou elemento
específico da documentação. Todos os Resources selecionados e suas devidas defini-
ções estão presentes no Quadro 13.
Figura 33 – Exemplo das notificações de eventos adversos e queixas técnicas de tec-

novigilância da ANVISA.
Figura 34 – Fluxo das informações das notificações de tecnovigilância da ANVISA com

os respectivos Resources.
3.3.2 Profiles
Para a criação dos Profiles a serem utilizados na proposta, foram levados em

consideração o cenário de pesquisa clínica e as restrições que esse contexto gera.
Com isso, foi utilizada a ferramenta Trifolia-on-FHIR para elaboração das StructureDe-
finitions, ValueSets e os demais Recursos de perfilização (LANTANA CONSULTING
GROUP, 2021). Por fim, cada estrutura de restrição obteve uma URL canônica para
identificação única e para uso posterior nas validações.
Figura 35 – Cenário do uso das notificações de tecnovigilância da ANVISA com os

respectivos Resources e suas referências.
Os Profiles elaborados por esse trabalho não são obrigatórios para o uso no
servidor, mas servem de grande auxílio no processo de armazenamento do que real-
mente é necessário, já que se tratam de dados de pesquisa e não de atendimento ao
paciente, consequentemente restringindo os elementos necessários.
3.3.3 Terminologias
Após o estudo dos dados apresentados anteriormente, foi possível elaborar um

conjunto de conceitos e suas devidas terminologias para manutenção da semântica das
informações utilizadas pelas pesquisas. Com isso, foram definidos quais os sistemas
de códigos empregados, sendo eles:
• SNOMED CT: para definir sinais, sintomas, diagnósticos, procedimentos, da-
dos observacionais e estruturas anatômicas. O Quadro 14 apresenta alguns
dos termos identificados para os estudos de casos, juntamente com seus
tipos e identificadores, conhecidos como SNOMED CT Identifier (SCTID).
Além disso, os Recursos que utilizarem os códigos precisam identificar a
URL canônica do sistema como "http://snomed.info/sct" (SNOMED INTER-
NATIONAL, 2021);
• LOINC: para definir observações clínicas e laboratoriais. Alguns dos termos
utilizados são apresentados no Quadro 15, juntamente com seus códigos
identificadores. Vale ressaltar que os Recursos que utilizarem os códigos
precisam identificar a URL canônica do sistema como "http://loinc.org" (RE-
Quadro 13 – Principais Resources utilizados nos estudos de caso e suas descrições.

Resource Descrição
Patient Dados demográficos e administrativos de um indivíduo
Condition Condição clínica, problema ou diagnóstico de um indivíduo
Observation Medidas e afirmações realizadas sobre um indivíduo
Interação entre um indivíduo e um provedor de saúde, com a finalidade de
Encounter
avaliar o estado de saúde do mesmo
Agrupamento formal ou informalmente reconhecido de pessoas ou organi-
Organization zações, com o propósito de realizar alguma forma de ação relacionada à
saúde
Local físico onde serviços são fornecidos e onde os recursos e os partici-
Location
pantes podem ser encontrados ou acomodados
Practitioner Profissional que está envolvido no processo e serviço relacionado à saúde
Conjunto de informações fornecidas por um serviço de diagnóstico quando
DiagnosticReport
as investigações são concluídas
QuestionnaireResponse Conjunto estruturado de perguntas e suas respostas
Evento real, potencial ou evitado que causa impacto não intencional em
AdverseEvent
indivíduos participantes
Media Conteúdo midiático relacionado à um evento de saúde
Planejamento e execução de uma série de etapas com o objetivo de am-
ResearchStudy
pliar o campo do conhecimento relacionado à saúde
Entidade física que é a unidade principal de interesse operacional e/ou
ResearchSubject
administrativo em um estudo
Item manufaturado para a prestação de cuidados de saúde sem ser subs-
Device
tancialmente alterado por essa atividade
Consentimento para participar de um protocolo de pesquisa e do compar-
Consent
tilhamento de informações
Grupo de entidades que estão sendo rastreadas, examinados ou referen-
Group
ciadas como parte de atividades relacionadas à saúde
GENSTRIEF INSTITUTE, 2021a);

• UCUM: para definir todas as unidades de medidas do International System
of Units (SI), com as dimensões de comprimento, tempo, massa, carga, tem-
peratura, intensidade luminosa e ângulo. Algumas das unidades utilizadas
são apresentadas no Quadro 16, juntamente com seus códigos. Para utili-
zação dos códigos nos Resources, precisa-se identificar a URL canônica
do sistema como "http://unitsofmeasure.org" (REGENSTRIEF INSTITUTE,
2021b);
• WHO-ART: para definir e classificar os tipos de eventos adversos que são
utilizadas pelas notificações da ANVISA;
• ANVISA: para o estudo de caso de eventos adversos e queixas técnicas da
ANVISA, foram utilizadas as terminologias internas da agência para o tipo
de notificação (evento adverso ou queixa técnica), classificação do risco dos
produtos (I, II, III ou IV) e seus nomes técnicos. Como esses conceitos se
encontram em documentos e não em sistemas com URLs canônicas publi-
cadas, foram criados ValueSets para os códigos utilizados, assim como um
Quadro 14 – Alguns dos termos do SNOMED CT utilizados nos estudos de caso.

Identificador Termo Tipo
46635009 Diabetes mellitus type 1 Disorder
44054006 Diabetes mellitus type 2 Disorder
11687002 Gestational diabetes mellitus Disorder
102512003 Well adult Finding
29303009 Electrocardiographic procedure Procedure
72075005 Photoplethysmography Procedure
364075005 Heart rate Observable entity
86290005 Respiratory rate Observable entity
271649006 Systolic blood pressure Observable entity
271650006 Diastolic blood pressure Observable entity
67866001 Insulin Substance
Quadro 15 – Alguns dos termos do LOINC utilizados nos estudos de caso.

Identificador Termo
76643-6 R-R interval.standard deviation (Heart rate variability) by EKG
75944-9 Left eye Pupil reaction [Time]
75945-6 Right eye Pupil reaction [Time]
8640-5 Left pupil Diameter Auto
8642-1 Right pupil Diameter Auto
8480-6 Systolic blood pressure
8462-4 Diastolic blood pressure
8302-2 Body height
29463-7 Body weight
Quadro 16 – Alguns dos termos do UCUM utilizados nos estudos de caso.

Código Termo
{beats}/min heart beats per minute
kg kilogram
m meter
s second
mm[Hg] millimeter of mercury
deg degree (plane angle)
% percent
mV millivolt
mm millimeter
ms millisecond
Cel degree Celsius
CodeSystem para reunir todos eles e suas definições formais, como apre-
sentado na Figura 36 (AGÊNCIA NACIONAL DE VIGILÂNCIA SANITÁRIA,
2021).
Figura 36 – CodeSystem desenvolvido para agrupar os conceitos utilizados pela AN-

VISA e que não possuem sistema canônico.
3.3.4 Implementation Guide
Para desenvolvimento do IG, foi utilizado a plataforma SIMPLIFIER.NET, capaz

de registrar e utilizar os profiles, as extensions e os demais Recursos de conformi-
dade. Essa plataforma oferece ferramentas de edição e uma estrutura funcional para
organizar as páginas de um IG, os pacotes de validação e toda a estrutura lógica
necessária para os Resources, além de possuir um Controle de Qualidade dessas
estruturas (FIRELY, 2021b).
Com o IG desenvolvido e publicado, é possível gerar um repositório com a ver-
são mais recente da implementação e incorporar esse pacote no servidor desenvolvido,
por meio da adição de um interceptador nas linhas de código. Esse interceptador utiliza
o link do pacote para baixar toda a estrutura dos Profiles para o banco de dados e
utilizá-los na validação de Recursos que se denominam pertencentes à esses perfis. O
servidor é capaz de realizar essa interceptação por meio da URL canônica adicionada
no elemento profile do Recurso.
3.4 ANÁLISE NASSS
Baseado na premissa do framework NASSS, apresentado no capítulo anterior,

este trabalho fez uma análise de complexidade dos 7 domínios que influenciam na
não-adoção, abandono e nos desafios de crescer, disseminar e sustentar as novas tec-
nologias de saúde nos contextos de pesquisa apresentados. O Quadro 17 esquematiza
os domínios definidos para a análise de cada estudo de caso.
Quadro 17 – Domínios definidos para análise da proposta pelo framework NASSS.

Domínio SDC-X Tecnovigilância
Condições clínicas causadas por
Diabetes mellitus e as complica-
1. Condição eventos adversos em produtos
ções causadas
médico-hospitalares
Servidor de dados de pesquisa clí- Servidor de dados de tecnovigilân-
2. Tecnologia nica baseado nas especificações cia baseado nas especificações do
do HL7 FHIR HL7 FHIR
Uso de tecnologias web modernas Uso de tecnologias web modernas
para compartilhamento e reutiliza- para reutilização de dados de tecno-
3. Proposição de Valor
ção de dados de pesquisas em vigilância para estudos na engenha-
saúde ria clínica
Pesquisadores da área de engenha-
Pesquisadores, profissionais de
4. Adotantes ria clínica e de tecnovigilância, além
saúde e pacientes
da indústria fabricante dos produtos
5. Organizações Envolvi- Universidade e instituições de pes- Universidade, instituições de pes-
das quisa quisa e fabricantes de produtos
Anonimização de dados de pes-
6. Sistema Amplo quisa pela LGPD, Guia de Imple- Guia de Implementação
mentação
7. Incorporação e Adap-
tação ao Longo do Adaptação com as tecnologias web Adaptação com as tecnologias web
Tempo
85
4 RESULTADOS
Neste capítulo são apresentados os resultados obtidos pelo sistema proposto e

implementado. Assim, são apontados os resultados específicos das funcionalidades do
servidor, do guia de implementação, dos estudos de caso de mapeamento de dados e
do uso da interface RESTful API em demais operações.
4.1 SERVIDOR
Nesta seção serão apresentados os resultados relacionados à implementação

do servidor, os aspectos de sua segurança, as interfaces para usuário e as operações
disponíveis em sua API.
4.1.1 Deploy
Como discutido no capítulo anterior, foi definido o uso da tecnologia de contêiner

para o deploy das versões do servidor. Logo, com a adaptação da biblioteca HAPI e
do preparo para conexão com o banco de dados PostgreSQL, foram realizados os
testes com a imagem gerada do servidor. Esses testes ocorreram na máquina local,
por meio do Docker Desktop e em dois grandes serviços PaaS na nuvem, o Google
Cloud Platform e o Heroku.
Todas as implementações funcionaram como planejado, mas nos serviços na
nuvem foram necessários a ativação de configurações para o maior armazenamento
e melhor hospedagem, sendo esses serviços adicionais pagos e onerosos. Com isso,
foi preferível realizar todos os testes individuais em máquina, simulando um servidor
em rede local da instituição e com capacidade de exposição da API para aplicações
externas.
4.1.2 Segurança
Com a implementação do interceptador de segurança, o acesso ao servidor foi

apenas atribuído ao usuário após uma página de autenticação, como observado na
Figura 37. Essa página apresenta o login, o cadastro de novos usuários, a opção de
recuperação de senha e suporte multilínguas. A partir desse interceptador, foi possível
desenvolver dois casos de uso para o usuário: a leitura e o registro de Recursos.
Para o caso de uso de leitura, que engloba as operações de requisição e pes-
quisa de Recursos, foi possível realizar as interações baseadas no diagrama de sequên-
cia da Figura 38. Assim, quando realizada uma operação de leitura, será gerada uma
resposta examinada pelo interceptador, antes de entregá-la ao cliente. Se as regras
não permitirem tal ação, o interceptador aborta a solicitação e retorna um código de
status apropriado.
Capítulo 4. Resultados 86
Figura 37 – Página de autenticação com login de usuário do servidor.
Já o caso de uso de registro, que engloba a criação e atualização de Recursos,

foi possível realizar as iterações como apresentada na Figura 39. Nesse cenário, o
interceptador de autorização analisa e toma uma decisão da solicitação para enfim
poder executar ou criar um novo Resource. Sem a devida permissão, o cliente não terá
acesso a essa operação e receberá um código de status apropriado.
4.1.3 Interface de Usuário
Após o acesso por autenticação em navegador, o usuário é levado à página

inicial do servidor, como demonstrado na Figura 40. Essa página foi implementada
para facilitar os primeiros acessos a quem esteja utilizando a proposta e para melhor
visualização das operações suportadas. Por ela, é possível escolher determinadas
configurações de codificação das mensagens (Encoding), além de todos os Resources
presentes e a quantidade armazenada de cada tipo. Além disso, é possível localizar
informações sobre o servidor, sua versão e seu endpoint (FHIR Base), que é a URL
base de todos os serviços da implementação.
Quando selecionado algum Recurso, o servidor apresenta a página especiali-
zada para as operações que podem ser realizadas com aquele tipo, como apresentado
na Figura 41. Essas operações básicas da API do servidor são:
• Read: para requisitar um Recurso pelo seu identificador (ID) ou uma versão
específica dele;
Figura 38 – Diagrama de sequência da autenticação em operações de leitura de Re-

cursos.
• History: para requisitar o histórico dos Recursos do tipo selecionado ou

de um Recurso específico. Pode-se também especificar uma data e limite
opcional de filtragem de informações;
• Delete: para deletar um Recurso específico pela identificação do seu ID;
• Create: para criar um novo Recurso com um ID especificado pelo client, e
quando não, é forçado pelo próprio servidor;
• Update: para atualizar um Recurso existente pelo seu ID;
• Validate: para validar a aceitação de um Recurso sem a necessidade de
armazená-lo.
4.1.4 Interface RESTful API
Como foi apresentado na Figura 40, a página principal disponibiliza o Recurso

com as capacidades do servidor (Conformance), o histórico de todos os Resources
armazenados (History ) e a capacidade de transação em massa por meio de bun-
dle (Transaction). Todas essas ferramentas fazem parte da interface RESTful API da
implementação, sendo uma proposta com intuito mais visual e facilitado.
Figura 39 – Diagrama de sequência da autenticação em operações de registro de

Recursos.
O Conformance retorna o CapabilityStatement da API, um documento no for-

mato FHIR com todas as regras lógicas dos Recursos e interações suportadas pela
implementação. Como apresentado na Figura 42, quando o CapabilityStatement é
requisitado, seu corpo de resposta detalha quais os Recursos suportados, como o
exemplo da linha 23, onde o servidor descreve ser capaz de computar o Resource
Account com o perfil base do padrão (linha 24) e com as suas devidas interações (e.g.,
create, delete).
Como o servidor foi desenvolvido em conformidade com as especificações do
OAS, a implementação ofereceu a página do Swagger UI da API. Essa página for-
neceu a lista de todos os Recursos suportados pela proposta, mostrando todas as
iterações que podem ser realizadas por cada um, como observado na Figura 43, onde
o Resource ResearchStudy foi selecionado, apresentando todas as operações HTTP
que podem ser realizadas com esse determinado tipo de Recurso. Nesse exemplo,
pode-se observar que um ResearchStudy pode ser requisitado (GET ) ou deletado
(DELETE) pelo seu ID, assim como também pode ser criado um novo (PUT ), dentre
outras operações. Além disso, os usuários administradores do sistema podem limitar
quais dessas iterações podem ser públicas ou para usuários específicos.
Assim que uma das operações do Swagger UI é selecionada, uma janela é ex-
pandida com os parâmetros necessários para a interação. A Figura 44 demonstra essa
ferramenta quando a operação update-instance (PUT ) é selecionada, possibilitando a
Figura 40 – Página inicial da interface de usuário do servidor proposto.
atribuição de um ID escolhido pelo usuário, o formato da mensagem (i.e., JSON, XML)

e o corpo da mesma no padrão FHIR. Nesse exemplo, o Recurso da mensagem será
criado com ID "sdc-ieb", mas se já existir um armazenado com o mesmo identificador,
ele será atualizado com os elementos novos ou editados. O intuito desse Recurso é
o de cadastrar a pesquisa "Screening for Diabetes Complications" (SDC-X) para ser
referenciada pelas demais estruturas que serão armazenadas pelo estudo.
A mesma janela ainda oferece o código Client Uniform Resource Locator (cURL)
com os cabeçalhos, o caminho com o ID definido, o formato e o corpo da requisição,
que pode ser facilmente copiado e colado em alguma outra ferramenta API, como um
terminal local ou o Postman.
Como esperado, a resposta apresenta o código de status da operação realizada,
o Recurso como foi armazenado e os cabeçalhos de resposta. A Figura 45 demonstra
o exemplo da resposta da requisição de criação do Resource ResearchStudy. Percebe-
se que o status foi o 201, ou seja, um novo Recurso foi criado no banco de dados.
4.1.5 Validação de Recursos
Quando alguma operação não é bem-sucedida, o servidor retornou um Recurso

manifestando o erro, como o exemplo da Figura 46, onde são apresentadas as res-
postas quando realizadas na interface do navegador ou na ferramenta Postman. Esse
Resource, conhecido como OperationOutcome, apresenta o código de status do pos-
sível erro e um conjunto de informações que caracterizam o motivo ou a localidade
Figura 41 – Página do Resource com suas operações.
da falha. No exemplo demonstrado, foi realizado um teste de criação de um Recurso

Organization com os elementos "idd" e "gender ", ou seja, um elemento com erro de
digitação e o outro elemento que faz parte da estrutura de outro Recurso, o Patient.
Logo, o servidor não validou os elementos, como esperado, por não reconhecê-los
parte da estrutura do Resource especificado. Assim, a mensagem não é processada
(código de status 422) e é retornado um OperationOutcome com as informações do
erro.
Também foi observado que a criação de novos Recursos e seus identificadores
ocorreram como esperado, ou seja, quando utilizado interação do tipo create com
PUT, o servidor armazena os Resources com o IDs especificados pelo cliente. Já
o create com POST armazenou os Recursos com identificador estabelecido pelo
servidor, sendo um valor numérico ordenado. Com isso, preferiu-se utilizar apenas
a opção de criação com escolha de ID, para o melhor rastreamento e pesquisas
posteriores das estruturas.
4.1.6 Pacote de Resources
Como parte da criação do Implementation Guide da proposta e da validação

dos Recursos pelo servidor, os profiles desenvolvidos foram publicados na plataforma
do SIMPLIFIER.NET, onde não foi encontrado nenhum problema pelo Controle de
Qualidade do sistema. A Figura 47 exibe a página dos Resources do projeto IEB-
Figura 42 – Resposta da API com o Recurso CapabilityStatement do servidor.
Figura 43 – Página da interface Swagger UI para acesso à OpenAPI do servidor.
UFSC on FHIR, onde é possível também observar o armazenamento dos profiles e

Recursos de terminologia utilizados. Vale ressaltar que estão presentes apenas os
Recursos definidos como importantes no armazenamento e na reutilização dos dados
de pesquisas clínicas, omitindo os Recursos e elementos desnecessários.
Com esse pacote implementado, foi possível adicioná-lo ao servidor por meio
da adição de um interceptador. Esse, por fim, utilizou a URL oficial do pacote, fornecido
pelo SIMPLIFIER.NET, para armazenar as últimas versões dos Recursos do projeto e
Figura 44 – Requisição realizada na interface Swagger UI para criação de um Re-

source ResearchStudy na OpenAPI do servidor.
utilizá-los como uma estrutura lógica de validação da implementação. Com isso, todo
Recurso de entrada que se declarou parte de algum perfil do pacote passou por uma
validação local baseada nesse interceptador.
Após a criação do pacote com os Resources necessários das estruturas de

perfis e terminologias, foi desenvolvido a página do Guia de Implementação do pro-
jeto. Essa página foi implementada e publicada utilizando o editor de IG do SIMPLI-
FIER.NET, criando toda a conexão do site com a estrutura lógica e computacional do
projeto em FHIR.
Considerando os estudos de caso propostos e o intuito de expansão para fu-
turas pesquisas, o IG foi elaborado com os profiles de cada caso, as terminologias
utilizadas e as operações suportadas por cada Recurso. Por fim, foi utilizado a ferra-
menta de validação de IG da plataforma, no qual não detectou problemas na estrutura
desenvolvida.
A Figura 48 apresenta a página inicial do IG, denominado de "IEB-UFSC on
FHIR Implementation Guide". Nessa primeira página estão as informações gerais do
projeto e os links para as demais páginas do guia, sendo elas: o índice das páginas
do site (Table of Contents), informações gerais sobre o uso dos Recursos no servidor
(Guidance), os Resources específicos de cada caso de uso e os exemplos para auxilio
no entendimento do padrão.
Figura 45 – Resposta de uma requisição realizada na interface Swagger UI para cria-

ção de um Resource ResearchStudy na OpenAPI do servidor.
A Figura 49 apresenta a página do Resource Patient do cenário de caso de

uso do SDC-X. Nessa página é apresentada a estrutura lógica do perfil, destacando
a cardinalidade de cada elemento. Pode-se observar, por exemplo, que o elemento
"name", presente no Patient da especificação base, foi omitido no projeto, demons-
trando a importância de evitar o armazenamento de dados sensíveis de voluntários. Já
alguns outros elementos se tornaram opcionais, como o falecimento (deceased) e o
estado civil (maritalStatus) do indivíduo.
Também foi observado que quando algum perfil ou outra estrutura do pacote do
projeto era alterado no SIMPLIFIER.NET, a atualização das páginas do IG com essas
novas estruturas aconteceram em tempo real. O mesmo aconteceu quando gerado
um novo pacote do projeto, atualizando os perfis do servidor com as novas mudanças
sempre que um novo deploy era realizado.
Figura 46 – Resposta do servidor com OperationOutcome manifestando erro na valida-

ção do Resource. Resposta na interface do navegador (a) e renderizada
na ferramenta Postman (b).
Com o servidor implementado, foi possível agregar os dados de pesquisas reais

e em andamento. Com isso, foram realizados estudos de caso com dados fisiológicos
(e.g., ECG, EEG, EMG, PPG, peso, altura, frequência cardíaca), doenças, eventos
adversos, dispositivos médicos, dados demográficos, questionários e informações de
pesquisa, todos mapeados para Resources específicos.
Utilizando a linguagem Python e as devidas bibliotecas de formatos (e.g., JSON,
CSV, XML), todos os dados foram mapeados para o FHIR em estruturas bundle, para
evitar o armazenamento individual dos Recursos e preparando uma requisição em
massa. A estrutura geral dos bundles finais é esquematizada na Figura 50, onde cada
bundle é tipado como "transaction", ou seja, são destinados para o servidor processar
toda a estrutura de forma massiva. Com isso, o Resource engloba todas as entradas
(entry ) que são carregadas, juntamente com a URL pretendida para armazenamento,
o ID especificado, o Recurso em si e o método de envio HTTP.
4.3.1 Estudos de Caso
Para confirmação dessa metodologia e arquitetura proposta, serão apresenta-

dos os estudos de caso individuais, realizados para a validação do sistema. Foram
utilizados dados sintéticos, os relatórios já gerados pelos módulos desenvolvidos pelo
SDC-X e dados relacionados às notificações de tecnovigilância da ANVISA. Esses re-
latórios foram adquiridos em formatos JSON, XLSX, TXT e CSV, todos com suporte a
mapeamento pelo Python. Além disso, todos os dados sensíveis foram desidentificados
Figura 47 – Página dos Resources do projeto IEB-UFSC on FHIR na plataforma SIM-

PLIFIER.NET.
e anonimizados com uso de ferramenta de código aberto.
4.3.1.1 Simulador Sintético de População
Para avaliação e validação do servidor para casos de envio massivo de dados,

foi primeiramente realizados testes com envio de Resources sintetizados pela ferra-
menta open source Synthea. Com isso, foram desenvolvidos 8 bundles com diferentes
cenários. Cada cenário envolveu de 26 a 17.564 Recursos, sendo calculados os tem-
pos totais de evento em segundos, o tamanho da requisição e o tamanho da resposta
em megabytes. Esses testes estão descritos no Quadro 18. Logo, a partir desses tes-
tes iniciais, foi possível determinar uma média de tempo de requisição de 29,03 ms por
Recurso, com um desvio padrão de 0,0108.
4.3.1.2 SDC-X
Após a realização do estudos dos dados gerados pelos módulos de pesquisa

do SDC-X, foram elaborados os mapeadores Python responsáveis pela conversão dos
formatos originais para o FHIR. Primeiro foram identificados os elementos adequados
e quais os Resources que os comportam, como definido no capítulo anterior.
Antes do envio em massa desses dados, foi identificado que seria melhor o
Figura 48 – Página inicial do Guia de Implementação do projeto IEB-UFSC on FHIR.
Quadro 18 – Testes de performance realizados no servidor com dados sintetizados.

Recursos Tempo Total (seg) Tamanho da Requisição (MB) Tamanho da Resposta (MB)
26 1,2946 0,07694 0,00538
222 4,8400 0,81782 0,04077
427 8,0200 1,32000 0,07777
1.531 29,4400 2,96000 0,27756
2.366 67,8600 8,56000 0,42939
3.123 84,6600 11,80000 0,56659
7.632 205,0200 15,74000 1,35000
17.564 702,1800 38,87000 3,10000
envio dos Recursos recorrentes e que são referenciados por quase todos os Recursos
individuais. Em outras palavras, é preferível primeiramente o envio dos Resources
Practitioner, Organization, Device, ResearchStudy e Consent, já que são referenciados
por quase todos os outros Recursos individuais, gerados pelas coletas de dados de
voluntários. Esses, por fim, foram facilmente enviados ao servidor com interação de
criação (PUT ) para uso de IDs sistematizados e de fácil rastreamento posterior.
Já os Recursos Patient, ResearchSubject, Encounter, QuestionnaireResponse,
Condition e Observation são individualizados para cada voluntário e suas devidas
coletas. Com isso, cada estrutura adquirida foi mapeada e convertida, como o exemplo
Figura 49 – Página do Recurso Patient do cenário do caso de uso SDC-X do Guia de

Implementação do projeto IEB-UFSC on FHIR.
da Figura 51, onde o JSON com dados adquiridos de um voluntário no modelo original
foram devidamente mapeados para o FHIR com o Python. A Figura 51 ainda apresenta
quais os elementos e as terminologias utilizadas em conformidade com os tipos de
dados padronizados pelo FHIR. Observa-se que a idade (age) não foi reutilizada, já
que há o elemento birthDate com os dados necessários. Além disso, o nome (name)
do paciente foi anonimizado para proteção de dados sensíveis, utilizando a ferramenta
Tools for Health Data Anonymization. Por fim, como o elemento "name" de Patient será
sempre omitido dos dados, o profile desse Recurso foi condicionado à cardinalidade
nula (0..0), ou seja, nunca deve haver os nomes dos voluntários nos arquivos enviados
ao servidor.
A Figura 52 apresenta uma parcialidade da conversão dos arquivos originais
em JSON para o JSON em concordância com o FHIR. Esse arquivo final é estruturado
como um bundle, sendo a coleção de todos os Resources em um único contêiner de
transação, para que as dezenas de Recursos sejam processados pelo servidor em
apenas uma mensagem HTTP.
Com esse arquivo mapeado, foi possível enviá-lo ao endpoint do Transaction do
servidor utilizando a ferramenta de cliente API Postman. Como esses dados geraram
poucas dezenas de Recursos, o arquivo final de requisição alcançou um tamanho de
66,69 kilobytes, gerando uma requisição simples de 1908,4 ms e com resposta de 6,49
kilobytes, com validação em conformidade e sucesso no armazenamento.
Figura 50 – Estrutura dos bundles utilizados para envio dos dados mapeados.
Figura 51 – Exemplo de um mapeamento da estrutura original dos dados adquiridos

dos voluntários do SDC-CARDIO para o formato FHIR.
4.3.1.3 Tecnovigilância
Os dados de notificações de tecnovigilância, adquiridos por meio da ANVISA,

estavam originalmente em formato XLSX, comumente utilizado para planilhas Excel.
Com isso, foi preferível primeiramente convertê-lo em CSV, um formato mais leve e
simples. O arquivo gerado possuía 8695 linhas, sendo cada linha uma notificação com
todos os elementos de dados separados por vírgulas.
Baseado no cenário definido no capítulo anterior, cada elemento sofreu um
Figura 52 – Exemplo de um mapeador JSON (esquerda) para JSON do FHIR (direita)

desenvolvido em Python para os dados do SDC-X.
mapeamento para um arquivo novo, no formato bundle do FHIR. Todos os elementos

foram devidamente coordenados por suas terminologias, como observado na Figura 53,
onde há a conversão de uma única notificação para os devidos elementos FHIR. Nota-
se que no formato original, as informações de data utilizavam 3 elementos, enquanto
que no FHIR é necessário apenas um. Os demais elementos foram adequados aos
Resources do cenário proposto, utilizando as terminologias atribuídas pela ANVISA.
A Figura 54 apresenta uma parcialidade da conversão do arquivo CSV para o
JSON em concordância com o FHIR. Esse arquivo final é estruturado como um bundle,
para que os milhares de Recursos sejam processados pelo servidor em uma única
requisição de transação HTTP.
Com esse arquivo convertido, foi possível enviá-lo ao endpoint do servidor imple-
mentado utilizando a ferramenta de cliente API Postman. Diferentemente do estudo de
caso dos dados do SDC-X, que geram arquivos com poucos kilobytes, o arquivo resul-
tante da tecnovigilância possuía 23,43 megabytes de tamanho. Com isso, a requisição
Figura 53 – Exemplo de um mapeamento da estrutura original das notificações de

tecnovigilância da ANVISA para o formato FHIR.
Figura 54 – Exemplo de um mapeador CSV (esquerda) para JSON do FHIR (direita)

desenvolvido em Python para os dados de tecnovigilância da ANVISA.
tornou-se mais longa, durando 13 minutos e 12 segundos, já que todos os Recursos

passaram pelo interceptador de validação do servidor antes de serem armazenados
com sucesso, gerando uma resposta de 1,7 megabytes.
4.4 BANCO DE DADOS
O banco de dados PostgreSQL foi capaz de armazenar todos os Recursos vali-

dados pelo servidor JPA, proporcionando ao mantedor da base de dados o manuseio
adicional das informações pela linguagem Structured Query Language (SQL). Porém,
vale ressaltar que o acesso direto ao banco de dados não ofereceu as estruturas no
formato FHIR e sim no modelo objeto relacional, já que tal oferta é realizada pela
camada de persistência do servidor. Também foi possível a realização de backups
de segurança dos dados e a exportação para formatos como o CSV, TXT e binário,
em arquivos pequenos e facilmente exportados por outras aplicações, tais como em
planilhas e em Power BI.
O banco de dados também forneceu um sistema de histórico, onde os Recursos
nunca são sobrepostos e sim atualizados com a criação de uma nova versão, possibili-
tando o acesso às versões anteriores. A omissão de Resources foi alcançada apenas
com a remoção dos mesmos.
Juntos, os estudos de caso do SDC-X e de Tecnovigilância, proporcionaram o
armazenamento de cerca de 8920 Resources, uma estrutura de banco de dados com
tamanho de 91 megabytes e um backup de 32,8 megabytes.
4.5 INTERFACE RESTFUL API
Com a interface RESTful API implementada, foi possível realizar teste de co-
nexão com ferramentas disponibilizadas na web, utilizando o endpoint do servidor e
devidas configurações de segurança. Essa operação foi validada na conexão com
a plataforma clinFHIR, para visualização e consulta de Recursos armazenados no
banco de dados do servidor. Com isso, o servidor se tornou apto a receber requisições
de aplicações exteriores, capazes de reutilizar e trabalhar com os dados contidos na
implementação.
Pelo deploy também possível adicionar conexão direta com outras APIs, tal
como a implementação pública do HAPI, que pôde ser utilizada para testes iniciais e
com dados fictícios, já que esse servidor é aberto ao público e sem serviços de segu-
rança. A mudança de conexão para outros servidores foi possível pela aba "Server ",
como foi apresentado na Figura 40.
Também foi possível realizar a conexão com outros IGs importantes, como o do
IPS e do Point-of-Care Device, expandindo a capacidade de conformidade com profiles
conhecidos e recomendados.
4.6 AVALIAÇÃO E VALIDAÇÃO DO SERVIDOR
Para validação do servidor e de suas funcionalidades, foi utilizado a ferramenta

open-source Crucible, para avaliação e testagem da implementação de acordo com
as especificações do FHIR. Os principais parâmetros avaliados são os formatos e
configurações dos Resources, além das operações REST suportadas pela API.
Os testes foram realizados na implementação em máquina local e foram dividi-
dos em duas avaliações, uma com a testagem do servidor por inteiro, avaliando toda a
sua estrutura, e outra avaliando apenas na perspectiva necessária para os estudos de

caso realizados por este trabalho.
Cada avaliação consiste em um conjunto de suites com vários testes cada. A
primeira avaliação, considerando todos os 293 suites e seus 2389 testes, obteve 97%
dos testes qualificados. Enquanto isso, a avaliação da estrutura necessária para os
estudos de caso de pesquisa, tendo 57 suites com 470 testes, obteve 98% dos testes
aprovados. Para todas as avaliações, a versão referência da especificação do FHIR
utilizada é a R4, sendo a mais recente e implementada em toda a proposta.
Em relação ao suporte de Recursos FHIR, a primeira avaliação obteve 97%
de sucesso nos testes, enquanto a segunda avaliação obteve 98%, mostrando ter
Resources do tipo Foundation em perfeita conformidade com as especificações. A
comparação das duas avaliações é apresentada na Figura 55.
Figura 55 – Comparação dos testes de conformidade dos Recursos do servidor por

inteiro (a) e com os dos estudos de caso (b).
Quanto ao suporte da interface RESTful API, as avaliações foram novamente

próximas, sendo 97% de sucesso para toda a interface do servidor e 98% para a
estrutura necessária aos estudos de caso com dados de pesquisa clínica. A Figura 56
apresenta essa comparação aproximada, demonstrando que o servidor foi capaz de
trabalhar com as principais interações e pesquisas, como esperado pela tecnologia
REST.
Figura 56 – Comparação dos testes de conformidade da interface RESTful API do

servidor por inteiro (a) e com os dos estudos de caso (b).

104
5 DISCUSSÃO
Este capítulo apresenta uma discussão sobre o padrão HL7 FHIR como proto-
colo de interoperabilidade na saúde, o servidor desenvolvido, o guia da implementação,
a metodologia de mapeamento de dados, a interface API de conexão e uma análise
final de complexidade pelo framework NASSS.
5.1 PADRÃO HL7 FHIR
Como observado por Benson e Grieve (2021) e Saripalle (2019), o padrão FHIR,
desenvolvido pela HL7, vem sendo visivelmente uma forte solução de interoperabili-
dade entre os números crescentes de variadas entidades de saúde. O padrão mostrou-
se ser de fácil entendimento e implementação, já que possui uma documentação bem
elaborada, diversos exemplos e uma comunidade ativa.
A relevância do FHIR foi também observada por grandes corporações de tec-
nologia, como a Google, Amazon e Microsoft, que já assinaram um documento com
compromisso de agregar o padrão na entrega de melhores resultados, a custos mais
baixos, decorrente do potencial dos dados de saúde (INFORMATION TECHNOLOGY
INDUSTRY COUNCIL, 2018). Esse compromisso foi observado pelas diversas aplica-
ções com suporte para o FHIR oferecidas por essas plataformas, como o Google Cloud
Platform, a ferramenta de anonimização da Microsoft e as diversas implementações de
servidores oferecidas por outras grandes multinacionais e utilizadas nos testes deste
trabalho.
5.2 SERVIDOR
O servidor implementado demonstrou performance adequada no que foi pro-

posto, já que a biblioteca HAPI utilizada ofereceu documentação suficiente para edição
e a adição dos interceptadores de segurança e de integração com pacotes de guias
de implementação. Além disso, o banco de dados PostgreSQL mostrou-se uma opção
apropriada para armazenamento e recuperação dos Recursos, de forma segura e bem
arquitetada, já que versões novas do servidor JPA podem ser lançadas, sem perda
dos dados já adquiridos anteriormente. Ainda assim, foi possível realizar backups dos
dados, sempre que possível, para a segurança na perda dos mesmos.
Evitando plataformas onerosas e softwares licenciados, a proposta demonstrou
desempenho adequado utilizando ferramentas de código aberto e hardwares sem gran-
des capacidades de armazenamento e de processamento, mostrando ser apropriado
na implementação em rede local e depois sim na integração com serviços na nuvem,
quando necessário. Isso foi observado pelos estudos de caso, que são pesquisas em
fases iniciais e ainda com poucas amostras a serem disponibilizadas e reutilizadas
Capítulo 5. Discussão 105
pelo público interessado.

A interface web implementada apresentou um acesso informativo às operações
oferecidas pela API, principalmente para usuários que estejam tendo primeiro con-
tato com a implementação. Além disso, a interface Swagger UI apresentou todas as
interações que podem ser realizadas, oferecendo as devidas estruturas HTTP, cabe-
çalhos, códigos e formatos necessários. A partir disso, aplicações externas podem
conhecer a infraestrutura da conexão e suas especificações, facilitando a conexão e
compartilhamento de mensagens.
Baseado na premissa de criação de profiles para especificação dos casos de

uso, foram realizados estudos dos dados adquiridos e armazenados por pesquisas
reais. A partir disso, foram elaborados os perfis dos Recursos necessários e suas
devidas restrições. Com isso, foi possível definir as terminologias necessárias para
a manutenção da semântica de todos os dados. Vale ressaltar que nenhum dado foi
perdido por falta de Resource na documentação.
Com a criação dessa estrutura computacional, por meio das StructureDefiniti-
ons e ValueSets, foi elaborado um pacote lógico que pôde ser integrado ao servidor,
servindo de adição ao interceptador de validação. Dessa forma, todos os dados que
foram enviados, e que estavam em conformidade com os respectivos perfis, foram
validados antes do armazenamento, mostrando a importância da manutenção sintática
e semântica.
Na facilitação ao usuário integrante da solução de interoperabilidade proposta
por este trabalho, foi desenvolvido e publicado um Guia de Implementação que acon-
selha e apresenta as estruturas, perfis, exemplos e as operações dos casos de uso.
Esse IG faz parte da documentação do FHIR, além de ser aconselhado pelo mesmo
para adoção em organizações e aplicações globais.
Como foi observado, o padrão HL7 FHIR está sendo introduzindo no SUS, pelo
Ministério da Saúde, mas ainda está em fases inicias e possui perfis relacionados ao
diagnóstico e imunização contra o COVID-19, demonstrando o poder do protocolo na
utilização por milhares de instituições de saúde. Esses dados servem como base de
dados para a vigilância e controle da pandemia (DEPARTAMENTO DE INFORMÁTICA
DO SUS, 2021b). Além disso, é esperada a colaboração de centros de pesquisas e
universidades na então criada RNDS, abrindo novas oportunidades de contribuição
de informações em maiores bancos de dados de evidências, como o OpenDATASUS
(DEPARTAMENTO DE INFORMÁTICA DO SUS, 2021a). Com isso, toda a estrutura
do IG foi desenvolvida utilizando as mesmas ferramentas utilizadas e recomendadas
pelo Ministério da Saúde.
Como a premissa dos estudos de caso era a validação dos tipos de dados
diversos para um padrão de interoperabilidade, foram realizados estudos dos modelos
de dados de pesquisas reais e criada uma metodologia de mapeamento. A linguagem
Python demonstrou ser uma ótima ferramenta de conversão, desde que haja um bom
uso de referências às terminologias e entre os Recursos.
Também foi destacada a importância da anonimização dos dados, eliminando
todas as informações sensíveis e relacionadas aos voluntários envolvidos nas pesqui-
sas. Essa metodologia se faz necessária após a publicação e vigência da LGPD, que
determina a proteção de dados pessoais pelos órgãos de pesquisa (BRASIL, 2018).
Além disso, foi observado que a lei, por ter sido lançada recentemente e ainda ser muito
abrangente, não alcança com detalhes os tópicos relacionados a saúde, diferente de
outras mundialmente conhecidas, como a HIPAA e a GDPR.
A importância da anonimização de dados foi evidenciada pelos testes iniciais
com dados sintéticos, que geraram registros de saúde em larga escala, de forma
econômica e sem riscos de divulgação acidental, o que reduz as barreiras atuais de
desenvolvimento nos primeiros estágios.
Em relação ao uso de terminologias, foi possível identificar que sistemas de có-
digos como o SNOMED CT e o LOINC possuem termos iguais (e.g., diabetes mellitus),
mas com códigos distintos. Essa problemática evidencia a dificuldade que muitos cená-
rios possuem ao definir um único sistema. Com isso, a proposta elaborou os cenários
utilizando todos os principais sistemas, mesmo com termos semelhantes, tornando as
informações compartilhadas acessíveis para diversas aplicações globais.
Também foi observado que a ANVISA utiliza o WHO-ART em uma versão tra-
duzida, mas não disponibiliza uma publicação da lista de termos e códigos desse
sistema. Essa problemática enfatiza a importância de que implementações futuras, uti-
lizando o FHIR, desenvolvam CodeSystems e ValueSets com as devidas terminologias
padronizadas e com suas definições.
Por fim, como o conceito de mapeamento é abstrato e dependente dos modelos
de dados, observou-se a importância da realização de um estudo preliminar, seguido
da agregação do conversor no próprio software utilizado para coleta, concentração e
armazenamento. No caso de uso do SDC-X, que foi desenvolvido utilizando bibliotecas
Python, houve grande facilidade de integração do mapeador para JSON nas linhas de
código, evitando as conversões futuras, treinamento de pessoal envolvido e dificultando
processos.
5.5 INTERFACE RESTFUL API
A interface RESTful API do servidor proporcionou suporte rápido a todas as

principais operações necessárias para a criação, atualização, exclusão e buscas de
Recursos. As requisições de criação e atualização sempre percorrem o interceptador
de validação, destacando a importância dos Resources estarem sempre em conformi-
dade com o padrão e com os devidos perfis antes de serem armazenados, mantendo a
sintaxe e semântica das estruturas. Quando ocorrido algum erro de validação, o servi-
dor sempre retorna o código de status e maiores informações da localidade das falhas.
Além disso, foi possível realizar diversas pesquisas utilizando consultas complexas e
melhores filtragens por elementos.
Pela exposição da API, foi possível validar a proposta de conexão com outras
aplicações REST e conformantes com o FHIR. Essa característica demonstrou o poder
das aplicações web na interoperabilidade pelo compartilhamento de dados de saúde.
5.6 INTEROPERABILIDADE NA PESQUISA
Não só com o intuito de padronizar a aquisição e armazenamento de dados de

saúde, a proposta demonstrou a importância de compartilhar essas informações de
pesquisa com o público interessado, tornando os dados reutilizáveis, para criação de
maiores amostras e melhores evidências, sem a perda de dados. Essa premissa foi
observada pelo projeto SDC-X, que promete acumular bastante dados fisiológicos e
relacionados ao diagnóstico e acompanhamento do diabetes mellitus. A evolução de
um banco de dados padronizado como esse, poderá alimentar melhores aplicações
de análise de big data e treinamento de IAs.
Observou-se que diversas aplicações já trabalham e aceitam o padrão FHIR,
tais como as ferramentas de análise de big data do OHDSI e do i2b2. Além disso,
tem-se tornado emergente a integração do padrão na recém criada RNDS do sistema
público de saúde brasileiro, que promete o surgimento de serviços de pesquisa para o
benefício da população, além da participação das universidades nos principais eixos
de fomento à inovação (DEPARTAMENTO DE INFORMÁTICA DO SUS, 2020b, 2020c).
Com isso, a proposta trás facilidade às possíveis integrações com serviços de inovação
e melhoramento da saúde pública.
5.7 ANÁLISE NASSS
Baseado no framework NASSS, apresentado anteriormente, foi possível ana-

lisar a proposta deste trabalho pela complexidade dos sete domínios envolvidos e
avaliar as possíveis perspectivas de não adoção, abandono, disseminação e sustenta-
bilidade da proposta. Vale ressaltar que todos os domínios dos estudos de caso estão
condizentes com um ambiente de pesquisa, não comercial e puramente acadêmico. O

formulário detalhado do framework NASSS utilizado pode ser observado no Apêndice
B, com todas as principais questões e suas respostas.
Pelo primeiro domínio, que considera as doenças e condições clínicas envol-
vidas em um projeto de inovação, foi possível compreender que os estudos de caso
abordam uma doença bem definida (i.e., diabetes mellitus) e as condições clínicas
causadas por eventos adversos com produtos médico-hospitalares. Todas essas condi-
ções possuem terminologias apropriadas, mas sintomas podem ser confundidos com
outras patologias, o que pode dificultar um diagnóstico preciso.
A tecnologia envolvida, considerada o segundo domínio, demonstra que a im-
plementação é facilmente definida, seja de onde ela vem e como ela performa. Porém,
ainda é incerto como será sua aceitabilidade no ambiente que ela foi proposta, além
de sua usabilidade e na modificação de rotinas já existentes, o que será observado
em futuros trabalhos. Mesmo assim, as arquiteturas utilizadas são atuais e dificilmente
serão modificadas significativamente nos próximos anos.
Em relação à proposição de valor, o terceiro domínio, foi compreendido que a
proposta possui um valor determinado e seguro aos pacientes, profissionais e aos
sistemas envolvidos, já que impulsiona o compartilhamento de dados e melhoramento
na reutilização dos mesmos por pesquisas que buscam aperfeiçoar diagnósticos e
acompanhamento de doenças, além da melhora da segurança contra eventos adversos
causados por produtos clínicos, todos por meio de acúmulo de evidências.
Os adotantes da tecnologia e inovação desenvolvida, considerados o quarto
domínio, demonstra que o modelo proposto e como será sua adoção é bem definido,
já que é disponibilizado um Guia de Implementação e ferramentas adequadas de API
para adequação ao padrão. Além disso, espera-se que as percepções dos adotantes
e usuários do sistema mude nos próximos anos, já que se observa a adequação de
grandes sistemas ao padrão FHIR, como o proposto pela RNDS no ambiente do SUS.
Pelo quinto domínio, que considera as organizações que implementam a inova-
ção, foi observado que o ambiente acadêmico e de pesquisa, do qual a proposta foi
planejada, possui total capacidade tecnológica e preparo para a tecnologia desenvol-
vida, já que não requer computação especial e onerosa. Porém, é incerto como ela
mudará os atuais processos, já que há a necessidade de desenvolver mapeadores,
atualização de softwares já desenvolvidos e treinamento de pessoal envolvido.
Em relação ao contexto externo da inovação, o sexto domínio do NASSS, notou-
se a importância da proteção dos voluntários envolvidos pela LGPD, sendo uma lei
recém publicada e passível de mudanças nos próximos anos, já que possui cunho
generalizado e com pouco enfoque nos dados de saúde para pesquisa. Além disso, é
esperado mudanças dos padrões e terminologias envolvidas, o que demanda constan-
tes atualizações do Guia de Implementação da proposta.
Já considerando a emergência da implementação ao longo do tempo, o sétimo

e último domínio do framework, tem-se que, por mais que alguns domínios possam
sofrer mudanças nos próximos anos, a proposta continua sendo voltada para cunho de
pesquisa acadêmica, envolvendo tecnologias atuais, com baixa probabilidade de mu-
danças significativas no futuro próximo, e um grande valor de retorno para publicações
voltadas à saúde.
Por fim, pelos estudos de caso de uso em pesquisa na saúde utilizando o
servidor, em conformidade com o padrão FHIR de interoperabilidade, para o compar-
tilhamento e reutilização de dados coletados, foi possível concluir que grande parte
da implementação é previsível, prática e funcional, já que a maioria dos domínios são
mais simples e complicados do que complexos. Essa análise prova que a proposta é
apta a ser uma inovação de possível adoção, disseminação e sustentabilidade.
110
6 CONCLUSÃO
Este trabalho apresentou um modelo implementável de um servidor em confor-

midade com o padrão HL7 FHIR de interoperabilidade de dados relacionados à saúde.
Essa proposta, desenvolvida para sistemas de informação e pesquisa em saúde, com-
plementa a premissa de que os estudos clínicos não precisam ser mais considerados
uma atividade isolada e sim conduzidos em estruturas de redes com troca contínua e
reutilização de dados para eficiência e eficácia operacional.
Os resultados adquiridos demonstram que é possível assim superar o grande
desafio na comparação de dados e resultados de diferentes fontes, ou seja, garantir
que os conjuntos sejam classificados e correspondentes entre si, formando grandes re-
des de dados padronizados de pesquisa, para o avanço médico e melhores resultados
clínicos.
O FHIR se mostrou a solução para a superação das deficiências técnicas dos
padrões de saúde existentes, favorecido pelo crescente poder da computação ubíqua
e dos serviços web. Sendo assim, a performance do servidor mostrou ser bastante
eficaz no armazenamento e requisição de dados de pesquisa em um banco de dados
local, por meio de interface RESTful API. Essa característica proporcionou a habilidade
de compartilhar dados de pesquisas dentro de uma instituição com redes maiores, pela
exposição da API para conexão e na utilização do mesmo padrão pelas plataformas
distintas. Também foi possível realizar a validação dos dados enviados ao servidor,
para verificação do modelo de dados e do uso correto de terminologias de informações
clínicas, ou seja, os dados são garantidos em estruturas de interoperabilidade de
sintaxe e de semântica.
A metodologia de mapeamento demonstrou a facilidade na conversão de mo-
delos de dados existentes para as estruturas de Resources do FHIR. Mesmo sendo
a problemática mais recorrente na adoção do padrão, sua integração mostrou-se ser
bastante acessível com linguagens como o Python e pela integração de conversores
nos softwares.
Por fim, foi possível agregar e estender os serviços do servidor com centenas
de aplicações de código livre disponibilizados na internet, seja para a validação das
funcionalidades do servidor, para a publicação de um Guia de Implementação e para
a segurança dos dados, sem a necessidade de computação avançada e onerosa.
Portanto, esse padrão possui extensa possibilidade de aplicação, seja mobile, serviços
em nuvem e comunicação entre servidores, com grandes atributos em segurança e
velocidade. Com isso, a colaboração, a coerência e a convergência de dados devem
tornar os serviços e as ações desenvolvidas no ecossistema de saúde mais preditivos,
personalizados e interoperáveis.
Capítulo 6. Conclusão 111
6.1 TRABALHOS FUTUROS
Com a implementação tornando-se operacional, algumas propostas de comple-

mentação e otimização do sistema foram levadas em consideração, sendo elas:
• Desenvolver uma plataforma multiusuário com conexão direta à API do ser-
vidor desenvolvido, para acesso aos dados pelos pacientes, profissionais de
saúde e pesquisadores, assim como uma interface para visualização das
informações coletadas para melhores interpretações;
• Realizar testes de reutilização dos dados, quando com mais amostras, em
sistemas de inteligência artificial, machine learning, dentro outras metodolo-
gias que buscam evidências nos dados e melhores resultados;
• Otimizar o Implementation Guide (IG) e publicá-lo no registro oficial de IGs
da HL7;
• Incentivar a adição de novos módulos do Screening for Diabetes Complicati-
ons (SDC-X), para elaboração de um banco de dados mais consistente para
as pesquisas sobre o Diabetes Mellitus;
• Implementar metodologias de segurança mais modernas e eficientes, como
o blockchain e a arquitetura de segurança SMART on FHIR;
• Utilizar as ferramentas de análise de big data, como as oferecidas pela
OHDSI e pelo i2b2, utilizando os dados já no formato FHIR;
• Buscar sempre o melhoramento das complexidades dos domínios da imple-
mentação pela análise do NASSS.
112
REFERÊNCIAS
AGÊNCIA NACIONAL DE VIGILÂNCIA SANITÁRIA. Tecnovigilância. [S.l.], 2021.

Disponível em: https://bit.ly/31JGkdv. Acesso em: 16 ago. 2021.
ALLWELL-BROWN, E. A Comparative Analysis of HL7 FHIR and openEHR for

Electronic Aggregation, Exchange and Reuse of Patient Data in Acute Care. n. 05,
2016.
AMERICAN DIABETES ASSOCIATION. Diagnosis and classification of diabetes

mellitus. Diabetes Care, ADA, v. 29, s43–s47, 2006.
AVENDAÑO, G.; RIENZO, A.; DANYAU, L. Importance of HTA in modern Clinical

Engineering. In: EMBEC and NBC 2017. [S.l.]: Springer, 2017. P. 73–76.
BENDER, D.; SARTIPI, K. HL7 FHIR: An agile and RESTful approach to healthcare
information exchange. Proceedings of CBMS 2013 - 26th IEEE International
Symposium on Computer-Based Medical Systems, p. 326–331, 2013. DOI:
10.1109/CBMS.2013.6627810.
BENSON, T.; GRIEVE, G. Principles of Health Interoperability: FHIR, HL7 and

SNOMED CT. 4. ed. Cham: Springer International Publishing, 2021. v. 44. (Health
Information Technology Standards, 8). DOI: 10.1007/978-3-030-56883-2.
BOSTON CHILDREN’S HOSPITAL; HEALTH LEVEL SEVEN INTERNATIONAL.

SMART Application Launch Framework. [S.l.], 2021. Disponível em:
http://www.hl7.org/fhir/smart-app-launch/. Acesso em: 3 jun. 2021.
BRANDÃO, M. R.; OJEDA, R. G.; COSTA, M. G.; SILVESTRI, C. T.; CHAGAS, M. D.;
CAMPOS, G. G. Clinical Engineering in the analysis of Adverse Events in Medical
Equipment in Brazil. In: INTERNATIONAL Clinical Engineering and Health Technology
Management Congress. Virtual Edition: [s.n.], 2021.
BRASIL. Lei Nº 13.709, de 14 de Agosto de 2018. Diário Oficial da União, 2018.
BRASIL. Portaria Nº 1.434, de 28 de Maio de 2020. Diário Oficial da União, 2020a.
BRASIL. Portaria Nº 1.792, de 17 de Julho de 2020. Diário Oficial da União, 2020b.

REFERÊNCIAS 113
BRAUNSTEIN, M. L. Health Informatics on FHIR: How HL7’s New API is

Transforming Healthcare. Cham: Springer International Publishing, 2018a. DOI:
10.1007/978-3-319-93414-3.
BRAUNSTEIN, M. L. Healthcare in the Age of Interoperability: The Promise of Fast

Healthcare Interoperability Resources. IEEE Pulse, IEEE, v. 9, n. 6, p. 24–27, nov.
2018b. DOI: 10.1109/MPUL.2018.2869317.
CARREIRA, M. et al. Depresión en la diabetes mellitus tipo 1 y factores asociados.

Med. clín, p. 151–155, 2010.
CHANCHAICHUJIT, J.; TAN, A.; MENG, F.; EAIMKHONG, S. Healthcare 4.0.

Singapore: Springer Singapore, 2019. P. 95–121. DOI: 10.1007/978-981-13-8114-0.
COLUMBIA UNIVERSITY. HL7 International and OHDSI Announce Collaboration

to Provide Single Common Data Model for Sharing Information in Clinical Care
and Observational Research. [S.l.], 2021a. Disponível em:
https://www.ohdsi.org/ohdsi-hl7-collaboration/. Acesso em: 15 ago. 2021.
COLUMBIA UNIVERSITY. The Observational Health Data Sciences and

Informatics (OHDSI). [S.l.], 2021b. Disponível em: https://ohdsi.org/. Acesso em:
12 out. 2021.
CREATIVE COMMONS. CC0 1.0 Universal (CC0 1.0) Public Domain Dedication.
[S.l.], 2021. Disponível em: https://creativecommons.org/publicdomain/zero/1.0/.
Acesso em: 17 mai. 2021.
DEPARTAMENTO DE INFORMÁTICA DO SUS. Estratégia de Saúde Digital para o

Brasil 2020-2028. 1. ed. Brasília, DF: Ministério da Saúde, 2020a.
DEPARTAMENTO DE INFORMÁTICA DO SUS. OpenDATASUS. [S.l.], 2021a.

Disponível em: https://opendatasus.saude.gov.br/. Acesso em: 15 ago. 2021.
DEPARTAMENTO DE INFORMÁTICA DO SUS. Plano de Ação, Monitoramento e

Avaliação da Estratégia de Saúde Digital para o Brasil 2019-2023. Brasília, DF:
Ministério da Saúde, 2020b.
REFERÊNCIAS 114
DEPARTAMENTO DE INFORMÁTICA DO SUS. Plano Diretor de Tecnologia da

Informação e Comunicação 2019/2020. v. 5. Brasília, DF: Biblioteca Virtual em
Saúde do Ministério da Saúde, 2020c.
DEPARTAMENTO DE INFORMÁTICA DO SUS. Rede Nacional de Dados em Saúde

Project. [S.l.], 2021b. Disponível em:
https://simplifier.net/RedeNacionaldeDadosemSaude/. Acesso em: 15 set. 2021.
DOCKER. Docker. [S.l.], 2021. Disponível em: https://www.docker.com/. Acesso

em: 16 jul. 2021.
ERICKSON, S. M.; WOLCOTT, J.; CORRIGAN, J. M.; ASPDEN, P. et al. Patient safety:
achieving a new standard for care. National Academies Press, 2003.
FIELDING, R. T. Architectural styles and the design of network-based software

architectures. 2000. F. 162. Tese (Doutorado).
FIRELY. Introduction to FHIR and Profiling. [S.l.], 2021a. Disponível em: https:
//simplifier.net/guide/profilingacademy/IntroductiontoFHIRandprofiling.
Acesso em: 18 ago. 2021.
FIRELY. SIMPLIFIER.NET. [S.l.], 2021b. Disponível em: https://simplifier.net/.

Acesso em: 17 ago. 2021.
FUNDAÇÃO OSWALDO CRUZ. Registro Brasileiro de Ensaios Clínicos (ReBEC).

[S.l.], 2021. Disponível em: https://ensaiosclinicos.gov.br/. Acesso em: 15 ago.
2021.
GESSERT, F.; WINGERATH, W.; RITTER, N. Fast and Scalable Cloud Data
Management. Cham: Springer International Publishing, 2020. DOI:
10.1007/978-3-030-43506-6.
GOOGLE. API Cloud Healthcare. [S.l.], 2021. Disponível em:

https://cloud.google.com/healthcare-api. Acesso em: 10 jul. 2021.
GREENE, D. N.; MCCLINTOCK, D. S.; DURANT, T. J. S. Interoperability: COVID-19 as

an Impetus for Change. Clinical Chemistry, v. 67, n. 4, p. 592–595, mar. 2021. DOI:
10.1093/clinchem/hvab006.
REFERÊNCIAS 115
GREENHALGH, T. How to improve success of technology projects in health and social

care. Public Health Research and Practice, v. 28, n. 3, p. 1–4, 2018. DOI:
10.17061/phrp2831815.
GREENHALGH, T. et al. Beyond Adoption: A New Framework for Theorizing and

Evaluating Nonadoption, Abandonment, and Challenges to the Scale-Up, Spread, and
Sustainability of Health and Care Technologies. Journal of Medical Internet
Research, v. 19, n. 11, nov. 2017. DOI: 10.2196/jmir.8775.
GREENHALGH, T. et al. The NASSS-CAT Tools for Understanding, Guiding,

Monitoring, and Researching Technology Implementation Projects in Health and Social
Care: Protocol for an Evaluation Study in Real-World Settings. JMIR Research
Protocols, v. 9, n. 5, e16861, mai. 2020. DOI: 10.2196/16861.
HAWIG, D.; ZHOU, C.; FUHRHOP, S.; FIALHO, A. S.; RAMACHANDRAN, N.

Designing a Distributed Ledger Technology System for Interoperable and General Data
Protection Regulation–Compliant Health Data Exchange: A Use Case in Blood
Glucose Data. Journal of Medical Internet Research, v. 21, n. 6, e13665, jun. 2019.
DOI: 10.2196/13665.
HEALTH LEVEL SEVEN INTERNATIONAL. Common Data Models Harmonization

FHIR Implementation Guide. [S.l.], 2019. Disponível em:
http://hl7.org/fhir/us/cdmh/2019May/index.html. Acesso em: 15 set. 2021.
HEALTH LEVEL SEVEN INTERNATIONAL. FHIR Release 4. [S.l.], 2021a. Disponível

em: http://hl7.org/fhir/. Acesso em: 18 set. 2021.
HEALTH LEVEL SEVEN INTERNATIONAL. HL7 FHIR ACCELERATOR Program.

[S.l.], 2021b. Disponível em: http://www.hl7.org/about/fhir-accelerator/.
Acesso em: 20 set. 2021.
HEALTH LEVEL SEVEN INTERNATIONAL. HL7 International Website. [S.l.], 2021c.

Disponível em: http://hl7.org/fhir/. Acesso em: 20 set. 2021.
HUSSEY, P.; MCGLINN, K. The Role of Academia in Reorientation Models of

Care—Insights on eHealth. Informatics, v. 6, n. 3, p. 37, set. 2019. DOI:
10.3390/informatics6030037.
REFERÊNCIAS 116
IEEE. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer

Glossaries. IEEE Std 610, p. 1–217, 1991. DOI: 10.1109/IEEESTD.1991.106963.
INFORMATION TECHNOLOGY INDUSTRY COUNCIL. Cloud Healthcare Pledge.

[S.l.], 2018. Disponível em:
https://www.itic.org/public-policy/CloudHealthcarePledge.pdf.
INTERNATIONAL DIABETES FEDERATION. Diabetes Atlas, 9th edn. Brussels,

Belgium. 2019. [S.l.: s.n.], 2019.
JAMES, H. M.; PAPOUTSI, C.; WHERTON, J.; GREENHALGH, T.; SHAW, S. E.

Spread, Scale-up, and Sustainability of Video Consulting in Health Care: Systematic
Review and Synthesis Guided by the NASSS Framework. Journal of Medical
Internet Research, v. 23, n. 1, e23775, jan. 2021. DOI: 10.2196/23775.
KATSAROU, A.; GUDBJORNSDOTTIR, S.; RAWSHANI, A.; DABELEA, D.;

BONIFACIO, E.; ANDERSON, B. J.; JACOBSEN, L. M.; SCHATZ, D. A.;
LERNMARK, Åke. Type 1 diabetes mellitus. Nature reviews Disease primers, Nature
Publishing Group, v. 3, n. 1, p. 1–17, 2017.
KAY, S.; CANGIOLI, G.; NUSBAUM, M. The international patient summary standard
and the extensibility requirement. Studies in Health Technology and Informatics,
v. 273, p. 54–62, 2020. DOI: 10.3233/SHTI200615.
KILINTZIS, V.; CHOUVARDA, I.; BEREDIMAS, N.; NATSIAVAS, P.; MAGLAVERAS, N.

Supporting integrated care with a flexible data management framework built upon
Linked Data, HL7 FHIR and ontologies. Journal of Biomedical Informatics, Elsevier,
v. 94, April, jun. 2019. DOI: 10.1016/j.jbi.2019.103179.
LACKERBAUER, A. M.; KRAUSS, O.; HEARN, J.; HELM, E. A Model for Implementing
an Interoperable Electronic Consent Form for Medical Treatment Using HL7 FHIR.
European Journal for Biomedical Informatics, v. 14, n. 3, p. 37–47, 2018. DOI:
10.24105/ejbi.2018.14.3.4.
LANTANA CONSULTING GROUP. Trifolia-on-FHIR. [S.l.], 2021. Disponível em:

https://trifolia-fhir.lantanagroup.com/. Acesso em: 17 ago. 2021.
LEROUX, H.; METKE-JIMENEZ, A.; LAWLEY, M. J. Towards achieving semantic

interoperability of clinical study data with FHIR. Journal of Biomedical Semantics,
REFERÊNCIAS 117
Journal of Biomedical Semantics, v. 8, n. 1, p. 41, dez. 2017. DOI:

10.1186/s13326-017-0148-7.
LONGARAY, A. A.; CASTELLI, T. M. Avaliação do desempenho do uso da tecnologia

da informação na saúde: revisão sistemática da literatura sobre o tema. Ciência e
Saúde Coletiva, v. 25, n. 11, p. 4327–4338, nov. 2020. DOI:
10.1590/1413-812320202511.26342018.
LYNIATE. clinFHIR Laucher. [S.l.], 2021. Disponível em: http://clinfhir.com/.

Acesso em: 30 set. 2021.
MAHEU, M.; WHITTEN, P.; ALLEN, A. E-Health, Telehealth, and Telemedicine: a

guide to startup and success. [S.l.]: John Wiley & Sons, 2002.
MALIK, S.; KIM, D. A comparison of RESTful vs. SOAP web services in actuator
networks. In: IEEE. 2017 Ninth International Conference on Ubiquitous and Future
Networks (ICUFN). [S.l.: s.n.], 2017. P. 753–755.
MARCOLINO, M. S. et al. A Rede de Teleassistência de Minas Gerais e suas

contribuições para atingir os princípios de universalidade, equidade e integralidade do
SUS - Relato de Experiência. Revista Eletrônica de Comunicação, Informação e
Inovação em Saúde, v. 7, n. 2, 2013.
MARTINEZ, L. C.; SHERLING, D.; HOLLEY, A. The screening and prevention of

diabetes mellitus. Primary Care: Clinics in Office Practice, Elsevier, v. 46, n. 1,
p. 41–52, 2019.
MAXHELAKU, S.; KIKA, A. Improving Interoperability in Healthcare Using HL7 FHIR.

International Academic Conference, International Institute of Social e Economic
Sciences, p. 35–42, 2019. DOI: 10.20472/IAC.2019.047.012.
METKE-JIMENEZ, A.; STEEL, J.; HANSEN, D.; LAWLEY, M. Ontoserver: a syndicated

terminology server. Journal of Biomedical Semantics, Journal of Biomedical
Semantics, v. 9, n. 1, p. 24, dez. 2018. DOI: 10.1186/s13326-018-0191-z.
MICROSOFT. Azure Healthcare APIs. [S.l.], 2021. Disponível em:

https://azure.microsoft.com/services/healthcare-apis/. Acesso em: 30 ago.
2021.
REFERÊNCIAS 118
MICROSOFT HEALTHCARE. Tools for Health Data Anonymization. [S.l.], 2021.

Disponível em:
https://github.com/microsoft/Tools-for-Health-Data-Anonymization. Acesso
em: 11 jun. 2021.
MIRANDA, M.; DUARTE, J.; ABELHA, A.; MACHADO, J. M.; NEVES, J.; NEVES, J.
Interoperability in Healthcare. Proceedings of the European Simulation and
Modelling Conference (ESM 2010), Hasselt, Belgium, 2010.
MITRE CORPORATION. Crucible. [S.l.], 2021a. Disponível em:

https://projectcrucible.org/. Acesso em: 29 set. 2021.
MITRE CORPORATION. Synthea Patient Generator. [S.l.], 2021b. Disponível em:

https://github.com/synthetichealth/synthea. Acesso em: 10 ago. 2021.
NIELSEN, H.; MOGUL, J.; MASINTER, L. M.; FIELDING, R. T.; GETTYS, J.;
LEACH, P. J.; BERNERS-LEE, T. Hypertext Transfer Protocol - HTTP/1.1. [S.l.]: RFC
Editor, jun. 1999. RFC 2616. (Request for Comments, 2616). DOI: 10.17487/RFC2616.
OEMIG, F.; SNELICK, R. Healthcare Interoperability Standards Compliance

Handbook. Cham: Springer International Publishing, 2016. P. 1–662. DOI:
10.1007/978-3-319-44839-8.
OPENEHR FOUNDATION. openEHR. [S.l.], 2021. Disponível em:

https://openehr.org/. Acesso em: 24 jul. 2021.
PATIENT CARE WORK GROUP. International Patient Summary Implementation

Guide. [S.l.], 2020. Disponível em: http://hl7.org/fhir/uv/ips/. Acesso em: 9 ago.
2021.
PFAFF, E. R. et al. Fast Healthcare Interoperability Resources (FHIR) as a Meta Model

to Integrate Common Data Models: Development of a Tool and Quantitative Validation
Study. JMIR Medical Informatics, v. 7, n. 4, e15199, out. 2019. DOI: 10.2196/15199.
PLSEK, P. E.; GREENHALGH, T. Complexity science: The challenge of complexity in

health care. BMJ, v. 323, n. 7313, p. 625–628, set. 2001. DOI:
10.1136/bmj.323.7313.625.
REFERÊNCIAS 119
POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL. [S.l.: s.n.], 2021.

Disponível em: https://www.postgresql.org/. Acesso em: 12 mar. 2021.
PYTHON SOFTWARE FOUNDATION. Python. [S.l.], 2021a. Disponível em:

https://www.python.org/. Acesso em: 19 mai. 2021.
PYTHON SOFTWARE FOUNDATION. The Python Standard Library. [S.l.], 2021b.

Disponível em: https://docs.python.org/3/library/. Acesso em: 10 mar. 2021.
QIU, D.; LI, B; LEUNG, H. Understanding the API usage in Java. Information and
Software Technology, v. 73, p. 81–100, 2016. DOI: 10.1016/j.infsof.2016.01.011.
RAD, B. B.; BHATTI, H. J.; AHMADI, M. An introduction to docker and analysis of its
performance. International Journal of Computer Science and Network Security,
International Journal of Computer Science e Network Security, v. 17, n. 3, p. 228,
2017.
RED HAT. Keycloak. [S.l.], 2021. Disponível em: https://www.keycloak.org/.

Acesso em: 2 jun. 2021.
REGENSTRIEF INSTITUTE. LOINC. [S.l.], 2021a. Disponível em:

https://loinc.org/. Acesso em: 3 mar. 2021.
REGENSTRIEF INSTITUTE. The Unified Code for Units of Measure. [S.l.], 2021b.
Disponível em: https://ucum.org/. Acesso em: 2 mar. 2021.
ROGERS, R.; PERES, Y.; MULLER, W. Living longer independently–a healthcare

interoperability perspective. Elektrotechnik und Informationstechnik, Springer,
v. 127, n. 7-8, p. 206–211, 2010.
SANZANA, M. G.; DURRUTY, P. Otros tipos específicos de diabetes mellitus. Revista

Médica Clínica Las Condes, Elsevier, v. 27, n. 2, p. 160–170, 2016.
SARIPALLE, R. K. Fast Health Interoperability Resources (FHIR): Current Status in the

Healthcare System. International Journal of E-Health and Medical
Communications, v. 10, n. 1, p. 76–93, 2019. DOI: 10.4018/IJEHMC.2019010105.
SAUERMANN, S.; DAVID, V.; SCHLOGL, A.; EGELKRAUT, R.; FROHNER, M.;
POHN, B.; URBAUER, P.; MENSE, A. Biosignals, standards and FHIR - The way to
REFERÊNCIAS 120
go? Studies in Health Technology and Informatics, v. 236, p. 356–362, 2017. DOI:
10.3233/978-1-61499-759-7-356.
SHORTLIFFE, E. H.; CIMINO, J. J. Biomedical Informatics: Computer

Applications in Health Care and Biomedicine. Edição: Edward H. Shortliffe e
James J. Cimino. Fourth. London: Springer London, 2014. DOI:
10.1007/978-1-4471-4474-8.
SMARTBEAR SOFTWARE. OpenAPI Specification. [S.l.], 2021. Disponível em:

https://swagger.io/specification/. Acesso em: 13 jul. 2021.
SMILE CDR. HAPI FHIR. [S.l.], 2021. Disponível em: https://hapifhir.io/. Acesso
em: 17 out. 2021.
SNOMED INTERNATIONAL. SNOMED CT. [S.l.], 2021. Disponível em:

https://www.snomed.org/. Acesso em: 4 mar. 2021.
SOCIETY FOR IMAGING INFORMATICS IN MEDICINE. SIIM Hackathon Dataset.

https://github.com/ImagingInformatics/hackathon-dataset. Acesso em: 10 ago.
2021.
SOLBRIG, H. R.; PRUD’HOMMEAUX, E.; GRIEVE, G.; MCKENZIE, L.;

MANDEL, J. C.; SHARMA, D. K.; JIANG, G. Modeling and Validating HL7 FHIR
Profiles Using Semantic Web Shape Expressions (ShEx). Journal of Biomedical
Informatics, v. 67, p. 90–100, 2017. DOI: 10.1016/j.jbi.2017.02.009.
TERRA, T. G. Software de Gerenciamento, Análise e Detecção Precoce da

Disfunção Autonômica em Indivíduos com Diabetes Mellitus. 2020. Dissertação
de Mestrado – Universidade Federal de Santa Catarina.
TESFAYE, S.; WU, J. Diabetic neuropathy. In: THE Diabetic Foot. [S.l.]: Springer, 2018.
P. 31–46.
THE BIOMEDICAL DATA TRANSLATOR CONSORTIUM. Toward A Universal

Biomedical Data Translator. Clinical and Translational Science, v. 12, n. 2, p. 86–90,
mar. 2019. DOI: 10.1111/cts.12591.
REFERÊNCIAS 121
THOMPSON, T. G.; BRAILER, D. J. The decade of health information technology:

delivering consumer-centric and information-rich health care. US Department of
Health and Human Services, Citeseer, 2004.
TRANSMART FOUNDATION. Informatics for Integrating Biology and the Bedside

(i2b2). [S.l.], 2021. Disponível em: https://www.i2b2.org/. Acesso em: 19 ago. 2021.
UCKER, M. Desenvolvimento de sistema point-of-care de pupilometria dinâmica

aplicado no screening da Neuropatia Autonômica Diabética. 2020. Dissertação
de Mestrado – Universidade Federal de Santa Catarina.
UCKER, M.; COSSUL, S.; FAVRETTO, M. A.; LOPES, L. B.; TERRA, T. G.;
FRANCO, M. V. B.; MARQUES, J. L. B. Desenvolvimento de um sistema de aquisição
de imagens de pupilometria dinâmica utilizando módulos OpenMV, set. 2019. DOI:
10.5281/zenodo.3461153.
US REALM STEERING COMMITTEE. HL7 FHIR® US Core Implementation Guide

STU3 Release 3.1.1. [S.l.], 2020. Disponível em:
https://www.hl7.org/fhir/us/core/. Acesso em: 5 abr. 2021.
VALENCIA, W. M.; FLOREZ, H. How to prevent the microvascular complications of

type 2 diabetes beyond glucose control. BMJ, British Medical Journal Publishing
Group, v. 356, 2017. DOI: 10.1136/bmj.j1018.
WALONOSKI, J. et al. Synthea: An approach, method, and software mechanism for

generating synthetic patients and the synthetic electronic health care record. Journal
of the American Medical Informatics Association, v. 25, n. 3, p. 230–238, mar.
2018. DOI: 10.1093/jamia/ocx079.
WEBER, G. M.; MANDL, K. D.; KOHANE, I. S. Finding the Missing Link for Big
Biomedical Data. JAMA, v. 311, n. 24, p. 2479–2480, mai. 2014. DOI:
10.1001/jama.2014.4228.
WORLD HEALTH ORGANIZATION. Classification of diabetes mellitus. World Health

Organization, 2019.
WORLD HEALTH ORGANIZATION. International Clinical Trials Registry Platform.

REFERÊNCIAS 122
https://www.who.int/clinical-trials-registry-platform. Acesso em: 16 ago.

2021.
WORLD HEALTH ORGANIZATION; INTERNATIONAL TELECOMMUNICATION

UNION. Digital Health Platform Handbook: Building a Digital Information
Infrastructure (Infostructure) for Health. Geneva: [s.n.], 2020.
WU, H.; YANG, S.; HUANG, Z.; HE, J.; WANG, X. Type 2 diabetes mellitus prediction
model based on data mining. Informatics in Medicine Unlocked, Elsevier, v. 10,
p. 100–107, 2018.
ZHANG, P.; WHITE, J.; SCHMIDT, D. C.; LENZ, G.; ROSENBLOOM, S. T. FHIRChain:
Applying Blockchain to Securely and Scalably Share Clinical Data. Computational
and Structural Biotechnology Journal, The Authors, v. 16, p. 267–278, 2018. DOI:
10.1016/j.csbj.2018.07.004.
123
APÊNDICE A – RESOURCES PRESENTES NA DOCUMENTAÇÃO E SUAS

CATEGORIAS
124
APÊNDICE B – ANÁLISE DA PROPOSTA PELO FRAMEWORK NASSS

APÊNDICE B. Análise da proposta pelo framework NASSS 125
APÊNDICE B. Análise da proposta pelo framework NASSS 126
127
ANEXO A – ESQUEMA DE INDEXAÇÃO PARA PESQUISA NO BANCO DE

DADOS
Fonte – Smile CDR (2021).

Peel2056 D

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

Peel2056 D

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DE SANTA CATARINA

Igor Oliveira Vieira

Estruturação e Implantação de um Servidor de Sistema de Informação em

Estruturação e Implantação de um Servidor de Sistema de Informação em

Dissertação submetida ao Programa de Pós-Graduação

Vieira, Igor Oliveira

Dissertação (mestrado) - Universidade Federal de Santa

1. Engenharia Elétrica. 2. Interoperabilidade. 3.

Estruturação e Implantação de um Servidor de Sistema de Informação em

O presente trabalho em nível de mestrado foi avaliado e aprovado por banca

Alexandre Savaris, Dr.

Prof. Renato Garcia Ojeda, Dr.

Prof. Telles Brunelli Lazzarin, Dr.

Prof. Jefferson Luiz Brum Marques, PhD

Agradeço, primeiramente, ao meu orientador, professor Dr. Jefferson Luiz Brum

VIEIRA, I. O.; MARQUES, J. L. B. Proposta de um Servidor de Dados em Pesquisa

VIEIRA, I. O.; FRANCISCO, M.; NETO, J. M.; OJEDA, R. G.; MARQUES, J. L. B.

A pesquisa clínica tem um papel fundamental na geração de evidências e na melhoria

Palavras-chave: HL7 FHIR. Sistema de Informação em Saúde. Pesquisa Clínica.

Figura 1 – Interfaces de comunicação de dados entre sistemas distintos sem

Quadro 1 – Principais padrões adotados pela Tecnologia da Informação na

ANVISA Agência Nacional de Vigilância Sanitária

A pesquisa na saúde desempenha um papel fundamental no avanço médico e

e a interoperabilidade para compartilhamento das informações. Logo, a colaboração,

1.1 MOTIVAÇÃO E JUSTIFICATIVA

A comunidade acadêmica fornece um ecossistema de reflexão e de criação

2020; UCKER et al., 2019; UCKER, 2020).

Nas seções abaixo estão descritos o objetivo geral e os objetivos específicos

1.2.1 Objetivo Geral

Desenvolver um servidor HL7 FHIR de interoperabilidade para apoio aos dados

1.2.2 Objetivos Específicos

Para cumprir o objetivo geral, foram definidos os seguintes objetivos específicos:

Neste capítulo é apresentada a fundamentação teórica que embasa a execução

2.1 INTEROPERABILIDADE NA PESQUISA EM SAÚDE

A pesquisa clínica conduz um papel fundamental na geração de evidência, que

Figura 1 – Interfaces de comunicação de dados entre sistemas distintos sem protocolo

Fonte – Elaborado pelo autor (2021).

ções significativas e iniciar ações e operações em conjunto, gerando benefício mútuo

2.2 PARADIGMAS DE INTEROPERABILIDADE

A complexidade da interoperabilidade pode ser explorada em 3 paradigmas

2.2.1 Interoperabilidade de Transporte

A forma mais simples e fácil de transferência de dados entre sistemas, onde

2.2.2 Interoperabilidade de Estrutura

2.2.3 Interoperabilidade de Semântica

É o nível mais alto de interoperabilidade, onde os dados necessitam ser su-

dados de um paciente para a análise e recomendações de diagnósticos e tratamen-

2.3 MODELO ISO/OSI

Outro aspecto importante relacionado à interoperabilidade está no chamado Mo-

Figura 2 – Modelo ISO/OSI no processo de comunicação entre duas aplicações.

Fonte – Adaptado de Oemig e Snelick (2016).

2.3.1 Application Programming Interface

As especificações de interoperabilidade podem ser abordadas pelos seguintes

das, deixando aos implementadores a vinculação de tecnologias (BENSON; GRIEVE,

2.3.2 Representational State Transfer

A Representational State Transfer (REST) foi primeiramente apresentada por

• Cliente e Servidor: os clientes não se preocupam com o armazenamento

2.4 PADRÕES DE INTEROPERABILIDADE NA SAÚDE

A Tecnologia da Informação na Saúde, Health Information Technology (HIT),

Quadro 1 – Principais padrões adotados pela Tecnologia da Informação na Saúde.

Formato dos Dados Terminologia Conteúdo EHR Transação

2021a; OPENEHR FOUNDATION, 2021). Em suma, os dois padrões são considera-

Quadro 2 – Comparação entre os padrões de comunicação HL7 FHIR e openEHR.

HL7 FHIR openEHR