Mirth Connect: diferenças entre revisões

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
Linha 13: Linha 13:
=Canais e conetores=
=Canais e conetores=
[[Ficheiro:Mirth_Connect_Canais_Conetores.png|commoldura|centro|Esquema de funcionamento de um canal]]
[[Ficheiro:Mirth_Connect_Canais_Conetores.png|commoldura|centro|Esquema de funcionamento de um canal]]
Mirth é baseado em canais que são interfaces de conexão que filtram, transformam e encaminham mensagens desde uma origem para um ou mais destinos. Estes canais podem ainda ser encadeados para uma lógica mais complexa.
Mirth é baseado em canais que são interfaces de conexão que filtram, transformam e encaminham mensagens desde uma origem para um ou mais destinos. Estes canais podem ainda ser encadeados para uma lógica mais complexa.<ref name="ref 4">http://bridge.mirth.com/media/3244/mirth-data-sheet-mirth-connect-3-3-user-guide.pdf</ref>
Um canal é composto por uma origem e, pelo menos, um destino. Tanto a origem como os destinos são conetores.
Um canal é composto por uma origem e, pelo menos, um destino. Tanto a origem como os destinos são conetores.
Os conetores têm como parâmetro entrada uma mensagem num determinado formato e como parâmetro de saída uma mensagem noutro formato. O destino de saída pode ser outro sistema ou outro conector de saída.
Os conetores têm como parâmetro entrada uma mensagem num determinado formato e como parâmetro de saída uma mensagem noutro formato. O destino de saída pode ser outro sistema ou outro conector de saída.

Revisão das 23h01min de 17 de abril de 2016

Plataformas de Integração na área da Saúde

As plataformas de integração, também conhecidas por motores de integração, têm por objetivo resolver os problemas de partilha e troca de dados entre sistemas de informação heterogêneos. Hospitais e outros prestadores de cuidados de saúde normalmente têm sistemas distintos que são incapazes de comunicarem uns com os outros. Plataformas de integração tem como objetivo conectar aplicativos fazendo mapeamento e transferência de dados entre os aplicativos que usando padrões e definições de dados compreendido nativamente por cada aplicação.

Introdução ao Mirth Connect

Mirth Connect Logo Util.png

Mirth Connect é um motor de integração, open source e cross-platform[1], que permite o envio bidirecional de mensagens entre sistemas de informação e aplicações clinicas ou administrativas.[2] Utiliza uma arquitetura baseada em canais de envio e recepção e permite que as mensagens sejam filtradas, transformadas e reencaminhadas. Existem vários sistemas de informação distintos e vários standards definidos na área da saúde, com diversos tipos de dados e protocolos de transmissão. Alguns sistemas podem usar standards definidos, como HL7, X12 ou DICOM, outros não oferecem qualquer interoperabilidade dispondo apenas de uma base de dados ou comunicam via XML ou até ficheiros de texto, torna-se evidente o problema de interoperabilidade na área da saúde. Mirth Connect pode colocar-se entre qualquer número de sistemas de informação ajudando-os a comunicar independentemente se usam ou não standards. Mirth é um componente de middleware flexível que pode desempenhar muitos papeis.[3] Pode proporcionar troca de integração central num Hospital, um gateway de uma clínica ou laboratório de referencia. Com um interface intuitivo e usando JavaScript para mapear dados, Mirth acelera o desenvolvimento de interfaces para troca segura de dados em formatos variados. Por exemplo, podemos transformar um ficheiro de texto separado por virgulas (CSV) em HL7 ou vice-versa. Esta facilidade de utilização reduz as barrerias para a criação de intercâmbio de informações envolvendo vários sistemas de informação diversificados e facilita iniciativas destinadas a melhorar a continuidade dos cuidados e segurança do doente.

Canais e conetores

Esquema de funcionamento de um canal

Mirth é baseado em canais que são interfaces de conexão que filtram, transformam e encaminham mensagens desde uma origem para um ou mais destinos. Estes canais podem ainda ser encadeados para uma lógica mais complexa.[4] Um canal é composto por uma origem e, pelo menos, um destino. Tanto a origem como os destinos são conetores. Os conetores têm como parâmetro entrada uma mensagem num determinado formato e como parâmetro de saída uma mensagem noutro formato. O destino de saída pode ser outro sistema ou outro conector de saída. A saída de um conector de origem está ligado a entrada dos conectores de destino, por sua vez o canal pode responder ao sistema que enviou a mensagem usando a saída de um dos seus destinos, fechando assim o circuito. Este circuito denomina-se por ResponseMap. Um canal tem uma configuração global que pode armazenar mensagens criptografadas numa base de dados e definir o tipo ou duração do armazenamento. Permite a execução de scripts em determinados momentos, por exemplo antes da origem receber a mensagem (pre-processor scripts) e logo após os destinos enviarem as mensagens (post-processor scripts). Cada canal tem ainda uma estrutura de dados para armazenar variáveis no âmbito dos conetores (ConnectorMap) ou do próprio canal (ChannelMap). A operação de cada canal depende do tipo de conetor em questão, a grande variedade de tipos conetores para a origem e para o destino é o que torna o Mirth uma ferramenta tão versátil.

Filtros e Transformadores

Esquema de funcionamento de um canal

Independentemente do seu tipo, cada conetor tem uma entrada e uma saída e nele podem ser definidos filtros e transformadores. Filtros são regras que determinam se o conetor deve continuar a execução. Normalmente utilizam-se expressões booleanas comparando valores de atributos, podemos ainda executar código JavaScript o que torna estes filtros muito versáteis. Transformadores são responsáveis por fazer as composições necessárias para criar a mensagem de saída a partir da mensagem de entrada, com a ajuda de modelos de processamento. Esta transformação pode ser um simples mapeamento de atributos entre a mensagem de entrada e a de saída ou à semelhança dos filtros executar código JavaScript aumentando a versatilidade. Existe a possibilidade de definir uma mensagem modelo quer para a entrada (Inbound Message Template) quer para a saída (Outbound Message Template), para facilitar quer a definição dos filtros ou dos transformadores.

Conclusão

A combinação de código aberto e uma abordagem baseada em padrões para a interoperabilidade em saúde tem-se afirmado como a resposta a vários dos problemas existentes.

Referências