Interoperability standards and schema
Standards development activities undertaken since the early 1980s aimed to provide solutions to these interoperability challenges., A Digital Imaging and Communications in Medicine (DICOM®), o comitê de normas do National Electrical Manufacturers Association (NEMA), foi um dos primeiros a desenvolver um padrão para a comunicação de imagens médicas, informações , agora publicado pela Organização Internacional para Padronização (ISO12052:2017). Todos os padrões de Nível Sete de saúde (HL7) são publicados por uma organização oficial de padrões nacionais, o American National Standards Institute (ANSI)., É importante notar que as normas HL7 (nível Sete de saúde) se concentram na interoperabilidade técnica (intercâmbio de dados de saúde), resultando em interoperabilidade Operacional limitada (semântica).
a agora muito popular norma FHIR® (Fast Healthcare Interoperability Resources) melhorou consideravelmente os fluxos de informação operacional . O modelo de referência HL7 FHIR® é definido por uma coleção de modelos de informação (recursos). Estes podem ser perfilados (ou não) para gerar um modelo de informação clínica., Os recursos FHIR® são produzidos a partir de um super conjunto de dados encontrados em sistemas legados para serem diretamente utilizados pelos desenvolvedores. Estritamente falando, estes não são “modelos” uma vez que nenhuma da herança habitual, encapsulação de elementos comuns ou práticas de tipagem são usados. A utilização bem sucedida da norma FHIR® depende do grau de acordo alcançado entre as partes. Chegar a acordo desta forma é mais fácil de conseguir nas organizações por um pequeno número de partes interessadas, incluindo os médicos, do que acordos para atender redes mais extensas. Isto limita as oportunidades de reutilização de software .,
uma revisão de seis organizações de cuidados médicos responsáveis dos EUA voltou a sublinhar a necessidade de adoptar uma abordagem padrão. Verificou-se que aqueles que utilizaram um único sistema electrónico de registos de saúde através das suas redes de fornecedores, foram capazes de partilhar dados em tempo real, aumentando a capacidade dos fornecedores de coordenarem os cuidados de saúde. Outros tiveram acesso a robustos intercâmbios de informações de saúde que permitem o acesso a dados de pacientes de fornecedores externos. Apesar disso, observou-se que o pleno potencial da saúde não foi realizado.,e o resultado da baixa interoperabilidade comprometer a capacidade de atenção, resultando em:
•
a Dependência de outros meios para o compartilhamento de dados, incluindo chamadas de telefone e de fax,
•
Penoso e frustrante uso do Pce
•
Médico de burnout, devido à carga de trabalho associada com EHR de gestão,
•
o Acesso à saúde intercâmbios de informações com pouca ou incompleta de dados, criação de dificuldades em relação a coordenação dos cuidados,
•
Incapacidade de oferecer em saúde para pacientes de outros que portais online para o seu Pce
•
Incapacidade de usar o google analytics para personalizar o cuidado para atender individual necessidades do paciente.,
uma iniciativa do sector privado está actualmente a realizar um projecto destinado a promover a adopção pela indústria de normas de interoperabilidade modernas e abertas, conhecidas como o projecto Argonaut . O objetivo deste projeto é desenvolver uma API de primeira geração baseada em FHIR®e especificações de Serviços de dados de base para permitir uma ampla partilha de informações para registros eletrônicos de saúde e outras tecnologias de informação de saúde com base em padrões de Internet e padrões e estilos arquitetônicos. Este trabalho está sendo patrocinado por inúmeros fornecedores, incluindo Cerner, Epic e Accenture., O escopo deste trabalho é acelerar o desenvolvimento do modelo FHIR®, concentrando-se em perfis e documentação mais específicos FHIR®, incluindo um foco no acompanhamento de especificações de segurança e documentação para permitir a interoperabilidade entre sistemas proprietários legados, onde seus fornecedores controlam contratualmente o acesso aos dados. O uso dessas APIs cria riscos inerentes para erros e segurança do paciente devido ao mapeamento de dados.
as organizações de cuidados de saúde estão agora a gerir a rápida adopção do FHIR® e o maior uso de APIs., Do ponto de vista da infra-estrutura nacional, é necessário dispor de meios para facilitar a reutilização de alguns modelos chave FHIR® frequentemente utilizados. Estes podem ser escolhidos para se tornarem normas HL7 aprovadas. Sem a adoção de modelos padrão acordados, haverá uma proliferação de modelos FHIR® desenvolvidos para atender às necessidades locais, muitas repetições e inconsistências limitando o progresso nacional geral para alcançar um ecossistema digital de saúde bem conectado., Os modelos FHIR® não cumprem Convenções de modelagem bem conhecidas, como demonstrado por Beale, que concluiu que:
os recursos FHIR parecem ser o resultado de comitês separados que trabalham com quase nenhuma referência cruzada, metodologia ou base comum de design. O resultado é que cada recurso é algo como um “saco de atributos”, presumivelmente devido à aplicação da chamada regra 80/20 no contexto da Comissão.
FHIR® models need to consider a very large and unmageable number of data points., Esta limitação é ultrapassada pela adopção de modelos genéricos perfeitamente adequados para mensagens, mas não para armazenamento de dados clínicos semanticamente coerentes. O contexto é parte integrante da forma como os médicos processam a informação. O contexto deve ser considerado ao desenvolver sistemas de apoio à decisão ou de inteligência artificial, ao adotar várias estratégias de análise de dados, e para qualquer número de normas relevantes, incluindo as utilizadas para mapeamento de dados.,diz — se que os recursos FHIR® contêm um continuum de níveis ontológicos, têm duas características indesejáveis num modelo de informação estável: volatilidade
– recursos clinicamente específicos terão claramente de mudar ao longo do tempo. Como isso afeta os perfis dependentes é uma questão interessante;
abertura-deve-se presumir que o conjunto de recursos irá simplesmente continuar crescendo para acomodar novas grandes categorias de informação clínica.,
as consequências destes factores são que o modelo nunca está “acabado” e que quaisquer bases de dados ou software baseados nele necessitarão igualmente de manutenção contínua. Há outra questão associada ao processamento de informação a jusante para utilização de dados secundários. Isso é uma incapacidade de saber se estruturas de dados que parecem ser quase iguais podem ser tratadas da mesma maneira; o padrão com FHIR é que cada recurso é sua própria coisa ., Um especialista internacional de normas observou que:
FHIR® foi projetado e planejado como um padrão API/interchange, a maioria das principais organizações ITC (Google, Microsoft, IBM, etc) e pelo menos um grande fornecedor EHR (Cerner) adotaram FHIR® como um esquema de objetos persistência e esquema datastore. O FHIR® continua subespecificado a nível internacional, uma vez que a ligação de conjuntos de valores é relegada para guias de implementação (por exemplo, o Guia de implementação FHIR® dos EUA)., Dada a predisposição nacional atual para os códigos de Tecnologia da Informação de saúde nacional (HIT) (praticamente todos os países têm sua própria publicação de códigos de procedimentos, e estranhamente o mundo inteiro ainda não está usando ICD11) esta separação é altamente pragmática. As barreiras à interoperabilidade internacional HIT têm menos a ver com especificações de sintaxe técnica, e muito mais a ver com a tendência quase intratável dos países para especificar os seus próprios sistemas de codificação, por vezes proprietários.,
adopção do quadro arquitetônico openEHR requer o uso de uma abordagem de modelagem mais abrangente . Estes modelos podem ligar-se aos modelos FHIR® sempre que necessário, por exemplo, o arquétipo de risco de reacção adversa openEHR e o recurso de Resistência a Alergiintolerância FHIR® foram publicados e alinhados em conjunto no final de 2015., Os arquétipos incorporam o trabalho colaborativo realizado por uma grande comunidade internacional virtual de profissionais multidisciplinares, transformando os dados de saúde em uma forma eletrônica baseada em evidências (computável) para garantir a interoperabilidade universal dentro de qualquer ecossistema de saúde digital. Esta abordagem consiste de modelagem de fonte única e multi-nível dentro de uma arquitetura de software orientada a serviços delineada por um conjunto de especificações publicadas pela Fundação openEHR e livremente disponível para qualquer pessoa.,
o openEHR é uma especificação padrão aberta regida por uma fundação sem fins lucrativos, está disponível gratuitamente para ser implementado por qualquer desenvolvedor. As especificações OpenEHR, resultado de 25 anos de investigação e desenvolvimento, representam a única instanciação séria do modelo de referência ISO 13606 para a comunicação electrónica de registos de saúde que detalha uma estrutura hierárquica para a informação clínica . Esta norma está a ser cada vez mais utilizada em projectos maciços no Reino Unido, Noruega, Finlândia, Eslovénia e Alemanha., Também a China, o Chile, o Brasil, a Itália e as Caraíbas adoptaram esta abordagem. Na verdade, a ISO 13606 foi derivada da experiência do openEHR, e mais recentemente foi influenciada pela experiência com outras normas, incluindo o FHIR®. O trabalho de modelagem clínica é mais extenso do que o realizado em qualquer outro lugar anteriormente com uma comunidade voluntária de mais de 2000 pessoas de 93 países.os modelos clínicos do domínio ISO13606 conhecidos como” arquétipos ” são externos ao software., Cada arquétipo define um número máximo de possíveis pontos de dados e grupos de dados que se aplicam ao conceito modelado. Isto prevê um número máximo de contextos diferentes para atender a todas as especialidades clínicas e utilizações potenciais de dados. Os modelos, constituídos por uma camada de” recombinação “de modelos para definir conjuntos de dados, utilizam apenas os pontos de referência de um conjunto (qualquer número ou seleção) de arquétipos que são necessários para qualquer” caso de uso ” ou aplicação específica, como qualquer tipo de avaliação clínica., Modelos podem ser usados como definições de mensagens para sistemas legados, bem como conjuntos de dados para novas aplicações, incluindo formulários. Isto significa que qualquer conjunto de arquétipos pode ser reutilizado para vários casos de uso. Permite que partes significativas do software sejam derivadas de máquinas a partir dos arquétipos. Os arquétipos representam dados atômicos em um padrão aberto; um fator de sucesso crítico capaz de suportar mudanças na tecnologia, particularmente o intercâmbio e a persistência.,
estes “arquétipos” (modelos) estão a ser utilizados por várias aplicações, incluindo no Serviço Nacional de saúde do Reino Unido, onde são utilizados para a conversão de sistemas sombra que permitem a utilização de repositórios de dados neutros pelos vendedores. Outros usuários são: Queensland Health e alguns hospitais privados para seus sistemas de controle de infecção, uma série de instalações de saúde primária de Sydney ocidental e do território do Norte saúde compartilhada EHR, e parceiros da indústria openEHR cujos sistemas são amplamente implementados nos países escandinavos., Componentes e sistemas conformes são “abertos” em termos de modelos de dados e APIs. Estrategicamente, a abordagem openEHR tem um foco de saúde bem adequado para cuidados centrados no paciente. Esta abordagem permite um mercado de software baseado em plataforma ou “open back-end” em que fornecedores da indústria de saúde e desenvolvedores de soluções interface com os outros sistemas através de modelos de informação padronizados, modelos de conteúdo, terminologias e interfaces de serviço.,uma colaboração aberta de indivíduos, indústria, organizações de Normalização e prestadores de cuidados de saúde concordaram em trabalhar em conjunto para acelerar o desenvolvimento de normas abertas para a interoperabilidade no sector da saúde e social. Eles têm proporcionado um fórum colaborativo para compartilhar experiências e fornecer soluções destinadas a superar esta paisagem confusa. Em julho de 2018 eles publicaram uma visão geral do que foi descrito aqui . Verificou-se que estas muitas normas estão em processo de convergência. As normas FHIR® e openEHR não abordam o mesmo problema., Ambos criam modelos de informação clínica, mas os modelos openEHR (arquétipos) são fornecedores de dados independentes em plataformas openEHR. A FHIR® é uma aplicação centrada, uma vez que cria um modelo comum para ser utilizado em qualquer aplicação para, em seguida, formar a base para definir a interoperabilidade entre aplicações, independentemente dos modelos abertos ou proprietários em que foram construídas. Os que utilizam soluções de interoperabilidade centradas na aplicação fazem-no para permitir a utilização contínua de sistemas antigos dispendiosos.,
openEHR e FHIR® fornecem abordagens complementares mas diferentes para conectar uma complexa manta de retalhos de aplicações em um único sistema coerente . A abordagem openEHR centrada nos dados se concentra em normalizar os dados de saúde em primeiro lugar, e construir novos sistemas em cima dos sistemas legados para evitar as questões de interoperabilidade em conjunto. Trata-se de definir uma camada de dados dentro de uma arquitetura de sistema aberto. Esta é a camada mais importante, uma vez que facilita a utilização óptima de dados para melhorar os resultados, gerir melhor as doenças crónicas e permitir uma melhor gestão da saúde da população., Isso requer que os dados sejam armazenados em formatos neutros de fornecedores, em oposição aos formatos proprietários da maioria dos sistemas legados. A abordagem centrada nos dados permite o armazenamento de dados de saúde digital e a sua utilização durante todo o tempo de vida de qualquer paciente.
quase todos os sistemas baseados em openEHR estão atualmente desenvolvendo interfaces FHIR® para garantir que eles possam suportar a jornada do paciente entre os sistemas openEHR e não openEHR . o esquema de conectividade openEHR pode ser construído uma vez e compartilhado entre todos os fornecedores openEHR, uma vez que eles são baseados em arquétipos comuns openEHR., As aplicações agrupadas numa plataforma baseada no openEHR não precisam de soluções de intercâmbio como o FHIR® porque são capazes de comunicar directamente entre si através de repositórios de dados clínicos partilhados. Isso permite que os novos operadores do mercado se concentrem no desenvolvimento de aplicações verdadeiramente inovadoras e funcionalmente para atender às necessidades clínicas de nicho. A capacidade FHIR® só é necessária para permitir que eles se comuniquem com aplicações proprietárias de fornecedores de ecossistemas mais amplos .
Leave a Reply