DOYLC

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 si...

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

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 featur...

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 commo...

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 commun...

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 optio...

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 Pat...