Difference between revisions of "HL7"
G.iannello (talk | contribs) m (→Overview) |
|||
| (26 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
==Overview== | ==Overview== | ||
| − | [http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing | + | [http://www.hl7.org/ HL7] is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world. |
| − | * Created to exchange information related to | + | * Created to exchange information related to patients |
* Standardizes the health system at clinical data exchange level | * Standardizes the health system at clinical data exchange level | ||
* Provides interfaces that allow the data flow through various systems | * Provides interfaces that allow the data flow through various systems | ||
| Line 13: | Line 13: | ||
The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x. | The {{GVESB}} HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x. | ||
The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used. | The use of the connector joint with the peculiarities of the {{GVESB}} [[Virtual Layer]] allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used. | ||
| − | |||
| − | The Inbound Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; | + | Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure. |
| − | the Outbound Connector allows to | + | |
| + | The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications. | ||
{{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations. | {{GVESB}} [[XML Data mapper | Data transformation]] feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations. | ||
| − | == | + | ==Outbound HL7 connector== |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on {{GVESB}} through [[VulCon]]. | ||
| − | + | These are the easy steps to follow to define a HL7 [[Channel]]: | |
| − | |||
| − | |||
| − | |||
| − | + | Creation of a [[System]] and of a [[Channel]] with the definition of a [[Hl7-call]] [[Operation]] | |
| − | [[ | ||
| − | + | [[File:1100px-ChannelHl7.png|thumb|center|256px]] | |
| + | * host: hostname or IP address of the HL7 application waiting for the message | ||
| + | * name: [[Virtual Layer]] [[operation]] name | ||
| + | * port: application HL7 port | ||
| + | * timeout: channel HL7 timeout | ||
| − | [[ | + | Definition of a service for the invocation of the defined HL7 [[channel]]: |
| + | [[File:1100px-ServizioHl7.png|thumb|center|256px]] | ||
| + | The service defined in this way can be called in any way allowed by {{GVESB}} i.e. [[Web Services]], http, tcp-ip, etc. | ||
| + | The HL7 connector manages the messages transforming them into XML messages. | ||
| − | [[ | + | For the mapping from a generic message to a HL7 message it is possible to define a transformation map through [[XML Data mapper | VulCon]] tool. |
| + | To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format: | ||
| + | [[File:TrasfHl7.png|thumb|center|256px]] | ||
| − | + | [[File:1100px-Mapping.png|thumb|center|256px]] | |
| − | |||
| − | + | ==Inbound HL7 Connector== | |
| + | The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a {{GVESB}} [[service]]. | ||
| + | The received HL7 message can be forwarded to one or more systems using any available {{GVESB}} enabled protocol: [[Web Services]], JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application. | ||
| − | + | The easy steps to follow to define an HL7 [[GVHL7ListenerManager | Listener]] are the following: | |
| − | [[ | ||
| + | Definition of a filter to apply to every received HL7 message: | ||
| + | [[File:1100px-ListnerHl7.png|thumb|center|256px]] | ||
| − | + | Association to a HL7 message to the [[service]] defined on {{GVESB}}: | |
| − | [[ | + | [[File:1100px-ListenerServiceHl7.png|thumb|center|256px]] |
| − | |||
Latest revision as of 08:40, 4 April 2014
Contents
Overview
HL7 is a standard for the exchange, integration, sharing and retrieval of electronic health information. The standard defines how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems. HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.
- Created to exchange information related to patients
- Standardizes the health system at clinical data exchange level
- Provides interfaces that allow the data flow through various systems
- Makes the health interoperability possible
Message structure
A HL7 message is composed by segments placed in a specific order. Each message is made up of a certain number of different segments (some are optional) that, combined, form a determined message type. A specific segment, identified by a code and a sequence number, represents a logic group of data fields and can be used only once within a specific message.
HL7 Connector
The GreenVulcano® ESB HL7 connector enables the inbound and outbound connections using the HL7 protocol in its version 2.x. The use of the connector joint with the peculiarities of the GreenVulcano® ESB Virtual Layer allows the management of HL7 applications in a simple and efficient way, separating the logic of the process implementation from the specific management of the messages and their structure, independently from the HL7 standard used.
Basically the connector allows the virtualization of the input/output operations to a HL7 application, making available to the service definition process the interfaces able to hide all the technical details related to HL7 standard. It is possible to define the message exchange mode transforming with a mapping operation the HL7 messages in XML messages, using any schema. The composition of the integration flow will comprise a data structure close to the business model that user is adopting or anyway a user defined data structure.
The Inbound HL7 Connector allows the HL7 message creation (in the version 2.x) to be sent to one or more destinations; the Outbound HL7 Connector allows to choose what message type to accept and route. Multiple destinations can be chosen automatically basing on the HL7 filters specifications.
GreenVulcano® ESB Data transformation feature allows fast creation of data transformation and mapping of the HL7 messages. The data mapping is made through simple "Drag and Drop" operations.
Outbound HL7 connector
Allows to define a call to a HL7 system defining the connection parameters and using the operation defined in an integration flow on GreenVulcano® ESB through VulCon.
These are the easy steps to follow to define a HL7 Channel:
Creation of a System and of a Channel with the definition of a Hl7-call Operation
- host: hostname or IP address of the HL7 application waiting for the message
- name: Virtual Layer operation name
- port: application HL7 port
- timeout: channel HL7 timeout
Definition of a service for the invocation of the defined HL7 channel:
The service defined in this way can be called in any way allowed by GreenVulcano® ESB i.e. Web Services, http, tcp-ip, etc. The HL7 connector manages the messages transforming them into XML messages.
For the mapping from a generic message to a HL7 message it is possible to define a transformation map through VulCon tool. To create the map, go to map configuration after having defined the xsd schema for the input message (incoming from any data source) and the output HL7 format:
Inbound HL7 Connector
The inbound HL7 connector allows the definition of a HL7 message listener, associating the message reception to a GreenVulcano® ESB service. The received HL7 message can be forwarded to one or more systems using any available GreenVulcano® ESB enabled protocol: Web Services, JDBC, email, ftp, etc. After every message received, a response message must be sent as acknowledge of the transaction (or abort). The connector enables the reply message creation with no applicative effort, mapping automatically the flow result with the ACK message to send back to the caller application.
The easy steps to follow to define an HL7 Listener are the following:
Definition of a filter to apply to every received HL7 message:
Association to a HL7 message to the service defined on GreenVulcano® ESB:
