This wiki has undergone a migration to Confluence found Here
Difference between revisions of "HL7 Application"
Jump to navigation
Jump to search
(→Notes) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Image:Reference Messaging Architecture.jpg|275px|right|thumb|Application Architecture]] | [[Image:Reference Messaging Architecture.jpg|275px|right|thumb|Application Architecture]] | ||
| − | An '''HL7 Application''' is an application level entity that posses knowledge and capability to produce and consume HL7 messages. HL7 Application encompasses the scope of the HL7 standardization efforts | + | An '''HL7 Application''' is an application level logical entity that posses knowledge and capability to produce and consume HL7 messages in accordance to the HL7 standardized methodology. The most important fact in regards to the HL7 Application is that it encompasses the scope of the HL7 standardization efforts. More precisely, it embeds the knowledge about HL7 modelling, processing of RIM based information models (DMIMs, RMIMs, related semantics, and respective receiver responsibilities), and is responsible for serializing the message using one of the HL7 ITS specifications available. |
== Notes == | == Notes == | ||
| − | *HL7 applications that have produced and consumed | + | *HL7 applications that have produced and consumed HL7 messages within an interaction are identified in the Device.id attribute within the Transmission Wrapper. |
| − | *HL7 application encompases the implementation of a set of one to many HL7 application roles and their respective responsibilities as defined by the HL7v3 standard. However, since the concept of the application role is not a normative one, we cannot reference the term in our | + | *HL7 application encompases the implementation of a set of one to many HL7 application roles and their respective responsibilities as defined by the HL7v3 standard. However, since the concept of the application role is not a normative one, we cannot reference the term in our definition. Hence, we use Trigger Event and Interaction as normative dynamic concept for HL7 application definition. |
| − | * | + | *There might be other business entities that reside in the application layer (e.g. data mining and warehousing applications, ERP systems, etc), which perfom various business fucntionalities in the healthcare settings. They are not represented on the [[Application Architecture]] map since they clearly fall out of the scope of HL7 messaging artifacts and standardization efforts. |
| − | |||
---- | ---- | ||
[[Category:ATS Glossary]] | [[Category:ATS Glossary]] | ||
Latest revision as of 09:25, 24 July 2007
An HL7 Application is an application level logical entity that posses knowledge and capability to produce and consume HL7 messages in accordance to the HL7 standardized methodology. The most important fact in regards to the HL7 Application is that it encompasses the scope of the HL7 standardization efforts. More precisely, it embeds the knowledge about HL7 modelling, processing of RIM based information models (DMIMs, RMIMs, related semantics, and respective receiver responsibilities), and is responsible for serializing the message using one of the HL7 ITS specifications available.
Notes
- HL7 applications that have produced and consumed HL7 messages within an interaction are identified in the Device.id attribute within the Transmission Wrapper.
- HL7 application encompases the implementation of a set of one to many HL7 application roles and their respective responsibilities as defined by the HL7v3 standard. However, since the concept of the application role is not a normative one, we cannot reference the term in our definition. Hence, we use Trigger Event and Interaction as normative dynamic concept for HL7 application definition.
- There might be other business entities that reside in the application layer (e.g. data mining and warehousing applications, ERP systems, etc), which perfom various business fucntionalities in the healthcare settings. They are not represented on the Application Architecture map since they clearly fall out of the scope of HL7 messaging artifacts and standardization efforts.
