O InterSystems HealthShare é uma plataforma de informática em saúde para hospitais, redes integradas de distribuição (IDNs) e intercâmbios regionais e nacionais de informações (HIE). O HealthShare inclui o intercâmbio de informações em saúde, agregação de dados, fluxo de trabalho, análise de texto e tecnologia analítica.
A InterSystems corrigiu um defeito que pode ocasionar resultados incorretos a partir de consultas SQL.
Este defeito existe apenas na versão 2021.2 (Entrega Contínua - CD) dos produtos:
InterSystems IRIS Data Platform
InterSystems IRIS for Health
HealthShare Health Connect
Olá Desenvolvedores,
Fiquem atualizados em relação às recentes alterações ao Provider Directory e Patient Index. Deem uma olhada no que está por vir:
⏯ Provider Directory & Patient Index: O que tem de novo e o que está por vir
13 de Dezembro de 2021 - Alerta: Vulnerabilidade na biblioteca Log4j2 da Apache e Impacto nos Produtos InterSystems
A InterSystems esta investigando no momento o impacto da vulnerabilidade reacionada ao Apache Log4j2.
A vulnerabilidade — impactando o Apache Log4j2 (versões 2.0 até 2.14.1) — foi recentemente anunciada pela Apache e está reportada na Base de Dados Nacional de Vulnerabilidade dos Estados Unidos (United States National Vulnerability Database (NVD)) como CVE-2021-44228 possuindo a maior classificação de severidade, 10.0.
Os kits InterSystems incluem um servidor web Apache que permite aos cliente uma forma conveniente de interação com o Portal de Administração do Caché/IRIS sem a necessidade de se instalar um servidor web externo; entretanto este servidor web nunca deve ser utilizado em instâncias de produção, e clientes devem instalar um servidor web que atendam a suas necessidades específicas e requisitos de segurança/risco.
26 de Outubro de 2021 – Alerta: Locks Faltando depois de um Reinício ou Failover de Servidor de Base de Dados ECP
A InterSystems corrigiu um defeito que pode violar as garantias de lock de aplicações em um cluster de cache distribuído (configuração ECP), que pode levar a problemas de integridade na aplicação. Este defeito afeta:
Olá Desenvolvedores !
Não percam esta oportunidade de aprender um pouco mais sobre a tecnologia InterSystems diretamente de nossa equipe, ao vivo, de forma prática e de graça !!!!
Olá Desenvolvedores !
É um prazer anunciar mais um evento com participação da InterSystems. Desta vez o evento será no World Trade Center Business Club.
.png)
Olá Desenvolvedores !
A Intersystems marca presença e patrocina o Fórum Healthcare Business, que acontece em Natal - RN. A 9ª edição do fórum traz o tema Liderança em saúde: resiliência no mundo após a pandemia.
O evento será presencial e contará com a presença do nosso diretor, Dr. Raimundo Nonato B. Cardoso, que irá participar do debate sobre:
Tecnologias alavancadas pela pandemia
Quais serão as soluções tecnológicas mais requisitadas e quais serão substituídas na era pós-covid?
Olá Desenvolvedores,
A InterSystems e a MIT Sloan lhes convidam para participar deste webinar onde serão debatidos e apresentados cases de sucesso do uso de tecnologia para alcançar mais qualidade e efetividade no atendimento de saúde em um país como o Brasil.
O evento será online e gratuito !!!! Inscreva-se já.
Olá Desenvolvedores !
A sétima edição do HIS – Healthcare Innovation Show está trazendo discussões importantes sobre inovações aplicadas à área de saúde e como ser mais eficiente, seguro e oferecer a melhor experiência ao cliente/paciente.
O evento contará com a presença de nosso diretor, Dr. Raimundo Nonato B. Cardoso, que abordará o tema:
Interoperabilidade Clínica Estratégica
.png)
O evento é online e gratuito, inscreva-se agora mesmo !
Olá Desenvolvedores.
A Digital Journey by Hospitalar, segunda edição, vai começar, com discussões importantes. A InterSystems participa de um painel sobre o desafio de atender a massa de procedimentos clínicos represados pelo isolamento social, que serão desovados no sistema público e suplementar de Saúde. Venha discutir conosco.
Teremos a participação do nosso diretor Dr. Raimundo Nonato Benevides Cardoso.
Olá Desenvolvedores,
Não percam o Dr. Raimundo Nonato Benevides Cardoso, diretor de desenvolvimento de negócios de saúde da InterSystems, em uma palestra sobre o modelo da Medicina do amanhã, focada nos princípios de que os serviços de saúde devem ser Preditivos, Preventivos, Proativos, Personalizados e baseados em Parceiros – daí os 5Ps.
Inspire-se! Inscreva-se!
Olá Comunidade,
Nós estamos querendo seus comentários sobre nossa nova oferta - Serviços de Transformação de Mensagens HealthShare.
O serviço foi publicado no Marketplace da AWS onde você pode testá-lo de graça!
Nós lançamos um desafio relacionado no Global Masters onde você pode ganhar pontos testando o serviço e um prêmio de "obrigado" a todos que deixarem os comentários a respeito da utilização do serviço nesta postagem.
Conversando com um amigo especialista em Machine Learning @Renato Banzai , um dos pontos que ele me passou e que hoje é um dos grandes desafios de Machine Learning das corporações é realizar o deploy de modelos de ML/AI em produção.
|
|
|
|
|
|
|
|
|
|
|
|
|
Olá Desenvolvedores !
O evento Fórum Saúde Digital, que acontece virtualmente nos dias 29 e 30 de junho, contará com a presença da InterSystems entre os painelistas. Em sua 12ª edição, o evento discutirá os avanços da tecnologia em toda a cadeia da Saúde, o impacto de tecnologias como Inteligência Artificial, Big Data, dispositivos móveis e Telemedicina.
Olá a todos,
O setor de Certificações InterSystems criou um novo exame de certificação e gostaríamos do feedback de nossa comunidade como forma de nos auxiliar com a validação dos tópicos do exame. Aqui está a sua chance de dar sua opinião sobre o conhecimento e habilidades necessárias a um Especialista de Implementação Técnica CCR InterSystems deve possuir.
Aqui está o título do exame e a sua definição:
Especialista de Implementação Técnica CCR InterSystems
Um profissional de desenvolvimento que:
Olá Comunidade!
A agenda de treinamentos de Outubro de 2021 para turmas virtuais ao vivo (em inglês) com exercícios práticos (hands-on) já se encontra disponível em classroom.intersystems.com.
Em particular, gostaríamos de destacar alguns dos cursos:
Clique aqui para se registrar para um dos cursos!
Olá Pessoal,
Estou com um problema na hora de criar uma base de dados remota (via ECP), quando seleciono o campo diretório remoto ele apresenta o erro abaixo:
Alguém já passou por isso?
Olá Comunidade!
Estou procurando nas documentações do HS como posso criar um menu custom e associar no Clinical Viewer chamado um tela ZEN custom, porém não estou encontrado nada sobre.
Poderia me da um norte como posso chegar nesse ponto?
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:
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.
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.
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.
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.
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.
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.
Estou tentando executar uma tarefa pelo terminal, utilizando:
set test=##class(%SYS.TaskSuper).%New()
d test.RunNow(1), passando o ID da tarefa, para executa-lá, porém ela não executa.
Qual seria um outro jeito para que eu consiga realizar essa execução pelo terminal?
Caro Cliente de HealthShare:
Esta postagem é parte do processo de comunidação de Alertas do HealthShare HS2021-03. A mesma informação foi divulgada através de:
Nós somos uma Rede de Informações de Saúde multiestado procurando analistas de integração com experiência para preencher posições de forma imediata. Atualmente estas posições são para trabalho 100% remoto. Excelentes benefícios.
Enterprise Master Patient Index - Este é o nome dado ao processo que faz com que os inúmeros cadastros e registros coletados dos vários sistemas das instituições e redes de saúde sejam identificados univocamente e interligados através de um identificador único por indivíduo.
Isto viabiliza uma infinidade de benefícios para as instituições ou redes de saúde, pois permite, além da gestão das duplicidades em um mesmo sistema de prontuário eletrônico, que todos os dados segregados por número de cadastro sejam visualizados de forma consolidada por indivíduo. Cada vez mais, as instituições estão buscando uma abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.
Falando sobre o produto Healthshare Patient Index da InterSystems, podemos dividi-lo em 6 grandes grupos de funcionalidades.
Esta etapa engloba todos os mecanismos de coleta 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 ofereça uma série de requisitos de interoperabilidade que assegure flexibilidade, governança e segurança.
É 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.
Geralmente as informações são enviadas ou disponibilizadas no momento em que o paciente é admitido nos estabelecimentos de saúde.
A arquitetura deste processo é definida conforme as necessidades de cada organização e disponibilidade dos recursos computacionais.
Normalizar significa trazer para um mesmo plano de comparação informações demográficas que foram cadastradas de formas completamente diferentes. É também nesta etapa que todo o “lixo” é removido. Isto não quer dizer que a informação seja ruim, mas que não serve para o processo do MPI.
Se os dados fossem comparados sem esta etapa, provavelmente cadastros de um mesmo indivíduo nunca seriam comparados, dada à discrepância de sistema para sistema.
Se observarmos o processo de cadastro de cada estabelecimento e sistema de origem, veremos uma infinidade de formas de entrada dos dados e diversas maneiras de armazenamento das informações. Isso depende de como cada sistema foi concebido e como cada processo foi implementado em cada setor da organização.
Um exemplo típico é o processo de admissão em alas emergenciais. Muitas vezes o paciente precisa ser atendido antes mesmo de ser identificado. Isso gera uma série de especificidades que precisam ser tratadas em uma análise qualitativa antes mesmo da implementação do processo de captura dos dados.
O outro exemplo muito comum é o cadastramento de recém nascidos. Cada caso é um caso. Em alguns sistemas os nomes são cadastrados com um prefixo “RN DE” seguido pelo nome da mãe. Isso porque os pais não sabem o nome dos bebês antes do parto e eles já precisam constar nos sistemas de prontuário eletrônico. Como todos os sistemas geralmente exigem o CPF, eles podem ser cadastrados com o mesmo CPF da mãe. É claro que este é só um exemplo de uma situação pontual, mas cada caso deve ser estudado e endereçado da forma mais adequada possível.
Além das especificidades de processo, há as que são de armazenamento dos dados. Documentos como CPF, RG e carteirinhas de seguro são armazenados com pontos e traços em alguns sistemas. Em outros são armazenados sem. O mesmo ocorre com datas. Nomes geralmente são armazenados em um único campo, uns com caixa baixa, outros com alta. Alguns são abreviados pela limitação de caracteres.
Endereços são os vilões na normalização. Os sistemas mais modernos são baseados no CEP, outros não. Os que não são sofrem muitas abreviações devidos aos sufixos, títulos ou até mesmo pela limitação dos caracteres.
Enfim, mesmo que em instituições mais modernas tecnologicamente, há sempre os sistemas legados. Estes também são incorporados ao processo de MPI porque trazem informações históricas valiosas para todo o processo assistencial.
Culturalmente e diferentemente dos sistemas norte americanos, os sistemas brasileiros possuem um único campo para capturar os nomes. Para melhorar a eficácia do processo de vinculação é importante que os sistemas tenham a capacidade de separar os nomes, considerando também os primeiros nomes compostos.
Outra capacidade não menos importante é a capacidade de trabalhar com as abreviações nos endereços. Isto requer um dicionário específico de abreviações para o nosso país.
Nesta etapa é que se decide quais serão os cadastros que serão comparados entre si, formando assim os chamados pares de comparação.
A decisão de se comparar registros não se baseia apenas nos documentos do paciente, assim como o CPF. Isso acontece porque há casos que não se tem o CPF do paciente ou casos que os filhos recebem o CPF dos pais. Para isto é necessário que o processo utilize os dados probabilísticos, assim como o nome, a data de nascimento, o sexo, os dados de contato e o endereço.
É preciso que este processo tenha algoritmos sofisticados para que os sistemas não gerem um número excessivo de comparações indevidas, assim como não deixem de fora comparações necessárias.
Por exemplo: A comparação de todos os “Josés” com todos os outros “Josés” não seria tão eficaz, pois poderia acarretar numa sobrecarga de processamento.
Outro ponto não menos importante nesta fase é a capacidade de se trabalhar com algoritmos fonéticos para o mercado brasileiro, que são completamente diferentes dos algoritmos americanos.
Isso significa que nomes escritos de maneiras diferentes ou equivocadas também serão considerados no processo. Exemplo: Dois cadastros de um determinado paciente com os nomes Walter Xavier e Valter Chavier podem se referir ao mesmo indivíduo.
O Healthshare MPI utiliza um processo extremamente eficiente de análise combinatória que evita este tipo de problema, utilizando tanto informações demográficas determinísticas quanto probabilísticas.
Para cada par de comparação gerado, todas as variáveis demográficas são pontuadas separadamente: Primeiros nomes, nomes do meio, sobrenomes, documentos, sexo, cep, telefones, e-mails e endereços.
Antes de iniciar a comparação, é determinado um peso com uma pontuação máxima e mínima para cada variável, considerando a singularidade de cada uma. Por exemplo, o sexo possui um peso menor que a data de nascimento, que possui peso menor que o nome, que possui um peso menor que o CPF. E assim por diante.
Cada variável possui um algoritmo específico não binário de comparação que vai atribuir uma pontuação entre a mínima e a máxima para cada variável demográfica.
Exemplo: Se o sexo for o mesmo, serão atribuídos 2 pontos. Se não for o mesmo será atribuída a pontuação mínima, -4 pontos. Se o CPF for o mesmo, serão atribuídos 14 pontos,
Primeiros nomes e sobrenomes comuns também recebem pontuações menores que nomes mais comuns, assim como Silva e Souza.
Nomes de casada e solteira também devem ser considerados aqui no Brasil.
Antes desta etapa, é necessário configurar as faixas de pontuação ou limiares que serão utilizados para vincular (mesmo indivíduo) ou não vincular (indivíduos diferentes) os pares de cadastro.
Neste ponto, pode-se definir também a faixa de pontuação dos pares que irão para uma lista de trabalho, passíveis de uma avaliação ou revisão humana.
Limiares a serem configurados:
Vínculo Automático – Acima de quantos pontos os pares serão automaticamente vinculados. Exemplo: Se o total de pontos dos pares estiver acima de 35 os mesmos serão automaticamente vinculados e não necessitarão de revisão humana.
Vínculo com posterior avaliação na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como vinculados (mesmos indivíduos) para avaliação humana. Exemplo: Os pares entre 30 e 35 pontos serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.
Não vínculo – Abaixo de quantos pontos os pares não serão vinculados. Exemplo: Se o total de pontos dos pares for abaixo de 30 eles não serão vinculados (indivíduos diferentes).
Não vínculo com revisão posterior na Lista de Trabalho – Entre quantos pontos os pares irão para a lista de trabalho como não vinculado (indivíduos diferentes) para uma revisão humana. Exemplo: Os pares entre 25 e 30 pontos não serão vinculados, mas poderão sofrer revisão de um profissional ou equipe designados para esta tarefa.
Há várias situações de exceções, onde mesmo pares com pontuação elevada podem não se referir ao mesmo indivíduo. Um exemplo típico são os gêmeos, que moram na mesma residência. Para isso é necessário que o produto disponibilize de artifícios para identificar estes casos.
Há outras situações que pares com baixa pontuação podem sofrer revisões se determinadas situações ocorrerem. Exemplo: pares com o mesmo CPF e data de nascimento e baixa pontuação. Este caso é no mínimo curioso, pois pode apontar um problema na baixa qualidade dos dados.
No HealthShare Patient Index, estes dispositivos são chamados de regras de vinculação (rules), que prevalecem sobre a regra de pontuação.
O produto já possui nativamente uma série de regras de exceção e elas são fundamentais para a segurança e confiabilidade de todo o processo.
Após esta etapa, todos os cadastros recebem um identificador universal denominado MPIID - Master Patient Index Identification. Os cadastros que possuírem o mesmo MPIID são referentes ao mesmo indivíduo.
Concluindo todo o processo de vinculação (Matching), é essencial que a plataforma ofereça maneiras passivas ou ativas de se comunicarem ou interoperarem com os sistemas de origem ou outros sistemas. Neste momento entram novamente todos os requisitos de interoperabilidade do produto, que já estão presentes na plataforma HealthShare da Intersystems.
As API’s de consumo do MPI são disponibilizadas neste momento através de protocolos conhecidos (HTTP Soap ou Rest) para que sistemas consigam obter as informações desejadas para diversos casos de uso.
Estes são alguns exemplos comuns de consumo de API’s do HealthShare MPI:
• Obter identificadores de outros sistemas partindo do identificador do sistema consumidor. Este tipo de consulta é denominada pelo IHE como PIX. Exemplo: Antes de enviar a prescrição para o laboratório o sistema de origem envia o seu identificador do cadastro e recebe uma resposta da API com o número do identificador do mesmo paciente no laboratório.
• Realizar pesquisas probabilísticas por dados demográficos. Exemplo: Consultar se existem cadastros demográficos para o paciente de nome Claudio Devecchi Junior. Este tipo de consulta é denominada pelo IHE como PDQ).
• Obter o melhor dado demográfico (Golden Record ou Composite Record) de um determinado paciente para enriquecer os cadastros demográficos ou para aproveitar os seus dados no momento de um determinado cadastro.
Existem também mecanismos ativos, onde o MPI se comunica com os sistemas para enviar informações úteis. Estes mecanismos também podem ser acionados de forma passiva através da chamada das Api’s.
Alguns exemplos são:
• No momento que um cadastro está sendo incluído ou atualizado o MPI pode fazer uma chamada retornando o identificador universal - MPIID. Desta forma o sistema de origem sempre ficará atualizado com este identificador. Quaisquer mudanças nas Listas de Trabalho são gatilhos para este tipo de chamada (callback)
• Quando algum cadastro for incluído e o MPI identificar que já existe esta mesma pessoa no mesmo sistema de origem, já é possível enviar uma notificação de duplicidade. Para os casos de resolução das duplicidades, é importante que exista um serviço específico para receber as mensagens de fusão de pacientes (PIX merge).
Todo o processo descrito anteriormente demonstra um pouco de como o produto HealthShare Patient Index trata dos desafios na área com relação aos cadastros e identificação dos pacientes e como é importante tratar das especificidades não somente do país, mas de organização para organização.
No próximo artigo, falaremos um pouco de como funciona o Healthshare Unified Care Record (UCR) e de como ele é fundamental para ajudar as instituições na abordagem holística do cuidado contínuo, da prevenção e da experiência centrada no paciente.
*Analista Ensemble Júnior / Pleno
Próximo Metrô Clínicas
REQUISITOS:
* COS / Portal
* Conhecimento em barramento e protocolos RESTFull / SOAP
* Integração com banco de dados Oracle / SQL Server
ATIVIDADES:
* Integração de sistemas hospitalares
* Administração do ambiente Ensemble
* Análise de Dados
Enviar CV com pretensão salarial
.
Contratação CLT ou PJ tempo indeterminado
Empresa ..................: JHealth Informatics
Email ........................: rh@jhealth.com.br
Quando se fala em tecnologia da informação nas instituições de saúde, principalmente nos hospitais e organizações de medicina diagnóstica, os CIO’s e a área de TI sabem muito bem que para que tudo funcione bem, é necessário que um número muito grande de sistemas e aplicações funcionem de maneira integrada.
Talvez a área da saúde seja uma das áreas mais heterogêneas do ponto de vista de negócio, pois engloba além da gestão administrativo financeira, hospitalar, clínica e diagnóstica, uma infinidade de outros sistemas, como o sistema de controle de estacionamento, de hotelaria, dos restaurantes, da recepção, de farmácias, etc. Isso sem contar os sistemas de informação das empresas terceirizadas.
Com tudo isso, é quase que impossível concentrar em um único sistema ou banco de dados todas as informações geradas durante o ciclo completo de atendimento de um paciente. É muito comum, por se tratar de sistemas, de tecnologias e fornecedores diferentes, que uma única pessoa tenha sido cadastrada facilmente em mais de dez sistemas e bancos de dados diferentes, com identificações próprias para cada um.
Considerando todo este cenário, para conseguir operacionalizar os processos, é imprescindível que as empresas tenham plataformas que promovam a interoperabilidade destes sistemas, assim como o IRIS for Health e Health Connect da InterSystems.
Em outras palavras, é preciso que os sistemas “se conversem” para que as informações geradas sejam automaticamente integradas de um sistema para outro, mantendo assim uma consistência e compatibilidade, mesmo que em sistemas e bancos de dados separados.
Ainda assim, as informações podem ser geradas e coletadas em momentos diferentes. Exemplo: Um determinado paciente passou pelo atendimento em uma clínica e neste evento foi orientado a realizar exames específicos na mesma ou em outra instituição e retornar quando os exames estivessem prontos. Além do cadastro e da coleta de informações demográficas deste paciente na clínica, foram realizados outros cadastros no momento da admissão deste paciente nos sistemas de medicina diagnóstica.
Ou seja, se levarmos em conta o processo assistencial de uma única pessoa, teremos informações pertencentes a diferentes cadastros, sob identificações e dados demográficos distintos, coletados por pessoas e de maneiras diferentes.
O fato é que se as empresas não fizerem nada para tratar especificamente desta questão, elas ficarão reféns da segregação dos dados gerados por cadastro, e não consolidados por indivíduo, independentes de quando e onde o mesmo foi atendido. Sempre terão uma visão parcial e não integral de todo o processo, tanto para fins assistenciais, quanto para quaisquer outros fins.
Cada vez mais, os gestores e profissionais de saúde sabem do valor de se ter a visão consolidada de todas as informações geradas em torno do paciente, independentes do tempo e do local, sejam elas administrativas, financeiras, comportamentais e principalmente relacionadas à saúde. Se pararmos pra pensar, nós mesmos gostaríamos de ver num único aplicativo todos os nossos dados de saúde, como os exames por exemplo, independente da instituição que nos atendeu.
Este sonho já está virando realidade em muitas instituições. Graças às plataformas de saúde como InterSystems Healthshare, e produtos como Healthshare Patient Index é possível levar a gestão de informações na área da saúde para o próximo patamar.
No próximo artigo, falaremos um pouco de como funciona o Healthshare Patient Index e de como ele é fundamental para ajudar as empresas a visualizarem o paciente como um único indivíduo e não apenas como um ou mais cadastros.
Boa tarde, estou desenvolvimento uma demo com iKnow, e gostaria de saber como eu acesso dados do healthshare?
Posição: Desenvolvedor Intersystems / IRIS
Local de trabalho: 100% Remoto
Duração: 6 Meses de contrato
Habilidades: Cache DB, Object Script, Intersystem, Ensemble (versão mais antiga )Healthconnect (versão intermediária), Healthshare(última versão), Mumps
Requisitos principais:
confiram as sessões de foco em interoperabilidade FHIR ao vivo esta semana.
