Mirth Connect: diferenças entre revisões

Fonte: aprendis
Saltar para a navegaçãoSaltar para a pesquisa
Sem resumo de edição
 
(Há 4 edições intermédias do mesmo utilizador que não estão a ser apresentadas)
Linha 1: Linha 1:
Miguel Duarte<br />
Mestrado de Informática Médica<br />
Universidade do Porto<br />
[mailto:up201501636@med.up.pt up201501636@med.up.pt]
=Plataformas de Integração na área da Saúde=
=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.
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.
Linha 10: Linha 16:
Mirth é um componente de middleware flexível que  pode desempenhar muitos papeis.<ref name="ref 3">http://timreview.ca/article/205</ref> Pode proporcionar troca de integração central num Hospital, um gateway de uma clínica ou laboratório de referencia.
Mirth é um componente de middleware flexível que  pode desempenhar muitos papeis.<ref name="ref 3">http://timreview.ca/article/205</ref> 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.
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=
=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.
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.
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.
Na tabela seguinte podemos ver os diferentes conetores disponíveis separados pelos conetores de origem e destino<ref name="ref 4"/>
{| class="wikitable"
! Source Connectors
! Destination Connectors
|-
| Channel Reader
| Channel Writer
|-
| DICOM Listener
| DICOM Sender
|-
| Database Reader
| Database Writer
|-
| —
| Document Writer
|-
| File Reader
| File Writer
|-
| HTTP Listener
| HTTP Sender
|-
| JMS Listener
| JMS Sender
|-
| JavaScript Reader
| JavaScript Writer
|-
| —
| Mirth Results Sender
|-
| Email Reader*
| SMTP Sender
|-
| TCP Listener
| TCP Sender
|-
| Web-Service Listener
| Web Service Sender
|-
| Serial Reader^
| Serial Sender^
|-
| colspan="2" | *Commercial plugin (requires a Gold-level support subscription)
^Commercial plugin (requires a Platinum-level support subscription)
|}
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.
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).
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.
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==
==Filtros e Transformadores==
[[Ficheiro:Mirth_Connect_Filtros_Transformadores.png|commoldura|centro|Esquema de funcionamento de um canal]]
[[Ficheiro:Mirth_Connect_Filtros_Transformadores.png|commoldura|centro|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.
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.
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.
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.
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.
[[Ficheiro:Mirth Connect Fundamentals.png|commoldura|centro|Processo fundamental de Mirth Connect - Canal]]


=Conclusão=
=Conclusão=

Edição atual desde as 23h37min de 17 de abril de 2016

Miguel Duarte
Mestrado de Informática Médica
Universidade do Porto
up201501636@med.up.pt

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.

Na tabela seguinte podemos ver os diferentes conetores disponíveis separados pelos conetores de origem e destino[4]

Source Connectors Destination Connectors
Channel Reader Channel Writer
DICOM Listener DICOM Sender
Database Reader Database Writer
Document Writer
File Reader File Writer
HTTP Listener HTTP Sender
JMS Listener JMS Sender
JavaScript Reader JavaScript Writer
Mirth Results Sender
Email Reader* SMTP Sender
TCP Listener TCP Sender
Web-Service Listener Web Service Sender
Serial Reader^ Serial Sender^
*Commercial plugin (requires a Gold-level support subscription)

^Commercial plugin (requires a Platinum-level support subscription)

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.

Processo fundamental de Mirth Connect - Canal

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