Are EHRs sufficiently “Clinically” Driven?


I was inspired to write this after reading of this great article Engaging Clinicians in Clinical Content: Herding Cats or Piece of Cake? by Heather LESLIE, Sam HEARD, Sebastian GARDE, Ian MCNICOLL

The very first paragraph got me thinking about more questions, see extract below:

“…Many will agree that, to date, the process of EHR development has not been clinician focused…”

The most immediate question – Really? Aren’t clinicians engaged in all of the recent large national programs we see globally? So, what are of our smartest and senior clinicians, clinical informatics folks doing in some of large national programs – is there a leading / best practice when it comes down to clinician : clinical informatician: healthcare IT engineer?

Another related question that has troubled me for a while: How do we measure whether an EHR implementation is reliable and safe?

Callum Bir


Is there hope in making Semantic Interoperability make sense?

“Semantic Interoperability” is one of those term that has bugged me for perhaps the longest; and each year, I gain a new level of appreciation.

A decade ago, I recall giving a talk in Beijing China titled “semantic interoperability” to a large audience who did not speak English. This was one of those dual English/Chinese presentations. The night before the presentation, I was briefing my translator, and also a good friend as he was also an associate professor then at the local university in medicine. The first hardest task, was to adequately translate “semantic interoperability” title in Chinese. This was a really long-night discussing the context, the semantics, the so-what, etc. The next day, the presentation I thought was reasonably well received, at least because there were so many questions (all in Chinese) asked by the audience. As I recall, it took us a few years in China and really tested us on our own understanding, especially when the landscape was so different; everything from problems we were trying to solve (then), were not as well articulated, the lack of business-case, commercial environment, and overall, lacked approaches that worked [in China].

By mid 2000s, having completed a few complex / large implementation projects in Asia, I recall another major time, when I presenting project updates to my colleagues in the US at HQ. During the presentation of the details of one my large and more complex projects ( >$10M), one of my US colleague was steaming, and, resulted in him starting to “scream” at me and my team, because it wasn’t going to achieve “semantic interoperability” goals. Our initial reaction was, the client is really happy, we have signed off on the deliverables, it is meeting the client’s business goals, so, what’s the gap? Was this just a matter of semantics? This meeting ended abruptly, as he went out of the room, and everyone else in the room was left perplexed. It was time to ask “what is semantic interoperability“? I took my Singapore team aside, and asked them, if they knew new what went wrong. At the day progressed, we had spoken to a larger number of people in the same floor, while nobody understood the point. Through the week, further analysis, we learnt about the “levels” of semantic interoperability, and what are some implementation considerations. For the next 5 years after that incident, within the core Singapore colleagues would dare use the word semantic interoperability, and had become a sacred term, and we spent every extra effort in circumventing it.

On the other hand, in the past 5 or so years, I have seen a lot more people who use these 2 words fluently, especially from those where English isn’t their first language. It always sounds so much better when someone else trying to explain what it means, or, to sit in a room full of people who can appreciate the term.

Fortunately, there are now “standard” definitions of semantic interoperability, and also standards on the levels of interoperability, eg, level 0, 1, 2, 3 with intermediate grades.  One the definition I find interesting reading is Conceptual Interoperability (source: wikipedia) , which is level 6,

"...Level 6: Finally, if the conceptual model – i.e. the assumptions and constraints of the meaningful abstraction of reality – are aligned, the highest level of interoperability is reached: Conceptual Interoperability. This requires that conceptual models are documented based on engineering methods enabling their interpretation and evaluation by other engineers. In essence, this requires a “fully specified, but implementation independent model” as requested by Davis and Anderson; this is not simply text describing the conceptual idea." (Source Wikipedia)

Could this be the next key word for the next decade?


Achieving Interoperability – Role of Standards in EHR

During the afternoon session of the pre-conference workshop titled “Going Beyond EHR” during the IBC Asia EHR Asia Conference as the chair, kick started using the following slides:

This was then followed by Case-Studies from Singapore and the US, followed by Panel Discussion.

It was interesting to get a lot of questions from our attendees from Philippines, Dubai, Malaysia and Singapore.

HL7 Standards – Non Healthcare Perspective

One of my colleague from a different division was helping me organize our training room in Singapore for the all-day HL7 certification / training. Out of curiosity, he looked up HL7 on Wikipedia which provided lots of information but still needed some context.

Here’s what HL7 is “sort-of” about vs. what it is, and somewhat to adopted for the local Singapore situation. This by no mean is intended to be an official statement

The general idea of hl7, is simple, to be part of a solution to solve the problem we have in healthcare, ie, how do we as the industry better coordinate care as patient moves around from points of care, second, how do we make delivery of care safe while improving quality and finally, do this while lowering cost. There are whole layers of standards to enable all of the above.

For example, in Singapore, we have the National Electronic Health Record initiative, this is enabled by underlying standard such as HL7.

Tired of hearing HL7 v3 has failed

The last thing I want to do here is to spark another debate around the so-called “failure” of HL7 version 3, instead, I want to provide some points of views to those who have not had exposure to anything beyond HL7 version 2.

So first, as I understand the debate, the blanket criticism around “HL7 version 3”, is largely around the HL7 version 3 messages. Often in the same sentence around HL7 version 3 also seems to suggest the success of CDA, Clinical Document Architecture, more specifically CDA level 3.

For those who have been around the block [HL7] for long enough, it’s pretty easy and straight forward to understand what is meant by this. However,  increasingly, I speak to people are just starting to get themselves acquainted to the realm of HL7 version 3, CDA, RIM, et al, some of the recent debates has created a confusion I am hoping to shed some light.

Perhaps one of the things to highlight is that HL7 version 3 isn’t just messaging as you have in the world of HL7 version 3.  It might be worth looking into some of the Foundation and Infrastructure components of HL7 version 3 that includes things like the Reference Information Model (RIM).

I also recently found it interesting that some of the newbies around CDA didn’t realize that CDA and v3 are related:

“CDA is based on the RIM (..), uses the V3 datatypes and methodology. The core of the CDA R2 body for machine processing (semantic interoperability) is the “clinical statement” model which is used across V3.” (Source: HL7)

“XML tags on their own do not have the precision required for clinical system interoperability. For example, does <provider> mean a person or an organization? Is it the person who created the document, signed it or performed some service? The XML tags in a CDA document are defined by the HL7 Reference Information Model (RIM) which is based on a variant of Unified Modeling Language (UML) and has been developed by literally hundreds of thousands of hours of collaborative work by practitioners, informaticists, vendors and implementers over the past decade. Each release of CDA is based on the version of the RIM current at the time of the ballot. The CDA specification details the relationship of the documents to the model and contains a refined model (RMIM) which takes RIM classes and further constrains them to define the precise parameters of a clinical document.” (Source: HL7)

With that background, the key question I ask, how is to do you actually work with CDA that’s meaningful for use for specific intentions?  Surprisingly, I see some of the newbies haven’t had the opportunity to understand the overall background to design by constraint or the overall Health Level 7 Development Framework (HDF).

Take CCD for example, which uses the framework and methodology of HL7 with CDA as the baseline to constrain for specific use, which is further constrained by ONC for the US.  “The Continuity of Care Document (CCD®) is a CDA® implementation of the continuity of care record (CCR), created by the American Society for Testing and Materials (ASTM). Disparate information systems can employ the CCD to exchange clinical summaries that contain key data about individual patients, such as diagnoses, medications, and allergies.” (Source: HL7)

Given the inter-relationship and dependencies, such claims perhaps need to more specific in nature to avoid confusion.

Callum Bir

ISO 21090 Harmonized Data Types

It was nice to see we still had a fair bit of group left to hear my technical presentation on ISO 21090 Harmonized Data Types at the HL7 Singapore AGM which was moved to the last on the agenda from being the first on the agenda as originally published.

One of the reasons I wanted to cover the ISO 21090 data types is that it also happens be pretty much the same as the HL7 RIM release 2, although most of my hands-on experience is with RIM release 1. The idea behind covering ISO 21090 is because this is pretty much aligned to Singapore LIM (SLIM) which is largely based on ISO 13606-1 which uses the ISO 21090 data-types.

Finally, I wanted to thank those who picked out errors in XML example. This was originally created based on working implementation example based on HL7 RIM R1 and then later I was pointed out the subtle change in XML which I had changed in Power Point directly without going through the review cycle. Good to see a handful number of people were paying attention.

Callum Bir

HL7 v3 Demystified in Singlish

As many of you know, I love being based in Singapore, and one of my best inventions of Singapore is Singlish.

As many of you know, I’ve been involved with various aspects of HL7 version 3 for nearly a decade of scars and bruises, I was hoping to share some perspectives, views, and personal experiences during the Technical Presentation 23 June 2011 at Singtel Auditorium.

Please ping me for the slides  “HL7 v3 Demystified in Singlish” in case you aren’t able to grab it from the HL7 Singapore site.

Callum Bir