How timely should data be integrated between EMR and EHR

How timely should the information from EMR integrated with centralized EHR?

There are different types of data that can be integrated between EMR and EHR, such as

1) Patient admission
2) Lab Order/Result
3) Medication prescription/dispense
4) Discharge summary, etc

Should the above information instantaneously integrated with EHR whenever the it is available in EMR? or should it be integrated with EHR only when the patient is discharged  or at the end of patient visit with exchanging of complete summarized information such as CCD?

If the patient is still in one healthcare institution, why is the need to push the data from EMR to EHR? More timely the data is pushed to EHR, there will be possibly more update and correction such as lab result correction. Sometimes due to manual process involved, some of the local update at EMR  may not be propagated all the way to EHR.

If cross-institution diagnosis is required at this stage during in-patient stay, then wouldn't it be more accurate and complete to access the EMR data instead of the subset data held within EHR.

What's your views?

China started to issue citizen health card

China started to issue health card to citizens, starting with these few provinces - He Nan, Inner Mongalia and Guang Dong.


The citizen health card contains the following information

1) Patient Information

• Patient Identification
• Patient Demographic
• Next of Kin

2) Card Identification Information

• Basic Card Data
  
• Issuing Organization

3) Basic Health Data

• Vital Sign
• Immunization
• Medication Allergy

4) Administrative Data

• Patient Visit
• Billing
  

More can be found at the following site

http://henan.qq.com/a/20120302/000003.htm

Australia PCEHR

Every nation wide EHR implementation is challenging, Australia's PCEHE is not alone, as what I quoted at the bottom of this post, there are both technical challenges and political challenges. However what I found good about PCEHR is the transparency and a lot of information is publicly available for discussion and comment. Here I list out few such documents I googled on the internet, which I found useful for sharing.

1. PCEHR Concept of Operations

The purpose of this document is to provide an overview of the Personally Controlled Electronic Health Record (PCEHR) System and how it will work.

Click here to access the document.

2. PCEHR Standards Review Final Selection of Standards

This report outlines the processes used in carrying out the PCEHR Standards Review, considers progress since previous related reviews and presents findings and recommendations for the proposed PCEHR system.

Click here to access the various documents.

3. Health CIO Paul Madden clears air on PCEHR standards debate

SPECIFICATIONS for a key part of the $500 million personally controlled e-health record have been released and a vendor portal launched to support software developers working on products for the system.

Click here for more.


4. Comments on the senate enquiry on the PCEHR

Click here for more.


Latest News w.r.t PCEHR

1) Everything you need to know about Australia PCEHR

Interestingly, advocates and critics both agree on the potential usefulness of electronic health records to improve patient outcomes and increase the potential efficiency of health services – even though evidence is scant that electronic health records, in and of themselves, improve the quality of care

It is very unlikely that the PCEHR will revolutionise health care in Australia any more than its equivalent did in the United Kingdom. From an e-health perspective, this will only come from a single shared electronic health record with clinical protocols and governance that allow health providers to collaborate with a patient in managing their health and wellbeing. But, hopefully, the steps taken in the PCEHR project will accelerate that process in Australia.

2). Labor's Personally Controlled Electronic Health Record system blows out to $760m

SPENDING on Labor's Personally Controlled Electronic Health Record system has blown out to $760 million, almost $300m more than the $466.7m budget.

The National E-Health Transition Authority has swallowed the original allocation almost whole -- it has received $466m in taxpayers' money since the PCEHR was announced by former health minister Nicola Roxon in 2010.

3). E-health records' $1m a day bill

KEVIN Rudd's plan for a popular, patient-centric e-health record system - announced to general head-scratching in early 2010 - has morphed into a lumbering monster that remains frustratingly out of everyone's grasp.

Allocated a mysteriously precise sum of $466.7m over two years in that budget, it now appears the decision was made by the boss in a hurry, without the benefit of proper cabinet consideration as former health minister Nicola Roxon revealed last week.

Abuse of Patient Safety in EHR design

One of the core architecture principles and unique challenge in EHR design is to ensure patient safety to prevent the potential misinterpretation of data stored in the system, as the implication of not doing so is so huge and obvious. To do so, the design needs to look at how user interface is designed, the application information model and the terminologies used to describe the content of each data element within the information model.

However I found often this principle is being abused.

Recently, I took part in design review of one EHR system, it integrates laboratory result from various systems. As following the guiding principles, in order to ensure patient safety and avoid potential misinterpretation, the designer decided that the EHR shall store the lab result as it is.

So for example, in system A, the result is organized in this way



In system B, the result is organized in slightly different way




So in order to save the above lab result of two different data structures, the designer created a more generic data structure as shown below




So far look okay, but the way the source data is being mapped to the common EHR data structure is very weird.

For System A, since it has four levels of data element, it is nicely mapped to the common data structure. But for System B, it has only three levels of data element, the "Lab sub category" element in common data structure is skipped since it is optional.

Take the example of one hematology lab test, the "Hematology" code is stored in "Lab Sub Category" data element for data received from source system A, whereas the same "Hematology" code is stored in "Lab Category" data element for data received from source system B.





During data retrieval e.g retrieve all the hematology lab report, in order to avoid the "if system A then .., If system B then ...", the designer added classification as another dimension to bottom two levels of data element in the common data structure as shown below. So now the query can be simplified as "select all lab panel or lab test item whose classification is 'hematology' ".





So what's your view, did the above design truly follows the guiding principle - store incoming data as it is to ensure patient safety, or it was abusing the guiding principle to make the system more complex. Or what should be the recommended approach for centralized EHR system to amalgamate data with data structure from different source systems.

Building Foundation going beyond EHR

Last Month I attended 3rd Annual Electronic Health Records (EHR) Asia 2011, during pre-conference workshop, I shared my experience in building adaptive enterprise foundation that goes beyond the current EHR capabilities. Below I summarized the key challenges we faced and the approaches of tackling these issues so that EHR scales up progressively to meet ongoing business needs.


1. Plan and design enterprise architecture with business capability centric view to support end-to-end care giving.

The boundary between EMR and summary care record EHR becomes increasingly fuzzy. Traditionally we plan IT systems from care setting perspective, however due to the fact that healthcare delivery is undergoing transformation to support patient centric care giving from primary care, inpatient acute care and the step-down care, there is increasing need for more efficient information flow to support seamless integration of care giving and transfer.

Just like Service Oriented Architecture design, enterprise architecture planning needs to be driven with "SOA style" - Business capability as Service, care setting is the context of the service, care provider/giver and patient are the consumer of the service.

2. Articulate the business benefits and value proposition from the perspective of the entire healthcare ecosystem.

The benefits of EHR is not equally shared by different stakeholders within the healthcare ecosystem, also the time of realizing these business benefits by different stakeholders are not synchronized. For example, in order to provide quality clinical analytic, we need to improve data quality at the point of data entry, however this will incur additional cost of system upgrading and might still increase the workload of data entry giving the current technology limitations and constraints. The additional workload during data entry might lead to time saving at another step of entire care giving process, also improved data quality and thus patient safety as whole.

However those benefits might not be realized immediately, thus at early planning stage, we need to highlight business value with the view from the entire care delivery perspective instead of individual setting perspective, also lays a foundation to allow different stakeholders to realize business benefits as early as possibly to drive up the adoption and at the same time progressively move up the IT capability ladder to enjoy more business benefits.

3. Role of different healthcare interoperability standards/specification

One of the question asked during the workshop is "What standard shall I use? e.g HL7v2, HL7v3, ISO13606, IHE" .

The common mistake in the current healthcare interoperability space is the notion of "all or nothing". To decide what interoperability standards to use, firstly we need to be clear that the above mentioned standards or specifications play different roles in healthcare interoperability, they are not equal, neither exclusive, they are complementary to each other to play its intended role in the entire software development life cycle.

Secondly we should define an architecture framework esp SOA reference architecture to position each respective standard/specification's role in the reference architecture to guide the overall solution design and implementation.

More detail can be found at EHR conference 2011.

How useful is 13606 RM record component id

I was asked why rc_id in ISO13606 is mandatory, below is the summary for sharing.

Note: below few paragraphs are excerpt from ISO13606-1 2008 version spec.

ISO 13606 is not intended to specify the internal architecture or database design of EHR systems or components. Nor is it intended to prescribe the kinds of clinical application that might require or contribute EHR data in particular settings, domains or specialities. For this reason, the information model proposed here is called the EHR Extract, and might be used to define a message, an XML document or schema, or an object interface.

ISO 13606 may offer a practical and useful contribution to the design of EHR systems but will primarily be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems.

Now lets look at this RM (reference model) as shown below RECORD_COMPONENT class which is the top level class for most of the 13606 RM classes - COMPOSITION, SECTION, ENTRY, ITEM and ELEMENT. ELEMENT class is the object that really holds the actual data. (this is important concept, we will refer it later)





"rc_id" attribute inRECORD_COMPONENT class is mandatory, now let's look at the definition of this attribute in ISO13606 spec,

rc_id: The globally-unique identifier by which this node in the EHR hierarchy is referenced in the EHR system to which the data were first committed. This identifier shall be retained by the EHR Recipient and re-used whenever this RECORD_COMPONENT is subsequently included in
another EHR_EXTRACT.

Below was my reply.

First, Is it meaningful or useful that every record in healthcare system has globally unique identifier in data exchange? As we mentioned above, RECORD_COMPONENT is top level class, so if rc_id is mandatory, then every sub class instance will need to supply value for rc_id.

Use a concrete example, lab test lipid panel has the following test item




Since in ISO13606 model, the actual data is holding in ELEMNT class, for the above test result, there are at least 4 ELEMENT object instance and 1 CLUSTER instance for the panel itself.

CLUSTER -- Lipid panel with direct LDL in Serum or Plasma
--> ELEMENT : Cholesterol [Mass/​volume] in Serum or Plasma
--> ELEMENT : Triglyceride [Mass/​volume] in Serum or Plasma
--> ELEMENT : Cholesterol in HDL [Mass/​volume] in Serum or Plasma
--> ELEMENT : Cholesterol in LDL [Mass/​volume] in Serum or Plasma by Direct assay

So for this particular report, the system needs to generate 5 GUID just to be compliant with the Reference Model. But how useful it is for data exchange? Does the receiving system need to know the GUID of each test item in the report? Will there be any value to the receiving system? Not at all.

Second, if the rc_id does not serve any purpose for data exchange, does it serve any purpose within the system? Yes, it is possibly required within the system itself, probably used as primary key to uniquely identify each record in database tables and the relationship. At relational data model level, there definitely needs to be primary key for each table, however this kind of information shall not surface at EHR extract reference model level. The abstract level information model shall not be mixed up the actual data model of the database otherwise each model will not be able to perform its intended function properly . Also it is contradictory to the intended objective of ISO13606 - "ISO 13606 is not intended to specify the internal architecture or database design of EHR systems or components".


So my conclusion is that it is wrong that ISO13606 RM specifies rc_id is mandatory.


However the user was not satisfied, he asked a very interesting question - why not let sending system specify what ever pseudo GUID in rc_id to be compliant with the reference model, and receiving system just ignore the value in rc_id, and then generate its own internally unique guid in rc_id attribute.

That's very very interesting - again back to the fundamental in any model design, if it does not serve any purpose, why you should model it in the first place?