|
HL7: UMA HISTÓRIA REPAGINADA
A ERA ‘FHIR‘
‘FHIR SÃO DUAS COISAS: TECNOLOGIA E CULTURA‘¹, Grahame Grieve FHIR Leader
À medida em que as tendências para melhor atenção á saúde se encaminham para a necessidade de dados sobre a saúde dos pacientes de forma flexível e imediata, a interoperabilidade é a prioridade e preocupação de lideranças em saúde, e deve ser considerada o pilar para inovações.
A interoperabilidade em saúde, em sua forma mais básica, se refere à capacidade dos sistemas, em especial os clínicos, padronizarem, harmonizarem e agregarem diversas e diferentes fontes seguras de dados, para compartilhamento e utilização pelos profissionais e pacientes que deles necessitem, onde estejam.
Desta forma, os padrões médicos tem sido tema de debates sobre o intercâmbio de dados em saúde, sendo o HL7, o padrão mais aceito pela indústria.
O HL7 foi projetado para a transmissão de grandes volumes de dados pré-definidos, e serem compartilhados e consumidos por várias e diferentes aplicações.
O protocolo utilizado preferencialmente para esta comunicação e transferência de arquivos, é o tradicional TCP/IP, tanto em tempo real quanto em lotes (batchs).
Este padrão foi criado inicialmente por especialistas em interfaces clínicas sendo a primeira versão em produção, o HL7 V2, que atendia necessidades de práticas clínicas do mundo real.
O grupo de especialistas envolvidos no desenvolvimento do padrão, optou por adotar a abordagem da regra 80/20, o que significa que 80% da estrutura do padrão está definida pelo HL7 e os demais 20% para serem personalizados pelos implementadores, de forma a atender necessidades locais ou especificas.
Esta abordagem fez com que usuários e fornecedores refletissem sobre as regras de negócios e fluxos de trabalho ditadas pelo padrão. O HL7 precisava ser flexível em seu início, porque era necessário que mais usuários o utilizassem, então, quanto mais flexível fosse o padrão, mais fácil seria da indústria adotá-lo.
À medida em que mais fornecedores adotaram os padrões HL7, o valor para os médicos e tecnólogos aumentou, e em 1998, a HL7 atingiu seu ponto de equilíbrio quando um número suficiente de sistemas foram implementados e assim evidenciou-se a vantagem em se utilizar o padrão.
Desde então, novas versões do V2 foram e continuam a serem lançadas. A versão do HL7 V2 que uma organização está usando não é necessariamente importante, porque o HL7 V2 deve ser compatível com versões anteriores.
Esta prática demandou ampla adoção do HL7, no entanto, devido ao objetivo da HL7 e a singularidade do framework, isto criou desafios significativos para o intercâmbio eletrônico de dados para o cuidado longitudinal do paciente.
Você pode estar pensando que parece ser contraditório dizer que um padrão seja personalizável, e realmente o é…. Mas, faz parte do problema com o HL7 V2.
Existem tabelas de códigos definidos pelo HL7, que são enviados entre os sistemas, e que a maioria reconhece, como as mensagens de ADT (admissão, alta, transferência).
Mas o problema aparece quando uma mensagem específica não pode acomodar todos os elementos de dados que precisam ser transmitidos. Por exemplo, se uma mensagem é definida pelo padrão para acomodar 75 elementos de dados, mas precisamos transmitir dados de um ECG, que exige 200 elementos, teremos que enviar o restante dos elementos através de segmentos do tipo Z, que não são definidos pelo padrão.
Estes dados devem ser analisados, mapeados e normalizados para serem úteis, exigindo uma quantidade impressionante de tempo de desenvolvimento e de design.
Outra problemática é que os códigos definidos pelo HL7 utilizados com mais frequência não são atendidos. É comum vermos que os EHRs e os hospitais usam seus próprios conjuntos de códigos predefinidos, o que pode exigir análises e pesquisas antes que estes também possam ser úteis.
Embora a V2 tenha sido refinada e amplamente adotada, os usuários ficaram frustrados porque grande personalização é necessária para se atingir plenamente o objetivo da interoperabilidade.
Mas, mesmo com todo este trabalho, a estrutura da mensagem é complexa, plana e delimitada. Visto isto, a HL7 International entendeu a problemática e determinou que seria necessário aplicar as lições aprendidas através do HL7 V2 e trabalhar no desenvolvimento de outra versão; Nasce então, o HL7 V3.
É importante entendermos e reconhecermos que o HL7 V2 foi criado por um especialista em interfaces clínicas, e o V3 foi criado pela maioria dos informatas médicos e demais membros dos grupos de trabalho do HL7. Mas o fato, é que cada versão é única.
O HL7 V3 fornece um modelo rígido e menos estruturas personalizáveis, menos funções de aplicativos, menos opções de mensagens e menos opções para criar e manter interfaces a médio e longo prazo. Devido a problemas legados, o HL7 V3 não é compatível com versões anteriores, o que significa que não funciona com o V2, nativamente.
Isso tornou a adoção do HL7 V3 mais custoso e demorada devido ao reinício das implementações, harmonização e reaproveitamento do HL7 V2, além do fato de que os aplicativos terem que suportar o V2 e o V3.
Os padrões HL7 V2 e V3 não são perfeitos, mesmo porque padronizar a prática clínica não é tarefa singular, mas os padrões HL7 oferecem o que a indústria da saúde precisa.
Para preencher estas lacunas, o HL7 se empenhou em desenvolver um novo padrão que incorporasse o melhor das versões anteriores da HL7, apoiando-se nas lições aprendidas sobre as dificuldades enfrentadas ao longo de seus ciclos de vida, e reaproveitando os melhores, mais modernos e consolidados padrões web como XML, JSON, OAUTH2,, ATOM, REST, HTTP dentre outros.
Este novo padrão é chamado de FHIR. FHIR é acrônimo para Fast Healthcare Interoperability Resources. Foi projetado para implementar segurança adicionando uma camada HTTPS, além de oferecer um modelo melhor definido e fornecer mecanismos mais fáceis para personalizações quando necessárias.
O FHIR é em REST, o que facilita a implementação, uma vez que é de domínio dos desenvolvedores e de fácil utilização pelas organizações.
Sendo mais fácil de se implementar e utilizar quando comparado ao HL7 V2 e/ou V3, podemos esperar maior economia e alto ROI.
Uma observação importante é que o FHIR está em desenvolvimento, sendo previsto a publicação da R4, a primeira normativa, para meados de 2018.
Mas, mesmo em STU, muitos projetos estão acontecendo por todo o mundo. O FHIR está evoluindo e amadurecendo rapidamente e um grande número de empresas de TICS brasileiras e internacionais estão ajustando suas soluções para a demanda de novas oportunidades que o FHIR possibilita.
Mas, e o futuro dos demais padrões HL7…
Não se preocupe, os demais padrões HL7 não desparecerão tão cedo e continuarão a serem utilizados, porque estão resolvendo problemas do mundo real e atual.
Embora um dos objetivos do FHIR seja reduzir a barreira na adoção de um ecossistema de saúde digital, o FHIR espera resolve-la através de interfaces REST, que são mais fáceis e ágeis de se desenvolver e utilizar.
O futuro para o FHIR é promissor devido ser uma plataforma aberta, e isto é importante porque é a única forma para que um padrão possa ser adotado, adaptável e útil, à medida em que novas tendências e necessidades evoluem. As versões das especificações são publicadas entre 18 e 24 meses, e em alguns casos até menos…
“A expansão da comunidade FHIR é impressionante. Estamos entusiasmados e acompanhando esta revolução em TICS”
Na verdade, o FHIR poderia para muitos, ser somente mais uma versão do HL7, mas não! Foi projetado do zero, é completamente novo. É como quando a Microsoft acumula muitas atualizações através das experiências positivas e negativas de seus usuários e então disponibiliza os temidos Service Packs, até que finalmente liberam um sistema com um novo nome, por exemplo.
Artigo:
A RELAÇÃO ENTRE O FHIR E OUTROS PADRÕES HL7
(in english)
No passado
Ao revisitarmos a história, os padrões HL7 são da década de 80. Nenhuma das tecnologias disponíveis e necessárias para a sociedade moderna, tinhamos quando em 1987, a primeira V2 entrou em produção.
‘Mas o paradigma atual é todo baseado em recursos e padrões da WEB 2.0’..
Sim, sabemos mas ….
Ainda, foram criados outros padrões baseados em documentos, como o CDA® R2 (Arquitetura para Documentos Clínicos) e os padrões baseados em SOA, como o Common Terminology Services (CTS). E, estes 30 anos de histórias de HL7, nos permitem uma boa ideia do que precisamos como usuários e desenvolvedores de padrões.
O que as organizações esperam dos padrões?
As organizações que implementam e usam padrões querem acesso aberto as especificações e as diretrizes de implementação. Necessariamente precisam que as especificações sejam de fácil e rápida compreensão, ferramentas de auxílio para implementação, implementações de referência, representação amigável de informações (instâncias), fácil acesso a vocabulários, validação automatizada de instâncias, conteúdo educacional acessível, um mecanismo formal de extensões.
E finalmente, eles precisam de exemplos, exemplos e mais exemplos. Eles precisam de muitos exemplos!
E o que implementadores precisam?
Os implementadoress têm necessidades diferentes das organizações. Estes precisam criar perfis reutilizáveis, interfaces gráficas para os usuários (GUI) e possibilitar a reutilização de modelos. Precisam de mecanismos para publicação automatizada, validação e perfis para o controle de qualidade, validação de instâncias, etc.
Mas, e onde erramos no passado?
Primeiro criamos barreiras à adoção, especialmente ao LMIC (Países de baixa e média renda). O acesso ao padrão e as guias de implementação somente eram acessíveis aos associados HL7, o que foi revisto, e os materiais passaram a ser disponibilizados livremente.
Outra barreira é que as especificações são extensas e confusas e constituídas por centenas e até milhares de páginas.
Os padrões V2 e V3 foram concebidos sobre padrões tecnologicos considerados arcaicos, com 30 anos para o V2 e mais de 20 anos para o V3.
Não haviam implementações de referência, validação de instâncias, ferramentas de gerenciamento de perfis, registro de modelos e não eram fornecidos exemplos.
WEB 2.0
‘A ERA FHIR’
Porquê HL7 FHIR?
O Fast Healthcare Interoperability Resources (FHIR®) é inovador. Você pode testar suas aplicações imediatamente em dezenas de servidores diferentes e também ter e configurar seu próprio servidor FHIR, em menos de uma hora.
As instâncias XML/JSON funcionam nativamente. O FHIR disponibiliza e permite que você use ferramentas de suporte à implementação e desenvolvimentos para o padrão.
Além disso, todas as especificações estão em uma única página e a (s) extensão (ões) são fáceis de se lidar, ao contrário dos temidos segmentos ‘Z‘.
O FHIR fornece centenas de exemplos para os usuários utilizarem como referência em suas implementações. Todoas as especificações para os diferentes tipos de recursos são publicadas com ao menos dois exemplos.
OFICINA DE INTEROPERABILIDADE
ON-LINE | AULAS AO VIVO
O Estado da Arte na LATAM
Nos últimos anos, países latino-americanos (LATAM) começaram a usar o CDA R2 para o compartilhamento de registros eletrônicos em saúde (EHR), além dos sistemas de informações laboratoriais (LIS) adotarem e implementarem o HL7 Versão 2.x, e as plataformas de radiologia.
Alguns desses países criaram regulamentações e leis sobre quais os padrões a serem utilizados em projetos regionais e nacionais em saúde.
Vejamos:
- O Uruguai adotou o CDA R2 como um padrão nacional.
- Na Argentina o CDA R2 está sendo traduzido pelo Instituto Argentino de Padronização e Certificação (IRAM). O CDA e o FHIR também estão sendo implementados no país.
- A Colômbia alcançou níveis maduros de implementação do CDA e atualmente vem experimentando o FHIR.
- E…,finalmente, o Chile, que tem explorado o uso do FHIR em testes de viabilidade.
E como a inovação melhora resultados?
Conheçe o SmileCDR?
O SmileCDR é um repositório de dados clínicos (CDR) construído sob as especificações HL7 FHIR. Com ele você pode alimentar aplicativos, compartilhar dados, realizar análises e proporcionar resultados eficientes para os gestores, clínicos e pacientes.
O SmileCDR é baseado no HAPI, uma plataforma consagrada e que é utilizada para integrar com sucesso sistemas eletronicos em saúde há mais de 15 anos.
‘Nossa plataforma foi projetada para ajudar as organizações a superem as barreiras do intercambio dos dados. Ela suporta toda a especificação do FHIR, permitindo a inovação em aplicações para cuidados médicos especializados’.
Oferecemos suporte a sistemas legados através de conectores e adaptadores para outros padrões (HL7 v2.x, CDA, XML, etc.). O Smile CDR tem rápido deploy e go-live.
LIBERTE SUAS APLICAÇÕES COM O SMARTCDR
Rápido de implementar: o SmileCDR é projetado para o rápido deploy e go-live.
Nossa plataforma é bastante customizável e fácil de configurar devido as poderosas ferramentas de gerenciamento e administração serem integradas.
‘Nós oferecemos suporte para muitos padrões que hoje são implementados nos sistemas de registro eletrônico em saúde’
Rápido de implementar: O SmileCDR pode ser hospedado em nuvem ou em servidores locais em seu próprio data center.
Rápida utilização: o SmileCDR foi projetado para suportar agrupamento horizontal e assim obter tempos de respostas mais rápidos e maior resiliência.
Segurança: Nós cobrimos este aspecto. O SmileCDR tem seu design orientado á privacidade…, apesar de acreditarmos que devemos ‘desbloquear’ os dados, mas mantendo-os, COMPLETAMENTE SEGUROS.
O SmileCDR possuem recursos de trilhas de auditoria integrada e ferramentas para o monitoramento de conformidades, oferecendo assim, suporte para integração com outras plataformas e ferramentas, utilizando mecanismos de segurança que você conhece e utiliza em seu cotidiano, como Active Directory, OAuth2, SAML, etc.
O Smile CDR também disponibiliza a implementação completa do framework de autorização para o SMART FHIR, permitindo asssim, implementar a próxima geração de aplicativos médicos de forma totalmente segura.
Compatibilidade
O Smile CDR é compliance HIPAA, PHIPA e demais quesitos de privacidade, além de atender conformidades ITIL, ITSM, e outras. Consulte-nos.
Econômico
PAGUE SOMENTE POR O QUE VOCÊ NECESSITA E UTILIZA
Nossos preços são baseados em SaaS para facilitar a utilização de tão poderosa plataforma como o SmileCDR. Você pode testar suas ideias e projetos e escalonar conforme as necessidades aumentem.
Preferir hospedar o sistema em seus servidores? ou mesmo incorporá-lo em suas soluções?
‘Nós oferecemos maneiras flexíveis de se fazer isso, e não se preocupe, apenas sorria’
🙂 – Deixe isto conosco
O SmileCDR foi projetado como uma implementação padrão de um servidor FHIR. Isto quer dizer que combina todas as poderosas funções integradas do HAPI com uma coleção adicional de ferramentas úteis projetadas para simplificar a utilização.
Compatibilidade com outros padrões
O SmileCDR possui conectores e adaptadores para integrar HL7 v2.x existentes e são adicionados mais formatos para rapida integração, constantemente.
Terminologias
O SmileCDR possui serviços de terminologias integrados que podem ser usados para mapear os dados conforme suas necessidades. Nossos serviços de terminologias são capazes de gerenciar SNOMED CT, LOINC e outros vocabulários comuns na atenção em saúde.
Auditoria e Conformidade
O SmileCDR monitora completamente todos os registros e transações facilitando aos administradores monitorarem tráfego, realizarem auditorias de privacidade e resolverem problemas com maior facilidade.
‘Nossa filosofia está em acreditar no poder do design e privacidade’
Escalabilidade
O SmileCDR foi projetado para atender necessidades do presente e do futuro. Nosso exclusivo e poderoso gerenciador de clusters, permite que você adicione tantos ‘nodes’ horizontais quantos necessários.
Para maiores informações entre em contato.
[contact-form to=”radespaulo@gmail.com” subject=”SMILECDR – CONTATO”][contact-field label=”Nome” type=”name” required=”1″][contact-field label=”E-mail” type=”email” required=”1″][contact-field label=”Telefone” type=”text” required=”1″][contact-field label=”Site” type=”url” required=”1″][contact-field label=”Mensagem” type=”textarea” required=”1″][/contact-form]
|
