standards

Archetypes/DCMs MIA in SDOs

Curious to note that there is very little apparent interest in detailed clinical information models (DCMs) of any brand or flavour in the major Standards Development Organisations (SDO's) - they are effectively Missing In Action when compared to the likes of CDA and IHE profiles. The ISO 13972 DCM specification took a long and tortuous time to travel through the ISO TC 215 processes. Engagement with 13972 during its development, and from what I can observe now it is on the verge of publication has been rather sparse.  A further piece of work is now starting in ISO regarding quality criteria for DCMs but it also seems to be struggling to find an audience that understands it, or even cares.

I don't quite understand why the concept of DCMs has not been a big ticket item on the radar of the SDOs for a long time as it is a major missing piece of any standards-based framework. Groups like CIMI are raising awareness, alongside the openEHR work, so momentum is gathering, but for some reason it seems to keep a very understated profile compared to new opportunities like FHIR in HL7.

The work of messages, documents, profiles and terminologies are clearly important for interoperability, but standardisation of clinical content models working closely with terminologies can potentially make the work required to develop messages, documents, and profiles orders of magnitude easier.

Let me test a metaphor on you. Think of each message, document or profile as a sentence and each archetype or DCM as a word, a building block that is one component of each sentence. By focussing on the building a specific sentence, we are working backwards by trying to determine the components, and the outcome is still just that single sentence. However if we start by standardising the words/archetypes, then once they are stable it is relatively simple to construct not only one sentence for a specific purpose, but the potential is a much greater output in which many more additional sentences can be created using a variety of words in different combinations. If we manage the words (archetypes) as core building blocks and get them right, then we allow a multitude of possible sentences (messages/documents/profiles) to proliferate.

The ‘brand’ of archetype/DCM solution does not concern me so much as raising awareness that clinician-led, standardised clinical content is a significant missing and overlooked piece of the international eHealth foundations puzzle.

Technical/Wire...Human/Content

In a comment on one of my most recent posts, Lloyd McKenzie, one of the main authors of the new HL7 FHIR standard made a comment which I think is important in the discourse about whether openEHR archetypes could be utilised within FHIR resources. To ensure it does not remain buried in the rather lengthy comments, I've posted my reply here, with my emphasis added.

Hi Lloyd,

This is where we fundamentally differ: You said: "And we don’t care if the data being shared reflects best practice, worst practice or anything in between."

I do. I care a lot.

High quality EHR data content is a key component of interoperability that has NEVER been solved. It is predominantly a human issue, not a technical one - success will only be achieved with heaps of human interaction and collaboration. With the openEHR methodology we are making some inroads into solving it. But even if archetypes are not the final solution, the models that are publicly available are freely available for others to leverage towards 'the ultimate solution'.

Conversely, I don't particularly care what wire format is used to exchange the data. FHIR is the latest of a number of health data exchange mechanisms that have been developed. Hopefully it will be one that is easier to use, more widely implemented and will contribute significantly to improve health data exchange. But ultimately data exchange is a largely technical issue, needs a technical solution and is relatively easy to solve by comparison.

I'm not trying to solve the same problem you are. I have different focus. But I do think that FHIR (and including HL7 more broadly) working together with the openEHR approach to clinical modelling/EHRs could be a pretty powerful combo, if we choose to.

Heather

We need both - quality EHR content AND an excellent technical exchange format. And EHR platforms, CDRs, registries etc. With common clinical archetypes defining the patterns in all of these uses, data can potentially start to flow... and not be blocked and potentially degraded by the current need for transforms, mappings, etc.

Oil & water: research & standards

The world of clinical modelling is exciting, relatively new and most definitely evolving. I have been modelling archetypes for over 8 years, yet each archetype presents a new challenge and often the need to apply my previous experience and clinical knowledge in order to tease out the best way to represent the clinical data. I am still learning from each archetype. And we are still definitely in the very early phases of understanding the requirements for appropriate governance and quality assurance. If I had been able to discern and document the 'recipe', then I would be the author of a best-selling 'archetype cookbook' by now. Unfortunately it is just not that easy. This is not a mature area of knowledge. I think clinical knowledge modellers are predominantly still researchers.

In around 2009 a new work item around Detailed Clinical Models was proposed within ISO. I was nominated as an expert. I tried to contribute. Originally it was targeting publication as an International Standard but this was reduced to an International Specification in mid-development, following ballot feedback from national member bodies. This work has had a somewhat tortuous gestation, but only last week the DCM specification has finally been approved for publication - likely to be available in early 2014. Unfortunately I don't think that it represents a common, much less consensus, view that represents the broad clinical modelling environment. I am neither pleased nor proud of the result.

From my point of view, development of an International Specification (much less the original International Standard) has been a very large step too far, way too fast. It will not be reviewed or revised for a number of years and so, on publication next year, the content will be locked down for a relatively long period of time, whilst the knowledge domain continues to grown and evolve.

Don't misunderstand me - I'm not knocking the standards development process. Where there are well established processes and a chance of consensus amongst parties being achieved we have a great starting point for a standard, and the potential for ongoing engagement and refinement into the future. But...

A standards organisation is NOT the place to conduct research. It is like oil and water - they should be clearly separated. A standards development organisation is a place to consolidate and formalise well established knowledge and/or processes.

Personally, I think it would have been much more valuable first step to investigate and publish a simple ISO Technical Report on the current clinical modelling environment. Who is modelling? What is their approach? What can we learn from each approach that can be shared with others?

Way back in 2011 I started to pull together a list of those we knew to be working in this area, then shared it via Google Docs. I see that others have continued to contribute to this public document. I'm not proposing it as a comparable output, but I would love to see this further developed so the clinical modelling community might enhance and facilitate collaboration and discussion, publish research findings, and propose (and test) approaches for best practice.

The time for formal specifications and standards in the clinical knowledge domain will come.  But that time will be when the modelling community have established a mature domain, and have enough experience to determine what 'best practice' means in our clinical knowledge environment.

Watch out for the publication of prEN/ISO/DTS 13972-2, Health informatics - Detailed clinical models, characteristics and processes. It will be interesting to observe how it is taken up and used by the modelling community. Perhaps I will be proven wrong.

With thanks to Thomas Beale (@wolands_cat) for the original insight into why I found the 13972 process so frustrating - that we are indeed still conducting research!

DCMs – clarifying the confusion

Detailed clinical models are certainly a buzz term in the health IT community in recent years, commonly abbreviated to DCMs. Many people are talking about them but unfortunately, often they are referring to different things. The level of confusion is at least as large as the hype.I sincerely hope that this post helps to lift the veil of confusion just a little...

Is an incremental approach to EHRs enough?

Attending the International Council meetings on the first day of the recent Sydney HL7 meeting, the resounding theme was that of many countries focussed on messages, documents and terminology as the solution for our health IT future; our EHRs; health interoperability. 19 countries presented and 18 repeated this theme. The nineteenth HL7 affiliate, Netherlands, stood out in splendid isolation by declaring an additional focus on the development of clinical content.

Incremental EHRs?

This common message/document/terminology approach to EHRs is largely for historical reasons - safe, solid and incremental innovation; building on what has been proven successful before. It is not unique to health IT. It is not unique to HL7 either - it was just very obvious on the day.

In fact you can see this same phenomena in many places in everyday life - the classic example being the manufacturing of disposable shavers. First a one blade razor, then two blades, then three... But how long can this go on for? Is seven blades a reasonable thing? Eight? Will infinitely more blades make a difference to the shaving outcome or experience? When will blade makes stop and rethink their approach to innovation?

Certainly messages, documents and terminology are approaches that have commenced as often relatively isolated islands of work, had some successes, progressed and are now gradually being drawn together to create opportunities for some interoperability of health information. And don't get me wrong, there are absolutely some successes occurring. However, three questions linger in my mind about this approach:

  1. Is it enough?
  2. Is it sustainable?
  3. Will it achieve interoperable systems?

We all hear the rhetoric that if we can interconnect financial systems, then we can do it for health. We've tried this incremental approach for over 30 years and made significant progress but we definitely haven't cracked it yet.

Messages

Paul Roemer used this diagram (right) to illustrate his view of the messaging exchanges in his blog post. I think the image is powerful, imparting both the complexity and chaos that an n-to-n messaging dependency will likely entail. The HIE approach might help, but ultimately a national approach to messaging will result in multiple images like this trying to connect to each other.

This is further complicated by messages often taking up to a year to negotiate between the sender and receiver, or potentially longer to successfully negotiate the national or international standards processes, and even then the resulting 'standard' is often being subjected to individual tweaks and updates at implementation in real-world systems where the 'one-size fits all' message doesn't meet the end-user's requirements.

In Australia the 'standard' pathology HL7 v2.x message is anything but standard with each clinical system vendor having to support multiple slightly different versions of the 'standard'. The big question is whether this is sustainable into the future.

In the US, the clinical content payload for the Direct project is yet to be determined and defined - "The project focuses on the technical standards and services necessary to securely transport content from point A to point B, and does not specify the actual content exchanged." This rings alarm bells for me.

I've been told that at one relatively large hospital system in the US, they require 30 permanent staff just to maintain their messages...! Whoa!!!

Messages and message networks try to be a simple incremental solution to interoperability. But are they really that simple? Are they sustainable? Locally, yes. Regionally, yes probably. Nationally? Internationally???

<My head hurts>

Documents

CDA documents featured highly on the HL7 agenda, with the current emphasis on simple documents, and increasingly we will welcome the inclusion of structured clinical content detail. Currently the content is HL7 v3 templates, but how will that content be standardised and support semantic interoperability?

Werner Ceusters describes semantic interoperability as:

Two information systems are semantically interoperable if and only if each can carry out the tasks for which it was designed using data and information taken from the other as seamlessly as using its own data and information.

Without working towards standardising clinical content we run the risk of our EHRs being little more than a filing cabinet full of unstructured documents that are human readable but not computer processable.

Terminology

We all need terminology, no matter which approach. That is an absolute given.

However the stand-out question that impacts all approaches is how to best 'harness' the terminology...

Interestingly the openEHR Board and the IHTSDO Management Board (SNOMED CT) have been talking about joining forces. An announcement on the openEHR site, in December 2010, states:

"At its October meeting in Toronto, the General Assembly of the IHTSDO received and discussed a proposal, submitted by its Management Board, to support, develop and maintain the IP in openEHR, within a broader framework of IHTSDO governance for clinical content of the electronic health record.

The openEHR Foundation Board has now heard from the IHTSDO Management Board, saying that, whilst the objective of the proposal was considered by the GA to be within the scope of the organisation and that it represented a pressing issue for their governments, it was unable to reach consensus that going forward with openEHR in this way is the right choice, at this time."

This suggests that the IHTSDO Management Board identified significant value in combining the structure of openEHR archetypes with SNOMED, enough to propose a stronger relationship. It will be interesting to see if these discussions continue to progress.

My view - this would be a game-changer. A common approach to using archetypes and SNOMED together is a potentially very powerful semantic combination.

An orthogonal approach - knowledge-driven EHRs

By contrast, the orthogonal approach taken by ISO 13606 & openEHR starts with computable, standardised clinical data definitions at the core - representing the clinical content within an electronic health record. The data definitions, comprising archetypes  plus terminology, are the key. Messages and documents are derived from these content specifications and will therefore be internally consistent with the EHR data from which they were generated and if received into an archetype-enabled system can be incorporated, as described by Werner's definition above, as though generated in the receiving system ie semantic interoperability - no data transformation required.  The openEHR communities of clinicians, informaticians and engineers are collaborating to agree and standardise these archetypes as a common starting point.

Working from standard content definitions will potentially make the development of documents and messages orders of magnitude simpler. If archetypes have been agreed and published via the CKM collaborative process, then engineers will be able to utilise these as building blocks for the creation of messages and documents for specific use cases, and for a multitude of other technical outputs.

The way forward?

Returning to the multi-blade EHR idea...

When will we stop, regroup and assess the merit of continuing as we are? Who will draw a line in the sand?

Difficult to answer.

Maybe never, maybe no-one.

openEHR/ISO 13606 may not be the right or final answer, but it does provide an alternative and orthogonal approach that has merit and is worth consideration.

Hopefully some of outcomes/proposed discussions from the recent HL7 meeting in Sydney will also contribute to clarifying a way forward.

Perhaps, even yet, we will devise a truly innovative approach to solving the difficulties of developing EHRs.

Adventures of a clinician in HL7!

I've just survived my first HL7 meeting, although amused colleagues tell me that I may not fully recover! ‘Clinician newbie’ to HL7 though I was, for my sins I am becoming increasingly drawn into work within other standards organisations, and my clinical work is no longer with patients but in working with clinicians to develop clinical content models for use in electronic health records. I have some experience of the world of health informatics.

Held relatively nearby in Sydney, it was too good a chance to miss attending an Australian HL7 meeting, and it was an ‘interesting’ experience. The meeting was certainly very casual with a plethora of geeky T-shirts and pony-tails – definitely not the norm at the ISO meetings I’m more familiar with. Some defied this stereotype and still wore their business suits, despite jet-lag and it being a weekend – there are definitely certain individuals that I’ve met over the years who I can only believe must paint the fence in a suit... I particularly remember a certain medical registrar that I worked with many years ago, who always turned up to a resuscitation in Emergency in the middle of the night with a tie perfectly knotted – go figure! But I digress...

I’m told that as the meeting was held outside the US, there was a different flavour of attendee – certainly many from Australia and New Zealand took the opportunity to attend for the first time. I gather many ‘regulars’ didn’t attend and so many of the clinically-related working groups did not meet at all, which was rather disappointing. I spent time in the Patient Care working group and attended the Clinical Interoperability Council. Unfortunately I’m still rather clueless about the remit of the CIC... for clarification in the future perhaps, but clinician-driven approaches to EHR development is a critical way forward, in my opinion.

There was certainly an emphasis on education at this meeting, and it appeared to be very successful with many first-time attendees getting involved, including myself. I attended the Introductory and Advanced tutorials on CDA.

Some highlights:

  • Without a doubt the absolute highlight was non-work related - the evening ‘networking reception’ held during a sunset cruise on Sydney Harbour (see the photo above). Rather spectacularly, the organising committee somehow arranged for some rather large yachts to breathtakingly race around us just before sunset. Brilliant!
  • Sharing a beer, or three, with Keith Boone. I was chuffed when he blogged that he was coming to meet me! And I’m pleased to report that I seemed to have some impact on him after showing some of our collaborative work happening on the openEHR CKM.
  • A refreshing open-mindedness towards our work in openEHR. I particularly like the symmetry – I attended Bob Dolin’s Advanced CDA tutorial, and Bob attended our openEHR sessions! We do have potential to learn from each other.

The outcomes:

I've definitely been encouraged by some of the HL7 meeting outcomes with respect to openEHR. There was definitely a different attitude towards exploring openEHR/HL7 collaboration:

  • A DCM feasiblity demonstration project has been proposed - with input from the Patient Care, Models & Methodology and Templates groups.
    • Start with archetypes as the base
    • Establish adornments that map these to the V3 Ontology (Structured Vocabulary and RIM)
    • Create tools that then consume these to produce useful HL7-V3 artifacts (templates, or such)
  • An afternoon was spent discussing openEHR & RIMBAA - focussing on the commonalities between openEHR and HL7 RIMBAA implementation issues
  • The opportunity to provide tutorials on openEHR within a formal HL7 meeting – the previous attitudes have been more confrontational than collaborative! Which approach will prevail? Rather than how can we learn from each other! The introductory session in the morning was focused on background and clinical knowledge management. The afternoon had a range of speakers with expertise in application of openEHR/ISO 13606 in the HL7 environment

For the future:

  • I'd love to have a chance to engage with the Clinical Interoperability Council - to explore how we can collaborate across technical approaches so that at least as clinicians we can ensure that the clinical content in our desktop EHRs is consistently represented, high quality and 'fit for purpose'. The DCM feasibility project outcome will heavily influence if and when this could productively occur.
  • As clinicians we have to ensure our access and input to these technical processes, otherwise we won't end up with systems that support us to provide care to our patients. And I challenge the standards bodies to 'demystify' the technical - to remove the technical barriers that prevent grassroots clinician input and restrict participation to those very few who can bridge the world of software engineering with clinical practice.

Other posts from the meeting:

  • Rene Spronk: Ringholm - HL7 and openEHR are cooperating (finally)
  • Keith Boone (@motorcycle_guy):
    • Triplets
      • @motocycle_guy: @omowizard An archetype, a DCM and a template walk into an #HL7WGM event, stroll up to the bar ... and the bartender says...
      • @omowizard: @motorcycle_guy ...identical triplets I presume! #HL7WGM
    • Convergence - regarding templates, detailed clinical models and archetypes

Don’t re-invent the (clinical content) wheel...

It was with great interest that I read about the the recommendation for a universal exchange language in the recent release of the US report to the President: REALIZING THE FULL POTENTIAL OF HEALTH INFORMATION TECHNOLOGY TO IMPROVE HEALTHCARE FOR AMERICANS: THE PATH FORWARD. I had asked the Direct project about the existence of a national plan for standardising clinical content only recently... It appeared that here was a plan after all.

So, to the report. The approach and benefits proposed started well...

The best way to achieve a national health IT ecosystem is to ensure that all electronic health systems can exchange data in a universal exchange language. The systems themselves could be designed in any manner desired — they could accommodate legacy systems that prevail or new recordkeeping systems and formats. The only requirement would be that the systems be able to send and receive data in the universal exchange language. (p41)

I have previously blogged about a universal health record underpinned by an application independent library of clinical content definitions, so the intent and benefits are well aligned with my preferred approach.

But then alarm bells started to ring....

Because of its multiple advantages, we advocate a universal exchange mechanism for health IT that is based on tagged data elements in an extensible markup language. If there were another equally good solution, it should also be considered; we have collectively been unable to think of one. (p43)

Issue #1: Isn't it more appropriate for step one to identify the need for standardised clinical content as a policy, rather than specify the format up front? Isn't that really the domain of health informatics experts as part of a subsequent work plan? I feel like we've skipped a couple of steps in the decision-making process. And are they really advocating the creation of this metadata-tagged XML from a zero starting point?

Issue #2: The last 9 words of that paragraph, "...we have collectively been unable to think of one." I'm glad that they are still open to equally good solutions being considered as indeed there are many ways that individuals, groups and organisations are exploring how to standardise clinical content definitions as the basis for a universal exchange mechanism.

In ISO TC 215, the International Standards Organisations Technical Committee for Health Informatics, there is a new work item which has been evolving for at least 2 years, although yet to attain committee draft status, known as ISO 13972 - Quality criteria for detailed clinical models. This work item is targeting a new international standard for determining quality criteria about the development of detailed clinical models - all clinical models, pick your flavour! In the world of international standards it has been recognised for years that with the plethora of different approaches to developing clinical models for EHRs, there is a need for some criteria to support quality aspect in their development. This work is being led by modellers from the Netherlands, with experts participating from the Australian, Danish, German, Swedish, US and Canadian standards organisations. Creating clinical content is definitely not a new field of endeavour by the time it enters the international standards arena.

So, I am extremely surprised that this expert PCAST group have not been able to 'collectively think' of an existing alternative.

In my last blog - Clinical Knowledge Governance in a Web 2.0 world – I pointed to a number of approaches to standardised clinical content to support health information exchange.

1. In the US – including, but by no means limited to:

  • the HL7 standards organisation - where my UK colleague, Charlie McKay, informs me that there are more than 20 different approaches to clinical content development. Keith Boone (@motorcycle_guy) has posted his response to the PCAST report from a HL7 point of view - The Language of HealthIT;
  • Stan Huff's group at Intermountain Health in Utah have had extensive experience in defining standardised clinical content across all of Intermountain's systems – they are leading experts in this domain; and
  • I understand Don Mon and his team from AHIMA have also been working in this area.

2. In Europe, and Australia:

In addition, a few more points...

Firstly, the focus of the PCAST report is still only on data exchange, not on ensuring a sound foundation of a person-centric electronic health record. I'll say it again... get the data right and then the data will be able to be re-used, to multitask, be liquid, flowing to where it needs to be. It will become the solid foundation on which to build lifelong health records, simpler health information exchange, data integration & aggregation, research, reporting and knowledge-based activities. By focusing on exchange alone, then... you'll hopefully be able to exchange well and the rest will be considerably more uncertain.

Secondly, the proposed variant of XML is described as a 'straightforward' and 'superior' solution (p44), and the assumption that it will be scalable, protected by encryption, and that data element access services will be enough to support the health information exchange required. By contrast HL7, ISO/CEN 13606 and openEHR have taken decades to develop and refine underlying reference models to ensure that they have an unambiguous, consistent, secure way to represent personal health information – so you know who created the data, who is the subject of care, what the data means, what are the access rules applicable etc. In the openEHR environment, the specification authors developed Archetype Definition Language (ADL) for the purpose - and now part of the ISO 13606 standard - because the alternatives such as standard XML were not robust enough to represent health information. A 'straightforward' XML approach has a strong possibility of failure without a RM underpinning it.

And finally, there is the area of clinical knowledge governance itself. Health is dynamic, complex and diverse. The work required to represent healthcare as computable clinical content definitions or specifications is huge – don't underestimate the sheer volume of work that will be required. It is not realistic to expect a 'rapid mapping' of existing proprietary data structures into tagged data elements. Who will decide the clinical content in the models? If there are over 7000 clinical vendors in the US, which will be 'the source' or sources? Which are 'correct' or 'authoritative'? What methodology will be used to create the models? What level of granularity for each clinical element? How will they be aggregated together to represent clinical documents or events, and constrained to be useful for the clinical purpose? I have a million more questions...

Once the information models are defined, there will be a need for them to be validated before they can become the basis for a standardised or national clinical content library – suitable for consumers, clinicians, organisations, vendors, researchers and jurisdictions. A requirement will be recognised for life-cycle management and publication of these models, roadmaps for legacy data to migrate towards, and harmonise with, the new national health information 'source of truth', plus ongoing maintenance and governance.

Eric Browne stated in his recent blog, Recasting e-Health in the USA:

The work in Sweden, the UK, Singapore and even Australia, based on openEHR or ISO 13606 archetypes (i.e. implementable renditions of Detailed Clinical Models) is far more advanced and promising than that offered by the PCAST approach.

openEHR, which is my interest, has an approach to defining, agreeing and governing clinical content models for electronic health records, known as archetypes. It has taken more than 18 years to develop the openEHR technical specifications, and the last 10 years to achieve its' current approach and position in terms of clinical modelling. It is gaining traction, albeit with a modest volunteer community, especially now that it has a collaborative portal, known as the Clinical Knowledge Manager, to support sharing or models, reviews of clinical content, translation and terminology binding, and model governance.

Standardising health information definitions for health records or exchange is not a trivial task. Learn from what has already been achieved – all shapes, flavours and doctrines. Whatever you do, don't reinvent the wheel and create yet another universal language!

Clinical Knowledge Governance in a Web2.0 world

Establishing and maintaining the quality of clinical knowledge is clearly the domain of the expert clinicians themselves. This is a broadly accepted principle for management and governance of the traditional clinical knowledge artefacts. However this assumption needs re-evaluation when we need to establish quality, safety and ‘fitness for purpose’ of computable clinical knowledge artefacts that populate Electronic Health Record (EHR) systems. Clinical knowledge has traditionally been created and shared through formal publication and peer-review processes that have been adjudicated by committees of clinical experts. Those expert committees have been appointed through a credentialing process and have had jurisdiction and oversight over the entire publishable content – ‘the buck stops here’. Before the rise of the internet, face-to-face meetings have been where most of the committee work has been done, and the process has most often been slow and expensive but delivered good quality publications. The opportunity cost to each participating clinician has been high with recurring interruptions to their clinical activities. Revision of those publications at a later date repeats this process, taking considerable time, money and resources.

Certainly in recent times, there have been more electronic tools to support these processes – email, teleconferences and videoconferences have improved the logistics of the process, but essentially the process remains unchanged.

Given the increasing traction of electronic health records, there is a parallel movement to develop and share computable clinical content definitions that can be created, published and implemented by: multiple clinical disciplines; generalists and specialists; primary, secondary and tertiary care organisations; population health planning; clinical researchers; and knowledge-enabled systems such as clinical decision support applications. They need to be language independent and translatable, in order to transport health information across national boundaries.

These kind of computable clinical models need the input from many experts, clinicians and others, to ensure that they are not only clinically appropriate but support safe data usage in our EHRs. These models are increasingly being created with ambitious goals – to create once and then re-use many times. In this case, the scope of the models needs to include requirements of the full breadth of clinical professions and specialties. Clinicians remain key to their development and publication, but they also require input from:

  • Other domain experts – non-clinicians who will want or need to use these same models for non-clinical purposes such as secondary data use;
  • Informaticians – who understand how these models will be the basis for recording health information, exchange between systems, reporting, data aggregation and how knowledge-based activities.
  • Terminologists – to ensure that the models will integrate with appropriate terminology value sets;
  • Technicians – who will advise on the technical impacts of these models in systems; and
  • Translators – who will ensure that the clinical information is faithfully transformed from one language to another.

Examples of these computable clinical content models are many and varied. There are open source and proprietary models of many different flavours and philosophies – archetypes, templates, detailed clinical models etc. In recent years there are increasing attempts to broaden the input to the creation of these models and even to start to standardise them – regionally, nationally and even internationally. In this new paradigm, the traditional approaches to clinical content development, management and governance are no longer sufficient.

When the full breadth, depth, and dynamic nature of clinical knowledge is considered, it is not feasible to be able to appoint an overarching committee or board who would be capable of providing final ‘sign off’ about the clinical ‘correctness’ for any one model. Each clinical knowledge model will require input from varying groups of expert clinicians, terminologists, informaticians and technicians, depending on the clinical knowledge artefact under review. We need to find innovative approaches to online and asynchronous collaboration of a wide range of individuals from diverse backgrounds, expertise and geographical location to ensure these models are suitable for use in clinical systems.

Traditional standards bodies, such as ISO, CEN or HL7 have well defined and fixed processes in place for managing the lifecycle of technical standards through a formal balloting process with registered member bodies. These are definitely not suitable for managing and governing an evolving and dynamic clinical content specification library.

There has been some early work on establishing abstract archetype quality criteria by QREC and more recently, ISO TC 215 Working Group 1 has established a new work item 13972, which is establishing “Quality criteria for detailed clinical models”.  However, neither of these are able to establish the quality of archetype instances for real world use.

I believe that HL7 is working to establish a Template Repository. As I understand it, it will operate as an indexing service to templates that will be stored on distributed servers. Others may be able to provide more details.

Other work is no doubt occurring, of which I am not aware. And of course, each clinical system has to establish the clinical content that it will use in its own proprietary information model. In the US alone, with thousands of clinical software vendors, this means that we have thousands of different computable versions of essentially identical clinical content, but none of it interchangeable without mappings or transformation – what a huge waste of resources! We need to change this blinkered way of thinking.

The openEHR Clinical Knowledge Manager (CKM) is the only online clinical knowledge resource, to my knowledge, which is supporting collaboration by clinicians, other domain experts, informaticians, technicians and translators to achieve consensus about quality and safety in clinical content models – in this instance, openEHR archetypes.  I am directly involved in the development of this tool, and am active as an Editor facilitating the review process of the archetypes – I have described it in previous blog posts.

While CKM is one of the early Web2.0 approaches to collaborating about clinical content models, I am sure there will be more over time. I have spoken to a number of Knowledge Management experts, and to my surprise no-one has yet been able to point me to similar tools, resources establishing quality within a Web2.0 environment. Are we really such pioneers? Surely there are similar approaches in other knowledge domains?

No matter. There is no doubt that we are only in the early stages of a transformation in clinical knowledge governance and we have a lot to learn about how to establish quality criteria in a Web2.0 environment. I’ll post some thoughts in my next post...

Why Is The Shared EHR So Hard?

'Provision of the right data to the right provider at the right time' is the mantra we commonly hear in eHealth. It sounds deceptively simple! Some promise it; some hope for it; but pretty much no-one has it. The collective desire for a seamless and efficient shared electronic health record (EHR) which actually provides that data to the provider at a particular time is widespread and yet the EHR remains elusive. If we know what we want, why is the shared EHR so hard to achieve? Why is it taking so long? And what's more, if the financial sector can do it, why not health?

The progress that we have made in the past 10-20 years of eHealth development has been glacially slow compared to other industries and domains. The approach to health IT, and in particular the shared EHR, has been primarily linear in nature with modest incremental successes achieved. Sure, progress has definitely been made, but despite investing enormous amounts of money and resources, the solution has been more difficult than most ever anticipated. Healthcare doesn't appear to fit the same data interoperability model that has been successful in other domains such as banking or financial services. In a world where connectivity reigns and personal data can flow freely, it is not yet the norm for our health information to be connected nor to flow!

In trying to understand the problem more fully, there are 3 broad headings we need to explore:

  1. Technical
  2. Human interaction and activities
  3. Information exchange

Let's explore some of these issues:

1. Technical

There is little doubt that traditional EHR development has been driven by technology requirements and engineering processes, so many of the typical aspects we consider when thinking of the EHR are actually quite manageable, if not solved - consider storage and retrieval of data, security, role-based access, audit trails, repository storage etc. It is not the technology holding us back here. Some even suggest that the technical aspects of the standalone EHR are the (relatively) easy part, and they may well be right!

With over 7000 EHR vendors in the United States alone, we have proof that building a standalone EHR is undoubtedly achievable. Our EHRs that are in use are traditionally rugged individuals, each created in splendid isolation with the finest data structure, processes and user interfaces! Unfortunately, building proprietary silos of health information is the almost universal approach to EHR development adopted by vendors and does not make it easy for health data to be shared.

I have seen and heard some say that we already have all the standards that we need for eHealth. This is still somewhat controversial and perhaps depends on what part of eHealth that you are trying to make work. For a coordinated eHealth system the desire is for each standards to not only achieve its purpose and goal, but to harmonize with all the others in existence to create a unified whole. Can this vision be achieved? There are certainly some examples of very successful standards.  There are also some examples of tweaking of standards for local use... which makes them non-standard again. There are also some examples of standards that have never yet been implemented... what? Let me refer you to the blog post from my colleague - The Crisis in eHealth Standards, by software engineer, Thomas Beale - for an erudite discourse on the strengths and weakness of standards and the standards processes.

2. Human interaction and activities

There is no doubt that some EHR technological achievements have been delayed or even diverted by the human, political and regulatory issues arising from practical implementation - and in most instances, rightly so.  We can develop a technological solution, the 'what', but in many jurisdictions the 'how' still has everyone tied up in knots.  For example we have technical solutions for unique patient identifiers, data security, and role-based access to data - but 'how' to apply these in practice is more elusive, often crossing into moral and ethical arguments (including confidentiality and privacy), requiring broad social and political agreement and sometimes supportive legislation. These issues have received a disproportionate amount of attention, particularly in the media, and perhaps at the expense of issues that follow which are not so well understood, yet!

Healthcare is not primarily a technical business - it is about people. Yet in our rush towards EHR development we seem to have focused on the EHR being a technical solution rather than merely a tool or medium to support the practical application of health knowledge and provision of healthcare to real people.  Some of the most underestimated and misunderstood problems in EHR development are related to:

  • the scope and dynamic nature of our health knowledge domain;
  • the nature of the human-human interaction that underpins quality health care;
  • the approach to capturing and storing the essence of a clinical encounter; and
  • the changing clinical requirements, processes and approaches to healthcare provision.

None of these are trivial concepts.  They are in the metaphorical 'EHR too hard basket', but we need to address them...

Health is possibly (more likely, probably) the most complex knowledge domain.  The extent and scope of health-related knowledge that needs to be represented in an EHR is enormous - it has huge breadth and depth, plus a fine web of complex relationships.  Most commonly underestimated is that health knowledge is dynamic - requirements distilled from a clinician and built into an EHR application by a software engineer today can be out-of-date by the time the product is launched.

An encounter between a clinician and a patient is a very complex pas de deux, an intricate communication dance between two parties.  Interestingly we clinicians have developed surprisingly effective written methods to capture the information exchange from these encounters, with all the required subtleties and nuances. Capturing the essence of this encounter into a format that can be stored, re-used, queried and shared on a computer is a daunting task and more complex than first appears. Attempting to represent both the data and our clinical processes via the user interface on a computer screen is definitely also an advanced task.

The nature of healthcare provision is also in flux. Consumers/patients/clients/citizens/individuals are increasingly mobile, more now than ever before, demanding healthcare from a range of providers in varying geographical locations.  Gone is the old-fashioned notion of the local family physician providing all our needs for all generations of the family; the local physicians are morphing into our health coordinators and facilitators in a world of collaborative and distributed models of care. Our ability to diagnose, treat and prevent conditions are moving with the assistance of new technological advances - in particular, watch out for the potential tsunami-like impact of personalized medicine/genomics on healthcare in the next few years.

3. Information exchange

There are many differing approaches to sharing health information. Why? The plain answer is that it is hard and there is no clear way forward; there are also many differing requirements and starting points:

  • Logically, the technical task of sharing health information would be easier if the data was in a common format. Conversely sharing seems to become more difficult by orders of magnitude if our collective data structure is in chaos.
  • Practically, some require only the simple exchange of a readable document such as a PDF or semi-structured documents. At the opposite end of the scale, there is need for EHR systems to share detailed and structured health information, so that not only can clinicians and patients read it but the meaning of each piece of data is clearly understood and it can be directly integrated into the computer and utilized in clinical decision-making - this is known as semantic interoperability.

In many places, national eHealth programs and the myriad of 'ruggedly individual' EHR vendors are pursuing technical approaches to data exchange through the set-up of information exchange hubs, message mapping and data transformations.  In this instance the focus is on exchange of complete or semi-structured documents as readable health information. Europe and some other parts of the world are taking a different approach, focusing on the exchange of standardized, atomic data  and reflected in the European decision to adopt ISO/EN 13606 as its standard for EHR extract exchange.

Exchange of unstructured health-related documents as 'blobs' of data is a great starting point, but in the long term it is a dead end. In reality it is not a sound basis for a shared EHR, nor interoperability, as we can only read them and then store them passively within the EHR. Personally, I want a dynamic, lifelong EHR for myself and my patients - one that can actively create, receive, integrate and re-use my atomic health information and put it to work for me to improve my current health and to provide the basis for future health decisions.

'Provision of the right data to the right provider at the right time' - can this actually be achieved? Clearly the relatively safe, comfortable and incremental technical innovation that has underpinned our EHR development to date hasn't provided the shared EHR solution we hoped for. So at this point let us draw from the wisdom of Einstein: “We can't solve problems by using the same kind of thinking we used when we created them." Indeed, perhaps it is time for a different approach to the shared EHR; one in which we divert our focus and are encouraged to push boundaries; to seek transformational change in our approach to eHealth.

In future posts, I hope to explore some of these issues in more depth and, in turn, some opportunities that arise...

Acknowledgments: Dr Sam Heard and Dr Hugh Leslie