Healthcare Informatics- A 3000 Feet View

Ensuring Clinical Safety - HL7 Implementation

2011-03-03T12:50:00.009Z

The one thing that is missed quite often during deployment and rollout of HL7 (read HL7V2.x) is the “clinical safety” factor. It is not often considered if introducing the messaging is any way compromising the information quality of patient’s data or if it’s introducing any major business changes to the existing clinical workflow in the organisation. Organisations need to stress to the system providers as well as to the system integrators that they ought to consider clinical safety as a major factor in all stages of the rollout including development, deployment and testing.

There are ways to ensure that the introduction of HL7 does not compromise clinical safety. This post discusses a approach for this

Conformance Accreditor: The organisation needs to employ a system integrator or act itself as one (in case it has a internal tech team) to define conformance standards

Conformance Guidelines: The defining of conformance standards need to be based on the following principles

Define the message set that is required to be used within the organisation and publish it. The definitive message needs to be based on the requirements to automate and provide seamless data access, subject to access controls.
Avoiding optionality and being more specific when defining the messages
Identify the use cases and build story boards using every day scenarios of the organisation. Involve the organisations clinical and administrative team in this.
Publication of defined code set to be used in the messages
Define mapping guidelines to enable system providers to identify the correct data attributes
Provide sufficient guidance on message interactions for the messages that need to be sent and received by the systems for different events.
Define the expected systems behaviour while processing the message.

The publication of proper definition of code sets and values, message specifications and mapping guidelines ensures that data is not manipulated in a clinically unsafe fashion or mapped to the wrong code compromising patient safety.

(See this for a better understanding of conformance : http://secure.cihi.ca/cihiweb/en/downloads/hl7can_conformance.pdf)

Conformance Tools: Provide simple test harness tools adhering to the proposed conformance standards, for the system providers to check the correctness of their implementation- e.g. message structures, data types, expected code values. Provide ability to view data in the message in a GUI so that they do not have to traverse the message. These tools are expected to be provided by the system integrator

Conformance Testing: The clinical safety testing process involves exhaustive end to end testing to see if the data sent by the sending systems has not hindered the work flow in the receiving system. The testing to defined work flows in system where the data is received and used ensures that safety of the patients is not compromised

Defining Transition: The changes that are brought about by implementing HL7 in an organisation needs to be formally documented. The capabilities and workflows in the organisation that are impacted by the implementation needs to be compared and ensure that the users are aware of the changes through training.

Standards - Case and Types

2011-02-19T17:17:00.006Z

The purpose of the post is to reinforce the need for standards and help classify standards

Case for Standards

The idea that Healthcare continuum (using information systems) extends not just across the departments in a healthcare enterprise, but across healthcare enterprises in different care settings (necessitating information exchange) has accelerated the adoption of standards. The other fact that the best of breed systems for different departments are now the preferred option to a single monolithic system for a single enterprise (requiring information and data exchange within the organisation to function as single entity) has again brought the notion of standards to the forefront. Even for organisations which have single enterprise wide system, healthcare standards are relevant as they need to standardise the entry and capture of healthcare data.

In summary standards are needed for representing and exchanging information to

Not compromise the safety of patients by preventing exchange of incorrect, insufficient and not understandable information , e.g. allergies , adverse reactions
Provide access to data for patients from different providers in uniform fashion
Allow aggregation of data for performance measurements and monitoring
Provide access in disparate systems for a longitudinal view of the patients medical history
Lower IT support costs by reducing need for data cleansing and data quality

Types of Standards

In general the implementation of standards fall in the following areas of categories

Voluntary Standards: These standards are usually developed in voluntary consensus by industry bodies or market groups associated with the industry. As these standards are developed by industry or someone associated with industry the standards are usually well regarded. The voluntary nature of standards will allow the implementers of standards to innovate on the base standards.

However the voluntary natures of standards ensure no enforcement mechanism, ambiguous interpretation and absence of mechanism for conflict resolution.

E.g. HL7V2.x standards developed by HL7 Inc which is a voluntary organisation

Regulatory Standards: These standards are usually legally binding contracts, laws or authority enforced regulations. Everyone must adhere to these standards and non-compliance is recognisable. There usually will be regulatory who ensure the compliance and assess the compliance.

However the regulatory standards encourage no innovation and sometimes do not cover all possible situations. Any conflicts on interpretation lead to long legal wrangles and the need for compliance assessment and inspection leads to large regulatory inspection teams

E.g. Usage of READ standards in UK NHS primary health care

Implementation and Conceptual Standards: Implementation standards are those have are dominant and wide usage and reinforce existing patterns. Conceptual standards are those which are developed to bring in new ways of thinking and working in the industry

E.g. Usage of XML, SOAP-WS

Product Standards: There are some standards which prescribe and recommend products or services. This can lead to better design of existing products and services or future products and services. This lead to a consistent and uniform feel to users of different products across the industry.

E.g. standards recommending common CUI (Clinical user interface)

Process Standards: A process is usually defined as a series of activities and logic that form a repeatable pattern. Process standards are those that focus on bringing efficiencies to the industry by developing repeatable processes.

E.g. Standard pathways for treating patients based on NICE guidelines

PS: Thanks to a friend who kept asking me for my next blog post and helping me revive my interest

Acknowledgements in HL7V2.x

2010-03-01T01:07:00.007Z

HL7V2.x messaging standard indicates that Acknowledgements (ACK’s) are messages sent by a receiving system to the sending system in response to a transaction from the sending application. In a setup where HL7 is implemented the sending system will assume that the message sent by it is not received till it receives an ACK from the receiver. So in summary Acknowledgements are used to confirm the receipt of the message. Acknowledgements are implemented at two levels transport level and application level. In this post we will have a look at both the options.

Transport Level Acknowledgements: Sending systems open a connection to send messages to the receiving messages, mostly through the interface engine which act as broker for communications between different systems in a healthcare setup. If a message is acknowledged on the same connection which is used to send a message they are termed as transport level acknowledgements.

The connections can be transient or persistent in nature. Transient connections are those where the connections are closed after an acknowledgement is received. Each time a message is sent a new connection is made. Persistent connections are those where the connections are kept open and messages are sent over the same connection in a sequence, in sense sending a next message over the same connection after an acknowledgement is received for the previous sent message. Persistent connections are generally configurable where the connections can be closed after a certain period of inactivity. There are different factors which determine the choice of connection. The factors include message throughput, latency, sequencing, fail over, high availability and general infrastructure of the organisation.

Transport Level Acknowledgements also indicate that the ownership of the message is passed to the receiving system after it has received a acknowledgment. The transport level acknowledgement also informs the transport and reception error.

If a message is received and accepted by the receiver then it sends a ACK and performs one of the following

•Validates and persists the message successfully, generating the functional response message with a value of AA (Application Accept) in MSA-1-acknowledgment code field.

•Send an error response, providing error information in functional segments to be included in the response message with a value of AE (Application Error) in MSA-1-acknowledgment code field.

•Fail to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the receiving system will be able to accept the same message at a later time. The sending system must decide on an application-specific basis whether the message should be automatically sent again. The response message contains a value of AR (Application Reject) in MSA-1-acknowledgment code.

Application Level Acknowledgement: A sending system may require an application level acknowledgment from the receiving system if confirmation of successful processing is required. This can take the form of an HL7v2 ACK message (e.g. to indicate a successful processing of order it received) or a business response.

Generally the transport acknowledgment only confirms the receipt of messages but does not convey any confirmation of processing of the message. The need for these interfaces needs to be decided by the business processes. They are transmitted in the same way as any other message

In HL7 terminology the above two types of ACK's are termed as follows

•Original Mode Acknowledgement - a "Receive" ACK and majority of the ACKs used in HL7 communications; indicates that a message has been received but not necessarily processed yet

•Enhanced Mode Acknowledgement - an "Application" ACK that is a resultant status return rather than a communication response (i.e. query results, order response, etc.)

ICP's and EHR

2009-10-22T18:45:00.002Z

An ICP determines locally agreed, multidisciplinary practice based on guidelines and evidence where available, for a specific patient/client group. It forms all or part of the clinical record, documents the care given and facilitates the evaluation of outcomes for continuous quality improvement".

National Pathway Association (1998)

ICP’s have their origin in providing coordinated care to patients by different specialist teams within a healthcare organisation. Each team records their interventions on a patient for a specific health condition in the organisation’s Electronic Patient Record (EPR) system and other teams intervene accordingly based on the notes provided. This paved the way to define electronic ICP’s (e-ICP) in EPR systems.

The advent of Electronic Health Records (EHR) brought the possibility of extending ICP’s across multiple healthcare organisations from different care settings. EHR's facilitate flow of information across different care setting boundaries even to agencies outside healthcare (e.g. social care) who are involved in the care of a patient.

Benefits of Electronic Care Pathways over EHR's:

• Allows care pathways to be built around patients and not institutions by providing real time recording and allowing different organisations involved in the patient care to have the same view
• e-ICP’s provide quick access to information(instead of browsing though bundles of paper for which each organisation has different format and different recording styles) and provide multiple views – high level summary view from different organisations as well as detailed view of each organisation in a chronological fashion
• e-ICP’s allow faster remodelling and review of business processes to suite each patient

However the difficulties in deploying e-ICPS’ through EHR is not a technological one but cultural and business one involving the need for agreeing common data formats and sharing the data owned by an organisation across different care settings and agencies.

EMR from Prespective of Pharma

2009-10-13T19:18:00.005Z

Pharma companies have started working with clinical service providers and started using EMR's from two prespectives

Data and Study Setup

Secondary Users Service

Data and Study Setup

Data and Study setup can be incorporated in a EMR to exploit the following features

Implement screening parameters into core EMR to identify prospective patients for pharma trials at point of care
Setup data capture from trials as part of clinical care and clinical documentation workflow
Populate data in care report forms automatically from EMR
Embed care record forms as tabs in core EMR so data is collected and stored against patient record
Implement clinical rules and alerts for compliance and range checks for data and structured documentation checks

Secondary Users Service

It can be used for the following

Easier data extraction from EMR for proper reporting on adverse events
Unified reporting of current and historical data
Findings can be published as standard clinical documentation
Monitor outcomes based on ICP’s and evidence based decision support

Example Implementations

Pfizer – Drug Safety -Supporting Physician Reporting of Adverse Reactions and Public Health Threats

NOVARTIS – Clinical Trial: Lab and Image Data - Innovating Clinical Data Capture for Labs and Images using EMR lab ordering and results reporting using HL7

Eli Lilly – Patient Visit Workflow – Streamlining the patient workflow using standard Inpatient and Outpatient workflows

genzyme – Disease Registry – Profiling diseases geographically and using other statistical profiling such as gender , age etc

SAIC – Biosurveillance -Standardizing and Facilitating Data Collection for Enhanced Biosurveillance

Ramblings about Electronic Patient Record

2009-04-15T14:10:00.005Z

This post is a set of ramblings which may sound a bit incoherent but needed to be grouped together to give an overview about some of the things that needed to considered about Electronic Patient record/Electronic Medical record.

Mandatory Pre-Requisite

In my view a mandatory pre-requisite for meeting the many objectives of Electronic Patient Record (EPR) is the ability of that application to support semantic interoperability of clinical information. What I mean by that is the Entry, storage and communication of clinical information by the application in ways that allow it to be consistently reused, retrieved and processed by it and its ability to communicate that information to different software applications. However maintaining Semantic Operability is not so easy due to various issues

• Technical issues
– Different information models
– Different clinical terminologies
– Different interfaces between information models and terminologies
• Practical issues
– Different perspectives on similar information
– Different motivations for data entry
– Different methods of data entry
– Different expectations about the use of information

Barriers

From my practical experience, implementation/deployment of EPR is not very easy; there are lots of barriers in implementing EPR. I jotted down a few of the barriers which needed to bottomed down in the business plan before deciding to implement EPR.

• Financial and Capital costs associated with the EPR applications

• Adoption of the systems mainly by clinicians and to some extent by auxiliary clinicians. Most organizations underestimate the training required for their staff to adopt the new system but also fail to convince them.

• Defining technology and information standards and adhering to them. I know in some cases it becomes expensive to adhere to them but if you start compromising then there will be no end to it.

•In some cases if the organization already has a legacy system the transition phase adds work to an already overburdened IT staff.

•Of course the now famous Information Governance issues covering security, privacy and consent to access the electronic records.

• In some cases the failure to define clear and tangible benefits also becomes a barrier

Standards

EMR’s and almost any other information-oriented system in a clinical environment cannot be used without well-defined standards for representing and communicating information. Data need to be exchanged between multiple, heterogeneous systems and might be used by very different applications .The following points highlight the need for standards

• Unavailable standardized communication results in health hazards, e.g. drug hypersensitivity
• Patients are starting to demand that ”their” data should be available online
• Improve efficiency by enabling professional cooperation in new ways
• Quality management requires aggregated data
• Standards allow integration of modular systems from different suppliers
• Many standards issues require professionals and authorities not just industry
• Standards can lower costs of ICT support by expanding the market

Failure Reasons

The failure of certain organisations in implementing Electronic Patient Record in my view is the failure to understand basic standardisation approaches in healthcare organisations. There are two standardisation approaches in theory

• External standardisation
– Strategic planning tool
– Market reassurance
– Consensus approach
• Internal standardisation
– Strategic enhancement of the use of internal resources
– Change management is essential
– Class discussion: regulatory and laissez-faire approaches to internal standardisation

Implementing EPR at a single organisation of multiple organisations read hospitals is essentially setting an internal standard for information processes related to patient information
– Regulatory approach: set the standard way for all possible situations involving production of patient information
– Laissez-faire approach: describe all accepted standard procedures and allow hospital staff to choose which standards to use or invent their own procedures, if necessary

Just wished they had known which approach to use.

The Transit Electronic Health Record

2009-03-14T23:46:00.003Z

Electronic Health Record is normally seen as repository of aggregate clinical and demographic information fed by point of source systems from different care settings. But the infrastructures associated with the EHR are being used to perform other ancillary functions such as facilitating the data exchange between the different point of the source systems. A classic example is the exchange of patient data between two systems through a project called GP2GP as a part of the UK CFH-Connecting for Health initiative.

The objective of GP2GP record transfer mechanism is to support the exchange of a GP’s (General Practitioner who is the patient primary care service provider in the context of UK) patient record electronically to a new practice when a patient registers with a new GP. In England an estimated 10% of patients change their practice each year and if the average list size of a practice is 1500 then there will be average of 150 transfers each year per practice. Most practices handle this transfer using the standard Lloyd George envelope or Medical Record envelope method for the transfer of the patient’s past care paper record.

The most common process of transfer of the electronic component of the patient record using Lloyd George envelope method is to produce a printout of the content of the medical record and to put it in the Lloyd George MRE at de-registration. Factually few doctors study such printouts and fewer practices re-enter any salient information and this information is unavailable to assist future care. Thus, an effective method which is aimed at the increased use of electronic records by GPs to improve the care of the patients is reducing the data quality of the patient record when passed to other GPs.

Currently England under CFH with history of pilot implementation of GP2GP using HL7 V3.0 by HIRI (Health Informatics Research International Ltd) consortium in 2003 is now trying to provide this transfer electronically using the national infrastructure and methodology developed under the National Programme for IT-CFH. The GP2GP messages, designed form part of the CFH Message Implementation Manual to support an automated request, acknowledgement and send of the electronic component of the record to assist in the continuation quality electronic records when a patient moves practice.

The objectives and benefits of GP2GP as per CFH website (http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) are twofold – benefits the patients and benefits to the practice administration. The benefits of using GP2GP to the patients as perceived under GP2GP are

Ø The patient health record being available to the new GP a lot sooner (e.g. within 24 hours)

Ø The new GP will have knowledge of the patient’s:
o Current medication
o Drug interactions
o Current problems
o Key past medical history
o An improvement in patient safety

Ø Increase patient confidence that they will get good continuing care

Ø Prevent patients being asked information that they have previously reported

The benefits to the practice administrative support teams as perceived under GP2GP are

Ø Reduction in administrative time at the previous GP practice to find and forward on patient records to the new GP practice

Ø Reduction in administrative and clinical time at the new GP practice to review and summarize or re-key the patient record received from the previous GP practice

Ø Reduction in the time taken for the practice to receive the patient record

Ø Reduction in administrative time to chase up patient records from Health Authorities

Exchange Mechanism under CFH GP2GP

The GP2GP process under CFH starts with the registration of a new patient with a GP practice. The GP2GP explicit flows are triggered by the NHAIS Registration links acceptance message flow and the update of the GP registration on a national MPI database called PDS (Personal Demographic Services) which is a part of the national EHR called Spine.

The GP2GP process covers the electronic transfer of the patient record between primary care systems through the MHS (Message Handling Service) of the Spine supplied by the NHS Care Record (NCRS) National Application Service Provider (NASP). There is no interaction with the on-going paper process of transferring Lloyd George envelopes.

The Expected basic functionality provided as part of GP2GP by CFH is as follows

Ø Construct and process EHR Request & Acknowledgement messages
Ø Construct and transfer EHR Extract and integrate into receiving system

Figure below the GP Exchange under CFH GP2GP when a patient shifts from Practice A to Practice B. The exchange is based on intermediary ebXML exchange where the infrastructure of the national EHR called Spine is used as the intermediary MHS.

A1- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A2- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A3- As part of the local registration process, the PDS is queried for the patient’s up to date details e.g. demographics, NHS number and current registration details

A4-The Spine Integration infrastructure will route the query to PDS which will populate a response message with the available patient details. If no record of the patient exists on PDS then a new entry will be created and appropriate PDS update messages sent

A5- The patient demographics and NHS number content of the PDS query response is integrated in the local system.

A6- The GP system will interrogate a national directory called SDS to find out if the practice system with which the patient was previously registered is compliant for GP2GP record transfer messages. The SDS keeps a list of all compliant systems.

A7-If the SDS response is negative e.g. the practice system is unable to send/receive GP2GP record transfer messages then the GP system will alert the user to the fact that no electronic transfer of the existing patient record is available

A8- A positive SDS response will trigger a record transfer request to be sent to Spine to route it to the GP practice system.

A9 - The Spine will route it to the GP practice system with which the patient was previously registered

A10- GP system will receive the request and alert appropriate users to the request.

A11- The EHR Request will be considered by the requested GP Practice

A12- The GP system will send an acknowledgement of receipt of the request to the spine which acts as intermediary to be sent to the requesting GP system.

A13- The Spine will forward the acknowledgement of receipt of the request to the requesting GP system.

A14- The GP system will receive the acknowledgement.

A15- The GP system will alert appropriate users to the receipt of the acknowledgement.

A16- If the request can be fulfilled the GP system will send the patient’s Primary care record as an EHR extract message to the Spine

A17- The Spine will forward the EHR extract to the requesting system by acting as intermediary.

A18- The GP system will receive an EHR extract

A19- The GP system will notify appropriate users to the receipt of EHR extract

A20- The EHR extract will be considered by the requested GP Practice

A21- The EHR extract will be integrated with the appropriate patients record

PS: Iam not sure why they are called EHR messages though but again everyone have their own definitions

EHR and Open Source Software

2009-02-08T21:55:00.004Z

One of the major obstacles in deploying Electronic Health Records (EHR) apart from the usual political and technical reasons is the huge outrageous economic costs associated with the product suites involved in the deployment of EHR. So one option to reduce the costs might be looking at using Open Source software (OSS) to improve the financial viability of the implementations. Gartner has predicted that

· By 2010, 90 percent of Global 2000 organizations will have formal open-source acquisition and management strategies.
· By 2008, OSS solutions will directly compete with closed-source products in all software infrastructure markets.
· By 2010, open source will be included in mission-critical software portfolios within 75 percent of Global 2000 enterprises.
· By 2010, Global 2000 IT organizations will consider open-source products in 80 percent of their infrastructure-focused software investments and 25 percent of business software investments

In this post I will look at the main features of Electronic Health Records and the commercial software available for implementing these features and the open source alternatives for them. At a high level the features of Electronic Health Records are

Patient / Person Registries

One of the important feature required for the successful implementation of a EHR is the establishment of a patient/person registry and the identifies associated with them. This will allow the correct identification of patient’s identification and subsequent association of care records with them. The issues associated with the establishment of such a registry are

• Management of local identifiers and national identifiers
• Migration of data; resolution of duplicates and confusions
• Synchronization mechanism between local and national records

The commercial software for the establishment of registry are
• SUN SeeBeyond eView
• QuadraMed EMPI Solutions
• Initiate Identity Hub™ software
• The MPI software associated with Product Vendors such as IDX, Cerner, Eclipsys, McKesson,

The alternative OSS for the registry are
• Record Locator Service (RLS) – openhre
• Part of Medsphere OpenVista
• Eclipse OHF - Patient Identifier Cross-Referencing (PIX)
• High Available Open Source Database Solution using MySQL for Enterprise Registry Application with advance features.

Exchange of HealthCare data –Application Interoperability

One of the major features of EHR is the ability to feed a central health repository healthcare data associated with key events and at the same time exchange the data with different clinical systems. The issues associated with exchange of clinical data are

• Level and Granularity of clinical data
• Quality of data and existing data
• Choosing the right standards
• Legacy Systems Compliance

The commercial software available for the exchange of clinical data are
• Sun SeeBeyond e*Gate
• Oracle HTB
• ORION Rhapsody
• Microsoft BizTalk
• IBM Websphere

The alternative OSS available for exchange of clinical data are
• Mirth
• Eclipse OHF Bridge
• JBOSS, Hibernate, Web Services,
• Enterprise Service Bus, Messaging

Appointment Bookings

Though Appointment bookings are not itself a part of the EHR the ability to provide options to referrals and allow appointments to be made between different care settings by clinicians and even by patients themselves is emerging as the part of different nation’s healthcare IT infrastructure. The issues associated with appointment bookings are

• Problems with departmental system slots
• Definition of Resources
• Category of appointments –Inpatient/Outpatient

The commercial software available for providing appointment bookings are

• Cerner Enterprise Wide Scheduling
• USA RMS
• Isoft Revive
• Scheduling.com
• Epic Cadence Scheduling

The alternative OSS available for appointment bookings are
• O3-MARIS
• OpenVistA Scheduling

Healthcare Portal

Healthcare Portals are a crucial component in the infrastructure of EHR not only from the perspective of content management of the data that can be made available to clinicians available in the repositories associated with EHR but also access to services like appointment booking which is a part of the EHR. The issues associated with Healthcare portals are

• Security controls for data visible to citizens over Internet
• Clinically safe to use with relevant data made visible

The commercial software available for building of Healthcare Portals are
• McKesson Physician Portal
• ORION Concerto™ Medical Applications Portal

The alternative OSS available for Healthcare Portals are
• iPath - Open Source Telemedicine Platform
• Liferay Portal Enterprise and Professional
• Akaza OpenClinica
• Integrated Portal and Enterprise Content Management system (Alfresco/OpenCMS/
Mambo/cocoon)

Information Governance – Access Control

Another crucial aspect in the management of portals is the management of access and the provision of role based access. The issues associated with access control are

• Definition of RBAC Activities
• Smart Card access for operators and normal for citizens
• Agreed definition of roles

The commercial software available for providing access based control are

• SUN LDAP
• Microsoft Active Directory

The alternative OSS available for access based control are
• Centralized Authentication & Authorization using Open LDAP

Reporting

One of the main outputs of EHR is the ability to generate reports and provide the ability to allow clinical and administrative governance. The issues associated with reporting are

• Lack of transparency of system schemas to reporters
• Lack of LDMs for operational / departmental systems, data warehouses
• Lack of data pedigrees for reported data elements
• Lack of comprehensive data dictionaries for systems

The commercial software available for providing reporting are
• Informatica
• Business Objects

The alternative OSS available for reporting are
• Jasper Suite

The Verbose HL7V3- Part 1

2009-02-03T12:45:00.013Z

In Mid-2006 Gartner in a note on HL7V3 stated that HL7V3.0 messages are quite verbose and applications require considerable effect to understand and process the message. Gartner suggested that HL7V3 messages need a critical midcourse correction and suggested to HL7 Inc to act vigorously to make HL7V3 messages easier to use and more compact.

In the next couple of posts I would look into the reasons and complications behind the verbose nature of HL7V3 and conclude by presenting the solutions on offer to overcome the problems associated with this verbose nature of HL7V3. This post will also help you to some extent to understand how to browse through an R-MIM.

Why are HL7V3 Messages Verbose?

HL7V3 messages are XML messages which are model driven and model driven XML are usually verbose in nature compared to custom written bespoke XML messages designed to convey the same information.

Why do we need Model driven messages?

Currently in the healthcare industry point-to-point messaging is common and non-standardised data exchange is the norm leading to data quality issues, confusions and processing errors sometimes with grave consequences affecting patient care. So it’s absolutely necessary to have a common understanding of the data that is being exchanged to eliminate the misinterpretations. To facilitate this, a level of semantic interoperability is required.

Semantic interoperability can be achieved using a common information exchange reference model so that data is shared and defined unambiguously. XML schema models are derived from this reference model and used to generate run time schemas which cannot be modified directly unless the model itself is modified. As different applications build XML messages sourced from the reference model they end up having the same content and construct facilitating meaningful data exchange. HL7 Inc produced a global semantic model for healthcare called Reference Information Model (RIM) which is the basis for HL7V3 messages [Refer to the HL7V3 Primer post dated January 2008 at

http://healthcareinformatics3000feet.blogspot.com/2008/01/hl7v30-primer.html].

So what’s the issue?

Well, let’s take a sample example and see what exactly the issue is. The following is an extract from XML instance to represent author of a clinical document based on the discharge summary CDA schema taken from CFH-MIM6.3 available on HL7-UK Website

Now let’s look in detail at the representation of the author. The R-MIM representation of the first part is shown below

The author representation starts with the author as participant. It contains the following attributes

1. “typecode” with a fixed value of “AUT” – Indicating this class is that of author

2. “functioncode" to indicate the function of document author from a pre-defined vocabulary. In this case it has a fixed value of “OA” indicating originating author.

3. “contextControlCode” - Specifies how the author contributes to the context of the discharge report and whether it may be propagated to descendent acts whose association allows such propagation.

4. “contentId” - An identifier for a template which constrains the classes and attributes which follow. This is more of a structural navigational aid and not an indicator of semantic meaning. In this case it is the AssignedAuthorSDS template.

5. “time” - The time at which the author authored the clinical document.

The XML representation of the above is shown below

The AuthorChoice leads to template for the author who is in a directory called SDS-Spine Directory of Services. The R-MIM representation of author in SDS is shown below

The AssignedAuthorSDS identifies a person playing the role of author. The role information includes the user identifier and role profile information of the author along with the job role.The AssignedAuthorSDS contains the following attributes.

1.“classCode” - A fixed value of “Assigned” indicating that this role is assigned

2.“id” – it has a cardinality of [1..2] with two identifiers one to identify the user id and one to identify the role profile of the person to whom the role is assigned

3.“code” - A code from a vocabulary which defines the person’s job role and with displayname associated with code

4.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedAuthor template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to person entity which is playing the role of the author. The attributes within the person entity are given below

1. “classCode” - A fixed value of “PSN” indicating that this entity is a person

2. “determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of person
Name – Name of the person

3. “templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the AssignedPerson template.

The XML representation of the above is shown below

The role AssignedAuthorSDS has links to the represented organisation to which the author belongs to. The attributes within the organisation entity are given below.

1. “classCode” - A fixed value of “ORG” indicating that this entity is a organisation

2.“determinerCode” – A fixed value of “INSTANCE” to indicate this is a instance of an organisation

3.“id” – A unique identifier which identifies the organisation nationally

4.“name” – name of the organisation

5.“templateId” - fixed value of this attribute provides a unique identifier for the template and the class name within that template. In this case that of the representedOrganisation template.

The XML representation of the above is shown below

Still not clear on what’s the issue here?

Well a simple XML representation of the author as described above would have probably looked something like this

Hmm…

But is it that not the price you pay for using a model to provide semantic interoperability?

Yes it is but the verbose nature of the HL7V3 problems are creating huge problems as mentioned above regarding the effect to understand and process the message correctly apart from hogging the network bandwidth and destroying one of the unique the advantage of XML messages- “Readability” which is critical for developers and testers.

So what can we do?

There is a huge debate going on if we can take an alternative path to provide semantic interoperability with simpler XML messages. We will discuss those options in our next post.

Acknowledgements and Copyrights

1. HL7-UK / CFH - MIM 6.3 - Copyrights for R-MIM

2. Acknowledgements - Is it Possible to be Simple Without being Stupid?

Exploring the Semantics of Model-driven XML - Ann Wrightson

Healthcare ESB Approach

2009-01-19T10:54:00.003Z

This post defines an approach which can be used for development of Enterprise Service Bus to enable communication using both HL7V2.x and HL7V3.0. The approach is based on Service-Oriented Architecture (SOA) to better align the solution with the business. Enterprise Service Bus (ESB) has emerged as the best proven, fastest and simplest way to implement SOA and offers dramatic productivity and ROI improvements over traditional integration technologies. Figure below a schematic representation of proposed ESB involving applications communicating using both HL7V2.x and HL7V3.0.

ESB Model

SOA simplifies the complexity in integration by the provision of a common infrastructure for service communication, mediation, transformation, and integration. ESB serves as the backbone for an SOA implementation. The ESB will provide the following services

Transport Services: The transport services need to support multiple communication protocols to support both local and national communication. The relevant communication protocols for the current scenario that will be supported are TCP-IP/MLLP, HTTP(S) and JMS.

Message Type: The solution need to support multiple messaging models such as synchronous, asynchronous, publish, subscribe and store and forward. The message types supported with these messaging models are JMS with headers, XML, SOAP and ebXML.

Validation Services: The messages come in different formats varying from string delimited for HL7 v2.x, XML for V3.0 and proprietary formats for existing systems. The validation components will vary from using standard XSD’s to custom XSD’s.

Transformation Services: The transformation service is required to transform currently one version of HL7v2.X to other versions of HL7V2.x and some custom format. The functionality supported by transformation service is
Ø Transforms messages based on the target service
Ø Transforms messages based on XQuery or XSLT
Ø Supports transformations on both XML and string delimited messages

Routing Services: The routing services need toallow routing of messages to existing systems and national applications based on the message content or message headers. The routing services will be based on XQuery-based policies or callouts to external Web services. The routing policies apply to both point-to-point and one-to-many routing scenarios.

Service Management: The service management services need to help handle logging, monitoring and error handling variety of message errors. The logging and monitoring will support logging messages for both systems operations and business auditing purposes, search capabilities, and others. Both business services and ESB services are monitored, as are response times, message counts, and error counts. The error handling components allows configuring of systems to format and send error messages, and return messages for consumers of services who expect a synchronous response.

Common Wrapper: The differences in transport mechanisms used by HL7V2.x and HL7V3.0 will hinder the ESB. The development of a common wrapper with elements of MLLP wrapper and SOAP/ebXML wrapper is crucial for successful deployment of this model.

Null Flavors in HL7V3

2008-10-09T13:50:00.009Z

The concept of null in HL7v3 is very different from HL7V2.x (See my old post on Null values in HL7V2.x. http://healthcareinformatics3000feet.blogspot.com/2007/11/null-values-in-hl7v2x.html). 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=" 2.22.222.2.222222.2.2.2.2.2222" 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:http://hl7-watch.blogspot.com) 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).

Business Case for HL7V3.0

2008-07-24T11:39:00.006Z

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.

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

2008-07-15T08:37:00.014Z

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
http://healthcareinformatics3000feet.blogspot.com/2007/12/hl7v2x-and-low-layer-protocols.html

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.

HL7 V3 Ready

2008-05-07T15:14:00.007Z

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.

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

2008-04-17T17:22:00.002Z

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.

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

2008-04-14T11:59:00.010Z

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.

Semantics: 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.

HL7V2.x - HL7V3.0 Transformation / Translation

2008-03-24T19:35:00.004Z

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

Vocabulary

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

Wrappers

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

HL7V3 and ebXML - Part 3

2008-03-13T12:52:00.006Z

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 http://www.ringholm.de/docs/03030_en.htm. 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.

HL7V2.x Implementation

2008-02-21T18:33:00.008Z

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.

HL7V3 and ebXML - Part 2

2008-02-15T14:49:00.011Z

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="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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.2.4.99.1" extension="12345"/>
</device>
</Receiver>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="67890"/>
</device>
</Sender>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
<----->
< ----->
</author>
<subject typeCode="SUBJ" contextConductionInd="false">
<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">

<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>

</RegistrationRequest>
</subject>
</ControlActEvent>
</PRPA_IN040000UK15>

-------------------------------

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="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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

3. The next set of relevant attributes are given below

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. 1.3.5.7.9.24.68) and adding additional digits in a unique fashion (e.g. 1.3.5.7.9.24.68.1, 1.3.5.7.9.24.68.2, 1.3.5.7.9.24.68.1.1, 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

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.2.4.99.1"/>
<name use="L">
<given>CAREEX</given>
</name>
<agencyFor classCode="AGNT">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="100100" root="2.16.840.1.113883.2.4.99.1"/>

<name use="L">
<given>Uxbridge Hospital</given>
</name>
</representedOrganization>
</agencyFor>
</device>
</receiver>

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.

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">
<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>
</RegistrationRequest>

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

HL7V3 and ebXML - Part 1

2008-02-08T16:23:00.001Z

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

--------------------------------------------------------

<soap-env:Envelope

xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" >
<soap-env:Header>
<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">
<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1 </eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>
<eb:CPAId>ABC22</eb:CPAId>
<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:ConversationId>
<eb:Service>urn:org:names:services:MPI</eb:Service>
<eb:Action>PRPA_IN040000UV15</eb:Action>
<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>
<eb:DuplicateElimination/>
</eb:MessageHeader>
<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH" />
</soap-env:Header>
<soap-env:Body>
<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
<soap-env:Envelope>

----------------------------------------------------

1. The wrapper starts with name space declaration

<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd >

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: “http://schemas.xmlsoap.org/soap/envelope/ “ 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
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd

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.
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd

[HL7-ebXML] extends the ebXML headers within the HL7 ebXML namespace. The namespace declaration for the extensions has a required value of:
xmlns:hl7ebxml=”urn:hl7-org:transport/ebxml/DSTUv1.0”

2. The next is SOAP Header Element

<soap-env:header>

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 (http://schemas.xmlsoap.org/soap/envelope/), 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:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1</eb:PartyId>
</eb:From>

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:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>

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.

<eb:CPAId>ABC22</eb:CPAId>

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

<eb:Service>urn:org:names:services:MPI</eb: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

<eb:Action>PRPA_IN040000UV15</eb:Action>

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

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>

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:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
<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

<eb:DuplicateElimination/>

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 (http://schemas.xmlsoap.org/soap/envelope/), 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="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>

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.

The HL7V3.0 Primer

2008-01-10T16:47:00.000Z

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.

Attributes:

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 Entity.id and Act.id, 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:

DMIM is

Ø 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

http://www.hl7.org

Brazil NHCP

2007-12-30T20:40:00.000Z

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

2007-12-02T22:57:00.001Z

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

2007-12-02T16:47:00.001Z

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

2007-11-30T09:44:00.000Z

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

2007-11-29T10:26:00.000Z

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

2007-11-29T10:23:00.000Z

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

2007-11-28T12:21:00.000Z

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

2007-11-28T12:19:00.000Z

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

2007-08-30T17:35:00.000Z

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

2007-08-29T18:10:00.000Z

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

2007-08-19T21:17:00.001Z

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

2007-05-30T11:44:00.000Z

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

2007-05-29T15:06:00.001Z

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

2007-03-03T23:43:00.000Z

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

2007-03-01T19:38:00.000Z

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

2007-02-26T18:08:00.000Z

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

2007-02-15T17:37:00.001Z

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

2007-02-13T13:31:00.000Z

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

2007-02-07T15:40:00.000Z

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.

Candian Infoway and Myths

2007-02-06T17:58:00.000Z

Ref: http://www.itbusiness.ca/it/client/en/Home/News.asp?id=40138&bSearch=True)

Canadian Infoway which aims to have a nationwide EHR by 2009 has recommended vendors to use version 3.0 in its blueprint. In 2006 The Association of health technologies industry (AITS) and the 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. The paper calls instead for Infoway to endorse HL7v2.5, which the associations say provides greater interoperability.

This is old news but the reason why i felt compelled to blog on this issue is the following presentation which is a more recent one on the infoway site
http://sl.infoway-inforoute.ca/downloads/HL7_CAN_Address_to_CRIM-AITS_October_2006_Final.pdf

Slide- 44
Myth #1• Interoperability on a large scale is possible with HL7 V2

Reality

• There is no common, pan-Canadian V2 standard

• No organization in North America is using V2.5

• The optionality in V2 inhibits (and in many cases, practically prevents)interoperability• V2 messages are designed for point-to-point systems integration, and donot easily support reuse and replication

• We need computable semantic interoperability in order to be successful withour agenda. HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds …. and V2 does not

My Comment :Well i dont understand the concept of pan-canadian understandard. One of the biggest advantage of HL7V2.x is getting different versions of HL7V2.x 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 2.x versions of HL7.

So is it not better to use V2.x and force and constrain systems vendors and organisations on issues of optionality and using standard codesets rather than using V3.0

The next point is a bit contentious where it is said there is no "No organization in North America is using V2.5" by that standards then there are no organisations in N.America which use V3.0. Apart from this Biosurveillance Technical Committee in US which submitted its selected standards Healthcare Information Technology Standards Panel did endorse HL7V2.5 as one of the for use in construction of the Interoperability.

V2 messages are designed for point-to-point systems integration,this is a statement which is highly debatable considering the fact that several organisations which adopted middleware based integartion-EAI or SOA use V2.x.

The statement that "HL7 V3 has the information model, robust data types,terminology bindings and a robust modeling methodology which support ourneeds" is right to some extent but given the problems associated with the stability of RIM and the number of revisions it went through and the known problems of V3 messages with SNOMED-CT dimmens the context and relevance of the statement.

SLIDE-45

Myth #2
• Vendors will not commit to pan-Canadian standards and HL7 V3

Reality

• Not all vendors will or can

• Vendors are responding to the growing market demand being advanced byInfoway ... We need to grow that market demand!– Vendors also complying with standards when these are specified in RFPs, egCeRx for PEI and NL– There are V3 implementations in progress: IBM, Eclipse open source, Emergis,DeltaWare, etc

• Vendor community representatives are committed to pan-Canadianstandards so they only have to implement once and conformance test once• It’s largely not a V2 versus V3 issue. Often the challenge is XML enablementof the application, new functionality, new data requirements, newterminologies, not the V3 message syntax

My Comment:The realities quoted in it does indicate that V3 implementaions are in progress and the end result is not known. The slide also says "XML enablementof the application" is the issue not a v2 versus v3 issue ; well we do have V2.x XML encoding for which ready made adpaters are available from several vendors.

SLIDE-48

Myth #5

• All existing local standards must be replaced with pan-Canadian standards

Reality
• Example 1 – All existing HL7 messages do not need to be replaced with HL7v3 messages– V2 and V3 can co-exist, V3 can be mapped to V2, and V3 compliance can beachieved (with V2 components) with the use of brokers

• Example 2 - PoS systems are not required to update internal HL7 v2.xmessages to use the pan-Canadian standards– Pan-Canadian standards are not focused at the Departmental level but are forinteroperability with the pan-Canadian EHR or jurisdictional repositories

• We are requiring that new HL7 messages to communicate with the HIAL beimplemented in V3, not v2.x.

• Implementation of a pan-Canadian standard is most feasible when a net-newsystem is being installed, or an existing system is being enhanced.

My Comment:Well V2 and V3 co-existing is a reality and its happening as can be seen in the English NHS project where intra organisation integartion is done using V2.x and messages to national EHR is done using V3.0. But the statement that V3 compliance can be acheived with v2 components and use if brokers is really far fetched statement. The mapping or translation of v2-v3 is not defined properly nor any detailed documentation on the mapping is available. It is also a know fact that HL7 v3 is much more detailed than HL7 v2 and the trigger events in V2 and V3 are sufficiently different apart from the bussiness process which triggers those messages.

Iam not saying that HL7V3.0 is better compared to V2,0 but when making a statement to vendors to instill confidence in them atleast make a realistic and fact filled statement not a statement which hangs on a set of incorrect "Realities" .