Paciente no centro de todas as Informações - Parte 3

Healthshare - Unified Care Record

Todas as instituições de saúde hoje, sejam públicas ou privadas, enfrentam os mesmos desafios:

Como fazer com que todas as informações de cada paciente sejam facilmente transmitidas dos seus sistemas de origem para as pessoas que precisam delas e vice-versa?

E como utilizar todas estas informações para melhorar a tomada de decisões, a qualidade do atendimento e os resultados?

Para atingir estes objetivos e fazer com que a informação consolidada do indivíduo seja finalmente disponibilizada para os diversos usos é preciso que as informações fluam por uma série de processos que vão desde a coleta da informação no sistema de origem, o seu tratamento, até as diferentes formas de disponibilização para os usuários finais.

E é exatamente esta a especialidade do produto HealthShare Unified Care Record da InterSystems. Ele atua em todas as etapas do processo, de forma rápida, através de inúmeras ferramentas e funcionalidades, as quais explanarei a seguir:

Interoperabilidade e Governança

Esta etapa engloba todos os mecanismos de coleta e tratamento das informações nos sistemas de origem, seja através de API’s com protocolos específicos de saúde como o HL7, seja através de processos específicos ou customizados.

Neste ponto, é importante que a plataforma de integração assegure flexibilidade, governança e segurança, além de performance e escalabilidade. Se qualquer sistema de origem “cair” a plataforma deve ter mecanismos de notificação para o time que gerencia o processo, assegurando que se o sistema voltar nenhuma informação será perdida.

A plataforma deve ser escalável tanto para “plugar” novas fontes de informação, quanto para suportar todas as requisições dos consumidores e usuários.

É muito comum sistemas de prontuário eletrônico internacionais fornecerem nativamente exportações de dados usando o protocolo HL7, que neste caso também é nativo nos produtos da Intersystems.

Os sistemas nacionais geralmente demandam processos menos padronizados, e é por isso que é necessário que a plataforma seja de fácil e rápida implementação, e que esteja preparada para trabalhar com os sistemas de prontuário eletrônico conhecidos no mercado brasileiro e fornecer outras abordagens de captura de dados que não exijam que o sistema de origem tenha API’s prontas para fornecer as informações necessárias.

Gestão de Terminologia

Quando se junta informações de diferentes sistemas e fontes, se junta também inúmeros sistemas de codificações, sejam eles públicos ou proprietários. Exemplos: CID10, TUSS, LOINC, SNOMED CT, CBHPMl, etc.

Isso pode gerar uma dificuldade para interpretar todos estes distintos sistemas de codificação.

Um exemplo hipotético de terminologia:

0 sistema A registrou no episódio de atendimento de um determinado paciente o código “S53 – Luxação, entorse e distensão das articulações e dos ligamentos do cotovelo”, referente ao sistema de codificação CID10. O mesmo código foi registrado pelo sistema B com uma ligeira diferença na descrição, por exemplo “Luxação e dist. das art. e dos ligamentos do cotovelo”, sofrendo uma abreviação por uma questão de limitação do campo descrição no sistema de origem.

Se os diagnósticos tratarem da mesma pessoa e do mesmo sistema de codificação, o profissional usuário da informação consolidada espera ver e interpretar as informações apresentadas da mesma maneira, não com descrições distintas.

Se os diagnósticos tratarem da mesma pessoa, mas de sistemas de codificações distintos, é importante que o sistema ofereça mecanismos de De/Para das tabelas de codificação para serem aplicadas apenas no consumo das informações, facilitando assim a interpretação das informações aos seus usuários e a aplicação de algoritmos pelos cientistas de dados.

Também é fundamental que todo tratamento de terminologia não altere e mantenha a informação que foi registrada no seu sistema de origem, com o seu devido sistema de codificação. Esse princípio é importante para que se mantenha e respeite todo o lastro da informação original e evite interpretações equivocadas em função do tratamento do dado.

Modelo Canônico de Dados e múltiplas formas de “input” ou consumo

Considerando apenas trocas de informações da área da saúde, há uma infinidade de protocolos. Temos por exemplo o HL7v2, o CCD, o PIX, o PDQ, DICOM para imagens, ASTM para laboratórios e o mais moderno HL7 FHIR, em diversas versões. No mercado nacional temos o TISS, que é utilizado para a saúde suplementar, entre muitos outros.

Todos estes padrões de interoperabilidade carregam informações relevantes do paciente e muitos deles são baseados em modelos de dados completamente distintos. E mesmo quando não surge um novo, todos estes citados anteriormente sofrem constantes atualizações. Sem considerar os modelos de mensagens proprietários no mercado brasileiro.

Levando em conta toda a variedade e dinamismo das mensagens, a InterSystems decidiu construir um modelo de dados central chamado de SDA (Summary Document Architecture) que fosse de simples entendimento, extensível e completo o suficiente para realizar a tradução, importação e exportação de todos estes protocolos que carregam as mensagens dos pacientes.

Isso dá uma enorme vantagem para quem irá construir regras de negócio para notificações clínicas, para sistemas de decisões clínicas (CDSS), algoritmos de predição ou para quaisquer outros processos ou fluxos de negócio.

Isso porque não exige que o especialista do negócio conheça os protocolos de entrada e saída, mas sim de apenas um único modelo de dados extremamente simplificado.

Outra vantagem é que a própria InterSystems mantem atualizada as bibliotecas de transformações dos protocolos conhecidos, tanto de entrada (captura) quanto de saída (consumo) para este modelo canônico central.

Gestão de Consentimento

Em 2018, o Brasil passou a fazer parte dos países que contam com uma legislação específica para proteção de dados e da privacidade dos seus cidadãos. Isso significa que os dados pessoais e sensíveis não podem ser deliberadamente utilizados sem a obtenção da expressa autorização do seu proprietário.
Mesmo antes de entrar em vigor esta legislação, a plataforma HealthShare já contava com as seguintes funcionalidades:

• Cadastrar e manter políticas de consentimento dos dados em nível de ecossistema, de estabelecimento, ou por indivíduo, dando a opção de quais dados serão utilizados e para qual finalidade.
• Armazenar o registro do consentimento, considerando-o também como parte das informações do paciente.
• Aplicar as políticas de consentimento em toda a plataforma, fornecendo aos consumidores logs e mensagens específicas do motivo da não exibição de determinado grupo de informação.
• Fornecer API’s para que além da plataforma, outros sistemas e usuários possam acessar e utilizar estes registros de consentimento.

Visualizador Clínico, Serviços e API’s

Depois que todas as informações do paciente são captadas, normalizadas e trabalhadas pela plataforma em todas as etapas descritas anteriormente, elas são disponibilizadas através de serviços na plataforma de Registro Unificado de Saúde.
O consumo destes serviços pode ocorrer de diversas maneiras, partindo de diferentes profissionais ou sistemas de informação.

A plataforma HealthShare Unified Care Record fornece nativamente as seguintes formas:

• Visualizador Clínico: Trata-se de uma aplicação responsiva que exibe aos profissionais de saúde e times de cuidado todas as informações relevantes do paciente. Nesta aplicação é possível visualizar todo o histórico evolutivo dos exames do paciente, as alergias, os sinais vitais, os exames e laudos de radiologia, etc. Essa aplicação pode ser acessada através do próprio sistema de prontuário eletrônico ou vista através de um “frame” embutido no mesmo.
• Mensageria: Consiste na entrega de mensagens clínicas, alertas ou notificações clínicas utilizando todo o potencial da plataforma de interoperabilidade e a riqueza das bibliotecas e protocolos disponíveis.
• API’s de Consumo: A plataforma fornece um conjunto de API’s para trabalhar com todos os tipos de interações com a plataforma. Por exemplo:
Serviços de Interação com o Master Patient Index (PIX, PDQ, Golden Record, etc.)
Serviços de Gestão de Consentimento, podendo ser acessado por outros sistemas para fins de LGPD.
Serviços de Cadastro de Usuários e Profissionais possibilitando a sincronização com o Single Sign-On da Organização.
Serviços de Auditoria (ATNA). Qualquer interação com a plataforma gera um registro de log.
Serviços de obtenção do Registro Unificado do Paciente, expostos de inúmeras formas (Documento PDF, TXT, XML, JSON, CDA, CCD, HL7, etc.)
HL7 FHIR: Possibilita o acesso aos dados do paciente utilizando as últimas versões do poderoso protocolo HL7 FHIR e todas as suas capacidades.

Conclusão

O que as instituições estão buscando, cada vez mais, é uma abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.

E para viabilizar de forma completa este objetivo tão almejado, é preciso que todas as informações do indivíduo sejam colocadas dentro de uma mesma “caixa”, independentes do local, da instituição, do sistema, da tecnologia e do tipo de informação que é coletada, podendo ser de saúde, administrativo financeira, assistencial, comportamental e social, registro das interações do paciente com a instituição, autorizações do convênio, etc.

É literalmente colocar o paciente no centro de tudo. É quebrar a fronteira dos silos e fazer uso das informações para o benefício do paciente e consequentemente de todos os que estão envolvidos no processo que o suporta.