PADRÕES DE CONECTIVIDADE PARA DISPOSITIVOS MÉDICOS UMA ANÁLISE - IHE PCD & HL7™ FHIR™
Paulo Rogério Rades, cpTICS
Novos empreendedores e mesmo tradicionais fabricantes de dispositivos e aplicativos médicos, podem, compreensivelmente, ficar confusos ao analisar o estado-da-arte dos padrões para a conectividade dos dispositivos médicos disponíveis.
Muitos poderiam supor que exista um ‘padrão ouro’ para a troca de informações, visto estarmos na era da interoperabilidade e do compartilhamento de informações. E, na verdade, este padrão inovador, agora existe, mas, ainda pouco explorado pela indústria de dispositivos.
É assustador para todos que pretendem implementar padrões em seus produtos e soluções analisar todas as informações disponíveis sobre padrões para a conectividade de dispositivos médicos.
São muitos artigos e muitas diferentes opiniões geradas diariamente pelas organizações de desenvolvimento de padrões, pelos fornecedores e pelos influenciadores do setor.
Sendo, a interoperabilidade, a integração de aplicações e de dispositivos médicos, o core business da InterOpera, apresentamos uma breve avaliação do estado-da-arte para a 2 interopera.com.br conectividade de dispositivos médicos, dando ênfase as duas das principais iniciativas, IHE PCD e o HL7™ FHIR™.
Neste artigo, nosso foco está na avaliação de padrões que permitam a integração e a interoperabilidade entre os dispositivos e os sistemas médicos.
Em última análise, o objetivo da interoperabilidade é permitir que os estabelecimentos de atenção à saúde troquem informações que sejam universalmente entendidas, sem necessidades de tradução extensiva ou de software intermediário.
O ESTADO-DA-ARTE DOS DISPOSITIVOS CONECTADOS
Este artigo foi produzido no final de 2018 e a realidade é que a maioria dos dispositivos médicos simplesmente não é interoperável.Observamos que a maioria destes dispositivos disponibiliza diferentes formatos de dados proprietário para cada fabricante.
Durante um projeto de integração de equipamentos e dispositivos médicos, analisamos doze dispositivos e encontramos doze diferentes formatos de dados, sendo os mais comuns, binários, XML, HL7™ e outros esquemas proprietários.
Para complicar ainda mais, os sistemas de terminologias encontrados foram SNOMED, LOINC, ISO 11073, utilizados pelos fabricantes. Estas terminologias servem como parte do vocabulário nas mensagens HL7™ e acabam não sendo interoperáveis entre si.
Um exemplo disto, seria uma medida simples de temperatura corporal, que pode ser representada de diferentes maneiras por estes sistemas terminológicos. A terminologia precisa estar harmonizada entre os sistemas antes que possamos obter o intercâmbio preciso dos dados.
Para que estes dispositivos possam se comunicar com o mundo externo, é necessário que os dispositivos enviem os dados para um servidor central (gateway) que seja capaz de traduzir mensagens proprietárias para o formato HL7™, um formato livre de proprietários. Embora o HL7™ seja um padrão de mensagens amplamente aceito para o intercâmbio de dados de saúde, sua inerente flexibilidade, contribuiu para sua incapacidade de servir como um verdadeiro padrão interoperável.
Em decorrência desta flexibilidade, cada aplicação ou sistema em um hospital pode implementar um “perfil” diferente para as mensagens HL7™, sendo que, estas, precisam 3 interopera.com.br ‘passar’ por um ‘motor de integrações HL7™’ que é um software que facilita a troca, tradução e o compartilhamento de dados de saúde no formato HL7™.
Sempre que um novo sistema, ou, um ou mais dispositivos for instalado no estabelecimento de atenção à saúde, o motor de integrações deverá ser atualizado para efetuar o correto mapeamento dos dados para atender adequadamente este intercâmbio.
Na maioria dos casos, esta solução é boa o suficiente para recuperar informações dos sistemas de prontuário eletrônico, porém, não promove a verdadeira interoperabilidade entre os dispositivos ou entre os dispositivos e os sistemas e aplicações em saúde. Além do mais, não habilita o compartilhamento de dados em tempo real, usados para análises preditivas, tipos de dados estes, que impulsionarão avanços importantes na análise profunda de dados e no aprendizado de máquina.
A primeira iniciativa a dar passos sérios para a resolução deste desafio de interoperabilidade entre dispositivos médicos é o IHE PCD e desde 2011, um emergente padrão chamado FHIR™, vem ganhando tração. Vamos analisá-los.
IHE PCD
Provavelmente, o padrão de interoperabilidade mais popular para implementação em dispositivos médicos seja o conjunto de perfis desenvolvidos pela organização IHE, sem fins lucrativos, que são os perfis do domínio PCD (Patient Care Device) que orientam a interoperabilidade entre os dispositivos e sistemas e aplicações médicas.
Tecnicamente, não podemos considerar o IHE PCD como um padrão. O IHE define perfis que especificam como devemos implementar padrões existentes para resolver os desafios da interoperabilidade dentro do contexto de casos de uso de gerenciamento da informação clínica.
De muitas maneiras, a iniciativa IHE foi bem-sucedida, mas a adoção ainda não é universal e algumas classes de dispositivos adotaram o IHE PCD mais do que outras. Dispositivos de infusão são bem atendidos pelo perfil IHE-PIV (Point of Care Infusion Verification) e a maioria dos fabricantes destes dispositivos implementaram o perfil em seus softwares.
Apesar de ser uma especificação muito difundida, o IHE PCD não conseguiu atingir uma grande gama de produtos, se considerarmos o amplo espectro de dispositivos médicos existente.
Isto não significa que o IHE PCD não tenha valor. O IHE PCD levou a indústria para mais perto de realizar o sonho da interoperabilidade, e, para muitas modalidades, representa a melhor opção.
Vamos ter em mente que o IHE não cria padrões. Os perfis IHE especificam e orientam em como usar os padrões existentes. Em teoria, o IHE não está vinculado a um padrão em específico, mas, na prática, muitos de seus perfis estão baseados no padrão HL7™ versão 2.x, padrão este, que está estagnado e sendo gradativamente substituído por iniciativas emergentes.
Por ser um padrão com mais de 30 anos, o HL7™ versão 2 possui deficiências, como o modelo de dados desatualizado e da falta de segurança. Esta deficiência se dá pelo fato de quando de seu desenvolvimento, a troca de dados ocorria internamente nos estabelecimentos de atenção à saúde.
A comunidade HL7™ reconheceu estas falhas e em 2011 iniciou o desenvolvimento de uma nova especificação que atendesse a casos de uso atuais, com maior facilidade de implementação e a custos e prazos menores.
Esta nova especificação foi batizada de HL7™ FHIR™ e sua primeira normativa foi publicada em janeiro de 2019.
FHIR™
Para resolver as deficiências do HL7™ versão 2.x, foi criado um novo padrão utilizandose uma abordagem mais moderna. O padrão FHIR™ (Fast Healthcare Interoperability Resources) baseia-se nas melhores experiências do HL7™ versão 2.x e versão 3, associando-o a um modelo de dados fortemente definido e a uma camada aprimorada para segurança através da especificação SMART.
O FHIR™ implementa ‘API´s’ através do protocolo ‘RESTful’ que é baseado em ‘HTTP’, permitindo os formatos ‘JSON’ (preferencial) ou o ‘XML’ para a representação dos dados.
Os dados são estruturados em diferentes tipos de recursos, que podem ser entendidos como os blocos de construção do modelo de informações. São entre 100 e 150 diferentes tipos de recursos que permitem a modelagem de praticamente qualquer caso de uso. Exemplo de recursos são: Patient, Practitioner, Medication, Device, Observation, etc.
O FHIR™ está cada vez mais perto de se tornar o real padrão para interoperabilidade entre os sistemas e também entre os dispositivos médicos.
Isto decorre do fato de que mesmo o FHIR™, quando em versões rascunho, as indústrias e os desenvolvedores de softwares médicos, já o estavam avaliando e criando soluções nunca antes criadas e com tanta rapidez.
Isto é só um começo.
É preciso termos em mente que o FHIR™ somente se tornou uma versão normativa em janeiro de 2019.
É esperado que com a publicação desta normativa, muitos desenvolvedores e fabricantes de dispositivos, e mesmo aqueles que ainda não haviam se dedicado ao FHIR™, passem a considerar, cada vez mais, a implementação do FHIR™ em seus produtos.
O FHIR™ foi publicado em 2014 como “rascunho de padrão para uso experimental – (DSTU) ”, isto quer dizer que, muitas definições poderiam ser alteradas e seu uso não é aconselhado para ambientes de produção.
Em 2013, a especificação foi elevada para o nível de “padrão para uso experimental – (STU) ”, o que quer dizer que muitas das definições estão bloqueadas para alterações, pelo fato de a comunidade FHIR™ ter chegado ao consenso sobre um recurso ou um tópico em questão. Estes bloqueios sobre os recursos, gera maior confiança em sua adoção. No entanto, existem desafios para o FHIR™.
DESAFIOS DE CURTO PRAZO
A especificação FHIR™ é um trabalho em constante evolução e isto pode trazer algum tipo de confusão quando da escolha sobre qual a versão utilizar. Estas evoluções podem estar presentes na própria normativa do FHIR™ e para identificá-las aconselhamos optar pelos recursos com níveis de maturidade mais alta.
O nível de maturidade de cada um dos recursos FHIR™ é definido conforme a comunidade FHIR™ o utiliza e o aprimora. Para que seu nível de maturidade seja 5, nível de pleno consenso, este deve passar por um connecthaton e estar presente em mais de uma real implementação.
Outro desafio, em todos os países, é que por uma infinidade de razões, a assistência médica é resistente à adoção antecipada de tecnologias. E finalizando, boa parte dos desenvolvedores de aplicações, apps e sistemas para saúde desconhecem os padrões HL7™, e/ou, mesmo aqueles que os conhecem, demonstram certa relutância em implementá-los.
Para superar estas barreiras, é necessário que todo o setor de saúde se comprometa com maior firmeza, assim como EUA, Canadá e outros países vem fazendo.
DESAFIOS FUTUROS
Os usuários dos sistemas hospitalares e os próprios pacientes, estão sendo muito bem atendidos pelo FHIR™ para recuperarem seus dados.
MAS, E QUANDO ABORDAMOS OS DISPOSITIVOS BIOMÉDICOS?
No FHIR™, as observações geradas pelos dispositivos médicos são estruturadas e armazenadas em recursos do tipo Device, porém, suas definições, em grande parte, são deixadas a critério dos fabricantes. Existe, ainda, certa escassez de diretrizes no padrão.
Um cenário decorrente e que poderemos vir a vivenciar é a de que fabricantes de dispositivos médicos, bem-intencionados quanto a implementação de padrões, provavelmente o implementem de diferentes maneiras, criando barreiras para a verdadeira interoperabilidade e o avanço da Internet das Coisas Médicas (IoMT).
Sem uma iniciativa para a padronização das observações e das medidas geradas pelos dispositivos biomédicos, permaneceremos no exato estado em que nos encontramos e mesmo que tenhamos atingido a padronização total dos dados dos pacientes com o HL7™ ou outro padrão médico.
O resultado é que não alcançarmos a real interoperabilidade e permaneceremos atrasados frente a outros setores que se beneficiam da comunicação de aplicações e dispositivos.
Com o FHIR™ temos esta oportunidade. Dar início a padronização da comunicação centrada nos dispositivos biomédicos, que inevitavelmente é tão importante quanto a padronização dos dados dos pacientes, os quais foram prioridade até este momento.
Somente a adoção do FHIR™ poderá determina seu sucesso, ou, fracasso. O FHIR™ está bem posicionado e é endereçado para solucionar os mais diferentes problemas de conectividade da assistência em saúde.
CONCLUSÃO
Sem dúvida, estamos vivenciando momentos de transições, seja na forma de acesso aos dados e/ou mesmo quando falamos em conectividade de dispositivos médicos.
Para startups e para os empreendedores que atuam com o desenvolvimento de soluções inovadoras usando as tecnologias de informação e comunicação em saúde, este artigo pode ter gerado mais perguntas do que respostas. Não se desespere.
Há respostas para suas dúvidas, sendo que, os padrões de conectividade e para comunicação que você adotará dependerão muito da modalidade de sua solução e/ou do uso pretendido de seu produto. Caso deseje, conte com a InterOpera. Estamos aqui para ajudar.
Trabalhando com organizações de saúde, fabricantes de dispositivos médicos e fornecedores de software, a InterOpera oferece cursos, treinamentos e capacitação profissional, além de desenvolver soluções que ajudam a resolver os desafios do intercambio dos dados, incluindo implementação de dispositivos, motores de integração, design, suporte a sistemas e definição de sua estratégia de integração dos dados.
CURSO ON-LINE AO VIVO: HL7 FHIR – ESPECIFICAÇÃO E IMPLEMENTAÇÃO
