Brazil NHCP

I have been too pre-occupied with my work to do some quality blogging; I have not written anything till now about my favorite topic – Electronic Health Records. This is first of serious of blogs on various EHR initiatives around the world.Most of the information that will be included is public information and my intention is to simplify the information about the implementation from what i understand while allowing the users also to examine the contrast in the patterns used by different implementations. I have been told that Brazil is one of the first countries to have a successful implementation of Nation Wide Electronic Health Records. The project was termed NHCP – National Health Card Project. This project began as early as 1999 and a clinical pilot began in 2001

Aim of NHCP

The project was started to create national patient identification and information system for the Brazilian Unique Healthcare System called SUS -- Sistema Único de Saúde. Its aim is to collect patient treatment information in a national repository of clinical data.


Architecture Principles and Components

Figure below shows the logical architecture of the project. NHCP System is divided into 5 hierarchical levels, from the bottom: Point of Care Level, Municipal Level, Concentrator Level, State Level and Federal Level. The top three levels of the system has Permanent IP based network and the lower two levels has Dial Up Network as shown in Figure below.

NHCP Project has five major components

Ø Telecommunication infrastructure
Ø Point of care terminals;
Ø Servers and database facilities
Ø Point of care terminal and servers software
Ø Security issues and national standards to represent transmit and store health information.

The architecture of the NHCP is centered on patient and users having health cards. The health cards adopted in the project are used only for IDENTIFICATION purposes of users and health professionals and not to store clinical data. Both the users’ and health professionals’ cards have embossed the unique identification number, name, date, city and state of residence. The point of care equipment specially developed for this project has the card reader. The access to the system is limited to health professionals authenticated by the card and password. All data captured at the point of care is stored in the servers at the municipal, state and federal level

The technologies that were used are based on Java technology and the XML data format. The Java framework is based on the following concepts

Ø The NHCP is XML message-based; all communication between machines is XML over HTTP.
Ø Every server node can send and receive XML messages to and from any another server node.
Ø XML messages are associated to Java business classes.
Ø All XML data is handled dynamically using Java Reflection.

All XML is validated according to a rigid specification (DTD, infrastructure, and domain), which provides the flexibility necessary to add or remove business classes, and to modify the XML validation rules. In addition, servers and clients must authenticate to a server node using digital certification. The figure below depicts a generic server node with its principal building blocks and data flows.

Standards and Data Sets

The transport protocol used is HTTPS (HTTP +SSL). The terminals of care and municipal servers communicate using XML. The specifications were not HL7 but specifications agreed between Ministry of Health and the providers contracted for the development of the project. Document Type Definition (DTD) has been used for specifications.

The essential encounter data set contains the following information

Ø Reason for the encounter
Ø Diagnosis
Ø Procedures Performed
Ø Patient’s work-out
Ø Medication
Ø Follow Up

The diagnosis information is entered using ICD-10

Informational Governance

The use of the database of the National Health Card aims to only the management of health services by the different spheres of government and was guaranteed not to be used for commercial purposes or for any reason which hinders with constitutional rights of the Brazilian citizens. The architecture incorporates a Information Governance policy covering five basic requirements: privacy, authenticity, integrity, access control and audit of health data tied to the National Health Card.

For authentication any addition or alteration of information in the system is linked to an operator duly registered both for operation of the server and the terminal. All the health professionals responsible for the entry of data to the system are authenticated using health professional card which contains a encrypted password on the card.For access control, the system allows the implementation of a policy of setting privileges of access to classes of operators and standards of disclosure. All attempts to access information and functions of the system are stored for auditing purposes.

From IG point of view the systems offline are treated the same way as that of online systems. The traffic between a terminal and a server, upload between servers or service is performed on the HTTPS protocol, or HTTP protocol (Hypertext Transfer Protocol) protocol on the SSL (Secure Sockets Layer).

Scalability

Since spring 2003, the pilot infrastructure has been fully operational, consisting of:

Ø 8 million patient ID health cards
Ø 50,000 professional ID cards
Ø 3200 point-of care-clients
Ø 2 federal servers
Ø 27 state servers
Ø 13 concentrator servers
Ø 44 municipal servers

In parallel with the pilot project and in anticipation of consolidation for the rest of the country, 80 million people have been uniquely identified in the NHCP database, representing 40% of the Brazilian population. Interoperability with external systems is also operational. Systems from external vendors are communicating with the NHCP by exchanging XML documents.

NHCP server -side data:

Ø 180 different use-cases
Ø 1,800 Java classes
Ø 230,000 lines of code
Ø 700 different database tables
Ø 160 different XML message types
Ø 50 gigabytes of data/million users/year

Advantages

NHCP allows data to be queries and profiled; for example diagram below shows actual data queried from the NHCP system for San Jose dos Campos, a city of 500,000 people near Sao Paulo. The x axis shows the treatment procedures codes, the y axis the date, and the vertical z axis shows the corresponding quantity. So what happened to cause this peak? From the data, it was possible to identify that the peak was due to the annual influenza immunization program; it was in winter, and over a two-week period, nearly 5000 people got their influenza shots.

My Observations

The project is simple implementation but strictly not a EHR implementation per-se and looks more of a data ware house implementation. There were claims that the message specifications were done after debate with clinicans who were the main users. It did not follow any reference model based specs so any of the changes to the specifications to keep in line with advances with clinical terminology and data will be adhoc. Also usage of ICD10 will limit the amount of data collected considering that its mostly disease based. The data sets indicate minimal information is captured and also a mechanism to retrieve from central repository to point of care systems is not well defined. The integration mechanism looks like a hardcore java implementation and non-implementation of a standard middle ware implementation will have its own technological refresh problems and scalability problems. Also some of the technologies used like DTD , XML binding has since become rarely used with the advent of XSD , SOAP , JAXB etc as the artcile on the SUN website indicates.

But the framework on the whole is a good start but building on the top of it may be bit difficult and any extensions to it may look out of place considering the usage of HL7V3.0 , SNOMED have become more wide-spread now.

Links, References, Acknowledgements and Copyright

http://java.sun.com/developer/technicalArticles/xml/brazil/

Lemos M, Leao de Faria B. The Brazilian national health card project. Proceedings of the International Nursing Informatics Conference. Rio de Janeiro; June 2003.

http://dtr2001.saude.gov.br/cartao/ - Official Site with detailed info

Understanding High Availability

This is a short article to define the concepts of High Availability to some one who is familair with Application Software but not with Infrastructure

High Availability is an option to create fault tolerant solutions to provide available and uninterrupted services to the users. High Available Solutions are developed by providing redundancy. Redundancy is provided by allowing a backup take over the role of the failed to avoid disruption of Service (Failover). Failover can be Stateless or Stateful. In a Stateless failover the solution providing the services is restarted without any restoration of data where as in a Stateful failover the data is check pointed to a standby hosting the solution offering the same services. High Availability needs to cater to both planned and unplanned types of service disruptions.

Availability is measured by the formula
= MTBF / (MTTR + MTBF)

Where MTBF is Mean Time between Failures. Calculated based on expected life of various components of a system

MTTR is Mean Time to Repair. Measurement of time required to bring a system back online after failure

High Availability is defined in terms of number of 9’s as shown in the following table

Number of 9’s Downtime / Year Typical Application

99.9% ~ 9 Hours Desk Top
99.99% ~ 1 Hour Enterprise Server
99.999% ~ 5 Minutes Carrier Class Switch
99.9999% ~ 30 Seconds Carrier Switch Equipment

Failover Design Principles

The basic design principles that were considered while evaluating the failover design are

Ø The failover design needs to be simple and transparent to the client who access the servers services

Ø The failover needs to be quick and the standby needs to be always booted up.

Ø There should be minimal manual intervention and the tasks involved in failover should be automated.

Ø The failover should ensure guaranteed data access, the receiving host should see exactly the same data as the original host.

Ø The failover design should not be designed only for current configuration but needs to consider future growth.

Ø The Operating System needs to be compatible with the failover design.

Failover designs are based on the concepts of Clustering, Load Balancing and Shared Storage.

Clustering

Clustering, by definition, is to configure a secondary system as a standby for the primary system. If the primary system fails, the standby system automatically steps in with minimum disruption in service, takes over the functions of the original primary. The downtime due to a failure in the primary is limited to the takeover time.

A cluster requires various components to turn two systems / servers into a failover pair Servers. The components required are Network Connections (heartbeat network, service network, administrative network), Disks (Shared /Unshared), Application Portability and the basic design principle is there would be no Single Point of failure.

Load Balancing

Load balancing optimizes the performance of a system by distributing the traffic efficiently among a group of network servers which results in high availability and scalability of the system.

A single virtual IP address which maps to the addresses of each of the servers hosting the solution is reflected on the router-based load balancer. If a host is removed from and or becomes unavailable, the incoming request does not risk of hitting a “dead” server, since all host machines of the solution connected to the load balancer appear to have the same IP address.When a response is returned, the client sees it coming from the load balancer. In other words, the client is dealing with a single machine, the router based load balancer

Load balancers support different load-balancing techniques, which can be setup and configured
Ø Round robin. Assigns connections sequentially among severs in the cluster.
Ø Least connections. The server with the least number of connections gets the next connection.
Ø Weighted distribution. Divides the load among the servers based on individual weight or priority assigned to each server in the cluster. This technique is often used for the heterogeneous clusters that consist of servers running on different platforms.

Storage Area Network

Storage area network is a network for interconnecting storage and computing systems into a shared pool that many different hosts can access. SANs are based on Fiber Channel (FC) or SCSI over IP (iSCSI). SANs can be based on a number of different underlying technologies, including IP-based networks. The storage devices on the SAN are usually limited to disks and tape drives.

SAN is central for configurations, such as N+1, 2N or even the complex N-to-1, N-to-N, to failover in a smart, quick and efficient manner.

HL7V2.x and Low Layer Protocols

Minimal LLP (MLLP) and the Hybrid LLP (HLLP) are the two widely used lower layer protocols (LLP) for HL7 versions 2.x transmission. They are efficient and extremely simple to implement and use simple socket based communication. MLLP and HLLP does not really qualify as a "protocol" as they make use of TCP's reliability. MLLP and HLLP are simply a means of framing individual HL7 messages which is needed at the 7th level.

There are two types of LLP connectivity

Ø Persistent - In this type of connectivity socket is cached based on the endpoint and only one socket per endpoint is created and reused for the next set of messages.

Ø Temporary - In this type of connectivity a new socket is created for each message. When a message is sent the sender waits for the ACK and once it is received socket is closed.

The processing rules for both MLLP and HLLP are more of less the same; however, processing rules for HLLP include additional logic to signal transmission errors.

MLLP Wrapper

The MLLP wire format looks like <SB>dddd<EB><CR>

Where <SB> is Start Block, 1 Byte, ASCII <VT>, HEX <OxOB> and should not be confused with ASCII characters SOH or STX.

dddd is the HL7 variable length HL7 message. The data can contain any displayable ASCII characters and the carriage return character, . <CR>

<EB> is End Block, 1 byte, ASCII<FS> , HEX <Ox1C> and should not be confused with ASCII characters ETX or EOT.

<CR>is Carriage Return, 1 byte, ASCII , HEX <OxOD>

HLLP Wrapper

The HLLP wire format looks like <SB>tvv<CR>ddddCcccc<EB><CR>

Where <SB> is Start Block, 1 Byte, ASCII<VT> , HEX <OxOB>and should not be confused with ASCII characters SOH or STX.

t is Block Type, 1 Byte. ‘D’ is data block. This is used for HL7application message and HL7 ACK response message.‘N’ is NAK block and is used only as NAK to signal transmission errors

vv is Protocol Id, 2 Bytes. The characters ‘2’’1’ for this version

<CR>is Carriage Return, 1 byte, ASCII<CR> , HEX <OxOD>

dddd is is the HL7 variable length HL7 message. The data can contain any displayable ASCII characters and the carriage return character, <CR>.

In a NAK block, this field contains a 1-byte reason code as follows:
‘C’ is character count wrong in previous data block received.
‘X’ is checksum wrong in previous data block received.
‘B’ is data too long for input buffer in previous block received.
‘G’ is error not covered elsewhere.

Ccccc is Block Size, 5 bytes and is the character count of all characters so far in the data block up to and including the last data character. For this version of the protocol this is 5 + the size of the dddd field. An encoded HL7 message ends with a <CR>character. This character is considered part of the data.

Xxx is Checksum, 3 bytes an X-OR checksum of all character in the block up to and including the last data character. The checksum is expressed as a decimal number in three ASCII digits. If the value is 999, the checksum should not be computed. Processing will proceed as if the checksum were correct. This feature is used for applications where the messages will be translated from one character set to another during transmission.

<EB>is End Block, 1 byte, ASCII<FS> , HEX <Ox1C> and should not be confused with ASCII characters ETX or EOT.

<CR>is Carriage Return, 1 byte, ASCII , HEX <OxOD>

Null Values in HL7V2.x

In HL7V2.x the null value is indicated by ¦""¦. When a system receives this it interprets that the particular attributes value has been changed to null as the sending system has deleted the value of that particular data element in its database. It also indicates that the data element is available in the sending system’s database but currently not valued. The receiving system on receiving it should change the current value to null for that data element. However the absence of a field (¦¦) from sending system indicates that the value of the absent element may not have changed since the last event and the receiving system should retain the current value. The absence of a field (¦¦) may also indicate that the particular data element is not available in the sending system’s database.

A few tips on interpretation of "null" value and "not available" in HL7V2.x messages for application programmers

1.If the HL7 NULL value is present in message received and if the application processing allows a field to be changed to null for this source, the Interface needs to null existing application data elements.

2. If an optional non-repeating field or entire optional segment is absent in a received message, the Interface must not null the existing application values.

3. The application Interface should not support partial updates of repeating data. If some fields in a set of repeating fields are absent or null, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.

4. The Application Interface must not support partial updates of repeating prioritized segments. If some segments in a set of repeating ordered segments are absent, the Application Interface may inappropriately overlay valid data or retain unwanted values. The Application Interface must not “error” the message.

5. When a message is sent the Application Interface must value all available changed and unchanged data elements in a segment

6.The Application Interface must send all instances of a repeating field.

7. The Application Interface must send all instances of repeating prioritized segments. For segments that repeat but can be uniquely identified and updated as an atomic unit, the Application Interface may send only the segment that has changed.

8.The Application Interface must send a null value for attributes that are present in the application database but have a null value. The option to send the HL7 null value need to be configurable by feed and not by field. The Application Interface must interpret zeros in a date field as null and zeros in an Application coded value field as null; however, the Application Interface must interpret zeros in a numeric field as a valid value.

Weakness of HL7V3.0

Administrative Overhead: The version 2.x has very simple administrative process than Version 3. Modifications to 2.x standard are done easily by editing the change into the appropriate word processing document. In Version 3 changes need to be done to the computerized models, and the downstream consequences in the message structures need to be taken care of. This disparity comes into focus especially when introducing small changes into existing interfaces.

Message Size: The usage of XML as ITS and the adoption of ebXML as the wrapping mechanism for HL7V3.0 messages increased the message size hugely compared to a HL7V2.X message. The two layered wrappers consisting of ebXML wrapper and HL7 wrapper with duplicate elements contributed to the size.

Technological Barriers: HL7V3.0 has been built on RIM a decision which has been made in 1996. Technological changes and new architectural patters e.g. SOA make RIM which uses for e.g. UML look like a legacy hangover. The level of extensibility of RIM with well-designed ontologies for functions like computerized decision support which came with advances in clinical research is unknown and undefined.

Learning Curve: There is a very steep learning curve in understanding HL7V3.0 and there are no standard implementation and deployment guides available for starters. They need to traverse through the documentation available on HL7V3.0 site and the structure of documentation adds further complexity to the understanding of Version 3.0.

Inadequate RIM: The HL7 RIM contains an ad hoc mixture of health-specific concepts and domain-independent concepts. There are no classes to represent key clinical concepts such as 'diagnosis', 'problem' etc .HL7 proponents would argue that it is indeed possible to represent 'problems', 'diagnoses', etc. using RIM components. This may well be the case, by using suitable values of codes etc, but the general view of this is that HL7 RIM is far too abstract to provide a useful basis for the specification of health event summaries,

Multiple Tools: Multiple tools are used to design and build HL7V3.0 message specifications. For example the RIM is defined using UML, D-MIM and R-MIM using Visio, HMD using Rose Tree and the messages are in XML. The story boards are in formal English language and the application roles, triggers and interactions are in a PubDB. The usage of different tools in designing and publishing message specifications is expensive.

Strengths of HL7V3.0

Optionality -HL7 version 3.0 has very little optionality which is one of the weaknesses of version 2.x. The RIM which is the basis for version 3 has no concept of optionality. The need for a value in the message is defined by trigger event rather than the data definition. This has led to better message definitions. Optionality in version 3 is replaced by “Conditionality” which means that the presence of a data field in the message may be allowed or not depending on the value of another field..

Model based - Version 3.0 is based on an object oriented model; Reference Information Model (RIM) to create message specifications. The model provides an explicit representation of the semantic and terminology relationships that is present in the information present in the fields of HL7 messages.

Conformance - HL7’s version 3.0 is primarily intended to be a stable and definite standard which will allow vendors to conform to a universal standard. This will allow regulatory agencies and local HL7 bodies where applicable test the applications to an agreed standard and provide a conformance certificate to the vendor.

Technology independent - Version 3 introduced the concept of “Implementable Technology Specification (ITS)” which describes the process of instantiating a message from its definition. Currently XML is the widely used and probably only one ITS available publicly. But unlike V2.x; HL7V3.0 ITS allows other technologies to be used for messages e.g. UML ITS, JavaBeans etc.

Electronic Health Record - HL7 version 3 offers a much more efficient method to communicate information between clinical systems by providing the context of information in the messages which is not possible in version 2.x. It also provides the ability to collect clinically coded information for the purpose of maintaining Electronic Health Record for sharing clinical data consistently across organizations. Version 3 is emerging as the standard of choice for creating national EHR’s due to the level of semantic interoperability provided by it.

Localization and Refinement: HL7 Inc allows a balloted HL7V3.0 specification to be further constrained for region specific profile aided by a HL7 Inc Affiliate. This localization of messages allows quick deployment of HL7V3.0 for an organization or region to meet their specific needs.

Weakness of HL7V2.x

Inter-Intra Enterprise - HL7 V2.x limitations came to the fore with the advent of Electronic Health Record (EHR) which involves exchange of data across organizations. The need for inter-enterprise data exchange exposed the ambiguous data semantics of HL7V2.x which is due to the fact that version 2 messages are based on no explicit model .For example relationship of OBX to OBR and ORC to PID is implied but not specified. Fields within a message originate from different implicit data models and lead to inconsistent interpretation of these fields.

Semantic Framework - The presence of semantics framework is crucial in understanding the definition of each element of data in the message and the relationship with other data elements. It is also crucial for representing coded elements and relationships within the terminology. So the absence of a semantics framework in HL7V 2.x messages makes it mandatory that the applications involved in the exchange of data needs to be programmed to interpret the different values that come in a field from other applications. This need for interpretation of messages by applications using programming increased the costs and effort for deployment of HL7V2.x messages.

Backward Compatibility - The mandatory requirement of maintaining backward compatibility between different versions of HL72.x is an overhead and constrains HL7V2.x from adopting new terminology and communication standards. This constraint led to version HL7V2.x being termed more of a data exchange standard rather than interoperability standard.

Data Relationship - There is a vague definition of relationship between message types, event types, and the structure of a message in HL7V2.x. There are no clearly defined rules describing the association between events and messages. For example in version2.3 a single ORM message is associated with different events such as new order, modify order and cancel order. In some scenarios the event types describes the message structure and the real time events associated with the messages and in other scenarios it describes the location of the target system where the data in the message has to be transmitted.

Methodology - There is no explicit methodology defined for building of HL7 V2.x messages. There is no detailed documentation associated with specifications to give guidance to developers and implementers on constructing HL7V2.x messages. Trigger events and data fields are described in formal language. The same message definitions are used for different trigger events. The different chapters in the documented specifications are not consistent in usage of trigger events and status codes. The specification concentrates solely on the behavior of sending system and does not define the receiving systems behavior nor does it provide guidance when a specific receiving system is expected to honor a trigger event or accept a message. HL7V2.x methodology is based on structured programming language but does not have formal operations and object oriented concepts such as generalization and specialization hierarchies.

Optionality - There is a substantial amount of optionality built in HL7VV2.x messages making it difficult for specifying precise contract terms for HL7 interfaces. Optionality also led to vendors making ambiguous HL7 conformance statements as it is difficult to define the exact semantics of a specific message. The use of optionality increased the costs of development of interfaces for applications which came with out-of-box HL7 interfaces. This led to HL7V2.x being termed as not a plug-and-play standard which usually is required for messaging standards in any industry for e.g. SWIFT standards for banking.

Security – Security has been always considered out-of-scope for HL7V2.x messages. There is no explicit support for security functions such as encryption, restricted access to data and digital signatures.

Strengths of HL7V2.x

Strengths of HL7V2.x

Mature Standard – HL7V2.x emerged as a mature stable standard in healthcare informatics after the specifications went through series of review iterations and modifications to cater to the needs of market. The HL7V2.x specifications are currently available and ready for use and easily implementable. A large number of existing applications are HL7V2.x conformant.

International Standard – HL7 has international affiliates in around 28 countries covering all major countries. It has emerged as the dominant clinical information standard in these markets. Majority of the HL7V2.x specifications including HL7V2.3/2.4 have been classified as ANSI accredited standards. HL7V2.4 is now being proposed as ISO standard. Apart from this some countries such as Germany have legislations that stipulate use of HL7V2.x.

Backward Compatibility - The biggest advantage of HL7V2.x is the ability of different versions of HL7V2.x to interoperate with one another. The rules for compatibility between different versions (e.g. V2.3.1, V2.4 and V2.5) have been documented in the specifications. These rules describe the transmission and receipt of messages and converting their contents to data values with full backward compatibility between all HL7V2.x versions.

Optionality - The use of optionality in HL7V2.x messages is helpful in gaining consensus and documenting compact specification. If a data field is declared optional within a segment then the segment can be re-used in different messages without defining a new segment which requires similar data fields. However there is a wide misuse of this optimality which will be discussed in next section.

Message Size: The chief virtue of HL7V2.x message specification is that its syntax is quite compact and hence the size of the message is minimal. This brings a huge benefit to the economy of bandwidth

HL7 Operation Forms

HL7 message exchange behaviour is governed by two forms of operation
· State Exchange Form(SEF)
· Remote Invocation Form(RIF)

State Exchange Form (SEF) is used to synchronise business processes running in separate systems usually across organisations. That is a business process engine in one organisation aligns the state of its process with a business process engine in another. SEF is usually performed through HL7 messages using reliable asynchronous ebXML pattern. Examples where SEF is used is in case of updates to patient demographics or creation of a new patient in a local system. The changes are initially done in the local application and then the external systems are notified of the changes through update or create messages. The external systems then use the data in these messages and update the data to keep in sync with the sending system.

Remote Invocation Form (RIF) is derived from standard client-server methods. The model is inherently synchronous from the perspective of the human actor in that the actor is “blocked” waiting for a response. RIF is usually performed through HL7 messages using synchronous Web service pattern or unreliable asynchronous ebXML pattern. Examples where RIF is used is in case of queries and retrievals of data from other systems. The sender system sends a query to the receiving system which maintains the MPI for the organisation and uses that data for further processing.

HL7/ebXML Slow Retry

ebXML Retries


According to ebXML Message Service Specification Version 2.0 a MSH (Message Service Handler) will perform multiple retries to send a message if it(sender) does not receive an Acknowledgement from the receiving MSH. The number of retries is one of parameters used by the sending MSH to confirm that a message is sent reliably.

According to ebMS2.0

Ø The Retries parameter is an integer value specifying the maximum number of times a Sending MSH SHOULD attempt to redeliver an unacknowledged message using the same Communications protocol

Ø If the Sending MSH does not receive an Acknowledgment Message after the maximum number of retries, the Sending MSH shall notify the application and/or system administrator function of the failure to receive an Acknowledgment Message.

From the second bullet point it is clear about what ebMS2.0 suggests us to do.

According to the classic Enterprise Integration Patterns "messaging" ensures that message will be guaranteely delivered but does not guarantee when it will be delivered. If the infrastructure supporting the conversation between sender and receiver is down for considerable time the sender will ensure that the receiver gets the message when the infrastructure is back. However when the message is delivered the context of the message may not be valid anymore. Generally systems implement message expiration that is if they receive a message which is quite old they discard the message and the “oldness” of the message usually is implementation specific. In some cases the messaging middleware implements the message expiration policy where it specifies how long a particular message type will live or when it will expire. The expired messages are written into dead letter queues for service management activities.

But ebMS2.0 does not specifically talk about what to do after the number of reties expire other than letting the layers above the messaging layer know of the failure to deliver the message. It also does not talk of the slow retry mode (or is it called long retry mode?) or about message expiration at all except for the number of retries as per the contract property.

In one of the large HL7V3.0 implementation where ebXML is implemented for asynchronous messaging it was recommended that systems use HL7 retry mode when sender MSH retries expire without an ACK being received from the receiver. In this particular implementation the system provider suggested that all systems which communicate with a particular sender should implement the “Slow retry” as exponential retry behavior that is, after each ebXML request sequence has failed, the Sender must retry with an increasing time interval. This might run into a problem for outages of longer duration as the persistent duration of the message might expire if at all the message has been received by the receiver but the acknowledgment has not reached the sender from the receiver.

According to ebMS2.0 persistent duration is a parameter which is defined as the minimum length of time data expressed as "duration" from a reliably sent message is kept in persistent storage by a Receiving MHS node. If the persistent duration has passed since the message was first sent, the Sending MSH SHOULD NOT resend the message with the same ebXML MessageId though the HL7 Message Id should be the same.

If response is not returned even after ebXML retries and “slow retry” there is no other way other than handling the problem manually. In case of Multi-Hop using a intermediary slow retry is not suggested at all it has to be handled manually as Multi-Hop do not conform to eith SEF or RIF(See my post on HL7 Forms of Operation)

EHR White Paper

Nation and Region Wide Electronic Health Records are currently deployed or are being deployed in several countries around the world to enable sharing of care records within an organization and between different organizations. This sharing of health records would enable the patient's medical history and other details to be available at the point of care and would enable effective treatment of patients. This is further discussed in a paper which was published on TCS web site where i work in which the need for Electronic Health Records (EHR) andthe key design principles for EHR are described.


The link for the white paper is at

http://www.tcs.com/SiteCollectionDocuments/White%20Papers/TCS_WP_NatHealth.pdf

Healthcare ESB Requirements

This is a summary of requirements for a ESB in a healthcare setting from my point of view.

Design and Development

1. The solution needs to support the proposed SOA/ESB reference architecture where the ESB is single point of integration for all the organizations requirements for communicating to internal systems and external systems. The tool sets used for the proposed solution needs to be interoperable from development perspective. For example the BPM tool needs to be integrated with development tool set.

2.The solution needs to be able cater and extend to alternative frameworks to SOA such as Model Driven Architecture and Event Driven Architecture.


3.The solution needs to adhere to a typical development lifecycle. The product suite needs to provide tools for design, development, testing, deployment and support.


4. The solution needs to provide tool sets to support XML, XSD authoring, XSLT (XML Transformation) and XPath.


5. The product suite used for the ESB needs to quicken development using off-the-shelf frameworks and support for health care standards such as HL7 , ASTM , DICOM etc.



Solution Framework

1.The ESB solution needs to support variants of HL7V2.x to support communication of local systems within an organization. The ESB needs to support backward compatibility of HL7V2.x messages by selective validation of message segments as per the version.


2.The HL7V2.x message types that need to be supported by the ESB primarily are ADT, Inbound Orders, Outbound Orders, Inbound Results, Outbound Results and Scheduling.


3.The HL7V2.x messages will contain user defined Z-Segments apart from standard segments originating from clinical applications and other existing systems. These messages need to be validated by the ESB against the standard specifications and rejected with a response back to the target system for possible resubmission.

4.The ESB needs ensure that messages from each clinical application are routed correctly to the target system.

5.The ESB needs to support persistent and transient connections from and to the organizations applications.

6.The ESB needs to support message sequencing and deliver the HL7V2.x messages to the clinical applications in the order they arrive at the ESB.

7.The ESB needs to provide duplicate elimination without compromising the ability to process messages faster.

8.The ESB needs to ensure message accuracy. Accurate means that the content and structure of a Message is maintained from the moment of receipt or generation of the Message by the ESB to the moment of Transfer, or completion of all required processing, of the Message by the system till it is delivered to target system.


9.The ESB needs to support Remote Invocation Form (RIF) that is derived from standard client-server methods. The model is inherently synchronous from the perspective of the human actor in that the actor is “blocked” waiting for a response. For RIF the ESB needs to keep the connection open till the response is back and do not allow a message to be fired with the same message id by the user. Allow the user to fire the same message with different message if a SOAP HTTP 2xx indicating failure for the first message comes back

10.The ESB needs to support State Exchange Form (SEF) that is used to synchronize business processes. In SEF application persists the data and sends the message to target system. The ESB needs to close of the connection. When the target system responds back it may be a success or failure. The success needs to conveyed back to application but not the failure. The failure needs to be logged by ESB for it to be investigated


11.The ESB needs to support ebXML mode for asynchronous messaging to applications. The ESB needs to build HL7 wrappers and validate payload from applications. The ESB needs to include HL7 wrapper and payload within a SOAP envelope, and transport the full message over HTTPS. The information behavior for MHS needs to be in sync with Oasis ebMS V2.0

12.The ESB needs to support both Single Mode and Intermediary mode for ebXML asynchronous messages.


13.The ESB needs to support SOAP-WS for synchronous messages to applications. The Web Services Mode of ESB is delivered by considering the target systems integration layer as a standard Web Service provider. The service provider MAY produce a WSDL definition for each web service. However, the WSDL is not warranted to generate web service stubs. This is due to the diversity of tools and the inability to guarantee that the WSDL will operate correctly in all environments. Implementers may use the WSDL to build product-specific WSDL, or implement the service interfaces in some other manner.


14.The ESB needs to support integration of legacy systems using different communication protocols like TCP-IP , MQ , FTP , HTTP , Web Services

15.The ESB needs to support proprietary queuing methods like variants of JMS and other queuing mechanisms.

16.The ESB needs to support sending of alerts to users using variety of communication methods – SMS , e-mail(SMTP) and Paging


17.The ESB should provide standard adapters of the product and its licensing policies associated with them. The adapters should cover communication protocols , database connectivity , transformation , message transport and message

18.The ESB needs to support LDAP and the ability to query LDAP for retrieving contract properties , CPA and possible reference data and route the responses to appropriate system.

19.The ESB needs to support message patterns – asynchronous and synchronous messaging –publish and subscribe – store and forward- push and pull mechanism.


20.The ESB should support internal interfaces which need not be HL7 v3 compliant interfaces and the HL7 v3 compliant interfaces and communication with the applications so that communications can take place between IT systems where one IT system is within the organizations boundary of responsibility and the other IT system is outside the organizations boundary of responsibility.

21.The ESB needs to support multiple versions of HL7V3 message interactions. The ESB needs to support the concept of sending a single HL7V3 message to multiple target systems.

Deployment

1.The ESB needs to be deployable in distributed and federated fashion with ability to monitor and support from a uniform platform.

2.The ESB need to have minimum downtime requirement for configuration changes and upgrades.

High Availability and Scalability


1.The ESB need to support large data volumes including large message sizes and high through put. Please mention the ability the solutions ability to support multi-threading without consuming infrastructure resources to support increase in volumes.


2.The ESB need to support different High Availability options using load balancing, clustering and failover methods without any loss of messages. The High Availability expected for the ESB is 99.9

Security

1.The proposed solution framework needs to be ensure that all messages sent over the internet need to be secure. The solution needs to ensure that there is no user based access to the ESB from external data sources other than via the defined messaging interfaces.

2.The ESB needs to provide Security Framework and Infrastructure with ability to encrypt and decrypt messages and support for creation, installation and deployment of Certificates.



Service Management and Support


1.The ESB needs to be provided a framework to log message attributes such as the message creation date/time, message identifier, referenced message identifier (for response messages), the message interaction identifier, message status (success or failure) and the unique row identifier into the audit queue where the audit event (HL7 message, SOAP message or ebXML Acknowledgement) is held.

2.ESB needs to log the error codes and the associated text returned in the message responses of failed and unsuccessful messages. A browser based Message Log Viewer needs to be provided and allow a user to search audit log and select to view a specific message from the audit queues.

3.The Message viewer should allow only the message headers to be viewed; the message body should not be allowed to be viewed.

4.The ESB framework need to be support error handling and log communication and mapping errors and should be viewable from the Message Viewer. The error logging framework needs to log alias translation, errant data, and functional errors.


5.The service management framework of ESB needs to be integrated with standard Service Management tools of IBM and CA.



Testing

1.The ESB testing framework needs to acts as test Harness for testing both HL7V2.x and HL7V3.0 messages.

2.The test Harness need to provide a UI (User Interface) with ability for application testers to setup test data needs to be incorporated

3.The test harness needs to be a virtual application providing the responses in sync with the expectation of the ESB.

4.The test harness needs to be readily configured to test all business cases of the organizations applications. The rules configuration also needs to be user interface based instead of using technologies like XPATH

Decoupling Mode Handling

1. The ESB needs to handle delivery of messages when target system is not available manifested by a failed http connection.

2. The ESB needs to handle failed delivery of messages manifested by in the ebXML message mode by non-receipt of the ebXML Acknowledgement following the required number of retries.

3. The ESB needs to operate in slow retry mode after the expiry of retries in ebXML mode

4.The ESB needs to covey to the application of non availability of applications for synchronous messages manifested by non-receipt of the HL7 response.

5. The ESB needs to handle failure to deliver HL7V2.x messages manifested by failed TCP-IP connection and target system not available.





Supplementary Requirements

1. The ESB needs to provide the ability to longitudinally construct patient’s journey with data retrieved from different clinical systems and display in a consistent and fashioned approach to the end user.

2. The ESB needs to support the ability to support presentation layer integration using CCOW and other relevant standards.

EHR and SOA

It has been some time before i posted anything new. A combination of lethargy and work pressure sucked me away. But something caught my eye which i thought is worth commenting on.

A lot of RFP's these days quote SOA as the preferred architectural pattern. Well it sounds reasonable considering the fact that

Ø Legacy applications/existing systems can be refined to support EHR without the need to make the supporting hospitals introduce new applications as is seen by in case of one national programme which is delayed.

Ø Support for new range of transactions/workflows by enabling orchestration of services in local application and EHR.

Ø Enables faster delivery and deployment of different components of the solution using off- the- shelf solutions.


SOA enables easy separation of EHR and local applications and at the same time the services exposed by applications within local and the EHR settings will be interoperable for the entire infrastructure to be perceived as single system. The separation of components into loosely coupled services optimizes scalability, maintainability and functional flexibility.


Challenges

However there are huge challenges in using SOA for creation of an EHR.

• Legacy Systems , geographically spread over wide area , fragmented , disparate data types , disparate data sources (electronic/paper), proprietary technological systems including in-house built systems

• Many governments are targeting EHR infrastructure to aid healthcare reforms which is stretching it to the limit and is beyond its intended use.

• Existing systems rich in function , poor in interoperability

• Desire to bridge legacy and provide for future extensibility of the systems is difficult due to absence of uniform standards

• Many EHR implementations are driving point of service vendors to use new industry standards which are not mature , e.g. HL7V3 and SNOMED

Pitfalls

Apart from the challenges there are a few pitfalls as well

• Not SO easy to convert closed legacy healthcare systems into open service oriented applications and databases

• Big Healthcare vendors are not “service oriented- Systems that had around for years are now cannot be suddenly, service oriented.

• New SOA Infrastructure e.g. IBM Websphere for ESB or Oracle HTB increases costs

• SOA in Healthcare not implemented and not deployed anywhere on a huge scale

EHR Patterns -Advantages and Challenges

This is an extract from a presentation which i gave recently where i have been asked to present the different EHR architecturial patterns and the advantages and challenges associated with each of the patterns

There are three types of EHR Models/Patterns which are in wide use

Ø Central Repository Model
Ø Federated Model
Ø Hybrid Model

Central Repository

Features

Ø Health record is stored at point of care systems as well as a common repository
Ø Patients record is identified by a unique identifier which may be allocated by the central repository or a national organization
Ø Local record may be a detailed record and the shared record a summary record
Ø Thin EHR

Advantages

Ø Easy and Quicker access to the data
Ø Security controls easy to implement compared to federated model
Ø Better price/performance ratio
Ø Data can be entered into the local systems or directly
Ø Allows data to be cleansed and its terminology standardized by reference to a canonical controlled vocabulary
Ø Consistent interpretation of data by different clinical settings


Challenges

Ø Determining ownership of data between organizations
Ø Infrastructure and scalability issues
Ø Decoupling and Business continuity issues
Ø Resolving conflicting data issues between central and local e.g. allergies information
Ø Governance and funding issues between different organizations

Federated Model

Features

Ø Health record is stored at their places of origin- point of care systems
Ø Patients unified record is fetched from different systems using patient indexes and record locator services
Ø The fetched record will usually be a agreed subset of data in the point-of-care systems
Ø Thick EHR

Advantages

Ø Avoids the infrastructure and ownership issues that are barriers to information sharing.
Ø Decentralized data approach safeguards privacy and security by affording a pathway that facilitates information exchange while leaving appropriate controls in place.
Ø Infrastructure can be relatively small and requires less capital and ongoing operating expense.
Ø Data can be managed locally
e.g. deletions without considering the impact on data sharing.


Challenges

Ø Appealing in theory but has many implementation and performance difficulties in practice, particularly for large systems with many records and many different federated EHR sources (or EHR nodes).

Ø Rely on a number of factors such as efficient distributed queries, short latencies, and compatible security models and are only as good as the weakest link in the chain.

Hybrid

Features

Ø Combination of the two architecture types
Ø Patients record are identified by a combination of identifiers – national and local
Ø Central record has only demographics and limited clinical data with access control and record locators for detailed data
Ø Thin and Thick EHR

Advantages

Ø Provides all of the advantages of a centralized data architecture for the most relevant clinical data required for care.
Ø Provides benefits of the federated architecture with access to detailed record
Ø Local systems still retain control of their data with access to relevant patient
data from other organizations


Challenges

Ø Deciding the scope of shared data and unshared data
Ø Different access controls required locally and centrally for similar data of a patient.

Message Sequencing in HL7V2.x

Maintaining message sequencing when clinical systems are integrated with in an enterprise using middleware approach and HL7V2.x message specifications is crucial from two perspectives

• Delivering messages in the order is crucial for HL7 messaging; for example an A03-Discharge message cannot arrive before an A04-register a patient or A01- Admit notification. In case of orders a Modify Order cannot reach before a Create New Order is sent
• If a sender needs to send an extremely large message to a receiver, typically containing multiple OBX segments it is impractical to send all the segments into a single message as it will not fit into a single message. The breaking the message into parts and sending each of the parts as a separate message requires that each message needs to indicate its position in the sequence and indicate the total number of messages to expect.

The obvious solution to maintain the messages in sequence in the order they are received and to keep them in sequence as they travel through the middleware-Integration Engine. The solution may be as simple as sending all HL7 ADT messages from the HIS/PAS system to departmental systems in the hospital in the order that they were generated. This can be done by allowing a single-threaded route from the originating application usually the HIS/PAS to the middleware-integration engine. This usually means implementation of a behavior where messages are sent to a single point (Fixed IP address and Port number) and a receipt of acknowledgement message for the previously sent message before the next message is sent.

However for large organizations with huge volumes of messages it is not feasable to maintain a single thread and implementation of multi-threading might disrupt the delivery of messages in the order which they arrive.


One way to solve the problem associated with message sequencing for multi-threaded solutions is to keep messages in sequence that contain information related to the same entity which can be the patient identifier and allow the middleware to route all the messages related to a particular patient or a rane of patinets based on the patient identifier range over the same thread.

Approach – A – Single Threaded Solution

Messages must be delivered by the sending system in sequence using a single communication channel with the integration engine. Messages are received from HIS/PAS through TCP/IP Socket Listener and are allocated a sequence number. The sequence number, and message control id (MSH-10) are persisted either onto the disk or to the database associated with the integration engine. Each of the message that is sent are checked against the stored sequence number and message control id to verify if messages are sent in sequence.

Approach – B – Multi Threaded Solution

When a message is received by the middleware it is allocated a sequence number and the number along with the patient id taken from message are persisted to the disk or database. In case of multi-threaded solution the messages can be processed in parallel by any of the thread which subscribes to the publisher of the message. The thread which picked up the message for processing checks to see if a message has been is delivered through that thread for the patient in the message by looking at the patient id. If it is established messages for that patient in fact have been sent through that thread then a check is made to see if the sequence number of the current message is greater or lower than previously sent stored message. On confirmation of the value of sequence number value the message is delivered to the destination system. The delivery status of the message can be stored in the system so that in case of non-delivery suitable rehydration mechanism can be established before delivering the next message with the same patient id.

Accurate Definitions -EMR/EPR/EHR

This is a post just to clarify the different terminologies used in Healthcare informatics and I feel annoyed when people use these terms intermittently as if they all mean the same.

EMR - Electronic Medical Record

The EMR is very medically focused and usually focuses on a particular medical domain for example orthopedics. EMR can be for a particular department in a hospital or a collection of patients medical information from all departments in a given hospital site. Rarely the scope of EMR extends outside a hospital even when it does it is usually for a organization which has multiple sites but never between two hospitals which belong to different organizations. This is a widely used term in N.America and Asia-Pacific and not commonly used in European countries.

EPR - Electronic Patient Record

This is a term which has its origins in the UK and essentially has the same definition as that of EMR. However the definition of EPR by NHS as “an electronic record of periodic health care of a single individual, provided mainly by one institution” makes EPR definition more patients centric. NHS has classified EPR into 6 levels

Level 1 - Patient Administration System and Departmental Systems
Level 2 - Integrated patient administration and departmental systems
Level 3 - Clinical activity support and noting
Level 4 - Clinical knowledge, decision support and integrated care pathways
Level 5 - Advanced clinical documentation and integration
Level 6 - Full multi-media EPR on line


EHR - Electronic Health Record


Electronic Health Record (EHR) is described as the concept of electronic longitudinal collection of patient’s health and health care – from cradle to grave. It combines information from different care settings held in different systems and in some instances aggregates the data and shows them as a single record.

The Committee for European Normalization provides the following definition for EHR:

“A repository of information in a computer readable format regarding the health of a subject of care “


The Australian National EHR Taskforce, defined EHR as

“an electronic longitudinal collection of personal health information based on an individual or family and entered or accepted by healthcare professionals .It can be distributed over a number of sites or aggregated at a particular source including a hand held device. The information is organised primarily to support continuing, efficient and quality healthcare.”

20 Minute HL7V2.x Primer

HL7 V2 Philosophy

The philosophy of HL7V2.x is based on the assumption that a real event that occurs in a healthcare setting creates data that needs to be exchanged between different systems of that setting. This is essentially to eliminate duplication of data collection from the patients and to automate administrative process saving time and money.

The real world events e.g. patient admitted or Lab orders raised are represented by trigger events and messages are specified for each trigger event. The structure of an HL7v2.x message is shown in Figure 1 below

Figure 1: Version 2 Message Structure

Segments - Version 2.X messages are designed around message segments indicated by a three letter segment id e.g. PID – Patient Identification; ORC- Common Order etc. Each message is composed of a group of segments in a defined sequence. Segments of message many be mandatory or optional and may repeat .A segment is a delimited line of data that contains data relevant to one specific use in the message. For example, patient identification information is in PID segment while patient allergies are defined in AL1 segment. Groups can be thought of as simply a collection of segments or other groups.

The HL7V2.x standard specification defines the standards segments. However the messages can also contain segments that are not part of the standard. These segments are locally-defined segments, called “Z-Segments” as their Segment ID code begins with a “Z”. These are allowed to add flexibility to the standard and usually appear at the end of the relevant segment group.

Each segment is a logical grouping of data fields. then composed of data fields. Each data field can have one or more components and each component may have sub-components.

HL7 V2.x History

HL7 1.0 originated in 1987 as an open standard for vendors for interfacing different clinical systems within an organization. It was defined in a period of six months with initial set of Orders and ADT messages. They were not widely implemented but laid a foundation for defining standard healthcare interfaces. HL7 v2.0 which was demonstrated at 1989 HIMSS convention introduced the concept of triggers, added additional detail to the Message header, and expanded the set of messages to include billing. HL7V2.0 was also not widely implemented. Figure 2 below shows a timeline of HL7 Version 2 releases.

Figure 2: Version 2 Timeline

HL7 Version 2.1 - HL7 Version 2.1 is the first widely used standard after its publication in March1990.HL7 2.1 is still in use today by some clinical systems.

HL7 Version 2.2 - HL7 Version 2.2 is primarily centered around cleaning up and clarifying version 2.1 specifications The notable changes to version 2.2 among others is that Segments were added to existing events for e.g. Merge Segment was added to the Transfer events (A06 & A07); Next of Kin Segment was added to the Patient Query (A19) event. Some additional fields were added to segments for e.g. additional fields to PID segment to handle newborn baby information and Next of Kin was made more generic to handle any person associated with the patient. New messages to handle Pharmacy, Diet and supply orders were added. Apart from adding new data types the HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each is required.

HL7 Version 2.3 - Version 2.3 offers new data types, especially the 'x'-tended versions of PN, CN, etc. Enhanced query functionality and clear definitions of tables for e.g. differentiating ID/IS data types. In Financial Management Additional messages were added and message constructs were extended to allow greater specificity in the intent of the message, and to report additional information.

HL7 Version 2.3.1 - HL7 V.2.3.1 includes an updated TQ (timing/quantity) datatype to manage order occurrences, updates to the OBR segments and ORU message to facilitate public health surveillance reporting, updates to tables, segments and data types to accommodate international paradigms for reporting names and pharmacy orders, and the addition of a new field to the ORC segment to satisfy the HCFA Medical Necessity requirements for outpatient services, and an update to the FT segment to satisfy federal requirements for Level 2 Modifiers.

HL7 Version 2.4 – Version 2.4 is approved as an ANSI standard in October 2000. HL7 v.24 introduces Conformance Query profiles, and adds messages for laboratory automation, application management and personnel management. Additionally, a new event, specific to OPPS and APC requirements was added. This event, Transmit Ambulatory Payment, includes two new segments, the Grouping/Reimbursement Visit Segment and the Grouping Reimbursement Procedure Segment.

HL7 V2.x Message Construction

Message Encoding Rules: Version 2.x messages have some defined special characters that delineate data fields which make up the message. These special characters are the segment terminator, the field separator, the component separator, the sub-component separator, and the repetition separator. Table 1 below shows the definition of these separators


Table 1: Version 2 Separators

The interface that implements version 2.x messages will use escape sequences for e.g. \F\- Field Separator to signify that reserved characters (delimiter or separator characters) is present in the value

Message Construction Rules: A Version 2.x message consists of segments. Message segments are constructed in the order defined below

1. The first three characters in the message segment that will be inserted into the message is the segment ID code, e.g. - PID – Patient Identification Details.

2. Each segments consists of different fields and each of those data fields that make up a segments are inserted into the segment in sequence:

2.1 A field separator ¦XYZ¦ is placed at the beginning and the end of the field. If there is no value present in the field then no other characters are required and a ¦¦ is used.

2.2 If the value is present but equivalent to null, two consecutive quotation marks are placed in the field ¦""¦.

2.3 If a field is defined to have components (combination of meaningful data fields), the following rules apply:

• Components are separated by the component separator.


• Components that are present but null are represented by two consecutive quotation marks


• Components with no value require a component delimiter but do not require characters in the component. For example: ¦ABC^^DEF¦


• Components at the end of a data field with no value do not have to be represented by a component delimiter. For example: ¦ABC^DEF^^¦ = ¦ABC^DEF¦


• When a component is itself a data type that contains components, its delimiters are demoted by one. For example, the component delimiters for the composite field ¦ABC^DEF¦ are demoted by one to ¦JKL^ABC&DEF¦

2.4 If component has sub-components, the following rules apply:

• Sub-components are separated by the sub-component separator.


• Sub-components that are present but null are represented by two consecutive quotation marks.


• Sub-components that are not present require place holder separator but no characters in the sub-component.


• Sub-components at the end of a data field with no value do not have to be represented by a sub-component delimiter.

2.5 If the field definition permits repetition, the repetition separator is used only if more than one occurrence is transmitted. The repetition separator is placed between occurrences.

2.6 End each segment with an ASCII Carriage Return character - ASCII(13), HEX(0D).

3. Steps 1 and 2 are repeated until all segments have been generated.

4. The receiving system will ignore segments, fields, components, and extra repetitions that are present but not expected. The receiving system will treat segments that are expected but not present as consisting entirely of fields that are “not present”, and it will treat fields and components that are expected but not included in a segment as “not present”.

Data Types: Data types define the structure of the fields. Data type specification is an important tool for simplifying the complexity of the HL7 standard, and is critical for understanding the data contents of an HL7 field.

Version 2 supports the following data types

• Primitive – consisting of one component e.g. ST(String)


• Simple – multiple components, no ‘type’ code e.g. CE (Coded Element)


• Complex – multiple components with a ‘type’ code e.g. XAD(Extended Address)

The application of data types to the fields can be gauged by the following examples.

The format of CE as per version 2 specification is

CE :< identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

e.g. 11289-6 ^ Body Temperature ^ LN

11289-6 is the identifier; Body Temperature is the text and LN (LONIC) is the name of the coding system.

The format of XAD as per version 2 specification is

XAD : <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)>^ <county/parish code
(IS)> ^ <census tract (IS)>

e.g.: ¦23 Sussex Place ^Flat 3 ^ Slough ^ Berkshire^SL11NH^UK^P^^BERK^¦

23 Sussex Place corresponds to street address ; Flat 3 for other designation; Slough for city; Berkshire for state;SL11NH for postcode; UK for country and P which stands for permanent.

HL7V2.x Message Anatomy

Imagine the following scenario

• Patient Andy Smith Carol was admitted on July 22, 2006 at 11:23 a.m. by Doctor John Carol (#C145678) for an orthopedic procedure (ORT).



• He has been assigned to room 202, bed 10 on nursing unit 1000.



• The Patient Lives at 23, Sussex Place, Slough, Berkshire, SL11NH and was born on December 23rd 1961.



• The hospital the Mary Green Maternity – MGM has PAS System - ADT1 and a laboratory system PATHLAB.

The admission of the patient corresponds to a trigger for Admit patients and an event A01 is intended for admitted patients. This will be sent from PAS system to Lab system in real time as soon as the admission takes place. According to HL7 V2.3.1 message specifications a portion of message structure of A01 shown in Table 2

Table 2: A01 Message Structure

Download the complete A01 HL7 V2.3 message specifications from HL7 website (http://www.hl7.org/)

The most important fields in the message segment (MSH) header are shown below in Table 3.

Table 3: Relevant MSH Fields

The message segment MSH shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.

The other important message segment PID in A01 whose important fields are shown in Table 4. The complete list of fields is available from v2.3.1 Message pack on HL7 Website.

Table4: Relevant PID fields

The message segment PID shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.

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

Current Status of HL7V2

Some countries such as Germany have legislation that stipulates the use of V2.X, and V2.4 which is a ANSI standard from 2004 is now being proposed as an ISO standard, making it a truly international standard though it have been developed for American market.

The Version 2.x standards are widely used in different countries in the world, in particular in acute healthcare settings and in some countries even in primary care. The HL7 versions 2.1 to 2.5 which have been published are in wide use and the work is underway on V2.6, which is expected to be published late 2005/early 2006.

Version 2.5 – HL7 Version 2.5 is the last published standard in the HL7 Version 2.x series. Version 2.5 contains new messages and updates to HL7 Version 2.4. Version 2.5 is supposed to be broader in scope that Canadian Health Information Technology Trade Association (CHITTA) have issued a position paper to Canada Health Infoway urging the agency to reconsider its support of Health Level 7 (HL7) Version 3 in view of the supposed unavailability of Version 3 normalised specifications (Ref: Section xxx) and asked it to endorse HL7V2.5 which provides greater interoperability. HL7 Version 2.5 introduced a number of new events, segments and messages and expanded the Control section. Version 2.5 is more consistent and supports more functionality than any of the previous versions. The significant modifications to version 2.5 are

• Better and clearer documentation of the data types



• A definition of a message profile methodology



• Better support for Radiology/Imaging by means of a new segment and a new order message



• Support for orders related to blood products



• New update message for diagnosis/procedures



• New specification of claims and reimbursement messages

Version 2.6 - HL7 Version 2.6 completed the first ballot cycle in September 2004 and is nearing completion and will be released in 2006. V2.6 will include enhancements made to allow the communication of Electronic Health Record (EHR) information which is sighted as one of the biggest deficiency of version2.x. Version 2.6 is an upgrade to HL7 Version 2.5 and it includes new segments, fields, components and subcomponents necessary to apply either a documented regulatory requirement or a harmonization requirement with HL7 Version 2 material created by other committees. The main changes to version 2.6 from version 2.5 are

• Addition of general new segment -UAC "User Authentication Credential"



• Better management of access to sensitive patient information by adding Access Restrictions (ARV) segment.

• New message type to support the US National Animal Health Laboratory Network (NAHLN)



• Deprecation of data types such as CNN,LA1, LA2 and NDL data types



• Addition of components to the XAD and XTM data types.



• "TS" Timestamp data type is being replaced by the DTM "Date/Time" data type.



• CE "Coded Element" data type is being replaced by either the CNE "Coded with No Exceptions" or the CWE "Coded with Exceptions" data types

• Code tables defined by external standards organizations will not be considered as HL7 tables but an HL7 number will be assigned.



• Many new fields have been added to the segments in the Financial Management



• “Observation Reporting” chapter has added support for referral and shared care



• Personnel Management chapter contains new attributes to the STF and ROL segments.



• New chapter Materials Management with messages for communicating various events related to the appointment scheduling for services and resources

XML encoding :The German HL7 group defined a comprehensive database of the HL7 standard to allow consistency checks of items and to support the application of the standard by the user when they realized that the different chapters in the published standard have been developed by different groups and there are no distinct rules or guidelines for the development of various parts of the standard.

The database is a Microsoft Access database and contains the official definitions for events, messages, segments, fields, data types, components, tables and values. An XML representation of version 2.x standard is algorithmically derived directly from this database. The algorithm consists of SQL queries to extract tables which are then exported to ASCII delimited files. Perl scripts are applied to these ASCII files to generate XML DTD’s.

Two sets of DTD’s have been provided;
A single DTD (hl7_v231.dtd) that contains all HL7V2.3.1 definitions. This file is broken up into four separate DTD definitions – Message.dtd; segments.dtd; fields.dtd datatypes.dtd.

One DTD for each message structure. Each imports the same datatype DTD referenced by hl7_v231.dtd, but is otherwise self contained with all message, segment and field declarations needed for the message structure.

The XML representation represents HL7 message structures as XML elements. Message structures contain segments, also represented as XML elements. Segments contain fields, again representedas XML elements. A field's data type is stored as a fixed attribute in the field's attribute list, while a field'scontent model contains the data type components. Other fixed attributes are used to expand abbreviations and indicate HL7 Table value restrictions


A simple version 2.x representation is shown below



The representation of the above message using XML encoding rules is shown below.

AJAX and Healthcare IT

One of the most important factors in driving users towards higher use of clinical systems is providing an effective user interface. Specifically for web based clinical applications it is quite a challenge to provide an effective user interface. AJAX (Asynchronous JavaScript and Extensible Markup Language) is emerging as an effective solution in providing such a interface

For starters Ajax lets web pages feel active and interactive in real time by exchanging small packets of data behind the scenes so that the entire web page doesn't have to be reloaded each time the user requests new information. Ajax makes web-based applications look and act like desktop applications. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.



For a more detailed understanding of AJAX Refer to this article http://adaptivepath.com/publications/essays/archives/000385.php

In healthcare IT AJAX can play a big role in simplifying User Interface workflows for end users. For example typically in existing applications scheduling of clinicians in an enterprise requires the clinician details to be searched before slots are associated for performing activities like procedures in different departments. AJAX allows auto-completion of data and it could aid in typing in clinicians names, procedure names, department names instead of remembering the codes associated with it. No popup listing and scanning down a list of values or searching is required.

It is typical while working in departments like Mental and Psychiatric departments large amounts of clinical data needs to be captured in one single form. It is often quite frustrating in web based applications after filling in the data accidental clicking on the wrong icon or page link causes complete loss of data. We can using AJAX we can to persist the values of form fields into the HTTPSession step by step, just incase someone clicks off their page by mistake or loses their work.

AJAX can also be used to navigate huge procedures tree, while retrieving the required element. This enabled us to deliver a much better user interface and lessens the data entry time.


One of the most exciting uses of AJAX can be for developing a UI for quick browsing and selecting of clinical codes. SNOMED-CT is emerging worldwide as the most dominant clinical coding standards. At the moment, most SNOMED-CT browsing is done using a free (but not open source) Visual Basic GUI application called CLUE (see http://www.clininfo.co.uk/clue5/index.htm). Ask any clinician or any organization where CLUE is used they can tell the issues associated with it. AJAX can be used to provide a Web-based SNOMED-CT browser/search facility to provide good interactivity in letting the clinicians browse and choose the correct SNOMED concept. The provision of SNOMED-CT look-up facility using AJAX can be used for both open source and closed source clinical applications. An AJAX based SNOMED browser will enable distribution of codes through a central service or access clinical codes locally. This will enable updating of clinical codes in local systems automatically either by client side polling or by user invoked requests.



One of the major hindrances of a nation wide EHR is the inability to provide an affordable application with a user interface relevant to organizations of different size ranging from a Family Physician office to a Big General Hospital. A web based solution centrally hosted solution is the oft quoted answer for this but it is a known fact that web based solution negates the rich experience of a local client apart from not catering to an individual organization needs. AJAX makes these web based user interfaces much more interactive without requiring the typical submit/post/redraw round-trip of an HTML interface. AJAX uses the “The Web as Platform" paradigm and allows Ajax desktops or personalized UI suiting to the organization.

Informational Governance and EHR

Most of the national EHR implementations seem to be plauged with issues concering the security of the data. Though it has been realised long back that Privacy and security are of utmost importance in the design of the EHR infrastructure enough attention has not been given by the policy makers involved in the deployment of EHR in their respective countries towards this.

A Canadian poll result indicated that the two most biggest concerns of the patients in the deployment of EHR in their country are

• Confidentiality and Privacy - 54%
• Safety of information - 31%

The key IG principles that need to be considered for building EHR are

• Restriction of access of the EHR to clinicians who currently have a duty of care for the individual concerned-The biggest issue with this principle is the decision to consider whetehr we restrict access to individual clinicans or group of cincians who are responsible for the care of the patient. It is a known fact that clinicans rarely work in silos expecially in acute settings.
  
• It should be possible to assign personally requested special levels of confidentiality to specific health information held in the EHR- Most people assume a simple Role Based Accesss is the solution for this but the key to this principle is associating multiple business activites with a role and linking thse activities to users of that role.

• EHR availability should be restricted within the organizational boundary within which it is created, except with patient consent -The issue with consent is the issues associated with explicit and implict consent and should the clinicans be able to override the dissent in case of emergenices.

• Operational staff (administrative and IT) should only have access to the minimum information required to perform their task-It is a well known fact more than outsiders it is insiders and more prominently operational staff who leak clinical data. But the issue is what level of data is minimal data ; how will the issues related to data inconsistency be resolved without operational staff looking at the data.

• All EHRs should have an automated and tamper-proof audit trail including a logof access which should be available to the patient.-Tamper proof audit trial should not be just a simple database log but much more secure than that for example we can considerr triggering alerts to responsible clinicans when patients sensitive data is viewed which shoud help mitigate this problem to a extent.

• The physical machinery storing the EHR should be protected -Proper Resilience and Disaster Recovery controls are key to this; a crucial factor is the amount of time taken to failover which is not a factor for secuirty but key factor for patient safety.