TCC_Interoperabilidade no desenvolvimento de software para a saúde

Prévia do material em texto

Abstract— The complexity involved in the processes of 
healthcare requires a definition of an interoperability standards 
to enable the implementation of information systems capable of 
exchanging information and knowledge. The definition of which 
standard to apply is a challenge for software developers, since 
there is no global definition for all healthcare sectors. Thus, this 
article presents a bibliographic study of patterns more consumed 
by the market and by health institutions in order to indicate 
which technologies and standards are used in the development of 
software applications for the different needs of healthcare. 
Similarly presents the solutions and standards set by the Ministry 
of Health for the development of systems used by the Sistema 
Ùnico de Saúde – SUS. 
Index Terms— eHealth, FHIR, Information System, 
Interoperability, openEHR, Standard. 
Resumo— A complexidade que envolve os processos da área da 
saúde exige que padrões de interoperabilidade sejam definidos, 
para viabilizar a implementação de sistemas de informação 
capazes de trocar informações e consequentemente conhecimento. 
A definição de que padrão aplicar é um desafio para os 
desenvolvedores de software, uma vez que, não há uma definição 
global para todos os setores da saúde. Assim, este artigo realiza 
um estudo bibliográfico dos padrões mais consumidos pelo 
mercado e pelas instituições de saúde, a fim de indicar quais 
tecnologias e padrões se utilizar no desenvolvimento de aplicações 
de software para as diferentes necessidades da área da saúde. Do 
mesmo modo são apresentadas as soluções e padrões definidos 
pelo Ministério da Saúde para o desenvolvimento de sistemas 
utilizados pelo Sistema Único de Saúde – SUS. 
Palavras chave— eSaúde, FHIR, Interoperabilidade, Padrão, 
openEHR, Sistemas de Informação. 
I. INTRODUÇÃO 
A informatização dos processos e o desenvolvimento de 
sistemas de informação para a área da saúde, também 
conhecidos como eSaúde (acrônimo para saúde eletrônica) 
vem crescendo substancialmente ao longo dos anos segundo a 
Sociedade Brasileira de Informática em Saúde - SBIS [1]. 
A natureza distribuída do domínio da saúde intensifica a 
complexidade dos seus processos dificultando as relações e a 
troca de informação. Sendo assim, a comunicação é o requisito 
principal para possibilitar e viabilizar a troca de experiências e 
do conhecimento adquirido [2]. 
O número da coleção de termos clínicos ultrapassa os 
450.000 com mais de 1 milhão de relações. Estes 
 
Trabalho de Conclusão de Curso apresentado ao Instituto Nacional de 
Telecomunicações, como parte dos requisitos para a obtenção do Certificado 
de Pós-Graduação em Engenhara Clínica e Engenharia Biomédica. 
Orientador: Prof. Marco Túlio Perlato. Trabalho aprovado em XX/20XX. 
números continuam em crescimento: 
• Em tamanho devido às novas descobertas; 
• Em profundidade conforme mais detalhes se 
tornam relevantes; 
• Em complexidade quando novas relações entre os 
dados são encontradas [3]. 
Com este cenário exige-se a definição de padrões de 
interoperabilidade para possibilitar que os sistemas de 
informação sejam capazes de se relacionar e apoiar a atenção 
aos pacientes. Em todo o mundo há diferentes propostas e 
definições para formatar as interações entre sistemas, porém 
não há uma padronização capaz de atender a todos os 
requisitos que permeiam a heterogeneidade dos países e de 
seus órgãos de saúde. 
Diversos padrões foram elaborados e testados nas últimas 
décadas para solucionar os problemas de interoperabilidade 
semântica e sintática. Deste modo, definir um padrão para 
iniciar o desenvolvimento de um software voltado ao domínio 
da saúde é uma tarefa árdua e suscetível ao fracasso, ou por 
não atender a todos os interessados ou por não alcançar em 
plenitude o imenso universo de conceitos e significados dos 
seus modelos de dados. Pois, o simples fato de se iniciar um 
projeto de software já envolve atividades difíceis de serem 
definidas e estimadas, o que afeta diretamente a qualidade dos 
produtos desenvolvidos e dos objetivos definidos. 
Sendo assim, analisar as propostas dos padrões mais 
consumidos universalmente e no Brasil é relevante. Neste 
contexto, pretende-se verificar e destacar os aspectos técnicos 
dos padrões existentes para promoção da interoperabilidade, e 
assim, definir-se qual ou quais se utilizar no desenvolvimento 
de sistemas de informação para a saúde. 
No decorrer deste trabalho serão definidos os conceitos e 
propósitos dos dois níveis de interoperabilidade e exposta as 
características dos padrões HL7 FHIR e openEHR, os quais 
vem se destacando pela adoção em diversos países e 
instituições de saúde, e que buscam acompanhar as novas 
tecnologias de desenvolvimento de software. Ao término do 
referencial teórico é apresentado um resumo das definições do 
Ministério da Saúde para a interoperabilidade dos sistemas de 
informação do SUS. 
II. OBJETIVOS 
A. Objetivo Geral 
O objetivo geral do trabalho é analisar as referências 
bibliográficas referentes aos padrões de informação e 
Interoperabilidade no Desenvolvimento de 
Software para a Saúde 
Marco Túlio Perlato & Leandro de Carvalho Maia 
 
interoperabilidade utilizados na construção de sistemas de 
informação para a área da saúde. 
B. Objetivos Específicos 
Identificar os padrões atuais de interoperabilidade utilizados 
pelas empresas e instituições de saúde. 
Indicar qual ou quais destes padrões devem ser aplicados no 
desenvolvimento de softwares para a área da saúde, de acordo 
com o presente cenário da tecnologia da informação. 
III. JUSTIFICATIVA 
Os modelos de dados da área da saúde são extremamente 
complexos e evoluem cada vez mais por meio impresso e 
muito mais rapidamente por meio digital. Há décadas são 
elaborados padrões de interoperabilidade para facilitar o 
compartilhamento de informação, mas de certa forma, nenhum 
destes conseguiu em sua plenitude cobrir todos os requisitos 
necessários. 
Sendo assim, este trabalho se justifica por realizar uma 
análise bibliográfica de um cenário sem definição ou consenso 
por parte das instituições de saúde e órgãos regulamentadores 
ligados às indústrias da saúde, de que padrão devem utilizar os 
desenvolvedores de software na criação de sistemas de 
informação para a área da saúde. Esta indefinição inviabiliza a 
implementação e entrega de novas soluções para a área da 
saúde, e até mesmo, que novos projetos de eSaúde sejam 
iniciados. 
IV. A INTEROPERABILIDADE 
O processo de informatização dos processos de negócios e 
das relações humanas, através do uso das tecnologias da 
informação e comunicação – TIC, “como nos mais diversos 
setores da sociedade, também gera reflexos importantes na 
área da saúde” [4]. 
O uso de TIC na saúde tem crescido nas últimas três 
décadas, com presença nos mais diversos setores e atividades 
dos agentes de saúde, não apenas utilizados na administração 
de unidades, como hospitais e clínicas, mas também no 
cadastro de pacientes, exames laboratoriais, gestão de recursos 
utilizados na saúde pública, e nos aplicativos que dão suporte 
para um melhor e mais seguro atendimento ao paciente. “Todo 
esse processo de informatização da Saúde nos leva ao conceito 
de e-Saúde” [4]. 
Ao lado deste crescimento abrangente, novos problemas são 
gerados. A inexistência de uma padronização nos processos de 
informatização e a implantação de sistemas de forma isolada 
acarreta na replicação de dados, inviabiliza a interação entre 
os sistemas, e com isso, têm-se perca de tempo e a 
impossibilidade de se extrair informações a partir da 
integração entre os dados. 
Possibilitar que sistemas de informação complexos, 
projetados de forma única e com objetivos distintos possam se 
integrar e beneficiar das especialidades de cada um só é 
possível atravésda padronização dos seus modelos de dados e 
de como os transmitem e os interpretam. É para este propósito 
que se define a interoperabilidade como a habilidade de dois 
ou mais sistemas (computadores, meios de comunicação, 
redes, software e outros componentes de tecnologia da 
informação) de interagir e de intercambiar dados de acordo 
com um método definido, de forma a obter os resultados 
esperados [5]. 
Diferente do processo de integração que busca permitir que 
sistemas de informação comuniquem-se de forma eficiente 
reunindo as partes relacionadas, a interoperabilidade é um 
processo mais complexo, pois propõe que dois ou mais 
sistemas compartilhem seus recursos dentro de suas fronteiras 
organizacionais, possibilitando que as mesmas informações 
possam ser interpretadas e compreendidas de ambos os lados. 
Interoperabilidade não é somente integração de 
sistemas nem somente integração de redes. Não 
referencia unicamente troca de dados entre sistemas e 
não contempla simplesmente definição de tecnologia. 
É, na verdade, a soma de todos esses fatores, 
considerando, também, a existência de um legado de 
sistemas, de plataformas de hardware e software 
instaladas. Parte de princípios que tratam da 
diversidade de componentes, com a utilização de 
produtos diversos de fornecedores distintos. Tem por 
meta a consideração de todos os fatores para que os 
sistemas possam atuar cooperativamente, fixando as 
normas, as políticas e os padrões necessários para 
consecução desses objetivos. [6]. 
No entanto, a efetivação deste processo “pode acontecer em 
diferentes níveis, a saber: nível de hardware, de plataforma, 
sintático e semântico” [7]. Neste artigo trabalhou-se o estudo 
dos níveis sintáticos e semânticos, que serão descritos a seguir: 
A. Interoperabilidade Sintática 
Também definida na literatura, por alguns autores, como 
interoperabilidade funcional, a interoperabilidade sintática 
define as regras de como os dados devem ser escritos, como 
também, a padronização de assinaturas de operações no 
compartilhamento de informação entre sistemas. Para isso, faz-
se necessário definir formatos de documentos para a notação 
de dados como: XML, JSON ou SQL [8]. 
B. Interoperabilidade Semântica 
A interoperabilidade semântica corresponde à capacidade 
das informações serem compreendidas por sistemas distintos e 
heterogêneos. Opera nos níveis de interpretação e 
entendimento comum dos dados, os quais são sustentados pela 
interoperabilidade sintática [7]. 
V. PADRÕES DE INTEROPERABILIDADE PARA A ESAÚDE 
 Os sistemas de informação para a área da saúde cresceram 
rapidamente nas últimas décadas. Partiram de sistemas 
hospitalares isolados para sistemas que suportam os processos 
clínicos, integrados com equipamentos médicos utilizados por 
múltiplos profissionais e instituições de saúde, abraçando os 
avanços computacionais e providos de diferentes ambientes 
interconectados. Com um cenário tão interativo como este, se 
faz necessário analisar como é realizado o compartilhamento 
da informação entre estes sistemas de informação da saúde, 
uma vez que, o trabalho dos profissionais da saúde e a 
qualidade dos serviços prestados aos pacientes estão 
 
intrinsicamente ligados ao quanto disponível e correto são os 
dados compartilhados entre estas aplicações [9]. 
Com isso, têm surgido diversas soluções e padrões para as 
questões de interoperabilidade, demonstrando não haver uma 
solução capaz de contemplar todos os requisitos da eSaúde. 
Mesmo em países com grande adoção da tecnologia 
da informação – TI na área da saúde, como os EUA, 
encontra-se ilhas com avançadas soluções 
tecnológicas, porém com pouca interconectividade. 
Isto significa que um relatório completo das 
informações da saúde não pode ser acessado e nem 
conhecido por outros prestadores de serviços durante 
a jornada de um paciente [10]. 
Embora o objetivo final seja estabelecer um padrão único e 
compreensível para todos os usuários, nenhum dos padrões 
disponíveis atualmente foi definido por um órgão mundial 
regulamentador. Assim, uma grande diversidade de padrões 
são consumidos e utilizados, atendendo especificamente as 
necessidades e localização de cada instituição ou órgão de 
saúde [10]. 
Há uma proliferação de padrões dos quais podemos citar: 
Logical Observations Identifiers Names and Codes - LOINC, 
RxNORM (Padronização da terminologia para drogas), 
ASTM Continuity of Care Record - CCR, Systematized 
Nomenclature of Medicine Clinical Terms - SNOMED CT, 
Unified Modelling Language System – UMLS e as mais 
empregadas mundialmente: Health Level Seven - HL7 
(V2/V3, CDA/CCD e a mais recente FHIR), ISO/EN 13606 e 
openEHR [2]. 
Esta grande diversidade de padrões demonstra o interesse 
por parte dos fornecedores de eSaúde em integrar suas 
aplicações. Porém, o que acontece atualmente é a utilização de 
muitas propostas de padrões no intercâmbio funcional e 
semântico das informações, provocando dispêndio de tempo e 
elevação dos custos para integração de sistemas de software. 
Além do mais, o desenvolvimento de sistemas adotando-se 
mais de um padrão de interoperabilidade eleva o tempo para 
correções de falhas e atualizações destes sistemas, o que 
também impossibilita a construção de novas soluções capazes 
de consumir os recursos de aplicações já em utilização. 
Correspondendo aos objetivos e justificativas deste 
trabalho, nos próximos itens apresenta-se os padrões HL7 
FHIR e o openEHR. 
VI. HL7 FHIR 
A Health Level 7 – HL7 é uma organização internacional 
sem fins lucrativos, dedicada à definição e criação de padrões 
para a área da saúde. 
Fundada em 1987 e acreditada em 1994 pela American 
National Standards Institute - ANSI, o HL7 busca prover um 
framework legível para o compartilhamento, troca, integração 
e busca de dados em sistemas de informação da saúde, 
cooperando com o gerenciamento, prestação e avaliação dos 
serviços da saúde [11]. 
O termo “Level 7” é uma referência a sétima camada do 
padrão Open Systems Interconnection - OSI definido pela 
ISO, o mais alto nível do modelo de comunicação. Com isso, 
busca ser uma camada de aplicação integrada ao transporte de 
dados e a compreensão das informações enviadas. “O sétimo 
nível suporta funções como checagem de segurança, 
identificação de usuários, checagem de disponibilidades, 
mecanismos de negociação de trocas, e o mais importante, 
estrutura de intercambio de informações” [11]. 
Atualmente o HL7 é uma comunidade internacional 
composta por especialistas em sistemas de informação da 
saúde para a colaboração no desenvolvimento de padrões de 
interoperabilidade. O HL7 define normas e padrões para trocas 
de mensagens entre sistemas (interoperabilidade sintática), 
como também, normas para a estruturação de documentos 
gerados pelos agentes e sistemas da saúde (interoperabilidade 
semântica) [12]. 
Os processos e normas para troca de mensagens HL7 estão 
disponíveis sobre os padrões HL7 version 2.x, HL7 version 3 e 
a última geração denominada HL7 FHIR [12]. A partir da 
segunda versão o HL7 tornou-se o padrão mais utilizado 
mundialmente. Atualmente o padrão encontra-se na terceira 
versão, porém, esta não obteve grande aceitação pelos 
desenvolvedores de software, pela falta de compatibilidade 
entre as versões, elevada complexidade da estrutura para 
atender as ações e situações clínicas e principalmente pela 
falta de documentação [11]. Contudo, a comunidade envolvida 
com os padrões HL7 é grande, instituições ligadas à 
mantenedora HL7.ORG estão presentes em vários países, o 
que promove a busca por atualizações que atendam aos 
problemas atuais da informática no domínio da saúde, como 
também, a divulgação e disseminação do uso destes padrões. 
Este trabalho enfoca o padrão FHIR, o qual combina as 
melhores caraterísticas dos padrões HL7 v2.x e HL7v3 com os 
mais recentes padrões web. 
A. FHIR 
Visando comtemplar necessidades de implementação do 
protocolo HL7 v3, um grupo independente de arquitetos do 
HL7 decidiu criar um novo modelo de interoperabilidade de 
sistemas eletrônicos de saúde, denominado Fast Healthcare 
Interoperability Resources – FHIR (pronunciado como HL7 
“Fire”). Disponibilizando a primeira versão em 2012 propôs-
se desenvolver um novo padrão utilizando-se dos recursos 
tecnológicos disponíveis no momento e o know-how adquirido 
ao longo dos anos com as outras versões do HL7[13]. 
O FHIR é disponibilizado de forma gratuita e busca 
simplificar e acelerar a aplicação do HL7, por ser facilmente 
consumido, robusto e construído sobre padrões abertos da 
internet, fazendo uso dos princípios do RESTful [12]. 
O Representational State Transfer – REST (acrônimo para 
"Transferência de Estado Representacional") não é um 
padrão, não é um protocolo e sim uma arquitetura de software 
operada sobre a rede, explicitamente através do protocolo 
Hypertext Transfer Protocol – HTTP para troca e envio de 
dados [14]. A arquitetura RESTful disponibiliza suas 
aplicações web como um conjunto de recursos que através dos 
verbos HTTP transfere ou altera seu conteúdo por meio de 
representações dos recursos em documentos XML, JSON ou 
ambos. O RESTful recentemente foi adotado por grandes 
provedores de serviços da WorldWideWeb – WWW, como 
Google, Microsoft, Facebook e Twitter, que migraram suas 
plataformas de serviço que utilizavam outras tecnologias como 
 
SOAP e WSDL. E assim, beneficia-se de recursos 
amplamente aplicados e testados, garantindo a plataforma 
visibilidade, confiabilidade e estabilidade [14]. 
 
 
Figura 1 - Dado de um paciente em formato XML gerado pelo FHIR 
 
Apesar de ser um novo padrão HL7, com caraterísticas 
distintas “os autores afirmam que HL7 v3 não foi jogado fora, 
mas que o FHIR foi criado através da aprendizagem desta 
versão” [12]. E seguindo esta filosofia o FHIR foi projetado 
para ser facilmente compreendido e aplicado, com tipos de 
modelo de dados simplificados, diferente do HL7 v3, que 
possui no mínimo três tipos principais, definidos como 
Wrapper, Payloads e Common Message Element Types 
(CMETs). O padrão também conta com exemplos de 
implementação de todos os seus artefatos e disponibilizados 
em várias plataformas, fornecendo um servidor online para 
testes [12]. 
O seu processo de desenvolvimento difere-se dos processos 
rígidos e engessados do HL7 v2 e HL2 v3, utilizando-se das 
metodologias ágeis de desenvolvimento de software, que prega 
teorias voltadas para os indivíduos e interações ao invés de 
processos, e para software funcionando ao invés de 
documentação abrangente. E assim, seus requisitos são 
desenvolvidos de forma iterativa e incremental, entregando 
pequenas funcionalidades por vez, as quais são testadas, 
utilizadas e avaliadas através de processos de feedback, 
contribuindo com a qualidade do processo de 
desenvolvimento, como também, dos artefatos 
disponibilizados para seus usuários [12]. 
Sendo assim, pode-se afirmar que o padrão FHIR não está 
pronto, estando em processo contínuo de desenvolvimento e 
de atualização. Por este motivo o HL7 FHIR é disponibilizado 
em versão Draft Standard for Trial Use – DSTU, ou seja, 
versão para “testes de uso” de um padrão HL7. Válida por dois 
anos, esta versão é consumida e testada por empresas e 
instituições, que podem requisitar atualizações, as quais 
poderão ser aplicadas em tempo hábil. Após este período, a 
versão em DSTU torna-se uma versão normativa. E em 
Fevereiro de 2014, após um processo de votação, a primeira 
versão DSTU do FHIR foi normatizada e considerada como 
usável [13]. 
A proposta principal do desenvolvimento do FHIR é 
compartilhar as informações de um sistema de informação da 
saúde como um recurso e suas composições. Cada recurso 
deve representar a menor parte possível da informação como 
uma entidade, identificada de forma única. Também se pode 
classificar um recurso como a menor parte lógica na troca de 
informações, a qual define comportamento e significado com 
localização e identificação conhecidos [14]. 
Para se localizar um recurso deve-se acessá-lo através do 
seu endereço na rede, fornecido como uma URL (Uniform 
Resource Locator). A Figura 2 apresenta como deve ser 
construído o endereçamento de um recurso Paciente, 
obedecendo a arquitetura RESTful. 
 
 
Figura 2 - Padrão de URL para o recurso Paciente 
 
Utilizando-se dos verbos HTTP: POST, GET, PUT e 
DELETE, as operações realizadas sobre os recurso são 
relativamente fixas, determinadas pelo acrônimo CRUDS: 
[C]reate: criar um novo recurso. 
[R]etrieve: obter um recurso. 
[U]pdate: atualizar um recurso. 
[D]elete: eliminar um recurso. 
[S]earch: buscar um recurso [11]. 
 Sendo assim, se pretender criar um recurso paciente, devem-
se enviar seus dados formatados em documentos XML e/ou 
JSON, através do verbo CREATE, o qual obtendo sucesso irá 
retornar o ID (identificador único) do novo paciente. Mas caso 
o objetivo for recuperar um recurso conhecido, deve-se utilizar 
o verbo GET enviando o seu ID. O mesmo processo se faz ao 
atualizar, remover ou recuperar um recurso, utilizando-se 
respectivamente dos verbos PUT, DELETE e SEARCH. 
 Para possibilitar a manutenção, atualização e reuso, o FHIR 
orienta que a quantidade de recursos deve ser limitada, comum 
e aplicável em diferentes transações de negócios. Além disso, 
devem possuir fronteiras bem definidas e compatíveis com um 
ou mais escopos lógicos [12]. 
 Com a união de experiências em padrões de 
interoperabilidade com tecnologias e processos amplamente 
consumidos por outras áreas, a fundação HL7 almeja 
aproximar os desenvolvedores de software do mundo 
complexo da saúde, e assim, possibilitar que novas soluções 
possam ser criadas, de forma ágil, com qualidade e 
correspondendo às necessidades de seus usuários. Além disso, 
 
viabiliza aos agentes de saúde que as novas tecnologias, como 
aplicativos para dispositivos móveis, possam também 
contribuir com este processo. 
VII. OPENEHR 
Definido em sua página principal na Internet como uma 
plataforma orientada a domínio aberto para 
desenvolvimento de sistemas eletrônicos de saúde flexíveis, a 
openEHR é sustentada por uma comunidade virtual que atua 
sobre a interoperabilidade e informatização de sistemas de 
informação da saúde. 
A fundação openEHR é uma organização internacional sem 
fins lucrativos com o objetivo principal de estabelecer um 
padrão aberto para a construção de sistemas para a eSaúde à 
prova de futuro. Ou seja, um modelo capaz de atender as 
necessidades da saúde e acompanhar as evoluções 
tecnológicas. Para isso, busca-se definir um conjunto de 
especificações de modelo de informação em saúde, 
denominadas arquétipos, os quais são isolados da 
implementação dos softwares e de suas linguagens de consulta 
[15]. 
No desenvolvimento de ferramentas e sistemas para o 
tratamento dos dados da saúde o essencial é a 
interoperabilidade no nível semântico. Para atender este 
requisito o openEHR foca na construção de aplicações 
interoperáveis, manuteníveis, escaláveis e extensíveis, 
desenvolvidas sobre uma modelagem multinível1 suportada 
por uma arquitetura orientada a serviços2, pela qual cada 
modelo é desenvolvido por um especialista dentro de sua 
própria camada [3]. 
 
 
Figura 3 - openEHR: Modelagem Multi Nível 
 
1
 A modelagem multinível propõe que as mudanças na estrutura e nas 
regras de inferência são refletidas sobre o Modelo de Domínio e não sobre o 
Modelo de Referência. 
2
 Arquitetura orientada a serviços: metodologia para desenvolvimento de 
software em forma de serviços, representando todos os ativos de softwares da 
empresa. 
A. Arquétipos e Templates 
A openEHR usufruindode sua arquitetura multinível 
propõe representar os dados pertinentes aos modelos da saúde 
de forma completa e sintetizada através das notações dos 
arquétipos, com os quais é possível registrar o conhecimento 
em partes pequenas para serem compostas em documentos sem 
conteúdos dotados de instruções para preenchimento 
denominados templates, e assim, atender a diferentes 
requisitos e diferentes sistemas de informação para a eSaúde. 
 E como descrito por Alkimim, 2013 “a principal 
característica oferecida pela modelagem de dois níveis é a 
separação (grifo dos autores) entre informação e 
conhecimento” [1] e cabe aos arquétipos representar os 
modelos de domínio ou do conhecimento, sendo este o ponto 
chave para possibilitar que profissionais da saúde possam 
capturar e registrar todos os atributos de um conceito clínico, 
tais como temperatura corporal, índice de massa corporal ou 
pressão sanguínea, sem a interferência ou dependência de 
profissionais da área da TI. 
Conforme descrito pelo openEHR seus componentes e 
sistemas são “abertos” quando se trata de dados, modelos e 
APIs, os quais são publicados e disponibilizados por meio dos 
arquétipos [15]. Sendo assim é disponibilizada pela fundação 
openEHR uma ferramenta on-line denominada Clinical 
Knowledge Manager - CKM, pela qual é possível obter acesso 
ao repositório de arquétipos. 
O CKM é disponibilizado gratuitamente sobre um ambiente 
web 2.0 pelo qual é armazenado, revisado, atualizado e 
traduzido os arquétipos. 
Com base na definição de cada arquétipo, é possível agrupá-
los formando templates, de acordo com as necessidade dos 
documentos ou recursos de sistemas que se deseja 
implementar. Com os templates também é possível realizar a 
modelagem, ou seja, definir o comportamento do sistema e 
quais os atributos dos arquétipos serão utilizados pelos 
desenvolvedores de software na construção dos campos que 
serão exibidos pelos sistemas de informação [10]. 
 
 
Figura 4 – Exemplo de arquétipo em mapa mental: Pressão Arterial 
 
Para a definição e serialização de arquétipos o openEHR 
oferece a linguagem Archetype Definition Language – ADL. 
“A linguagem se baseia em modelos de restrições de entidades 
de domínio, ou regras de negócio estruturadas“ [1], sendo esta 
composta de três sintaxes diferentes: 
• dADL: Data ADL ou modo de definição de dados; 
• cADL: Constraint ADL ou modo de restrições; 
• FOPL: First-Order Predicate Logic ou versão de 
lógica de predicados de primeira ordem; 
 
A proposta multinível da openEHR com foco na 
interoperabilidade semântica através dos arquétipos, 
demonstra-se capaz de oferecer um canal eficaz para a relação 
entre definições técnicas da implementação de software com o 
complexo conjunto de termos, conceitos e processos da saúde. 
E assim, possibilita-se que todos os elementos contidos num 
processo clínico possam beneficiar-se desta arquitetura como 
fornecedores de equipamentos, profissionais de TI, 
profissionais da saúde e pacientes. 
Além disso, se promove o registro e a gestão do 
conhecimento, fundamentada numa comunidade aberta, 
cooperativa e mundialmente conectada. 
B. Consumidores openEHR 
O padrão multinível oferecido pela fundação openEHR tem-
se demonstrado uma forma eficaz para a solução de 
interoperabilidade semântica e sintática na área da saúde, 
constatado pelo volume de trabalhos científicos desenvolvidos 
a seu respeito e pelo número de adeptos ao redor do mundo. 
As instituições, governos e indústrias da saúde que estão 
utilizando o padrão openEHR como solução para a questão de 
interoperabilidade no desenvolvimento de seus sistemas de 
informação, podem ser encontradas no site da fundação 
openEHR. Aqui podemos destacar os governos da Austrália, 
Brasil, Chile, Dinamarca, Holanda, Nova Zelândia, 
Eslováquia, Eslovênia, Suécia e Reino Unido [15]. 
Especificamente no Brasil a fundação openEHR Brasil 
destaca em sua página principal as empresas e instituições: 
Unimed, Cimatec, UNB, UFMG, SUS e Ministério da Saúde 
[16]. 
VIII. UNIÃO FHIR E OPENEHR 
Na atualidade desenvolver soluções eSaúde adotando um 
padrão único de interoperabilidade sintática e semântica, capaz 
de atender aos diferentes sistemas existentes não é um requisito 
possível de se implementar. No entanto, a união da maturidade 
obtida pela fundação openEHR e pela organização HL7, 
demonstra ser a saída para a obtenção de uma especificação 
única, através da convergência dos padrões FHIR e openEHR. 
Como evidência de um processo que se inicia, o assunto 
“União FHIR e openEHR” já faz parte de lista de discussão em 
fóruns na internet voltados a interoperabilidade para a eSaúde. 
As propostas apresentadas destacam a cooperação entre os 
recursos FHIR e a base de arquétipos do openEHR, aplicando-
se os processos do FHIR conectados com o auto nível de 
envolvimento dos clínicos openEHR para a modelagem dos 
recursos clínicos [17]. 
Outros autores destacam a importância de se preservar o ponto 
forte de cada padrão, e compartilhar as melhores caraterísticas, 
como os destacados por Koray Atalag: 
1. Arquétipos: meio para modelagem dos termos 
clínicos; 
2. FHIR: meio para troca de informações clínicas 
pela rede. Formato moderno, não orientado a 
documentação e mensagens; 
3. Desenvolvimento orientado a modelos do 
openEHR: metodologia para a criação de 
sistemas de informação para a saúde de forma 
altamente flexível e manutenível; [18] 
O resultado da cooperação entre os dois padrões demonstra 
ser uma solução sólida e condizente com as necessidades da 
saúde na busca de um padrão único de interoperabilidade. Este 
propósito facilitará a criação de novas aplicações a partir de 
sistemas já implantados e permitirão que mais áreas da saúde 
se beneficiem do compartilhamento de dados e da 
informatização dos processos e dos termos clínicos. 
IX. PADRÕES UTILIZADOS NO BRASIL 
O processo de informatização da saúde no Brasil assemelha-se 
com as demais atividades administrativas do poder público, 
permeados por processos burocráticos e complexos, com 
dificuldades na sua aplicação. Além deste cenário, a autonomia 
de diferentes órgãos da saúde para a contratação de softwares e 
equipamentos de redes, somados ao modelo de gerenciamento 
hierárquico “chegou-se a um resultado geral insatisfatório para 
aplicações de Governo Eletrônico no país” [19]. Desta forma, 
identificou-se a necessidade de um cadastro único para 
cidadãos, empresas e organizações não governamentais. 
Neste contexto, a busca por interoperabilidade tornou-se 
oportuna para se possibilitar a informatização dos processos da 
saúde, buscando contribuir para a simplificação dos serviços 
prestados, aumento da qualidade e auxílio na tomada de 
decisão. 
Contribuindo com este processo e para a integração dos 
dados, o Ministério da Saúde através da Portaria Nº 940, de 28 
de abril de 2011, regulamentou o Cartão Nacional da Saúde 
buscando informatizar o setor público e ser a chave 
integradora entre os sistemas de informação da saúde, 
possibilitando assim uma interoperabilidade entre as 
ferramentas [20]. O Cartão Nacional da Saúde é constituído 
pelo cartão do cidadão, cartão do profissional e uma 
infraestrutura de informação e telecomunicação. 
Identificadas estas necessidades foi criada uma nova 
portaria - Portaria Nº 2.073, de 31 de agosto de 2011, para 
determinar os padrões de Interoperabilidade do SUS. Em 
suma, esta portaria regulamenta os padrões que devem ser 
utilizados na construção de sistemas de informação para o 
âmbito do SUS envolvendo o setor público, privado e setores 
suplementar da saúde [21]. 
Abaixo é apresentado um resumo dos padrões definidos 
para o desenvolvimento de sistemas de informação para o 
SUS: 
• openEHR: interoperabilidade semântica. 
• HL7: estabelecer a interoperabilidade entre sistemascom vista à integração dos resultados e solicitações 
de exames. 
• HL7 CDA (Clinical Document Architecture): 
definição da arquitetura do documento clínico. 
• LOINC: será usado para codificação de exames 
laboratoriais. 
• SNOMED: será usado para codificação de termos 
clínicos e mapeamento das terminologias nacionais 
e internacionais. 
• TISS: usado para a interoperabilidade com sistemas 
de saúde suplementar. 
• DICOM: usado para a representação da informação 
relativa a exames de imagem. 
 
• ISO 13606-2: usado para a interoperabilidade de 
modelos de conhecimento, incluindo arquétipos, 
templates e metodologia de gestão. 
Para a implementação de interoperabilidade entre os 
sistemas de informação do SUS, foi definido a tecnologia Web 
Service, com o padrão SOAP 1.1, devendo todas as definições 
constar no Catálogo de Padrões de Interoperabilidade de 
Informações de Sistemas de Saúde (CPIISS), publicado pelo 
Departamento de Informática do SUS (DATASUS), o qual é 
de responsabilidade de uma comissão do Ministério da Saúde 
[21]. 
A Organização Mundial de Saúde por meio do Departament 
of Knowledge, Ethics and Research “está estimulando os 
países a adotarem a ideia de utilizar plataformas interoperáveis 
com os outros países” [22], porém é um processo difícil de ser 
aplicado devido a grande heterogeneidade de vários sistemas 
de informação. Todavia, diferente de outros países com 
tamanho continentais como a China, Rússia e Estados Unidos, 
o Brasil conseguiria mais facilmente definir um padrão único 
de interoperabilidade para seus sistemas de eSaúde por possuir 
um sistema único de saúde [22]. 
X. CONCLUSÕES 
Conclui-se que a definição de um padrão abrangente e único 
de interoperabilidade para sistemas de informação da saúde 
está num nível de maturidade não antes conquistado desde o 
advento dos recursos computacionais. De acordo com as 
revisões bibliográficas este progresso deve-se a evolução dos 
padrões HL7 e do engajamento e união da comunidade da 
saúde em torno de padrões abertos como o openEHR, 
alinhados com as novas plataformas e soluções no 
desenvolvimento de software. 
Também contribuíram para este processo o rápido 
crescimento das chamadas Tecnologias da Informação e 
Comunicação – TICs, que viabilizaram o acesso a hardwares e 
softwares para grande parte das pessoas. Além disso, a adoção 
da Internet em todos os setores da sociedade exige das 
empresas e instituições maior competitividade e ao mesmo 
tempo uma integração entre si. Este cenário reflete em como 
os sistemas de informação devem ser projetados, o que se 
consegue por meio da interoperabilidade sintática e semântica 
dos seus recursos e modelos de negócios. E na área da saúde 
não é diferente, aplicar uma solução de interoperabilidade é 
vital para a organização ter acesso a dados complexos e de 
suma importância para a prestação de serviços com qualidade 
para os pacientes. 
Em suma, após os estudos realizados neste trabalho, observa-se 
que o estabelecimento de um padrão único para a 
interoperabilidade sintática e semântica dependerá da integração 
total ou parcial dos padrões FHIR e openEHR. E apesar de o 
padrão FHIR possuir uma história recente, o mesmo foi 
concebido por instituições sólidas e evoluído de padrões 
mundialmente aplicados em cima de uma arquitetura de software 
também madura e amplamente utilizada pelo mercado de 
desenvolvimento de softwares aplicativos. Já o openEHR conta 
com o empenho das instituições médicas, fornecedores de 
equipamentos médicos e dispõe de uma solução capaz de evoluir 
e atender ao complexo cenário apresentado pela 
interoperabilidade semântica, devido o foco ser os agentes da 
saúde e o arquétipo se comprovar ser o modo mais eficaz para a 
modelagem dos termos médicos. 
O debate em torno da união ou cooperação entre os padrões 
FHIR e openEHR já é um processo iniciado, como evidenciado 
na lista de discussões mantida pelo consultor e desenvolvedor 
HL7 Grahame Grieve [21]. A questão FHIR e openEHR é 
colocada em pauta e conclui-se que esta cooperação é necessária 
dentro do contexto de interoperabilidade, pois são pertinentes as 
fortes caraterísticas de cada plataforma, que juntas parecem 
oferecer uma saída para a definição de um padrão único para 
interoperabilidade sintática e semântica. No entanto, isto só se 
tornará fato se ocorrer dentro de uma comunidade, ou seja, a 
união de todos os interessados por um objetivo comum: a 
integração total entre os sistemas de eSaúde. 
 
REFERÊNCIAS 
[1] ALKIMIM, Reinaldo Araújo de. Modelo de Objetos do Openehr: 
Uma Avaliação em Termos de Métricas Orientadas a Objeto. 
Dissertação de Mestrado. Faculdade de Ciências Empresariais da 
Universidade FUMEC. Belo Horizonte, 2013. 
[2] MENEZES, A.; GOMES, A. T. A.; ZIVIANI, A. Uma Abordagem 
Transformacional para Geração de Módulos de Comunicação em 
Sistemas de Informação em Saúde. In: Workshop de Informática 
Médica (WIM), 2013, Maceió-AL. Anais do XIII Workshop de 
Informática Médica. Porto Alegre-RS: SBC, 2013. 
[3] CORREIA, Ricardo João Cruz, OpenEHR and Breast Cancer. In: 
Breast Cancer Workshop. University of Porto – Portugal, 2013. 
[4] BARBOSA, Alexandre F. TIC Saúde 2013:[livro eletrônico]: pesquisa 
sobre o uso das tecnologias de informação e comunicação nos 
estabelecimentos de saúde brasileiros. São Paulo. Comitê Gestor da 
Internet no Brasil, 2014. 
[5] ISO/TC215 18308. Health informatics -- Requirements for an 
electronic health record architecture. ISO, 2011. 
[6] Portal de Governo Eletrônico do Brasil. O que é Interoperabilidade? 
(on-line) Disponível na internet. URL: 
http://www.governoeletronico.gov.br/acoes-e-projetos/e-ping-padroes-
de-interoperabilidade/o-que-e-interoperabilidade, 2014. 
[7] BRINGUENTE, Ana Christina de Oliveira. Reengenharia de uma 
ontologia de processo de software e seu uso para a integração de 
ferramentas de apoio ao planejamento de projetos. Dissertação de 
Mestrado. Universidade Federal do Espírito Santo. Vitória, 2011. 
[8] PIRES, Daniel Facciolo; RUIZ, Evandro Eduardo Seron. 
Interoperabilidade terminológica em sistemas de informação em 
saúde: problemas e soluções com a UMLS. Journal of Health 
Informatics, São Paulo, vol. 2, no. 2, pp. 34-42, Abril-Junho 2010. 
[9] BEGOYAN, A. An Overview of Interoperability Standards for 
Electronic Health Records. In: Proceedings of the 10th Int. 
Conference on Integrated Design and Process Technology. Antalya, 
Turkey. 2007 Jun. p. 3-8. 
[10] ATALAG, Koray; KENWORTHY, Alastair; HAY, David. 
Underpinnings of the Interoperability Reference Architecture. In: HINZ 
2012 Conference and Exhibition. New Zealand. 2012. 
[11] Health Level Seven International. About HL7 (on-line). Disponível na 
internet. URL: http://www.hl7.org/about/index.cfm?ref=nav, 2014. 
[12] BENDER, Duane; SARTIPI, Kamran. HL7 FHIR: An Agile and 
RESTful approach to healthcare information exchange. In: CBMS: 
IEEE. Portugal, 2013. p. 326-331. 
[13] KAMINKER, Diego. FHIR é DSTU. In: CAIS 2014 5to Congresso 
Argentino de Informática e Saúde. Argentina, 2014. p. 2-5. 
[14] MANTOVANI, Daniel. Arquitetura REST e o serviço web 'RESTful' 
(on-line). Disponível na internet. URL: http://sao-
paulo.pm.org/artigo/2010/RESTful, 2014. 
[15] openEHR Foundation. What is openEHR? (on-line). Disponível na 
internet. URL: http://www.openehr.org/, 2014. 
 
[16] openEHR Brasil. Como Funciona (on-line). Disponível na internet. 
URL: http://openehrbrasil.com.br/index.php/como-funciona, 2013. 
[17] GRIEVE, Grahame. Question: openEHR and FHIR (on-line). 
Disponível na internet. URL: 
http://www.healthintersections.com.au/?p=1878http://www.healthinters
ections.com.au/?p=1878, 2014. 
[18] LESLIE, Heather. Stop the #healthIT ‘religious’ wars (on-line). 
Disponível na internet. URL: 
http://omowizard.wordpress.com/2014/02/17/stop-the-healthit-religious-wars/, 2014. 
[19] MESQUITA, Cláudia S. F; BRETAS, Nazaré L. Panorama da 
interoperabilidade no Brasil. Ministério do Planejamento, Orçamento 
e Gestão, Secretaria de Logística e Tecnologia da Informação. Brasília: 
MP/SLTI, 2010. 
[20] Agência Nacional De Saúde Suplementar. Cartão Nacional de Saúde: 
uma realidade para todos os brasileiros (on-line). Disponível na 
internet. URL: http://www.ans.gov.br/index.php/a-ans/sala-de-noticias-
ans/consumidor/1819-cartao-nacional-de-saude-uma-realidade-para-
todos-os-brasileiros, 2014. 
[21] CARNEIRO, Leandra L. R. Padrões de Interoperabilidade do SUS - 
nova portaria (on-line). Disponível na internet. URL: 
http://timedicina.blogspot.com.br/2011/08/padroes-de-
interoperabilidade-do-sus.html, 2014. 
[22] PERCHE, Moacyr. Unidade Técnica Gestão do Conhecimento e 
Comunicação (on-line). Disponível na internet. URL: 
http://www.paho.org/bra/index.php?option=com_content&view=article
&id=4562:moacyr-perche-representando-o-ministerio-da-saude-do-
brasil-da-palestra-na-oms-sobre-a-atuacao-da-estrategia-de-
esaude&Itemid=371, 2014. 
 
Leandro de Carvalho Maia nasceu em Pouso 
Alegre, MG, em 02 de julho de 1982. Possui os 
títulos: Bacharel em Sistemas de Informação 
(UNIVÁS, 2008), Licenciatura Plena em Sistemas 
de Informação (Instituto Federal de Educação, 
Ciência e Tecnologia do Sul de Minas Gerais, 
2013). 
Desde janeiro de 2009 é Especialista em 
Sistemas do Inatel Competence Center onde atua 
em desenvolvimento de softwares web e desktop 
para as plataformas Java, C# .Net e Python. Tem 
interesse nas áreas de desenvolvimento Web, API’s RESTful, Cloud 
Computing, metodologias ágeis e testes de software automatizados.