Thursday, 9 October 2008

Null Flavors in HL7V3

The concept of null in HL7v3 is very different from HL7V2.x (See my old post on Null values in HL7V2.x. This is essentially to do with lack of support for optionality in HL7V3 – Reference Information Model which itself rose from the issues associated with optionality in HL7V2.x – see else where in this blog for strengths and weaknesses of HL7V2.x and HL7V3.0.
At a high level we can say that in HL7V3 the multiple exceptional values, i.e. values other than recommended or allowed by message specifications are grouped under the banner of NullFlavor. nullFlavor is a property of every data type through ‘extension.’ This property is valued and communicated as part of a message when information is missing. The flavor provides the reason why the information is missing. This can be best illustrated by the following example

The Character String with Code (SC) data type contains a character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.

If the name of the software(e.g. RamboRavage) is known

< softwareName> RamboRavage < /softwareName >

To indicate the name of software (RamboRavage)and code of the software(RaRv)

< softwareName code="1" codeSystem="" displayName=" RamboRavage" >RaRv</softwareName>

To indicate that the software name is unknown

<softwareName nullFlavor=" UNK" />
It need to be remembered that a nullFlavor is not permitted simultaneously with a value. The various types of null flavour as per the latest HL7V3 ballot pack are given below

1.NI -no information- This is the most general and default exceptional value. There is no information which can be inferred from this exceptional value.

2.MSK- masked – This particular item has a known proper value, but it cannot be released in a given context due to security, privacy or other reasons.

3. OTH- other -There is a value, but it is not an element in the value domain of a variable
NINF negative infinity of numbers
PINF positive infinity of numbers

4.UNK- unknown - proper value is applicable, but not known.

  • ASKU - asked but unknown – information was sought from the source but not known (e.g., patient was asked but didn't know)
  • NAV temporarily not available - Information is not available at this time but it is expected that it will be available later.
  • NASK not asked - The Information was not requested from the patient
  • QS Sufficient quantity – The actual quantity is not known but sufficient enough to achieve a specific goal. For example the advice can be add sufficient quantity of water to 10 mg of medicine
  • TRC trace – The content is tool small to measure but a nonzero value

5. NA not applicable – There is no proper value for this data item for this patient; for example the date of last menstrual period is not applicable for a male.

The practical use of null can be gauged from different scenarios. For example a unconscious patient brought to the hospital have to be registered and most Patient Administration systems need at least one address. If the patient address is not known the patient address element <addr> can be set to UNK and sent to other down stream systems or repositories. If Sensitive/VIP patients need to be sent to other systems and if they do not have the same levels of security and control as the sending system have the sending system can send a null flavor of MSK indicating that they do not wish to expose the patients address.

But the usage of nullflavor has come under for huge criticism from different quarters notably from Barry Smith(Ref: where it was pointed out that the different nullflavors might lead to the need for different reasoning services and might become an overhead for message processing by applications. The other criticism of nullflavor is that the need for mandatory values for attributes would force systems to be modified to restrict users who normally ignore non-mandatory fields on screen to fill them with nullflavors. They need to be manually filled in with the real reason for that null value and proper nullflavor need to be entered on the screen. Some of the nullflavors like NAV (temporarily unavailable) are not very user intuitive terms for them to be selected. The values of +infinity and –infinity are mathematical conceptual numbers and does not indicate non-availability of data in any manner.

Organization such as CEN have rejected HL7V3 data types apart from Australia opposing the current draft ISO health data types standard (ISO 20190) based on HL7 v3 data types and one of the reasons it has been rejected or opposed is the huge confusion over usage of nullflavors(see the debate on nullflavors on openEHR website).

Thursday, 24 July 2008

Business Case for HL7V3.0

My previous posts clearly indicate that HL7 V3.0 represents a quite radical departure from the HL7V2.x standards in its development methodology. Most of the early adopters believed that the HL7V3.0 would replace HL7V2.x in its entirety, but the reality of the substantial investments in HL7V2.x systems by different organizations and vendors soon became apparent. The recent versions of HL7V2.x notably HLV2.6/HL7V2.7 added new features e.g. EHR messages which enhanced the capabilities of V2.x standards matching the features of Version 3.0. The areas area’s where V3 was supposed to solve V2.x problems e.g. Clinical Messages were found to be very work-intensive with issues pending around these domains.

The last released normative edition HL7V2006 as shown in the Figure below indicate that some of the domains have not yet been approved for example Specimen domain( Informative).The final standards of some domains are in a trial form ( - DSTU = Draft Standard for Trial Use)only for example Patient Administration which maps onto ADT in HL7V2.x.

2006 Normative Edition Domains [Copyright: HL7]

Currently one Normative Edition is coming out per year and this is increasing the uncertainty around this version.Figure below shows the world wide usage of different HL7 versions. The figure indicates that HL7 V3 is not in wide use and V2 would need to be supported for a long time

HL7 Version Usage Statistics [Copyright : Neotool]

The business case for using HL7V3.0 for sites which already has HL7 v2.x deployed is different from that sites of which do any have any variant of HL7V2.x implemented is also different. Another important factor that needs to be considered for building a business case for deploying version 3.0 in an organization is the extent of usage of department specific systems rather than an integrated system.

HL7 Sites: Large numbers of organizations around the world have made huge investments and effort in developing and maintaining HL7 V2.x interfaces. Most of these deployments have taken place in the last few years and it will take huge effort in convincing these sites to give up HL7V2.x and adapt HL7V3.0. If the requirements and need of the organizations are met by the existing v 2.x implementations then it would make little sense in replacing them with expensive V3.0 implementations not withstanding the thought the long term infrastructure and support costs for V2.x depending on the volumetric increase. However for new domains which are not yet deployed in that clinical setting it would be advantageous to start with V3.0.

Non-HL7 Sites: For Non-HL7 sites the factors that needed to be considered for V3.0 implementation are the capabilities of the existing applications in that clinical setting and the consideration of features and needs of the clinical setting that cannot be provided by version 2.x such as semantic interoperability, support for research, genomics, web services and integrating with nation wide or region wide EHR systems. But the semantic richness and the transport protocols of V3.0 does make it a better alternative to V2.x to take advantage of the COTS products features to quicken development. It has been observed that early adopters of V3 are typically "green field” sites with no HL7 complaint systems. Other implementation sites are academic and research oriented deployments and a few others are sites which implemented HL7 V3 to adhere with regulatory agency compliance specifications.

The complexity in understanding HL7 v3.0 is a major challenge for a clinical enterprise to implement HL7V3.0. The organization which wishes to implement HL7V3.0 needs to get involved the activities of HL7 organization and educate the stakeholders before impacting the effort involved in making their environment HL7 V3.0 compliant. The effort involved in making applications in an organization conform to V3.0 is proportionate to the application functionality required by the defined role of the application. The vendors of the application might not modify their applications to suit to the specific organization needs hence an organization should carefully tread the HL7 V3.0 path only after studying the market trends associated with HL7 V3. The market trend does indicate HL7 V2.x and V3.0 coexisting together for the next few years.

Tuesday, 15 July 2008

HL7V2.x and Non-MLLP/ HL7V2.x and CDA

After working for 10 years for a company i resigned my job last month and joined a new job last week.Iam not in a position to post anything new due to lack of time and lack of space(shifting to a new home as well). I will do so from August when i hope to get some decent time and space in my new home.But i could not resist posting two quick comments for those who came to my my blog with two search words and terms

The first one is for the person who came to my blog with the long search query term “is there any other way of transporting hl7 message apart from mllp”. Yes there are , there are two alternative options to sending HL7V2.xmessages over MLLP one is sending it over HLLLP; For details see my post on HL7V2.x and Low layer protocols

The other option is to use ebXML; use the normal ebxml header and put the hl7v2.x message in the MIME part; for discussions on ebXML structure see my ebXML and HL7V3 posts.

The second comment is for the guys who came with the term HL7V2.x and CDA , I just want to mention that From the perspective of a V2.x CDA document is a multimedia object, to be exchanged as a Multipurpose Internet Mail Extensions (MIME, RFC 2046) package, encoded as an encapsulated data type (ED).In V2.x, CDA documents are to be exchanged in the OBX segment, in any message that can exchange documents (such as MDM). Within the OBX segment, the MIME package is placed in OBX.5 (Field 00573 Observation value), encoded as a V2.x encapsulated data type.

I will write in detail later on the above two in my next posts.

Wednesday, 7 May 2008

HL7 V3 Ready

The difficulties in mapping HL7V2.x to HL7V3.0 does not make a solution based on transformation and translation easy to implement. The difficulties encounter by initial adopters is making the total adoption of HL7V3.0 very difficult. Version 3 was created as a replacement for Version 2.x, but it is observed that the two versions are catering to distinct markets. However the impending success of major projects like UK-CFH is going to make HL7V3.0 a major standard and replace HL7V2.x in the longer run. It is a well known fact that big bang change of standards in applications deployed in clinical settings is a recipe for major disaster so proposal for a transition path to independent “V3-ready” implementations and “V3-ready” implementations of Version 2.x is required. The following approaches are proposals for an HL7V3.0 ready implementation.

New HL7 V3 domains: Most of the domains which exist in HL7V2.x have equivalence in HL7V3.0 for e.g. ADT in V2.x has equivalent domain called Patient Administration in V3.0, Scheduling exists in both HL7V2.x and HL7V3.0. However the limitations of HL7V2.X did not cater for advances in clinical areas like Clinical Genomics and Clinical trials but the specifications in these areas are well defined in HL7V3.0. It is recommended that organizations start implementing these new domains in their applications using HL7V3.0 and support the existing HL7V2.x messages in other domains before phasing them out as HL7V3.0 standards in those domains mature.

Z- Segment and Z- Fields: Most of the existing clinical settings in different countries have implemented and deployed HL7V2.x specifications in their applications. The ease of implementing HL7V3.0 in these applications depends on the architectural framework and openness to extension. For legacy application which has a V2.x interface and implementing V3.0 in these applications is a cost intensive then it is recommended to use Z-segments and Z-Fields and wrap multiple messages in a single message so that the content needed to populate a v3 message can be obtained. This approach may mitigate some of the mapping and transformation issues defined in the above section.

RIM based Data Model: It should be possible to modify the physical data model of the clinical applications to follow the HL7 model. This means maintaining a relationship between the HL7V3.0 RIM based data model and physical database model. The success of this approach depends on how closely the physical data model matches the RIM logical data model (e.g. D-MIM, R-MIM). This will enable the mapping of HL V3.0 message attributes with the required table attributes in the database.

HL7V3 Conformance for V2.x Implementation: The version 3.0 approaches of use cases, story boards, interaction models and vocabulary can be used in Version 2.x implementations so that the message profiles developed for Version 2 can be mapped onto Version 3 at some point in the future. The development of message profiles as a means to guide a new HL7V2.x implementation or modify an existing HL7V2.x implementation is consistent with HL7V3.0 development methodology. This will allow us to focus on non-data aspects of HL7V3.0 i.e. defining the interactions in an implementation and the application behavior associated with this implementation. The focus shift will enable us to concentrate on HL7V3.0 messages data structure as the need for changes to application functionality is reduced.

CDA Implementation: An alternative strategy is to use CDA (Clinical Document Architecture). The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. CDA documents are encoded in XML and derive their machine processable meaning from the HL7 Reference Information Model (RIM) and use the HL7 Version 3 Data Types. The factor that makes it easy to move to CDA is that this specification defines a multi level architecture where each level is derived from a more basic level. The levels refer to varying degrees of required markup granularity and specificity and not the depth or granularity of the content. Figure below shows the definition of different CDA Levels

Figure: CDA Levels

CDA Levels provide iteratively adding greater markup to clinical documents apart from establishing baselines for conformance. As Level one includes only header includes and semantics in level one body is easy initially to implement this and have a defined phased approach to other levels.

Thursday, 17 April 2008

HL7V2.x to HL7V3.0 Translation Issues Details-2

In continuation of my previous post this post lists the other issues associated with HL7 v2.x to HL7v3 translation
Conformance Patterns: The other major issue with the transformation of messages is the behavior of application when a particular information exchange takes place. In HL7V3.0 apart from the trigger events and interactions there exists the notion of application role as senders and receivers. The application role is characterized as the entire set of interactions for which the sender and receiver are responsible for transmitting. HL7V3.0 clearly defines the possible interactions and the application behavior associated these interactions in the form of responses for which the sender and receiver needs to adhere to. The differences in messages between V2.x and V3.0 and absence of clear guidance on V2.x regarding application behavior on receipt of message makes the transformation exercise more difficult.

Vocabulary: It is a well known fact that 80% of HL7 V2.x message failures are a result of code mismatches. HL7V2.x needs a translation table for each interface and this puts a huge overhead on HL7V2.x implementation. Version 2.x has no formal binding of standard vocabularies to structures. The bindings are ad hoc and always site specific. However Version 3.0 has a strong semantic foundation in explicitly defined concept domains drawn from the standard terminologies. Each concept in a vocabulary domain (a defined set of coded concepts) is represented using a code from a specific vocabulary. The mapping of an ad hoc vocabulary to a standard vocabulary is problematic as cases like one-to-many and many-to-many mappings will be encountered which can be resolved only manually and cannot be automated. One major issue with vocabulary is the emergence of SNOMED as vocabulary of choice for HL7V3.0 messages. SNOMED Post-coordination which describes representation of a Concept using a combination of two or more codes is not possible for V2.x messages up to V2.4 and this makes the mapping and translation more difficult.

Cardinality Constraints: The mapping of cardinality constraints between HL7V3.0 and HL7V2.x is very complex due to the HL7V2.x messages being shallower and less expressive than HL7V3.0 messages. So HL7V2.x messages are unlikely to be able to represent the full range of allowed cardinalities of attributes and associations that HL7V3.0 message can represent

Wrappers: The information present in the HL7V2.x TCP-IP MLLP wrapper is insufficient to populate the ebXML/SOAP HL7V3.0 wrappers to enable the communication and routing of the messages at the integration layer level where HL7 wrappers are not considered. HL7 V3.0 XML ITS can use MLLP for transport but the HL7 interaction semantics defined in the V3.0 standard transport specification using SOAP/ebXML will be disturbed.

Monday, 14 April 2008

HL7V2.x to HL7V3.0 Translation Issues Details-1

In my last post i mentioned that i will publish the detailed information of the translation issues in a white paper. I wanted to use the white paper as a medium to let the wider auidence know of the issues which i thought were deterrent for undertaking the strategy of HL7V2-V3 translation. However the profile of visitors to the blog did convince me that publishing the information here will receive wider publicity. In the first of posts i will discuss the issues with data types.

The attributes/data fields in both HL7 v2.x and HL73.0 are associated with a specific HL7 data types. In both the versions data types are basic building blocks of information exchanged in the messages. In V2.x data types are just another level of nesting and the different data types are just considered “formats” of character strings that would appear in HL7 data fields. In V3 the data types define clearly the semantics of data values that can be assigned to a data element. All the data types that exist in Version 2.X do not exist in Version 3 and this complicates the mapping. A few data types like composite types, such as CN (CN - composite ID number and name), contain multiple concepts, and are now represented more explicitly in the information model as either attributes or classes. Some data types like NM (Numeric) in V2.x are expanded in V3 into multiple data types like Integer Number (INT) and Real or Decimal Number (REAL). Other types, such as ID, IS, and CE, received more rigorous definition and an automatic 1:1 mapping is often not possible.

Context: Most of the mapping issues are context driven, for example observations that reside in ‘allergies and adverse reactions’ class of HL7V3.0 contain observations and no clear guidance is available if these need to mapped to general observations in OBX or to AL1 segment in HL7 v2.x. Some other issues are with the message content, for example there is a mismatch between V2.x and V3.0 in terms of Laboratory orders as all V3 Lab Messages are specimen centric i.e. one specimen , several tests and results . V2.5 is specimen centric and match V3 structure but V2.2 to V2.4 which most lab systems in Europe use does not contain any specimen information. The confusion in V2.x on data types like Composite Quantity with Unit" (CQ) which existed in all versions of HL7 v2.x had contradicted with measurement observations (OBX) where numerical result (value type NM) and the units are sent in separate OBX field. In HL7V3 there is only data type Physical Quantity (PQ) with attributes ‘value’ and ‘unit’.

Time: There are some clearly documented and known issues with time data types between V2 and V3.The TQ (Timing Quantity) data type which describes when a service should be performed and how frequently have potentially three V3 data types that can be mapped onto PIVL – Periodic Interval of Time, EIVL – Event-Related Periodic Interval of Time and GTS – General Timing Specification. Both the data types are complex and have multiple representational approaches and no specific level mappings are currently available. The TQ data type has been deprecated from HL7V2.5.

Another issues with the time data types is that the v3 data type Interval IVL containing a single time point is suggested to map to v2.x data type TS (Time Stamp). This mapping carries a risk of semantics loss as v3 IVL used in this way states that the ‘event’ occurred over an interval containing the specified time point, whereas TS states that the ‘event’ occurred at the specified point in time.

Information Loss:There are some imperfect mappings where information loss can be caused when external vocabularies are used in HL7. For example in HL7V2.X the Observation identifier (CE) carries the name of the coding system as a string and in v3.x the coding system is indicated by an OID (Object Identifier) which are globally unique. However in general the OID in HL7V3.0 in general is mapped to HD (Hierarchical descriptor) and EI (Entity identifier) HL7V2.x data types and generally used for facilities, applications, organizations, providers, patients, etc.

Monday, 24 March 2008

HL7V2.x - HL7V3.0 Transformation / Translation

The adoption of any new messaging standard will be faster only if there exists a clear and defined transformation and migration strategy between the new standards and existing standards. It is always preferred to handle such a strategy in a middleware so as not to modify the core clinical applications to cater to the standard which is very expensive in the shorter run. However till now there is no clearly defined guidance to facilitate such a transformation of messages between Version 2 and Version 3.

These differences in methodology make the transformation from one version to another difficult. Technically it is possible to map the segments in V2 messages to XML sub-tree in XML schema with defined conversion mapping rules. However site specific interpretations of V2.x with user defined segments and fields make the transformation to V3.0 based on a common reference model appear like a mapping from a proprietary standard to a universal standard.

There are several instances where HL7 V2-V3 mapping has been attempted and tools are made available for specific projects like caBIG (Cancer Biomedical Informatics Grid) and commercial tools like Oracle HTB. Figure below shows a generic architecture used in these different initiatives. The mapping in these tools is manual and there is no pre-defined intelligent mapping or guidance provided with the tool sets. Exceptional domain expertise is required to perform the mapping in these tools.

The message structures used by HL7 v2 and V3 are different and the initial step involves converting the messages to a common canonical format before the mapping can be done. The V3.0 XML format is not compatible with the string delimited non-XML V2.x format. The V2.x XML encoding will enable it to be compatible with V3.0 XML format. The canonical transformation component will enable both these XML messages to be converted into an intermediate format to enable the mapping. The mapping between V2 and V3 is relatively straight forward in some cases of demographic data and clinical data where HL7V2.x segments directly map onto HL7 V3 classes. In other areas it has been not possible to map the different versions. A summary of some of the the difficulties faced during the mapping are [ Full details in my to be shortly published white Paper ]

Data Types

  • Formats of Character Strings to Semantic data values
  • Context and Content driven mapping issues leading to information loss

Conformance Patterns

  • Clear definition of roles for Senders and Receivers in HL7V3.0
  • No Clear guidance on application behaviour using HL7V2.x


  • V3.0 has strong semantic foundation and V2.x has no formal binding to Voc
  • No one to one data types exist

Cardinality Constraints

V2.x messages shallower and less expressive than HL7V3.0 messages


Insufficient information in HL7V2.x-MLLP compared to HL7V3.0-ebXML/SOAP

Thursday, 13 March 2008

HL7V3 and ebXML - Part 3

I apologise for the delay in publishing the Part 3 of the ebXML and HL7V3. I see that a portion of hits to my blog are coming from the links provided by Marc de Graauw in Section 7 of his article Implementing “Web Services in Dutch Healthcare” at I thank him for considering my blog posts worth the mention.

What is ebXML MSH?

HL7 V3 message triggered from Sender are sent over their integration layer as HL7 Request to sender MSH (Message Service Handler). MSH is a piece of software used to send and receive ebXML messages. Figure below shows the functions of MSH.

The textual description of the services depicted above is given below

Ø MSH Service Interface – This is the abstract interface applications use to interact with MSH to send and receive messages.

Ø Header Processing – the creation of the ebXML Header elements for the messages sent from the applications. It also involves parsing of header elements and interactions with contract properties. [See below for Contract Properties]

Ø Security Services – this includes digital signature creation in the messages (which may be used in headers), verification, encryption, authentication and authorization.

Ø Message Packaging – this will perform the enveloping of an ebXML Message (ebXML header elements and payload) into its SOAP Messages with Attachments container

Ø Reliable Messaging Services – this service handles the delivery and acknowledgment of ebXML Messages. It also deals with persistence of messages, retry, error notification and acknowledgment of messages requiring reliable delivery.

Ø Transport Binding – This is the abstract interface between the MSH and the various protocol stacks.

Ø Error Handling – this handles the logging and reporting of errors encountered during MSH or Application processing of a message.

Contract Properties

To understand the exchange of messages between two MSH’s we need to understand the term “contract properties”

Each MSH processes the messages sent by the other MSH by the contracted interface properties. These properties describe Quality of Service (QoS) from reliability and security point of view. The MSH uses these properties to build the ebXML wrapper. The contract properties are defined during message definition process and agreed between two organizations or two system vendors who will exchange the messages. Contract properties are defined for each HL7 interaction. The contract properties given for each interaction are identified by a CPAId. The sender will use the CPAId that is relevant for that HL7 message interaction and agreed with the receiver.

The relevant contract properties are Service, Action, Persist Duration, RetryInterval, Retries, AckRequested, SyncReplyMode, Actor, EndPoint, IsAuthenticated etc.- See HL7V3 and ebXML – Part 1 for details about these properties.

ebXML Message Exchange :

Figure below shows the sequencing involved in ebXML message exchange

Let me explain the flow in the above sequence diagram

1. In a typical implementation the Sender builds the HL7 message with the HL7 Wrapper and passes it onto the sender MSH

2. The sender MSH looks at the message interaction id and looks up in the database for the contract properties for the message and builds the ebXML wrapper.

3. The ebXML message sent by sender MSH containing the HL7 message payload will get ebXML acknowledgement synchronously on the same connection over HTTP 202. The ebXML Acknowledgements are sent without a payload.

4. If the ebXML acknowledgement from Receiver MSH is not received within a time interval Sender MSH resends the message. The number of retries and retry time interval are dependant upon the contract properties attached with that message.

5. If the number of retries expires depending upon the message business functionality Sender MSH will report the error back to application which sent the message or enter into a HL7 slow retry method.

6. In case of ebXML errors Receiver MSH sends a message with the same end-point binding associated with ebXML acknowledgement service except that a Message Error will be sent.

7. The business responses or application acknowledgements from Receiver MSH in response to the message sent are received and processed by the Sender MSH exactly in the same fashion as Receiver MSH does on receiving a request from Sender MSH.

The above description is only for direct reliable message exchange between two MSH's ; we can have intermediary exchange with two MSH's communicating to each other using anothe MSH or we can also have direct unreliable message exchange. I have not discussed them here not i do intend to discuss them here.

Thursday, 21 February 2008

HL7V2.x Implementation

The key activities that need to be considered for the implementation of a HL7 version 2.x are

  • Identifying the list of relevant messages from the standard documentation set

  • Mapping of the fields in the messages to the attributes in the application database

  • Identifying the tools and methods for construction of messages based on the triggers in the application

  • Identifying the tools for message communication and validation.

Message Identification

The messages are identified based on the data flows required for the healthcare organization. The transactions that need to trigger these messages in the sender need to be identifier along with the list of receiving systems. The required and optional segments in each of the messages are identified. Any implementation specific data those are not available in the standard segment need to be sent in the user defined Z segments.

Message Mapping

Message mapping involves mapping of HL7 data elements to the application tables, columns and code sets. This is a crucial step of the implementation and involves specialist knowledge of the application and healthcare domain.

Message Generation

The construction and generation of version 2.x messages from healthcare systems can be done using three different approaches which are depicted in Figure and described below

Native Generation – The messages can be generated natively within the application using the same software components that makeup the core application. This approach is advantageous for enterprises with lower interfaces and a small number of departmental systems. This approach is essentially based on point-to-point integration and not suitable for organizations with complex interfaces and large number of departmental systems.

Middleware Approach This is external to the applications and applications used different mechanisms to communicate with the middleware. These range from systems sending messages and data in a proprietary format based on the event to middleware and it building the message into HL7 format to message sending standard HL7 messages and middleware validating the message before sending the message in format understood by target system.

API Approach – This approach involves deploying readily available software components and libraries external to the application and modifying the applications source code to make a call to the libraries. This is ideal for closed legacy applications and quickens the deployment of HL7.

Messaging Communication

The most commonly used mechanism for sending HL7 Version 2.x messages is Lower Layer Transport protocol (LLP). The messages are sent over TCP/IP over the network.

The protocol is very simple to implement using the implementation setting sockets. The protocol requires that that each message should be preceded with the character 0x0B (11) and followed with the characters 0x1C (28) and 0x0D (13). This is required for communications code to be able to recognize the start and the end of each message Finally each segment is terminated by a 0x0D (13) character. This is mandated by the standard, but often HL7 log data can be received via ftp or email where the segment separators have been transformed into 0x0A characters, etc.

See my post on MLLP and HLLP for more details

Major Implementations of HL7V2.x

Several countries in the world have recognized version 2.x of HL7 as national standard for example version 2.4 is established as a German Industrial Standard. The SCIPHOX (Standardized Communication of Information Systems in Physicians Offices and Hospitals) used standard HL7V2 for communication between hospitals though it used CDA (Clinical Document Architecture; for communication between hospitals. SCIPHOX encompasses laboratory results, diagnoses, medications, procedures and referral data.

National Healthlink Project in Ireland is an electronic communications project between GPs and hospitals. Version 2.4 with XML encoding is used as the messaging standard; for example ADT A01 is used to notify GP’s of a patient visit to A&E; ADTA03 is used to notify GP’s that their patients have been discharged or died. Apart from ADT ORU R01 is used to notify Radiology and Pathology results of patients to their GP’s.

The national layer of Australian Standards documents in the AS4700.x series constrain and localise the ANSI/HL7 v2.x series of standards for use in Australian healthcare settings. Version 2.3/2.3.1 is used for Patient administration, Pathology orders and results, Electronic messages for exchange of information on drug prescription, Discharge and Referrals. Though some of the standards have not been upgraded to 2.4 with most of the sites still using version 2.4

The application vendors and Local service providers of NHS - Connecting for Health programme which are one of the frontrunners in implementation of HL7V3 are using variants of HL7Version2 (CSC: UK HL7vA.2, HL7V2.3,HL7V2.4; BT: UK HL7V2.3;Fujitsu: HL7V2.3) for intra-organisation communication.

Friday, 15 February 2008

HL7V3 and ebXML - Part 2

In this post we will look at the second MIME part which we mentioned in the first part as Payload Containers containing application level payloads. We will observe what exactly is contained in the Payload containers. The payload container contains HL7V3 composite messages composed of three parts

Ø Transmission or Transport Wrapper

Ø Control Act Wrapper

Ø HL7 Domain content

Figure below shows the structure of the second MIME part when expanded

The Transport wrapper includes information needed by a sending application or ebXML message handler route HL7V3 composite Message to the intended receiving application(s) and/or message handler.

As in the first post let me take an example and explain it


<PRPA_IN040000UV15 xmlns="urn:hl7-org:v3" xmlns:fo="" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">
<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>
<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/>
<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883." extension="12345"/>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883." extension="67890"/>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
< ----->
<subject typeCode="SUBJ" contextConductionInd="false">
<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">
<streetAddressLine>oxform farm</streetAddressLine>
<low value="19550101"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>




1. The second MIME starts with the name of the message interaction ; name space and schema location

<PRPA_IN040000Uv15 xmlns="urn:hl7-org:v3" xmlns:fo="" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">

PRPA_IN040000Uv15 is the name of the message interaction and is the same as the one included in the Action element of ebXML wrapper.

2. The next attribute is the unique identifier for this message. It is based on the I I – Instance identifier data type. Instance identifier contains root of type UID(Unique identifier ) , extension(ST) , assigningAuthorityName(ST) and displayable(Boolean). Most of the case the root alone may be the entire instance identifier. Figure below shows a case where the identifier has a DCE UUID held in the root attribute

<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>

3. The next set of relevant attributes are given below

<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/&gt

The creationTime is date and time that the sending system created the message and it uses the datatype-TS

The versionCode is the domain of HL7 version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard. HL7V3 2006 normative edition has a default value of V3PR1. In UK-CFH land this field is used to define the version of MIM-Message Implementation Manual from to which the message interaction belongs to e.g. V3NPfIT3.1.10 indicating that this message interaction is from MIM3.1.10.

The interaction identifier is a unique reference to the message type, trigger event and application roles that send and receive the message. This is the same as the one populated in the Action element of ebXML wrapper. The root contains the OID value. An OID (object identifier) is a numeric string that is used to uniquely identify an object. OIDs are intended to be globally unique. They are formed by taking a unique numeric string (e.g. and adding additional digits in a unique fashion (e.g.,,, etc.)

The processing code is used to identify the environment that the message must be processed in. The possible values for this are D-Debugging; P-Production and T-Training.

The processingModeCode is a code identifying the mode that this message is being sent in. The possible values for this are A-Archive Mode; I- Initial Mode ; R- Restore from Archive and T- Current Processing.

The acceptAckcode is a code identifying the conditions under which accept acknowledgements are required to be returned in response to this message. The possible values are AL- Always, ER- Error and NE- Never.

4. The transport wrapper carries information about the receiver and sender systems for the messages as shown below

<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883." extension="12345"/>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883." extension="67890"/>

It starts with the typeCode; The three RIM back-bone classes -- Participation, ActRelationship and RoleLink -- are not represented by generalization-specialization hierarchies. these classes represent a variety of concepts, such as different forms of participation or different kinds of relationships between acts. These distinctions are represented by a typeCode attribute that is asserted for each of these classes. For a receiver the receiver has a typeCode value of RCV-Receiver and for Sender SND-Sender. Both sender and receiver carry the information identifying the device.

The device starts with a Classcode [w.r.t Entity ClassCode is an HL7 defined value representing the class or category that the Entity instance represents.] and for both sender and receiver has a fixed value DEV indicating that the entity is a device. It also has a determinerCode which is an HL7 defined value representing whether the Entity represents a kind-of or a specific instance. In this case it is an “INSTANCE”.

It optionally carries the telecom value – WP indicating that it is a work phone. The id is a single unique identifier of the accredited system that represents the party who is either sending or receiving the message. The root carries the OID and the extension carries the application identifier. Optionally it can also carry the Name , Manufacturer , Software name and the represented organization as shown below.

<receiver typeCode="RCV">
<telecom use="WP" value="tel:+31303248724"/>
<device classCode="DEV" determinerCode="INSTANCE">
<id extension="700856" root="2.16.840.1.113883."/>
<name use="L">
<agencyFor classCode="AGNT">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="100100" root="2.16.840.1.113883."/>

<name use="L">
<given>Uxbridge Hospital</given>

5.The "Trigger Event Control Act" contains administrative information related to the "controlled act" which is being communicated as a messaging interaction. It is also the part of HL7 messages that can convey status or commands for logical operations being coordinated between healthcare applications, e.g., the coordination of query specification/query response interactions and registry act interactions. The Control Act does not appear in accept level acknowledgements (i.e., messages used only for conveying the status of message communications) or with messages carrying commands to coordinate the operation of message handling services

The "semantic content" of a HL7V3 message is the combination of the ControlAct and the payload. Tofully understand the trigger event you need both. The Control Act just says "Please 'do something' with 'this thing'".The payload is needed to indicate what 'this thing' is. However, the bulk of the trigger event information is attached to the Control Act.

<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
< ----->
< ----->
<subject typeCode="SUBJ" contextConductionInd="false">

The message types defined in the Message Control Act Infrastructure section of the HL7V3 2006 Normative ballot are highly generic and inclusive. Message designers and implementers can further refine and constrain Trigger Event Control Acts.

6.The last part of the message is the "HL7 Domain Content" which is the primary domain content of the messaging interaction .It contains domain specific content that is specified by an HL7 technical committee to satisfy a use case driven requirement for an HL7 messaging interaction. For example the below is an loose example of a RegistrationRequest domain in which a extract of the message used to capture the details of patient used to register a patient are sent.

<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">
<streetAddressLine>oxform farm</streetAddressLine>
<low value="19550101"/>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>


In the final post next week in ths series i will try to explain the actual implemenation mechanics.

Friday, 8 February 2008

HL7V3 and ebXML - Part 1

In 2003 HL7 Board of Directors approved usage of ebXML for transporting HL7V3 messages as Draft Standard for Trail Use (DSTU) . The English Connecting for Health is one of the first major users of this transport and all HL7V3 asynchronous messages communications in that project is performed using ebXML. This is the first of blogs to understand the relationship between HL7v3 and ebXML . In this process we will also discuss the structure of HL7V3 message as well.

Figure below shows the general structure and composition of an ebXML message

The ebXML Message is a MIME/Multipart message envelope structured in compliance with the SOAP Messages with Attachments specification and is referred to as Message Package.

The Message Package is divided logically into two MIME parts

  • A MIME part, referred to as Header Container containing one SOAP 1.1 compliant message. This message is referred to as SOAP message

  • Zero or more additional MIME parts referred to as Payload Containers containing application level payloads

The SOAP Message is an XML document that consists of the SOAP Envelope element. The SOAP Envelope element consists of the following:

  • SOAP Header element - This is a generic mechanism for adding features to a SOAP Message, including ebXML specific header elements.

  • SOAP Body element. - This is a container for message service handler control data and information related to the payload parts of the message.

In this post let’s discuss the first MIME part containing the SOAP envelope. Let me take an example of ebXML wrapper and run through so that the context can be understood.

Now let us analyse the wrapper in detail



xmlns:soap-env="" xmlns:xsi="" xmlns:eb="" xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="" xsi:schemaLocation="" >
<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1 </eb:PartyId>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH" />
<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="">
<eb:Schema eb:location="" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />


1. The wrapper starts with name space declaration

xmlns:soap-env="" xmlns:xsi="" xmlns:eb=""
xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="" xsi:schemaLocation=" >

Name space declaration for the ebXML SOAP extensions may be included in the SOAP Envelope, Header or Body elements, or directly in each of the ebXML SOAP extension elements.

The SOAP namespace: “ “ resolves to a W3C XML Schema specification. The ebXML OASIS ebXML Messaging TC has provided an equivalent version of the SOAP schema conforming to the W3C Recommendation version of the XML Schema specification

The XML schema-instance namespace qualified schemaLocation attribute in the SOAP envelope to indicate to validating parsers a location of the schema document should be used to validate the document is also included.


[HL7-ebXML] extends the ebXML headers within the HL7 ebXML namespace. The namespace declaration for the extensions has a required value of:

2. The next is SOAP Header Element


The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is a element indicating the required transport state to the next SOAP node.

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is an element indicating the required transport state to the next SOAP node.

3. The Message Header starts with Version and SOAPUnderstand attribute as shown below

<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">

The REQUIRED version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (, indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

4. The next element is the From Element

<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1</eb:PartyId>

The REQUIRED From element identifies the Party that originated the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attributeindicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

5. The next element is the To Element

<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>

The REQUIRED To element identifies the Party that is the intended recipient of the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attribute indicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

6.The CPAId element is a string that identifies the parameters governing the exchange of messages between the parties.


The recipient of a message MUST be able to resolve the CPAId to an individual set of parameters, taking into account the sender of the message. The value of a CPAId element MUST be unique within a namespace mutually agreed by the two parties. The value ABC22 reference the contract properties assigned to each service/action.

7. The ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId.

<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7 </eb:ConversationId>

The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent.

8. The Service element identifies the service that acts on the message and it is specified by the designer of the service


The designer of the service may be:
• a standards organization, or
• an individual or enterprise

The above value indicates that it has something to do with the Master Patient Index

9.The Action element identifies a process within a Service that processes the Message. Action SHALL be unique within the Service in which it is defined


The value of the Action element is specified by the designer of the service. The above value is the message interaction that is sent with this ebXML wrapper and used for the MPI service.

10. The MessageData element provides a means of uniquely identifying an ebXML Message. It contains the following:

MessageId element
Timestamp element
RefToMessageId element


MessageId is a globally unique identifier for each message conforming to MessageId.

Timestamp is a value representing the time that the message header was created conforming to a dateTime [XMLSchema] and MUST be expressed as UTC

RefToMessageId element has a cardinality of zero or one. When present, it MUST contain the MessageId value of an earlier ebXML Message to which this message relates. If there is no earlier related message, the element MUST NOT be present. For example if is present the Message Data will be something like

<eb:RefToMessageId>39E66A20-2DD3-22B3-91FA-81CE4147A4A7 </eb:RefToMessageId>

11.The DuplicateElimination element, if present, identifies a request by the sender for the receiving MSH to check for duplicate messages


12. The AckRequested element is an OPTIONAL extension to the SOAP Header used by the Sending MSH to request a Receiving MSH, acting in the role of the actor URI identified in the SOAP actor attribute, returns an Acknowledgment Message. The AckRequested element contains the following:

• a version attribute
• a SOAP mustUnderstand attribute with a value of "1"
• a SOAP actor attribute
• a signed attribute

<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml- msg:actor:toPartyMHS" />

The SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (, indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The AckRequested element MUST be targeted at either the Next MSH or the To Party MSH (these are equivalent for single-hop routing). This is accomplished by including a SOAP actor with a URN value with one of the two ebXML actor URNs defined in sections 2.3.10 and 2.3.11 or by leaving this attribute out. The default actor targets the To Party MSH.

The REQUIRED signed attribute is used by a From Party to indicate whether or not a message received by the To Party MSH should result in the To Party returning a signed Acknowledgment Message – containing a [XMLDSIG] Signature element . Valid values for signed are:
true - a signed Acknowledgment Message is requested, or
false - an unsigned Acknowledgment Message is requested

13.The Manifest element identifies the payload messages that are carried with the ebXML message. Manifest is included in the SOAP:Body. These references can be:

· References to the attached MIME parts using the cid reference mechanism.
· References to remote content not included in the message but accessible via other means and referenced via a URI

<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="">
<eb:Schema eb:location="" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The Reference element is a composite element consisting of the following subordinate elements:
• zero or more Schema elements – information about the schema(s) that define the instance document identified in the parent Reference element
• zero or more Description elements – a textual description of the payload object referenced by the parent Reference element

The Reference element itself is a simple link [XLINK]. In this context it has the following attribute content

xlink:href – this REQUIRED attribute has a value that is the URI of the payload object referenced. It SHALL conform to the XLINK [XLINK] specification criteria for a simple link.

The schema element provides a means of identifying the schema and its version defining the payload object identified by the parent Reference element. The Schema element contains the following attributes:
• location – the REQUIRED URI of the schema
• version – a version identifier of the schema

The final element is the payload element. This element contains style or standard to which the message in the payload conforms. In this case it is “HL7". It contains the encoding method for the standard which is used to encode the message in the payload. For HL7v3.0 we use "XML". Finally the version of the standard to which the payload message conforms and for HL7V3.0 its 3.0.

Thursday, 10 January 2008

The HL7V3.0 Primer

What is HL7V3.0 ?

HL7V3.0 is a model based messaging specification which was proposed to resolve the weaknesses of HL7V2.x. The aim of a model based messaging standard is to create a standard set of structures for the sharing of healthcare information and support binding of standard clinical terminologies to the model. The creation of a standard clinical model with standard terminology establishes a healthcare domain specific common language which would allow any healthcare application model to map onto the reference model. This mapping would allow interoperability with other applications apart from allowing re-use of healthcare data in the application which has mapped its model onto the model.

Methodology Overview

Figure below shows the methodology used in HL7V3.0

The different processes in the HL7V3.0 methodology to obtain the message specifications are described below

Use Case Modeling:

The Use case Model consists of the following definitions

Ø Scope statement: A high level use case for the entire project

Ø Use case: Describes specific situations in which communication between healthcare entities is needed

Ø Actor: An entity which initiates or participates in the use case. Discovered in the process of developing use cases

Ø Use Case Diagram: Provides a graphical form to develop the use case model from the business process analysis and makes it easy to show the relationship between use cases

Interaction Modeling:

The Interaction Model

Ø Describes roles to which systems may claim conformance

Ø Fine-grained abstraction; every system will claim several roles

Ø Not standardizing system or application functions, only messaging roles

Ø Basis for contractual agreement

Ø Potential basis for conformance testing

Ø Captured in a MODEL, a TABLE, and a DIAGRAM

Each Interaction consists of:

Ø Trigger event :Event dependency usually expressed as the state of one or more classes

Ø Message ID : Each interaction sends one particular message

Ø Sender role

Ø Receiver role

Ø Receiver responsibility :A specific functional responsibility for the receiver to initiate another (consequential) interaction

Information Modeling:

The information model consists of the following

Ø A detailed and precise definition for the information from which the data content of HL7 messages are drawn.

Ø Follows object-oriented modeling and diagramming techniques, and is centered on a depiction of the classes that form the basis for the objects in HL7 messages.

Ø Provides a means for expressing and reconciling differences in data definition independent of message structure.

Ø Forms a shared view of the information domain used across all HL7 messages.

The Information Model defines

Ø classes, attributes, data types, and relationships

Ø vocabulary domains, code systems, and value sets

Ø states, trigger events, and transitions

Reference Information Model:

The model which forms the basis for the development of HL7V3.0 message specifications labeled RIM (Reference Information Model) is an object oriented model where the information is organized into classes that have attributes and that maintain associations with other classes. The information-related content of HL7 3.0 protocol specification standards is drawn from this model. RIM uses notation based on the Uniform Modeling Language (UML) and information modeling conventions outlined in the HL7 message development framework. RIM provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

RIM is conveniently fashioned into three areas – semantic control, structured documents and message control.

The backbone of RIM consists of four primary classes and two linking classes. The four primary classes in the semantic content partition of the RIM are

Act: An Act is defined as intentional healthcare related action in the business domain of HL7. An instance is a record of an act. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. An act is represented by a brick colored block in the RIM as following example

Act has the following sub-classes
Ø Account
Ø ControlAct
Ø DeviceTask
Ø DiagnosticImage
Ø Diet
Ø FinancialContract
Ø FinancialTransaction
Ø InvoiceElement
Ø Observation
Ø Participation
Ø PatientEncounter
Ø Procedure
Ø PublicHealthCase
Ø SubstanceAdministration
Ø Supply
Ø WorkingList

Entity: Entity is a physical thing or organization and grouping of physical things. A physical thing is anything that has extent in space, mass. Excludes information structures, electronic medical records, messages, data structures, etc. An Entity is represented by a green colored block in the RIM as following example

Entity has the following sub-classes

Ø Container
Ø Device
Ø LanguageCommunication
Ø LivingSubject
Ø ManufacturedMaterial
Ø Material
Ø NonPersonLivingSubject
Ø Organization
Ø Person
Ø Place

Role : For people, role is usually positions, jobs, or ‘hats’ and for places and things are what these places or things are normally used for. Each role is “played by” one Entity and is usually “scoped” by another. Thus the role of Patient is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, an Employee role is scoped by the employer. A role is represented by a yellow colored block in the RIM as follows

Role has the following sub-classes:

Ø Access
Ø Employee
Ø LicensedEntity
Ø Patient

Participation: Role exists only within the scope of one act. Acts have multiple participants, each of which is an entity in a role. Role signifies competence while participation signifies performance. Participation is represented in the RIM by the following block

Participation has ManagedParticipation sub-class.

Act Relationship: ActRelationship is association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance.Act Relationship is represented in RIM by the following block

ActRelationship has no sub-classes

Role Link: Role Link is a relationship between two entity roles. For example Clinicians relationship with a Hospital and a Patients relationship with a Hospital to express the doctor and patient relationship. Role Link is represented in RIM by the following block

RIM Classes Example

Figure below shows the relationships between the different classes in the RIM with an example

In the above example the Act Examination is performed by Entity Person A in his role as GP and the Subject of the Examination is the Entity Person B in his role as Patient.


Class attributes are the core components of the information model. The attributes are the source for all the information content of HL7. There are three special kinds of attributes in the information model: identifier attributes, classifier attributes and state attributes.

Ø Identifier attributes: Identifier attributes can be used to identify an instance of a class. Values of identifier attributes never change. Examples of identifier attributes from the RIM include and, which uniquely identify a particular Entity or Act respectively

Ø Classifier Attributes: The classifier attributes are a critical aspect of the classes forming the backbone of the RIM. The classifier attributes are named "classCode".

Ø Structural Attributes: Structural attributes are those attributes whose coded values are needed to fully interpret the classes that they classify. ClassCode together with moodCode, typeCode and determinerCode are the structural attributes.

Ø State Attributes: A state attribute is used in subject classes (classes that a Technical Committee designates as the central focus of a collection of messages). It contains a value that concisely indicates the current state (named condition) of the class.

Message Design:

The Message Design in HL7V3 from RIM is obtained as follows Message Design Overview

Domain Message Information Model:


Ø Full description (model) of the information classes within a domain and the way in which they are being used

Ø Classes are ‘cloned’ (copied and adapted) and renamed (alias) according to the way they are used in the domain context

Ø Data Types and vocabulary for attributes are specified

Ø Every RIM class category has its own colour; this makes the model description more visual

To obtain D-MIM from RIM

Ø Select RIM classes to be included in D-MIM Select the subset of RIM classes relevant to the problem domain.

Ø Clone subset classes of the RIM If the same RIM class is selected to meet different information needs then create as many clones of the RIM base class as needed. Ø Select a subset of class relationships Add relationships between the D-MIM clones consistent with existing class relationships in the RIM.

Ø Select a subset of class attributes For each D-MIM clone select the applicable attributes from its RIM base class.

Ø Select a subset of attribute data types and vocabulary domains Assign data types and domains to D-MIM attributes that are consistent with assigned data types and domains in the RIM

Refined Message Information Model:

R-MIM is

Ø Same type of representation as D-MIM

Ø Aimed for a specific category of interaction (e.g. all inpatient admission related messages) Ø Special form of an R-MIM are the Common Message Element Types (CMETs).These express common and reusable ‘information units’, that are derived from a D-MIM (like all R-MIMs) but can be used in other D-MIMs (and therefore R-MIMs) as building blocks (e.g. ‘patient’)

To obtain R-MIM from D-MIM

Ø Create clones of D-MIM classes and attributes Further specialize D-MIM classes by creating additional clones for each unique collection of attributes

Ø Assign alias class and relationship role names Assign domain specific names to class clones Ø Eliminate unnecessary class hierarchies Remove classes with no attributes and relationships from the class hierarchy

Ø Finalize class relationships and cardinality Alter relationship cardinality to reflect the appropriate minimum and maximum class occurrences

Ø Finalize attribute data types and domains Replace data type and domain specifications with the most appropriate constrained version of each

Hierarchical Message Definition

HMD is a further restriction of an R-MIM:sequentialized/serialized; represented in a different format. To create a HMD

Ø Select a root class for the message Chose a class to serve as the starting point for message content

Ø Arrange classes and attributes hierarchically Follow the relationships from class to class and add the attributes to the HMD.

Ø Declare inclusion and repetition constraints For each attribute specify if its presence in message content is optional, mandatory, or conditional and specify the number of times the attribute may repeat

Ø Declare data type and domain value constraints Declare additional constraints on the data types and domain values

Ø Assign message element names Assign a final meaningful business name to each attribute in the HMD

HL7 V3.0 Data Types:

HL7 data types define the structure and constrain the allowable values of attributes in the RIM. The HL7 data type specification declares the set of data types, identifies components of complex types, and defines relationships between data types. The HL7 data type implementation technology specification defines constraints and operations for data types and describes how data types are to be represented in XML. Data types are reusable atomic building blocks used to create all HL7 V3 information structures. Each RIM attribute is assigned one data type; each data type is assigned to zero, one, or more RIM attribute. Few of HL7V3.0 data types are given below

• AD: Postal Address
• ANY: DataValue
• BAG: Bag
• BL: Boolean
• CD: Concept Descriptor
• CE: Coded With Equivalents
• CS: Coded Simple Value
• ED: Encapsulated Data
• EN: Entity Name
• GTS: General Timing Specification
• HIST: History
• II: Instance Identifier

• INT: Integer Number
• IVL: Interval
• LIST: Sequence
• MO: Monetary Amount
• ON: Organization Name
• PN: Person Name
• PPD: Parametric Probability Distribution
• PQ: Physical Quantity
• REAL: Real Number
• RTO: Ratio
• SC: Character String with Code
• SET: Set
• ST: Character String
• TEL: Telecommunication Address
• TN: Trivial Name
• TS: Point in Time
• UVP: Uncertain Value - Probabilistic

HL7V3.0 Vocabulary Specification:

The HL7 V3 Vocabulary Specification defines vocabulary domains used in RIM coded Attributes and coded data type properties. A vocabulary domain is an abstract collection of interrelated concepts. It describes the purpose or intent of a coded attribute. A value set is a collection of coded concepts drawn from a single code system. A vocabulary domain may be associated with many value sets. A context expression provides a means of designating which value sets within a given domain are applicable for a given usage context. A coded concept has a concept code assigned by the coding system and a concept designation which names the referenced concept. A coded concept may be a parent concept for a collection of additional concepts within the same code system.

HL7 XML Schema Generator:

The HMD’s constrained with HL7 Vocabulary Specification and HL7 Data Type specification to a HL7XML schema Generator gives the XSD the schema definition of an HL7V3.0 message. Figure below shows the set up for the generation of XSD.

Links, References, Acknowledgements and Copyright