ICP's and EHR

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

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

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

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

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

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

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.