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:

• The Australian National eHealth Transition Authority (NEHTA) has just launched a national clinician-led CKM approach to grassroots clinical content standardisation creating NEHTA's Detailed Clinical Models (DCMs).
• The Swedish national eHealth program has been actively working to integrate openEHR archetypes with its' VTIM architecture.

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

The Swedish vs US approaches: health information, not just communication

National approaches to eHealth program development have been varied, and unfortunately we can all probably identify more failed attempts than successes. Just recently we have seen a spectacular regrouping within the UK NHS in the face of cost blow-outs and underperformance - a stellar example of how a project commonly described as the biggest computing exercise in the world, outside the military, has hit the proverbial brick wall. My question is not so much "What is the 'right' approach?" but more importantly "What is a sustainable approach, so that our valuable health information will persist at least as long as we do, and hopefully as long as our children need it?" Brian Ahier (@ahier) triggered some thoughts when he sent me a link to the new O'Reilly Radar article, Healthcare communication gets an upgrade which he co-authored with Rich Elmore and David C. Kibbe. It is an informative and succinct post that explains the US Direct Project (formerly NHIN Direct) in words that actually make sense to this non-technical clinician! No doubt it is good infrastructural work that will be very valuable.

However, given my day-to-day work with archetypes and standardising clinical content in Europe and Australia, the 'elephant-in-the-room' for me in this article is what is the clinical content that is to be exchanged? I assume we are talking about structured clinical documents as CDA, and similar. And that is great for short- to medium-term gains but, in the longer timeframe, as we want to share more data, and more complex data, and then we also expect to be able to compute upon that data rather than just read it... what then? How do we make sure that the data is safe and exchangeable between disparate systems? What is the long-term plan? Is a structured document enough? I think absolutely not.

So "What is the plan", I asked today of the authors and the Direct Project. I watch with interest for a response. Is there a strategy for content standardisation?

My understanding of the current situation with content development in the US?

• Stan Huff's team has done fantastic work at Intermountain Health - a very sophisticated approach, but only used within their group;
• UK's Charlie McKay tells me that there are currently at least 20 different approaches to clinical content development within HL7 alone that he can identify - a rather unfortunate situation for a standards body;
• Think of all the clinical application developers in the US alone - more than 7000 vendors I'm told. Even if it is only hundreds, imagine the resources poured into developing the same clinical content in different ways for each separate application's proprietary information model, each reinventing the wheel and only interoperable by accident - what a waste of resources;
• and then a plethora of others, including Tolven etc.

I have not been able to identify a cohesive approach to defining clinical content such that it is safe to be directly exchanged between clinical systems - am I wrong?

By contrast, only last week there was a series of emails on the openEHR Clinical discussion email list. It was offering a number of links to Sweden's recent very public meeting where they invited experts from throughout Europe to share the Swedish national eHealth program and plans, and to receive feedback from their EU colleagues. Taking a totally orthogonal approach, the Swedish priority is identifying clinical/business processes and getting data right.

Tony Shannon, Chair of the openEHR Clinical Review Board, triggered the discussion with this blog post - Sweden's noble eHealth strategy. Further emails elucidated links to all of the Swedish presentations from the Lund meeting, held on November 2, 2010, which I have included below.

However it was Sam Heard's email in that thread which summed up my concerns about the aforesaid 'elephant' and ensuring that health information is recorded consistently and safely. I particularly like the way he has described the problem, and his suggested solution. With his permission I post it here (with my emphasis)...

I was not able to get to Lund unfortunately - but it is clear there is some good work going on. In Inger Wejerfelt's introduction it was good to see the statement:

"Swedish national decision: Standards with focus on the information and not the communication only."

This is a critical shift and one that needs more attention. I cannot help but think we are stuck in a world where everyone thinks that health records can be whatever anyone dreams up and then they will interoperate. It is like the first few years of word processors and we are agreeing on what words are and paragraph breaks. We still have our own character representation and we are agreeing on sending paragraphs to each other to share. It is hard work.

Companies have made a lot of progress, Vista is open source and has a lot in it and GE's collaboration with Intermountain has the benefit of Stan Huff's insight. But health records are too important to do in a closed way or tied to a particular technology. Peter Fleming, head of NEHTA, has said "The Best of Breed is not an option" meaning we are not looking for good software that everyone can use. That is why I work in the openEHR community; so we can get on with this together and create a record that actually delivers what health care needs while allowing maximum diversity in applications.

A risk we might fall into is trying to do everything at once - this is not possible as 'everything' grows quickly from the previous everything. At this stage in developments the range of new possibilities transforms every year or less. So we need to decide on the first piece and implement it widely. For me that has always been the health record - concentrating on what has to be recorded. It will not do everything that is required but it will keep a record of it. Then we can then get smarter and do more.

The openEHR ACTION class embodies this divide between the model of care (workflow) and a model of recording. The care pathway steps are not actually the steps but rather the things that a clinician might record in following an instruction (or just doing it). People I am working with want to consider the workflow and transitions but the fact is that these all happen in the real world and do not get recorded consistently. When something _is_ recorded it is essential that we capture the state of the (possibly virtual) order. This means we have an idea of what is outstanding, ongoing etc.

We need more Swedens, more countries willing to think about the health record as possibly the most valuable resource. We need more people working on the shared logical specifications based on shared implementations.

...

Cheers, Sam

In Europe CEN 13606, now ISO 13606, has been mandated as the standard for EHR extract. A significant part of this standard is about the standardised definition of clinical content using archetypes. openEHR can be thought of as a superset of the 13606 standard, focused on the whole EHR, not just the extract.

In particular:
• the —UK, Singapore, Danish and Australian national eHealth programs are gaining momentum in determining EHR clinical content definitions.
• the international openEHR community is gaining traction - clinicians defining clinical content through archetypes, and using the openEHR Clinical Knowledge Manager as a library and for life cycle management/peer review of archetypes, templates and terminology reference sets. Archetypes have been translated from English to Japanese, Chinese, Russian, Farsi, Dutch, German, Portuguese & Slovenian. They are also being created in other languages & translated into English. We are sharing clinical content models across international borders!;
• applications based on shared archetypes are being built & implemented in Netherlands, UK, Australia, Brazil, Slovenia & the US;
• professional clinical colleges are starting to drive archetype development in Australia & US to ensure that the EHRs they use are safe & 'fit for purpose'; and
• Sweden's national approach is focused clearly on identification of the clinical business processes and defining clinical content through openEHR archetypes.

The Swedish approach is well documented and publicly available. The following presentations were given by key figures within the Swedish eHealth program at the international meeting held recently in Lund on November 3, 2010 (courtesy of Rikard Lövström):

1. V-Tim - Inger Wejerfelt, Chief Health Informatics Officer, CeHis A presentation about V-TIM – the applied information model that is a framework for the “content and context” described for a clinical perspective and a result of national and regional projects.
2. What are we trying to achieve? - Nils Schönström, MD PhD, Senior Advisor CeHis
3. The Swedish eHealth approach - Dr Karl-Henrik Lundell
4. The Swedish eHealth approach- Dr Håkan Nordgren, Head of National e-Health architecture board CeHis, MD .
5. openEHR in Sweden and beyond - Thomas Beale.
6. SNOMED CT - concept model attributes, archetype integration and terminology binding made by Jessica Rosenälv
7. The reference archetypes - Helene Broberg
8. Interdisciplinary Terminology for Health Care and Social Care in Sweden - Bengt Kron.
9. Business driven archetype development - Jessica Rosenälv

The US approach gets lots of airplay because of the sheer volume of eHealth in the US in every dimension. However, in my humble view, it has significant limitations when it is so strongly focussed on the messaging and communication, at the expense of the health information itself. In a few years when the messaging paradigm is no longer sustainable, what then?

Addressing the issue of standardising EHR content will make exchange of health information simpler by orders of magnitude - drawing data directly from the EHR itself and being incorporated directly into the receiving EHR itself at the other end, ready to be computed upon without any interpretation. This is a foundation requirement for safe exchange of shared health information record, for data aggregation, for secondary use of data and for knowledge-based activities such as Clinical Decision Support.

Messaging hubs alone will not sustain the EHR revolution! Consider the other approaches that are also proving successful, especially that of the Scandinavians who are widely regarded as being the world leaders in this eHealth environment - they haven't got it perfect yet, but it is worth watching them very, very closely...

Records, the universe and everything

Here is a surprising gem that I found this morning - "Records, the universe and everything" is part of a presentation entitled "Where is THE medical record?" given by David Markwell to the Primary Health Care Specialist Group of the British Computer Society back in September 1996.  Enjoy...

Carrie Byte sifted through the envelopes on her desk. She had already searched the practice computer without finding anything of interest. Her face was a picture of tired resignation. She was about to see Arthur Dent. She had never met him before, but her senior partner had once told her something about him. She could not remember what it was, but she did recall it was unusual. Without the record she would be at a serious disadvantage.

She lifted the phone and dialled.

"Hello, George. Mr Dent's record doesn't seem to be here."

George apologised and said he would look for it. As Carrie hung up the phone, there was a knock at the door and, almost immediately, in walked a nondescript man.

"Hello, I'm Arthur. I expect that you are Dr Byte."

Carrie agreed that she was, asked what she could do for him, and apologised that his record was missing. He smiled and said that he had been away for a few years.

"Your record is probably with the FHSA", she suggested.

"Perhaps the Vogons mislaid it when they destroyed the planet", he countered.

"What do you mean?" she asked.

"I admit the FHSA is more likely, but never dismiss the improbable."

"Good advice for a doctor - but tell me what I can do for you today", Carrie said, trying to regain control.

The smell of coffee percolated through the door and she wanted to get this consultation finished. After another knock at the door George entered, carrying three thick Lloyd George envelopes.

"I found it, Doctor."

Arthur noticed that Carrie looked more downcast by the size of the records than she had been by their absence.

"Bit of a trilogy, isn't it, Doctor?" he quipped.

She smiled and he continued "Don't panic! I only want to know the results of my last hospital visit. Your partner, Morris Oxford, referred me for an opinion."

Ten minutes later she had waded through letters, printouts from other practice computers and reams of notes and established that the hospital letter was missing. It took ten more minutes for George to find it in Dr Oxford's in-tray.

As Author left the room he turned and said "Just one more thing, Doctor." Her heart dropped.

"I have a friend who has really good ideas about piles of paper. He'd help you find the right information more easily and have time for a coffee break."

"Oh yes", she replied sceptically.

"Yes", he said emphatically. "You must meet him. One o'clock in the Frog and Sparrow, and bring a towel."

He spoke with such authority that she felt obliged to join Arthur and his friend at the appointed time. Arthur introduced Mr Prefect who frowned as he greeted her and said "No towel. You've forgotten the towel. Oh well, I suppose it doesn't matter."

He took from his pocket a small box with the words "Don't panic!" written on it. "This", he said, "is what Arthur was telling you about."

By the end of lunch break she was convinced. A week later her practice had installed the Instant Transfer Computerised Heath Hyper Record. At the heart of this system, known as the ITCH-Hyper Record, was the concept of the improbably distributed record. Few people understood it, but that didn't seem to matter. It promised an end to 'missing record' misery and it really worked. Within three months, every practice, every hospital and every community unit in the country had installed the ITCH-Hyper Record. Clinical information entered anywhere was seamlessly shared by everyone, subject to necessary and appropriate security constraints. The age of information sharing had arrived, dreams of patients outshining paper became reality, the wood was seen, the trees were spared and crocks of gold appeared under every rainbow.

Six months later Carrie started to worry. She was looking at a record which showed a high blood sugar result two days previously. She switched screens to check the advice on her decision support system. She returned to the record and the blood sugar was normal. The first time it happened she assumed she had misread the screen. The next day it happened to another patient's record, and then another. She queried it with the lab. They said there had been some errors in a batch of tests but insisted they were corrected immediately. Then why, she wondered, had she seen the erroneous results nearly a week later? Soon the medical press were full of stories of similar incidents. Ford Prefect explained by saying "The old record is cached and not refreshed until it is re-accessed. It's just a glitch: we'll fix it."

The next problems Carrie noticed were intermittent gaps in records. These were accompanied by ubiquitous "Don't panic!" messages accompanied by icons depicting sporting events. Enquiries to the support desk were met with the patronising response and brief explanation that the tennis racket meant a 'service fault', the rugby ball a 'line out' and the golf club 'open links'. These errors became more common and it was inevitable that before long the system acquired the less flattering nickname "The Glitch".

Just over a year after Carrie's meeting in the Frog and Sparrow, she was the defendant in the first court case in which two incompatible versions of a patient's ITCH-Hyper Record were presented as evidence. Both carried all the marks of authentication as the genuine record for the same patient. The judge asked for explanations. Ford and Arthur attempted to explain about caches, probability, post-dating, modification, repudiation and the importance of towels for galactic hitchhikers. The judge was unimpressed and asked a simple question: "Where is THE medical record for this patient?"

Ford asked for clarification and the judge obliged. "Where are the original records of the clinical information recorded by each of the health care professionals involved in the care of this patient?"

Ford regarded the judge as a child who wanted to open a television to look for the people inside. He made a contemptuous remark and was silenced.

Arthur came to the rescue. "It's like this, I think. It's sort of everywhere. Well, everywhere in the cyberspace defined by thirty thousand clinical systems in the UK. That is, it could be anywhere, but nobody knows where, and of course, nobody really needs to." The judge was silent for half a minute. During those thirty seconds several dolphins spontaneously appeared, unnoticed, in the courtroom. Then the judge spoke very slowly and deliberately: "I need to know and I need to know now. Otherwise, how can I determine which of these pieces of so-called evidence is genuine?" He paused, waiting for a response. As the silence continued, Ford and Arthur vanished, having hitched a lift on a passing Dolphinian space trawler. The silence resumed. The dolphins smiled and vanished, still unnoticed.

Then the judge summed up. "It is claimed that the medical record is everywhere. That it is distributed across what has been called cyberspace. Yet, since we find that in two places it differs, from a legal perspective there are at least two versions. Neither of these can be located and nor can they be separated or distinguished from one another, except by the factual differences in the statements they contain. It follows that I am unable to determine the legal status of either. Therefore, for the purposes of this court, I rule that this patient's medical record is located nowhere. Since something that is nowhere does not exist, I further rule that it is inadmissible in this court. This being the case, can anyone present any evidence that will help this court to reach a judgment?" There was another pause while the judge and others noticed the absence of the expert witnesses. He smiled and added: "I presume that Messrs. Ford and Dent are now distributed in a manner similar to their records. Is there a shred of evidence to assist us with this case?"

Carrie passed forward a page torn from her diary on which she had made a few rough scribbles. Her counsel rose. "If it please your honour, I have here a piece of paper written on by Dr Byte at the time. It appears to corroborate her account." The judge, having studied the paper, passed it to the plaintiff's legal team and asked if they offered any further evidence. After a hasty conversation with their client, they indicated that no more evidence would be offered and the case was dropped.

The profession was not always the beneficiary of this legal precedent. Patients who made their own rough notes immediately after consultations won otherwise absurd cases against doctors unable to cite admissible medical records. Within a few weeks most GPs were reopening their filing cabinets, brushing the dust off their pens and relearning elaborate hieroglyphics. The ancient art of doctors' writing was reborn. Years later, when Carrie retired, she cleared out her desk and found a perfect glass replica of a 3.5" computer disk. She didn't know where it came from, but it reminded her of the heady days of her youth when she really believed paperless practice had arrived.

Interesting to see a summary of the conference agenda and links from the proceedings still online and active.

Clinician-led eHealth records - a knowledge-enabled approach

My presentation given to W.H.O. in Geneva last week... [slideshare id=5492832&doc=20101008whoclinician-ledehealthrecords-101019133425-phpapp02]

An orthogonal question...

Just askin'. Just curious... What single eHealth activity, process or solution now available could:

• Ensure that EHR data is safe and ‘fit for clinical purpose’;
• Support data integration, data aggregation & comparative analysis;
• Simplify and support messaging and data exchange;
• Enable co-ordinated knowledge-based activities; and
• Provide a clear transition path for existing EHR applications towards common data representations.

...now there's a list that covers a broad range of eHealth, including may of our current, collective headaches, doesn't it!

The main thrust of the question is one that doesn't get asked very often, as it is  orthogonal to our more common application- and messaging-driven approaches.  It focuses on the most important part of any eHealth activities, yet it remains largely ignored - the quality and re-use of health information. Liquid data. Shareable data.

My opinion is that we need a clinical knowledge repository of common and agreed data definitions - that much should be clear from my other posts.

What other alternatives do you think can provide a solution in this knowledge space? How will we fill these needs?

What is the vision for an Open Health platform?

Came across a tweet this morning from Tim O'Reilly (@timoreilly) linking to an article by Mark Drapeau (@cheekygeeky) entitled 'What is the Vision for Open Government Entrepreneurship'. The first paragraph in particular caught my eye:

Tim O’Reilly often explains Open Government, or Government 2.0, as “Government as a Platform” on which citizens build things for each other and participate in their government (rather than treating it like a vending machine).  The co-founder of Personal Democracy Forum and techPresident Andrew Rasiej has a similar notion that he terms WeGovernment.

And then following the link to Tim O'Reilly's 2009 article, “Government as a Platform”:

...But as with Web 2.0, the real secret of success in Government 2.0 is thinking about government as a platform. If there’s one thing we learn from the technology industry, it’s that every big winner has been a platform company: someone whose success has enabled others, who’ve built on their work and multiplied its impact. Microsoft put “a PC on every desk and in every home,” the internet connected those PCs, Google enabled a generation of ad-supported startups, Apple turned the phone market upside down by letting developers loose to invent applications no phone company would ever have thought of. In each case, the platform provider raised the bar, and created opportunities for others to exploit.

There are signs that government is starting to adopt this kind of platform thinking.

It got me wondering... When will the eHealth community start thinking in these terms?

• Open Government; Open Health.
• Government as a platform; Health as a platform.
• A cohesive platform approach rather than fragmented proprietary silos.
• Opportunities and innovations as spin-offs.

I wrote in a previous post about the concept of a universal health record based on an open, standardised architecture as the basis for a cohesive and sustainable approach to recording and exchanging health information, health data aggregation, support for knowledge-based activities such as clinical decision support and comparative data analysis. I also posted, rather naively perhaps, about the openEHR platform in which I work, as an open source health equivalent of the iPod/IPhone platform.

I’m sure most won’t accept a Microsoft-, Google- or Apple-equivalent as the platform and will push for an open option. And whatever you do, don't confuse open source software applications with the concept of an open source platform. An open platform can enable all software developers to play, no matter what their philosophy - 'what is under the hood' is open source and standardised - and that is a key differentiator.

But you get the idea, I think - the underlying notion of an Open Health platform is sound. Other knowledge domains are embracing the concept and way ahead in terms of innovation in this space.

When will the health domain  start to engage in the same open-minded and innovative manner? Only then can we start to think in terms of Open Health Entrepreneurship as mentioned in @cheekygeeky's article.

Time for a revolution, me thinks!

Archetypes: the ‘glide path’ to knowledge-enabled interoperability

In a world where connectivity is the universal aspiration, our health information is largely still caught up in silos and, in the main, is not accessible to those who need it – patients, clinicians, researchers, epidemiologists and planners. Shared electronic health records (EHRs) are increasingly needed to support the improvement of health outcomes by providing a timely, comprehensive and coordinated foundation for provision of healthcare. For decades people have been attempting to share health information, but the incremental approach has not been wholly successful – progress has been made, but despite enormous investment and resources, the solution has been found to be more difficult than most anticipated; many well-funded attempts have been stunningly unsuccessful. Healthcare provision appears not to fit the model that has been so successful in other domains such as banking or financial services. Why has sharing health information been so difficult? After all, on the surface, data are, simply, data.

Why is the health information domain different?

Health information is the most multifaceted and largest knowledge domains to try to represent in a computer. The SNOMED CT terminology alone has over 450,000 terms expressing health-related concepts, and our collective knowledge about health is far broader, deeper and richer than that required to represent financial systems. The added bonus in health is that our information domain is dynamic - growing and changing as our understanding increases.

Recording, communicating and making sense of health information is something that clinicians do remarkably well in a localised, non-digital world. However the human cognitive processes and assumptions that underpin the traditional health records do not easily translate into the computerised environment. Consider the need for narrative versus structured data; the complexity of clinical statements; use of the same data in a variety of clinical contexts; the need for clinicians to make ‘normal’ or ‘nil significant’ statements, and also the oft underrated positive statements of absence; and the need for graphs, images or multimedia in a good health record. Grassroots clinicians have different personal preferences for creating their clinical records and to support their requirements for direct provision of clinical care and communication to colleagues. In parallel, jurisdictions have different expectations of the grassroots clinical data collection that will support reporting, data aggregation and secondary use of data.

Throw into this mix the complex and convoluted processes required to support healthcare provision; mobile patient populations; and the need for lifelong health records, and it starts to become easier to understand why eHealth has been more of a challenge that many first thought.

Information-driven EHRs

Traditional approaches to the development of EHRs have been software application-driven, hard-coding clinical knowledge into the proprietary data model for each software system and resulting in silos of health information locked away in proprietary databases. This is valuable data, and even more valuable if we can get access to it, exchange it and utilise it. Key stakeholders – patients, clinicians, researchers, planners and jurisdictions – are currently disempowered and are not easily able influence or express their data requirements. We have mistaken the software application for the electronic health record - a classic example of the ‘tail wagging the dog’.

If we focus on the electronic health record being the data, we turn the traditional paradigm upside down. Our EHRs become information-driven by putting the stakeholders at the centre to direct the information content and quality aspects of our EHR systems. It is only then that our systems will be able to reflect the real requirements of stakeholders, ensuring that health information collected data is ‘fit for use’ and will support personal health records, clinician health records and, with appropriate authorisation and permissions, the broadest range of secondary use.

Sharing health information requires common and coherent health information definitions or models – ensuring that health information can be expressed in a way that is meaningful to stakeholders AND that computers can process it. According to Walker et al , Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data. In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation. This semantic, or knowledge-level, interoperability is absolutely required for truly shareable health records, data aggregation, knowledge-based activities such as clinical decision support, and to support comparative analysis of health data. Further, it is only when this health information model is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels. The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange.

The openEHR paradigm

openEHR is a purpose-built, open source, information-driven electronic health record architecture focused on ensuring that the grassroots health information is recorded clearly, coherently and unambiguously in EHRs, and supporting re-use in other contexts where appropriate. It adopts an orthogonal approach to EHRs - a dual-level modelling methodology with clear separation of the technical from the clinical domains, where software engineers focus on their application development and the clinical domain experts focus on the health information definitions. openEHR focuses on the data - using computable knowledge artefacts known as archetypes and templates to formally express health information.

openEHR archetypes are computable definitions created by the clinical domain experts for each single discrete clinical concept – a maximal (rather than minimum) data-set designed for all use-cases and all stakeholders. For example, one archetype can describe all data, methods and situations required to capture a blood sugar measurement from a glucometer at home, during a clinical consultation, or when having a glucose tolerance test or challenge at the laboratory. Other archetypes enable us to record the details about a diagnosis or to order a medication. Each archetype is built to a ‘design once, re-use over and over again’ principle and, most important, the archetype outputs are structured and fully computable representations of the health information. They can be linked to clinical terminologies such as SNOMED-CT, allowing clinicians to document the health information unambiguously to support direct patient care. The maximal data-set notion underpinning archetypes ensures that data conforming to an archetype can be re-used in all related use-cases – from direct provision of clinical care through to a range of secondary uses.

Templates are used in openEHR to aggregate all the archetypes that are required for a particular clinical scenario – for example a consultation or a report. These can also be shared, preventing more ‘wheel re-invention’. Individual content elements of each maximal archetype can be ‘disabled’ in the template so that the only data elements presented to the clinician are those that conform to national or local requirements and are relevant and appropriate for that use-case scenario. For example, a typical Discharge Summary may commonly comprise 10 common archetypes; templates allow the orthopaedic surgeon to express a slightly different ‘flavour’ of the Discharge Summary based on which elements of each archetype being either active or disabled, compared to that required by a Obstetrician who needs to share information about both mother and newborn. One ‘size’, or document, does not fit all. The archetypes, as building blocks, are the key to semantic interoperability; while templates allow flexible expression of the archetypes to fulfill use-case requirements.

How achievable is this? Only ten archetypes are needed to share core clinical information that could save a life in an emergency or provide the majority of content for a discharge summary or a referral. If each archetype takes an average of six review rounds to reach clinician consensus and each review round is open for 2 weeks, it is possible to obtain consensus within an average of three months per archetype – some complex or abstract ones may be longer; other simpler, more concrete archetypes will be shorter. Many archetypes are already well developed in the international arena and within national programs. As archetype reviews can be run in parallel, a willing community of clinicians could achieve consensus for core clinical EHR content within three to six months.

It is estimated that as few as fifty archetypes will comprise the core clinical content for a primary care EHR, and maybe only up to two thousand archetypes for a hospital EHR system including many clinical specialties. The initial core clinical content will be common to all clinical disciplines and can be re-used by other specialist colleges and interested groups. More specialised archetypes will gradually and progressively be added to enhance the core archetype pool over time.

The openEHR Clinical Knowledge Manager (CKM) is an online clinical knowledge management tool – www.openEHR.org/knowledge - which provides a repository for archetypes and other clinical knowledge artefacts, such as terminology subsets and document templates. Based on a data asset management platform it provides a clinical knowledge ecosystem supporting the publication lifecycle and governance of the archetypes. Within CKM, a community of grassroots clinicians and health informaticians collaborate in online reviews of each archetype until consensus is reached and the agreed archetype content is published. Clinicians and other domain experts need no technical knowledge to engage with archetypes - the technical aspects of archetypes are kept hidden ‘under the bonnet’ – but they use their expertise to ensure that the content definitions within each archetype is correct and appropriate. Each content review is conducted online at a time of convenience to the clinician and usually only takes five to ten minutes for each participant. Thus the clinical domain experts themselves drive the archetype content definitions, and CKM has become a peer-reviewed knowledge resource for all parties seeking shared, standardised and computable health information models.

At the time of writing CKM has acquired, largely by word of mouth, 565 registered users from 62 countries, including 181 people who have volunteered to review archetypes, and 73 who have volunteered to translate archetypes. The repository contains 273 archetypes, of which 15 have content that are in team review and 9 published. Two example templates have been uploaded, and we await final publication of the openEHR template specification before we expect to see template activity increase. Terminology subset functionality has been added only recently and our first terminology subsets uploaded. So, while CKM is still relatively new, its Web2.0 approach to artifact collaboration and publishing, combined with formal knowledge artifact governance positions CKM as a pioneering ‘one stop shop’ for clinical knowledge resources online.

Current CKM functionality includes:

• Display of artefacts including structured views, technical representations and mind maps to make it easy for clinicians and others to review;
• Uploading of new knowledge artefacts – archetypes, templates and terminology subsets – for review and publication;
• Archetype metadata supporting classification, ontological relationships and repository-wide searches;
• Digital asset management including provenance and artefact audit trail;
• Integration with openEHR tools supporting quality assessment & technical validation checks;
• Review and publication process for clinical content – draft, team review, published and reassess states
• Terminology binding and terminology subset reviews;
• Online archetype translation with review;
• Community engagement via threaded discussions, repository downloads, attached resources, watch lists, email notifications, user dashboards and release sets;,
• Editorial support via To Do lists, user and team administration, review management, artefact modification, classification management, broadcast emails etc;
• Subscriber auto-notification including Twitter and email
• Reports – Archetypes, Templates and Registered users

A governed repository of shared and agreed archetypes will provide a ‘glide path’ towards full semantic interoperability of health information; a clear forward path for standardisation of data definitions. These will bootstrap new application or program development, provide a ‘road map’ to support gradual transition of existing systems to common data representation and provide the means to integrate valuable silos of legacy data.

Benefits of a collaborative, data-driven approach

A collaborative and domain expert-led approach to our health information provides many benefits which include the following.

Benefits for stakeholders

• Active involvement of domain experts to ensure the safety and quality of health information.
• Development of a coherent set of health information definitions:
  • Improved data quality – shared core clinical content plus specialised domain-specific content will be agreed and ratified by the domain expert community; health information created will need to conform to the agreed archetype specifications.
  • Improved data ‘liquidity’ – specifications to support exchange, flow and re-use of health information - from direct patient care through to secondary use of data. Improved data longevity – shared non-proprietary health information definitions minimise need for data transformations or system migration and the inherent risk of data loss; will support the cumulative, lifelong health records and longitudinal data repositories;
  • Improved data availability – easier integration of health information from disparate sources when based on common archetype definitions;
  • Re-use, integrate and aggregate data for supporting quality processes such as clinical audit, reporting and research; and
  • Break down the existing ‘silos’ of health information based on proprietary and varied definitions.

• Online collaboration maximises the potential for a breadth of grassroots stakeholder engagement in ensuring correctness of the health information definitions.
• Active participation by clinical domain experts to shape and influence their EHRs, ensuring that EHR content is ‘fit for clinical purpose’.
• Online participation in clinical content review will be of short duration and at times of convenience to the clinician, avoiding the significant time and opportunity cost of attendance at face-to-face meetings.

Benefits for patients

• Data created and stored in a shared, standardised and non-proprietary representation supports the potential for application-independent data records that can persist for the life of the patient.
• Improved data ‘liquidity’ – so that data can flow between healthcare providers and systems to where the patient needs it.

Benefits for national programs and other jurisdictions

• Development of a coherent national set of clinical content specifications to support the shared EHR programs, health information exchange and secondary use.
• Enables national governance of foundation clinical content while at the same time facilitates flexible expression of local domain requirements
• Efficient use of sparse clinical, informatics and stakeholder resources:
  • Design & create an archetype once; re-use many times;
  • Leveraging existing clinical specification work done internationally to improve local national pool of archetypes;
  • Online collaboration maximise the potential for stakeholder engagement at the same time as minimising the requirement for expensive face-to-face meetings; and
  • Review and publication of agreed clinical specification definitions within weeks to months;
  • Review and standardisation of clinical documents containing agreed archetypes will be relatively short.
• • Clinical knowledge management ecosystem:
  • Single national repository of clinical knowledge artefacts, including archetypes and terminology subsets.
  • Focussed and coordinated knowledge management environment where all stakeholders can observe, participate and benefit; the opposite of the current fragmented, isolated and proprietary approach to defining health information content.
  • Digital knowledge asset management:
    • Manages authoring, reviewing, publication and update lifecycle of all knowledge assets;
    • Provenance and asset audit trails;
    • Ensures asset compliance to quality criteria;
    • Ensures technical validation of assets; and
    • Development of coherent release sets for implementers;
  • Governance of knowledge assets.
  • Distribution of knowledge assets via coherent release sets.
• Removes the need for per message or per document negotiation between application developers, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.
• Transparency of editorial and publishing processes; accountability to the domain expert community itself.
• Precludes the need for ratification of clinical or reporting documents through a traditional standards process when they consist of subsets of the nationally agreed archetypes.

Benefits for application developers

• Download coherent sets of clinical content definitions from a published and agreed national repository – not re-inventing the wheel by defining each piece of health information over and over.
• Software development remains focused within the expert technical domain – user interface; workflow processes; security, data capture, storage, retrieval and querying; etc.
• Removes the need for per message or per document negotiation between vendors, organisations and jurisdictions each time information needs to be integrated or exchanged by use of the standardised content within more generic message wrappers or document structures.

Benefits for secondary users of data

• Existing data can be mapped to archetypes once only, and transformed into a validated and consistent format; new data can be captured and aggregated according to the same national archetype definitions.
• Data stored in a common representation can be more easily aggregated and integrated.
• Access to valuable legacy data that would otherwise be unavailable.

Agreed and shared representations of the health information, embracing existing stakeholder requirements and developed rapidly by an active online community, will kick-start and accelerate many currently fragmented eHealth activities. Sharing archetypes as the definition of our health information will not only provide a common basis for recording and exchanging health information but also simplify data aggregation of data, support knowledge-based activities and comparative data analysis. Perhaps even more compelling, we are making certain that our domain experts warrant that the data within our EHRs, and flowing between stakeholders, is safe and 'fit for purpose'.

The state of the CKM!

The openEHR Clinical Knowledge Manager (CKM) is a unique resource for the specification of health information that will become part of people’s lifelong health record. The work raises questions. What more do we need to develop and manage high quality specifications for health information suitable for sharing between clinical applications? How do we manage the tension between harnessing the richness of contributions from the large and enthusiastic community of clinicians and health informaticians and ensuring that the specifications are comprehensive and internally consistent?  This has been weighing on my mind over the past couple of years as our team have developed a Web 2.0 approach to openEHR clinical knowledge collaboration. CKM  is an international, online clinical knowledge repository providing digital asset management throughout the authoring, reviewing, publication and update lifecycle of these specifications. It has been designed to provide governance capabilities, and facilitates collaboration by registered participants. The full range of openEHR clinical knowledge resources - archetypes, templates and terminology subsets – are now managed in this environment.

Under the auspice of the openEHR Foundation, our goal is to offer a clinical knowledge management ecosystem in which: the knowledge artefacts are based on open specifications; the service and programming interfaces are openly specified; and the production data representations are also openly specified. Archetypes are freely available under a Creative Commons license.

The focus of CKM to date has been to publish a coherent set of archetypes that can be use by national body or health application developers in projects that involve shared EHRs. These archetypes have developed in different projects, including work in partnership with the UK, Singapore, Australian and Swedish eHealth Programs and in collaboration with clinical application developers building working systems. The work has also been influenced by the openEHR international community’s proposal to develop a set of high quality archetypes to support a shared Emergency summary.  These ‘top 10’ archetypes define core clinical content in many common clinical scenarios.

The intent for current CKM archetype design is to make it possible for them to be used across any and all clinical systems - ‘global’ archetypes. By design these archetypes:

• Are a maximal dataset to maximise inclusiveness and uptake;
• Are re-usable across universal use cases;
• Are an internally consistent set;
• Minimise model overlap;
• Are based on generic patterns (which are evolving and design pattern principles are becoming clearer);
• Support further specialisations to meet local or specific domain requirements; and
• Provide design guidance for archetype development for similar concepts.

The draft archetypes currently in CKM do not meet all these requirements but as they progress through the publication process are brought closer to this ideal.  As requirements develop (and health care changes) the archetypes will be revised always seeking to maintain universal sharing of the very important health information held in a lifelong record.

At the time of writing CKM has acquired, largely by word of mouth, 556 registered users from 62 countries, including 179 people who have volunteered to review archetypes, and 72 who have volunteered to translate archetypes.  The repository contains 273 archetypes, of which 15 have content that are in team review and 9 published. Two example templates have been uploaded, and we await final publication of the template specification before we expect to see templating activity increase. Terminology subset functionality has been added only this week and our first SNOMED subsets uploaded. This enables CKM to become a ‘one stop shop’ for clinical knowledge resources online.

Current CKM functionality includes:

• Display of artefacts including structured views, technical representations and mind maps to make it easy for clinicians and others to review;
• Uploading of new knowledge artefacts – archetypes, templates and terminology subsets – for review and publication;
• Archetype metadata supporting classification, ontological relationships and repository-wide searches;
• Digital asset management including provenance and artefact audit trail;
• Integration with openEHR tools supporting quality assessment & technical validation checks;
• Review and publication process for clinical content – draft, team review, published and reassess states
• Terminology binding and terminology subset reviews;
• Online archetype translation with review;
• Community engagement via threaded discussions, repository downloads, attached resources, watch lists, email notifications, user dashboards and release sets;,
• Editorial support via do lists, user and team administration, review management, artefact modification, classification management, broadcast emails etc;
• Subscriber auto-notification including Twitter and email
• Reports – Archetypes, Templates and Registered users

Transparency is a key principle within CKM. Editors are accountable to the community at every step; all comments, review rounds, changes etc. within CKM can be seen by the users.  This ensures that if a user flags an issue, it is managed publicly and the user community can comment on the resolution.

Editorial work and fine-tuning the archetypes towards publication takes time and with a small number of volunteer editors the work has been a little slower than anticipated. Interestingly the rate limiting step at present is availability of the editorial support, NOT an interested community willing to contribute their expertise – joining the community largely only by word of mouth, they are motivated and willing to contribute whenever requested!

Yet we are very pleased with our modest achievements to date:

• A reasonably robust tool built through real experience;
• Established processes for the transparent governance of the range of openEHR-related clinical knowledge artefacts; progressively fine-tuned as we identify and understand the issues involved; and
• A motivated community supporting us and keen to participate in a web 2.0 environment.

Perhaps most important is what has been learned about knowledge governance – a relatively new domain. We anticipated complexity and the more we advance the CKM tool, the more we discover! This is an exciting and challenging journey.

We are ready now to encourage and embrace greater participation - harnessing the collective intelligence of the CKM community - through development of an archetype ‘pool’ where users can share their work on archetypes, templates and terminology subsets - a stepping stone into the tightly governed 'global' archetype pool. Some of these community archetypes will be developed for other purposes than the ‘maximal data set, universal use case’ scenario and provide valuable intermediate steps to support existing protocols and work to be used in a shared health record. We want to enable these to be shared and reused while at the same time encouraging work towards more general and broadly shareable solutions – all will benefit if we can share and learn from each other.

We continue to look for ways to help developers and implementers get what they need from CKM and this is an ongoing work. One important development is the ability to federate instances of CKM with the international openEHR service which offers a way of keeping national/jurisdictional efforts aligned but independently managed. Release sets of coherent archetypes are also a high development priority.

There are a diverse set of requirements and a growing set of artefacts – no simple one size solution that fits all. We can’t simply declare that we need a ‘top down’ or ‘bottom up’ approach. Sometimes leadership will be key, sometimes democracy.We are aiming for a pragmatic mix, with accountability to the community through transparency of process being paramount.

To our thinking, generating formal and computable health information specifications conveniently and openly on the web by a motivated, international community of grassroots clinicians, informaticians and implementers is potentially world-changing. And perhaps even more exciting, we are enabling our domain experts, the clinicians themselves, to make sure that the data within our EHRs is safe and 'fit for purpose'.

We are on a journey to create a clinical knowledge ecosystem – and this is the state of the CKM!

Special thanks to Sam Heard for his editorial assistance.

And to the CKM team - Sam Heard (@samheardoi) in Australia, Ian McNicoll (@ianmcnicoll) in Scotland and Sebastian Garde (@gardes) in Germany.

Don't forget to follow @openEHRckm for notification of CKM activity and updates.

openEHR - the World’s Record

I wrote this overview of openEHR way back in 2007, and it was published in PulseIT (Sydney, Australia) [Internet], pp50-55, Issue 6, November 2007. The online publisher has removed access to it, so I've posted it here.

The principles remain unchanged.  I've updated some links, and indicated some minor parts that are a little out-of-date. My previous posts, What on earth is openEHR & Connect with openEHR provide up-to-date stats and links.

In a world where connectivity reigns, our health information is largely still caught up in silos and, in the main, is not shareable by clinicians.  Shared electronic health records (SEHRs) are increasingly needed to provide timely, comprehensive and coordinated healthcare.  Over many years there have been ongoing and thorough attempts to achieve the sharing of health information in order to support the improvement of health outcomes, but this incremental approach, gradually building on previous experience, has not been wholly successful.  Progress has been made, but despite enormous investment and resources, the solution has been more difficult than most ever anticipated.  Healthcare provision does not seem to fit into the same kind of data sharing model as has been successful in other domains such as banking or financial services.

In order to support interoperability of health information SEHRs need clinical content to be standardised.  This assists the move to standardised communication of complex health information between systems and the opening of these vertical domain and organisational silos, allowing accurate and semantically computable health information flow.  Inevitably the shared clinical content specifications begin to influence the information models within clinical applications.  openEHR is an electronic health record architecture based on many years of research and development, and designed to work in partnership with all vendor systems, organisations and providers to facilitate semantic interoperability of health information.  It is a comprehensive and transformational solution which applies to the capturing and sharing of information from the most complex and dynamic knowledge domain – health.

Why are Health Records so difficult?

The interoperability of health information problem is twofold – firstly, the evolving clinical needs and requirements for a SEHR are difficult to pin down, and secondly the technical issues related to a SEHR solution.

Why are clinical requirements so difficult to capture and transform into an electronic health record (EHR)?  Certainly no-one will argue that our experience of healthcare delivery is changing – hospital in the home projects; supported self-management; patient requests for access to GP and hospital clinical records; personal health records; service coordination; clinical care plans; preventive health priorities...  The list goes on, mirroring the rapidly evolving change in clinical EHR requirements needed to support these new paradigms of healthcare delivery.  These new ways of delivering care require a coordinated approach – healthcare providers need to collaborate efficiently in real time, which is not adequately supported by traditional methods such as meetings and phone calls.  We really need an interoperable and integrated patient record in which all healthcare providers can participate, within a framework providing governance, authorisation and security measures.

Clinical knowledge domain is very complex and dynamic, so any clinical system created using traditional software development methods (embedding the clinical knowledge directly into proprietary application code and databases) has an uphill battle to deal with the changes.  Considering the time it takes for a clinical application to be developed, it may already be out-of-date at its launch!  The inherent difficulties in updating knowledge structures that are hard-coded into the application and database inevitably lead to a gradual deterioration of the integrity of the system.

Clinical decision support is another difficult area – there is a lot of discussion about it, but there is very little real computerised decision support happening in practice.  Certainly, each clinical system has some that is custom built – usually limited to allergy and drug interaction alerts and a reminder system – but there has been very little general progress in this area.  Why is clinical decision support (CDS) still largely found only in the academic domain and not implemented in production clinical systems?  We already have clinical guidelines and other resources which are approved and used in paper formats – why are they not integrated in our clinical desktop applications?  The answer is multi-factorial.  Things that have blocked progress include ownership and sharing of intellectual property, licensing problems etc, but the main issue is to do with practical implementation and cost.  An approved guideline can be transformed into some proprietary computable format, but then it has to be able to integrate into every other clinical system – lots of interfaces have to be built, paid for and maintained.  This is a nightmare.  Another approach is for each system developer to take a guideline and integrate it into their system as best they can.  This introduces variability and the potential for significant quality and liability issues to arise.

Silos of proprietary information cannot talk to each other without mappings and necessary assumptions.  Such transformations inevitably compromise the quality and integrity of the information being shared, thus creating more threats to patient safety.  It is only through use of a common logical clinical content model reflected in our EHRs and CDS systems that the guidelines can be created once according to this agreed model and can be integrated meaningfully and accurately with the clinical information systems to give us quality clinical decision support at the point of care.

From a technical point of view, the current reality around the world is that the majority of vendors are competing to build the greatest and ‘best of breed’ clinical software applications, but all are doing it in their own proprietary way.  The software may have a rich functionality and a great user interface.  It may do a great job in the clinic, hospital or network on which it is installed, but how does it share clinical data?  Some software applications may be able to share with the same system in another geographical location because they share a common data structure, but cannot easily share with the system of another vendor.

Current clinical applications can usually send or receive point-to-point messages using a format which is known and agreed, and based on a standard such as the Health Level 7 (HL7) version 2.  The software may also incorporate a terminology to assist in capturing and storing common clinical concepts.  However, there is a common misconception that if we simply have a messaging standard paired with a terminology, then we have ‘achieved interoperability’.

A New Paradigm for Electronic Health Records

Most of us mistake the software program for the electronic health record; in fact in the USA the word EHR means a clinical application.  The openEHR approach asserts that it is not the application, but rather the data, or health information, which makes up the health record.  And further, that it is a common and agreed structure of that data is what makes the electronic health record of any use for computing in health.

In order for two clinical systems to be able to share health data unambiguously, such that clinicians can read it and the computer can compute with it, more is required.  This semantic, or knowledge-level, interoperability, based on a common and coherent clinical model, is an absolute requirement for truly shareable EHRs and valuable complementary functionality such as clinical decision support and workflow/care planning.  Further, it is only when this clinical content structure is agreed at a local, regional, national or international level, that true semantic interoperability can occur at each of these levels.  The broader the level of clinical content model agreement, the broader the potential for semantic health information exchange. While an increasing number of health informatics experts agree on this view of the problem, incremental work towards EHR standards based on messaging paradigms, such as HL7 v3, have only had limited degrees of success.  At an international level, there is increasing concern that this incremental approach to SEHRs may not be able to solve the issues of semantically interoperable EHRs.  Remember that Einstein argued: “We can't solve problems by using the same kind of thinking we used when we created them.”

We need semantic interoperability for our SEHRs and in order to achieve this we need a transformational change.  We need to use a different paradigm.  The openEHR paradigm has been collaboratively developed, reviewed and refined to realise a collective vision of a high quality, internationally interoperable EHR.

What is semantic interoperability?

Let’s be clear about what semantic interoperability means.  According to Walker et al[1], Level 4 interoperability, or ‘machine interpretable data’, comprises both structured messages and standardised content/coded data.  In practice, it means that data can be transmitted and viewed by clinical systems without need for further interpretation or translation.  This is a basic foundation for a truly shareable EHR and for functionality such as clinical decision support.

For clarity, existing HL7 v2 messages probably fit into Level 3 of Walker’s conceptual framework – ‘Machine organisable data’ which comprises structured messages but unstructured content.  According to Walker, a level 3 message “requires interfaces that can translate incoming data from the sending organization’s vocabulary to the receiving organization’s vocabulary; usually results in imperfect translations because of vocabularies’ incompatible levels of detail.”  We cannot directly compute on a Level 3 message – it requires interpretation or transformation before the computer can use it.  HL7 v3 goes a step further with an underlying semantic model.  The problem has been that using this in systems has proved very difficult.  The HL7 CDA, chosen by Nehta for communication in Australia, bypasses some of the difficulties by at least enabling us to share documents that we can read.  More is needed to achieve semantic interoperability.

What is openEHR?

openEHR[2] is a set of open specifications for an Electronic Health Record (EHR) architecture – but it is not a software application.  Its design purpose is to enable semantic interoperability of health information between, and within, EHR systems – all in a non-proprietary format, avoiding vendor lock-in of data.

All clinical knowledge concepts are captured in a structured way - known as archetypes – outside the software.  The types of archetypes support the recording required for common clinical activities, with some of the key building block archetypes comprising observations, evaluations, instructions and actions.  Data built according to these are stored in an EHR in larger ‘composition’ structures, which have their own archetypes.  Compositions are comparable to a document that results from a clinical event which is performed e.g. a consultation record or a discharge summary.  Archetypes can be simple, such as temperature, blood pressure or diagnosis, or complex, such as capturing the risk to a fetus if the father has a grandmother with Huntingdon’s chorea.  The archetypes contain a maximum data set about each clinical concept, including attendant data required such as: protocol, or method of measurement; related events; and context that is required for the clinical data to be interpreted accurately.  The creation of archetypes and templates is almost purely a task for clinicians – openEHR archetypes put clinicians in the driver’s seat, enabling them to create the breadth, depth and complexity of the health record to suit their needs for direct healthcare provision.

Aggregations of archetypes are combined in openEHR ‘templates’ in order to capture the data-set corresponding to a particular clinical task, such as an ICU discharge summary or antenatal visit record.  When clinicians look at templates, the information contained within them inherently makes sense and doesn’t require significant training for interested clinicians to be able to create templates for their own purposes – be it domain, organisation or purpose specific.  Templates can be used to build generic forms to represent the approximate layout of the EHR in a practical sense, and these can be used by vendors to contribute to their user interface development.

Both archetypes and templates can be linked to terminologies or contextually appropriate terminology subsets that will support appropriate term selection by healthcare providers at the point of data entry.

openEHR is rapidly gaining international momentum, supported by evidence from current high profile implementations of the openEHR specifications such as in the UK NHS Connecting for Health program.

Who is openEHR?

The openEHR Foundation owns the intellectual property of the openEHR architecture specifications.  The Foundation is a not-for-profit company, with the founding partners being University College London (CHIME department) and Australian company, Ocean Informatics. The specifications are the result of over 15 years of research and international implementations, including the Good European Health Record (GEHR), and the collaboration of an international community of people who share a common goal – that of the realisation of clinically comprehensive and interoperable electronic health records to support seamless and high quality patient care.

The registered online community has over 1000 members from 75 countries with many actively participating in debate and contributing to ongoing openEHR development from both technical and clinical perspectives.

What is openEHR used for?

openEHR is a specification for secure, shareable health information and provides a foundation on which to build interoperable, modular software applications.  These, in turn, can support distributed clinical workflow, such as care plans.

The openEHR specification can be implemented in a number of ways:

• Scalable EHRs – from Personal Health Records to small/medium/large organisations to regional or state clinical record systems and on through to National e-Health programs;
• Message-based, web-service, middleware applications; and
• Integrating existing clinical systems, including virtual federation of data for research or public health purposes.

However, while it has much in the way of additional functionality, it is important not to lose sight of openEHR’s raison d'être – semantic interoperability, or more simply, a truly shareable Electronic Health Record.

How is openEHR different?

There are many aspects of openEHR which clearly differentiate it from other EHR models:

1. Open source initiative The openEHR specifications are freely available under an open licence.
2. Separation of the technical and clinical domains The openEHR design is markedly different to traditional EHR development - it is a 2 level information model.  These 2 levels allow a clear separation of the technical reference (i.e. data) model on which software is based from the clinical knowledge itself.  The appeal of this new design is that the technical components of the EHR can be kept quite separate from the dynamic clinical knowledge model.  In practice, the technicians manage just the technical aspects, while the clinicians are critical in the development of the clinical archetypes and templates that shape the nature of their EHR.
3. Purpose-built EHR The design of the reference and archetype models support many unique openEHR features required for robust clinical record keeping, clinical business process and medico-legal compliance, such as:  distributed versioning and merging of EHR records, including audit trails; a strong history and event model for complex observational information; and archetype-driven semantic querying. openEHR designs supports configurable security, anonymous EHRs, fine-grained standards-based privacy, digital signing, and access auditing.
4. Knowledge-enabled – capturing the dynamic and complex nature of health information Clinicians are able to contribute actively and directly to the development of the clinical knowledge models that underpin their EHRs.  Archetypes can be revised and versioned to reflect the rapid and varied changes in health domain knowledge.
5. Terminology agnostic openEHR connects flexibly to any or all terminologies through either archetypes or templates.  Terminologies such as SNOMED-CT are leveraged when used alongside archetypes, with the archetype clinical model providing context to minimise the need for post-coordination and complexity.  Archetypes and terminologies are not competitive but rather complement each other.
6. Semantic querying Archetypes, in combination with terminologies enable powerful possibilities for semantic querying of repository data – whether for individual usage or for population research.  Archetype-based querying enables true longitudinal processing of health data, regardless of the originating system.
7. Language independent There is no language primacy in archetypes; they can begin in any language and be translated to multiple other languages.  Translation enables the same archetype to be used in different countries, with data created in one language to be interoperable with systems developed and used in other languages.  Archetypes are currently available in English, German, Turkish, Dutch, Swedish, Farsi, Spanish and Portuguese.
8. Sustainable reference model – life-long EHRs The openEHR reference model has been rigorously engineered over the past 15+ years as the foundation for a comprehensive health computing platform.  It consists only of generic data types, structures and a small number of generic patterns, resulting in a small, stable and sustainable information model for IT people to maintain.  This approach allows a clinical data repository to act as a future-proof data store, totally independent of software applications and technology change.  In practice this means that no software application changes, or redeployment, are required when new or revised archetypes are published to reflect changing clinical knowledge.  As a result, life-long, application-independent health records are possible for the first time.
9. Ease of implementation openEHR is comparatively easy to implement:
   • there is little infrastructure required;
   • the software required is small, due to being based on a compact and stable, object-oriented reference model; and
   • the clinical models (Archetypes) can be developed separately from the software application.
10. Ongoing development and enhancement Based on feedback from its international collaborators, openEHR is undergoing continuing development, with ongoing maintenance and releases of specifications and software.
11. Governance of shared content Archetypes are created once, and if broadly agreed upon, they can become the basis of consistent sharing of data content between systems, providers and even other countries.  While archetypes can be designed and used by a given solo practitioner/researcher or locally within an organisation, the power of archetypes becomes more evident the more broadly they are shared.  All systems that use the same archetype – even across country borders and terminologies – will be able to interoperate. The openEHR Foundation is in the process of developing an ontologically based international, open source archetype and template repository[3].  This is being supported by a governance framework which will facilitate archetypes to be submitted for international clinical review, and publication.  It comprises a complete archetype and template lifecycle and version management repository and supporting processes to allow countries, regions, organisations or vendors to freely download and utilise these commonly agreed archetypes in their clinical systems.  Archetype libraries can also be set up at other levels, as needed – domain, organisational, regional, or national.
12. A collaborative model of development rather than a standards-based path The openEHR development to date has been the result of an interested and motivated volunteers from a broad international community of clinicians and software engineers.  Formal and rigorous processes have underpinned its progress and both Architectural and Clinical Review Boards, comprising world experts in their fields, have had oversight of the overarching strategy, process and governance. Standards are not rejected in the openEHR approach; they are just not a part of the development process.  In comparison to a traditional standards-based approach, openEHR development has been relatively rapid and pragmatic, rather than being held back by the slower process of ‘design by committee’.  In fact, the recent European CEN standard for EHR extracts (EN13606) has been based on an earlier version of, and a subset of, openEHR.  In addition, openEHR’s Archetype Definition Language (ADL), has recently been accepted as an International Standards Organisation (ISO) committee draft, for consideration as a standard.

Where is openEHR being used? [as at October, 2007]

openEHR is being used in both active research and commercial activities.  [4] Research on openEHR is being conducted in Sweden, Australia, United Kingdom, USA, Sri Lanka and Spain.  Commercial development is occurring in Australia, United Kingdom’s NHS Connecting for Health, Netherlands, Belgium, Sweden, Turkey and the USA.

The United Kingdom’s National Health Service (NHS) Connecting for Health program has just commenced a formal clinical modelling program using openEHR archetypes and templates to provide a common and agreed clinical content on which to base its clinical applications.  In a pilot early in 2007, content developed for NHS Maternity and Emergency domains were provided to vendors for implementation in new clinical application development.[5] These archetypes are available in the public domain, and have undergone broad internal review by expert clinicians prior to being approved for NHS usage.  The Emergency templates developed reflect the top 10 presentations to an Emergency Department – including chest pain, shortness of breath and collapse.  The Maternity templates followed the clinical journey of a pregnant woman – from a pre-pregnancy consultation and antenatal visits, through to capturing the labour and delivery record, including Partogram data.  Each template is made up of a variable number of archetypes – ranging from a few simple templates containing only 2 or 3 archetypes through to complex templates containing up to 80 discrete clinical concepts.

Current openEHR status and supporting tools [as at October, 2007]

1. openEHR Specification The latest openEHR Specification (Release 1.0.1) was published on 15 April 2007.
2. Clinical Content Development of archetypes and templates has gained significant momentum in the past 12 months:
   • Archetypes As a result of initial Australian modelling work and, more recently, within the UK NHS, there are now approximately 250 archetypes.
   • Templates Over forty distinct templates representing clinical needs in Emergency and Maternity were developed over a short time period in March/April 2007.
3. Commercial Tools Currently there are a number of commercial tools supporting the open source openEHR implementation.  The major tools to date are developed in .Net and Java.  Australia’s Ocean Informatics[6] has developed a suite of products supporting openEHR implementation in .Net, while Sweden’s Linkoping University have developed an Archetype Editor in Java and Cambio Healthcare Systems[7] have an early Java kernel.

The Ocean .Net products include:

• Clinical Knowledge Suite:
  • Archetype Editor (open source) and Template Designer, including semi-automated screen form construction based on templates;
  • Terminology Toolset – including a caching terminology server and subsetting tool, incorporating SNOMED-CT in the first instance; and
  • Archetype-powered Query Designer

• OceanEHR platform – including a universal data repository, demographic service binding, generic EHR Viewer; and data integration & transformation services.
• Archetype/Template Library Service as an online template and archetype repository

Get involved with openEHR

Membership of the openEHR community is free and open to everyone via the openEHR website[8].  It assumes a commitment to a common vision for high quality, interoperable EHRs, and a willingness to share ideas and experience.  All levels of interest and contribution are welcome – from novice to expert.  The lists range from discussion on technical, clinical and implementer mailing lists through active development of archetypes, templates and tools, to review and critique of clinical content models and technical specifications. Whether you are a clinician, patient advocate, vendor or provider of health care you have a role in the development of what is becoming known as 'the world's record'.

---

[1] Walker J, Pan E, Johnston D, Adler-Milstein J, Bates DW, Middleton B. The Value of Health Care Information Exchange and Interoperability. Health Affairs 2005 Jan 19 - http://content.healthaffairs.org/cgi/content/abstract/hlthaff.w5.10v1

[2] For more details, see www.openEHR.org

[3] For more details, see www.archetypes.com.au [UPDATE 2010: Clinical Knowledge Manager - www.openEHR.org/knowledge]

[4] For more details, see www.openehr.org/projects/t_projects.htm [UPDATE 2010: http://www.openehr.org/projects/eiffel.html]

[5] For more details of the NHS clinical modeling work, see www.ehr.chime.ucl.ac.uk/display/nhsmodels/Home

[6] For more details, see www.oceaninformatics.com

[7] For more details, see www.cambio.se/zino.aspx?lan=en-us

[8] www.openehr.org

Is your clinical data 'fit for purpose'?

We clinicians expect a lot from our electronic health records (EHR), & so we should. Yet I am surprised at how remarkably passive we, as a group, are about the structure & quality of the data that underpins it.

• Does it store the data we need?
• Can it be utilized for decision support.
• Will it support our research?
• Can it easily be shared?

Most of us don't know - we just don't tend to look 'under the bonnet'.

Yet we are undeniably clinical domain experts. We also understand what information we need for providing patient care & our research. What if our systems don't capture what we need or in the optimal way for us to use?

We need to ensure that all our efforts to conscientiously enter good patient data is reflected in the underlying data structure - that our clinical data is 'fit for purpose'.

It is important to understand & acknowledge that there are many ways to represent the same data, and not all are equivalent! We need those trained as both clinicians & informaticians to be intimately involved in developing high quality eHealth tools. Clinician informaticians provide the critical link between our software engineers & our grassroots clinician experts.

Have you ever considered how the data in our systems is designed?  What is the process? What is the criteria for 'quality'?

I have seen many examples of clinical information requirements that have been gathered 'with extensive stakeholder engagement'. OK, but when you enquire who gathered the requirements it is not always (& sadly, most often not) a clinician informatician who has asked the questions. I have to ask the question. If you are not a clinician & don't understand how health data is going to be used (content, processes, reference models, querying, use of terminologies etc), how can you ask a reference group the right questions in the first place & ensure that you have the right answers? The chances of the reference group consisting of clinician informaticians to spoon feed you the right information is pretty slim. So by my reckoning there may be a significant risk of 'the blind leading the blind' syndrome occurring in this not uncommon scenario. Learning point: Always question the credentials of the initial data requirements!

On a number of occasions I have been shown some data requirements for core archetype modeling - problem/diagnosis, adverse reactions, medication orders & the like. It is frequently clear they have been developed by a technical analyst with very little clinician informatician input. Turning these requirements into an archetype is not an issue, however I have concerns that my 'fit for clinical use' criteria will not be met. They might be perfect for reporting back to government, but for clinical care, decision support, research, sharing etc... maybe not so good, yet they are being created for use in desktop clinical EHRs.

Interestingly in openEHR training sessions I have supplied a set of clinical requirements for an archetype to participants, encouraging them to break into mixed teams of both clinicians & technicians to try their hand at collectively building their first archetype. Not so surprisingly, they most often split into clearly demarcated technical & clinical groups - no cross-pollination at all;-). Despite being presented with the same requirements, inevitably both groups tend to represent the data quite differently - clinicians intuitively represent it the way they know it & need it; the technicians making a best guess based on their incidental domain knowledge. 

When I train people in how to build archetypes, I always state that the best archetypes - by that I mean 'fit for purpose' - are those built by clinician informaticians. Next best are those built in close collaboration with clinician experts, preferably staring over their shoulder & offering feedback in real time! Lastly, those built by technical modelers with little or no direct domain understanding. (Unfortunately, by far the most modelers that are in the employ of our national eHealth programs & large vendors are in the latter category.)

I have seen surprisingly bad archetyping efforts by very proficient technical modelers, largely just because they don't understand the clinical context. In most instances, a spreadsheet or UML diagram of requirements just isn't enough. On many occasions over the past few years I have found that their idea of a clinical concept is often quite different to that of a clinician - not unexpected really!

My conclusion - clinical experience matters!

Health informaticians are few on the ground. Clinician informaticians are even fewer. We need a transformational approach to EHR development - working smarter & more efficiently. Clinician informaticians are critical to ensure the development of shareable, 'fit for purpose' clinical content specifications as a solid foundation for good quality health data, both within & for sharing between systems.

What if... grassroots professional clinical colleges were driving EHRs?

Is the tail wagging the dog? Should vendors decide what clinicians need? OR should the professional clinical colleges be driving the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that colleges should be the experts driving this new paradigm of clinical care. As a group, professional clinical colleges as a group usually state that one of their major roles is in establishing and driving the benchmarks for acceptable clinical practice standards in their field of expertise. Most do this very well in the traditional areas of clinical practice.

Scouring the web it is possible to see that some are engaging actively in eHealth. For example, from the website of The Council of the Royal College of Physicians in UK, a vision statement published in January 2010 incorporates this final paragraph:

"Effective implementation of standardised, structured, patient focused records requires strongly led culture change, embraced by all medical and clinical staff. They are essential prerequisites for safe, high quality care and for the safe, efficient and effective migration from paper to electronic patient records. Such records will also enable innovative development of services that cross traditional boundaries and, by giving patients access to their record, empower them to take more responsibility for their own care."

If colleges have had a traditional role in ensuring safe, high quality care, then the advent of electronic health information should logically trigger a natural extension of their pre-existing work and roles into the eHealth arena. I would go further and suggest that they should also be actively driving an eHealth agenda that reflects their college remit regarding provision of quality care and standards; ensuring that the data created, stored, shared and queried is good and fit for use in clinical care.

This agenda may, or may not, be aligned with the activities of national eHealth programs. As we look at the news in recent weeks it is becoming apparent that many are struggling with implementation of top-down agendas. We have seen major changes in the national approach to eHealth happening in Netherlands, Germany, and England's NHS. Perhaps it is time for a grassroots, bottom-up approach from the end-users, the healthcare providers, and their patients, the healthcare consumers.

How can colleges drive eHealth?

1. Promote the establishment of a universal health record - a long-term, data-driven health record platform based upon open source specifications, a standardised health data structure, and application-independence. If we place the patient's universal health record at the focus, applications can effectively 'plug & play' with an open, standardised patient data repository, instead of struggling/battling to move/transform/migrate/map/message bits of health information between proprietary application silos.
2. Develop clinical quality-related eHealth standards:
   • Knowledge artefacts specifications The clinical knowledge expertise of colleges can be used not only to develop principles of best practice and clinical guidelines etc but also the structured clinical content specifications that underpin the universal health record and ensure that the health record is able to capture all the data that their clinicians need to provide quality clinical care, to share with other healthcare professionals and for research. These specifications need to be defined both at the clinical concept level, such as the specification for blood pressure, but also expressing how many clinical concepts can be aggregated together and constrained to specify the requirements for a computable discharge summary or an anaesthetic record. Ideally this would be work done in collaboration with other clinicians, colleges and informaticians to make sure that the agreed concept specifications are applicable for all colleges and clinical domains, so that there is one common concept in use for all. Colleges as domain experts are also best placed to determine the terminology subsets that are appropriate for use by their clinicians.
   • EHR best practice: Develop principles around the best practice use of electronic health records, including:
     • Data quality principles and activities. As health records become electronic, the previous remit of Colleges to make sure that clinical practices are accredited and that paper records are kept to a documented standard can be transformed to the eHealth paradigm. There are similar principles that can be developed and applied when clinicians are capturing and using data. Programs such as Primus Plus in the UK have worked directly with primary care clinicians to educate and support about best practice data management.
     • EHR safety - User interfaces,clinical processes, decision support etc

Colleges may bundle these new standards-based eHealth activities within existing service provision to, or activities involving, their members.

In addition, commercially savvy colleges could develop ways to develop and sell practical solutions or packages around these quality principles direct to members – products or programs to make it easy for members to put the evidence-based and quality principles into practice.

Herein lies a challenge for contemporary professional clinical colleges – to both embrace eHealth and to actively drive it in a way that promotes and preserves safety, quality and best practice in healthcare, such that eHealth becomes a positive tool for healthcare provision and, possibly even, reform.

And how to do this in practice? Well, it is no secret that I think openEHR can offer a solution to a lot of these issues - see my previous posts 'What on earth is openEHR' and 'Connect with openEHR'.

Time will tell if I'm on the right track. For me as a clinician, the more time I spend with it, the more compelling this openEHR story becomes...

So I'll ask you a question. Is the tail wagging the dog? Should vendors be deciding what clinicians need? OR Should the colleges be driving vendors to develop the EHRs that members need to provide quality healthcare to their patients? From a quality point of view, one could strongly suggest that professional colleges should be the experts driving this new paradigm of clinical care.

Defining the PHR – take II

Following on from my April post regarding thoughts about Person Health Records, I've been working with Professor Dipak Kalra to clarify the definitions and purpose of PHRs. This work is intended to be part of a much larger document which describes PHRs and provides examples. It is not an easy task - PHRs are difficult critters to pin down and most definitions are more a description, but here is my next take on trying to do so...

Personal Health Records are by their very nature hard to define and in order to tease out the breadth and depth of PHRs, it may be helpful to consider PHRs and clinical EHRs being positioned at two opposing ends of a spectrum of health records (see diagram). We could attempt to define a PHR as the direct counterpoint to an Electronic Health Record, but in practice the lines of demarcation are most often not clear nor desirable, except when viewed in terms of who has control over the health record and the content within.

While EHRs have traditionally been defined as “logical representations of information regarding or relevant to the health of a subject of care”, they have existed primarily for the purposes of the healthcare provider providing care to an individual. Information from EHRs may be made available to the subject of care or their authorised representative, upon request to the clinician who is acting as a steward of the health information. In some countries this is supported by specific legislation.

PHRs are also “logical representation of information regarding or relevant to the health of a subject of care”, however in the strictest sense these health records are primarily managed and controlled by the individual who is subject of care, or their authorised representative. The individual has rights over the clinical content held within a PHR, including the ability to delegate those rights to others, especially in the case of minors, the elderly or the disabled. The individual, or their authorised representative, is the key stake-holder determining that the content of the PHR is relevant and appropriate. Simplest examples include self-contained mobile phone applications that track a personal diet or exercise history – individual controlled and accessed only by the individual themselves.

However, in between these two strictest views of an EHR and a PHR is a continuum of person-centric health records with varying degrees of control, access and participation by the individual and their healthcare providers. Toward the EHR end of the spectrum, some EHRs provide viewing access or annotation by the individual to some or all of the clinician’s EHR notes. Conversely, at the other end of the continuum, some PHRs enable individuals to allow varying degrees of participation by authorised clinicians to their health information – from simple viewing of data through to write access to part or all of the PHR.

In the middle range of this continuum exist a growing plethora of person-centric health records that operate under collaborative models, combining content from individuals and healthcare providers under agreed terms and conditions depending on the purpose of the health record. Control of the record may be shared, or parts controlled primarily by either the individual or the healthcare provider with specified permissions being granted to the other party.  For example a shared antenatal record may be either primarily a PHR, under auspice of the individual, permitting authorised health care providers to contribute content or directly edit part of all of the record itself, or it may be an extension of an organisations EHR, permitting the individual to view or directly contribute content to some or all of the record. The exact nature of the sharing of responsibilities and participations by each party needs to be specified in the terms and conditions of the health record.

Intent of health information with a PHR may be purely for use by the individual themselves or it may be used to share with healthcare providers and others, such as family members.

Ownership of the PHR can be complicated – requiring differentiation between moral ownership of the health information content and technical/legal stewardship for storing and securing the data. Storage of health information upon a PHR platform that is managed by a third party requires a formal relationship between the two parties so that individuals can assert their rights, as must the third party uphold their responsibilities.

The content scope for a PHR varies according to purpose, and is broader than most conventional EHRs. In the maximal scope a PHR may have a breadth that encompasses health, wellness, development, welfare and concerns; plus a chronological depth which embraces history of past events, actions and services; tracking and monitoring of current health or activities; and goals and plans for the future. Some PHRs will have a very general, summary focus; others may be activity-driven eg a diabetes management record within a Diabetes community portal or an personal fitness and exercise record. An individual may choose to have one single summary PHR or multiple activity driven PHRs, or a combination of both.

Acknowledgement: Prof Dipak Kalra, CHIME, University College London

Connect with openEHR

If you're not technical it isn't easy to work out how to get started with openEHR; in fact it can seem quite impenetrable to the non-technical community and in particular those clinicians who are critical for collaboration around archetypes. While no specific knowledge of openEHR is required for clinicians to engage in review of clinical content prior to publication, the process of archetype creation itself requires the strategic input of clinicians with some knowledge of openEHR.

So... Where to start?

Check out some of the Ocean Informatics resources. In particular, you may like to start with:

• Archetypes 101 - Leslie, Heard; 2006

• The openEHR advantage - Pishev, 2006

• Engaging Clinicians in Clinical Content Development - Leslie, Garde, Heard, McNicoll; 2009; Ppt

• Introduction to the Clinical Knowledge Manager on the openEHR CKM wiki and video guides on use of CKM

• Tutorial: Building Archetypes (Ppt, 1.25 MB download)

And of course:

• The quintessential Resource -  the 'source of all truth' -  all about openEHR including the technical specifications on the openEHR Foundation's website: www.openEHR.org

• openEHR community - engage directly with the openEHR community via the openEHR mailing lists. There are active announcement, clinical, decision support, implementer and technical lists with an interested community; a place for sharing ideas, collaborative problem solving and sharing of experiences in working with openEHR.

• Twitter

  • Follow the openEHR Foundation - @openEHR

  • Follow CKM announcements - @openEHR_ckm

  • Search for #openEHR

  • My personal twitter list of those with openEHR expertise - omowizard/openehr-resources

Defining the PHR

We're all pretty familiar now with the concepts of HealthVault and Google Health as PHRs.  Then there is also PatientsLikeMe and PHRs sponsored by diabetes and other chronic condition organisations, and those proposed by your health insurer, and those on your phone that support you managing your weight, diet, fitness, blood pressure, glucose readings... the list goes on. Horses for courses. I spent a reasonable portion of my Easter break commenting on an evolving draft ISO technical report that is attempting to provide an authoritative view on the definition, scope and context of Personal Health Records (PHRs).  Given that standards organizations are usually way behind the times, it is good to see that they are attempting to address these issues, but then again, there were over 200 PHR's on the market back in 2000 when I did some market research - 10 years ago. Most are now defunct and we now have a new range of PHRs - most with better business models, not necessarily better functionality!

So after observing the PHR evolution for some time now, my conclusion is that it appears to be getting significantly harder to define the PHR, rather than easier. It's a bit of a mess really - most 'definitions' actually describe what a PHR might or can DO, not being brave enough to define exactly what it IS!  This reflects the real difficulty in pinning down the concept of a personal health record as the domain is filled with huge variation in potential solutions: those aimed at supporting individual self management of health conditions, informed consumer decision-making and consumer entered health information; those evolving towards shared records and distributed healthcare in varying levels of collaboration with clinicians; and those providing constrained access for the individual to clinician EHRs - all complicated by varieties of input, control, ownership of content and access rules for individuals and clinicians.

Some describe the individual merely as 'a key stakeholder determining its content and with rights over that content' - I find this problematic. Can the individual only be a stakeholder in a PHR - personally I think of the individual or the consumer or the patient as the absolute focus and the pivot point of a PHR - it is all about them AND it is all for them.

All in all, I think that the number of disparate 'definitions'/descriptions reflects the difficulty that comes from trying to define a concept that is hugely broad in scope and function, and is likely to evolve and increase in complexity over time.  And these current definitions and descriptions certainly don't reflect my current simple use of a number of different types of PHRs on my phone.

I am increasingly of the opinion that there are actually two conceptual entities that we should consider in relation to personal health records :

• The first being a 'pure PHR' which are usually self-contained applications where the individual owns, controls and maintains their health information (or delegates the control and maintenance to a trusted individual to operate on their behalf).  The 'pure PHR' can be viewed as the counterpoint to the clinician's EHR - authored, managed and owned by the clinician (although with obligations to make that information available to the individual upon request). Thus, the 'pure' PHR could be defined relatively simply, encompassing the opposite end of the spectrum to the clinician's formal EHR. There are so many examples of these applications.
  • Many small self-contained 'best of breed' ones available on PCs or our phones tracking our weight and blood sugar, diet diaries - I have Weightbot, ShapeUp, and bant on my iPhone as examples.
  • Some are integrators, offering a number of these applications in one place eg HealthVault. Still, the individual owns and manages it all on one platform.
• Then there are 'the rest' - which, for want of a better term, I will call the 'hybrid health record'. These hybrid health records are proliferating at a great rate, and with many permutations and combinations with respect to the role of the individual and the clinician; how much health information is shared between parties; inclusion of third party content; ownership; who controls what, etc. This group of hybrid records are difficult to clearly define, but have the potential to transform the way we deliver health care in the next decade. This is where I believe that the 'magic' will happen - where we will really begin to make a difference in healthcare!
  • At the EHR end of the hybrid spectrum will be EHRs with patient portals which will allow the individual to view some of the content with their clinician's EHR.
  • Towards the 'pure' PHR end of the hybrid spectrum will be primarily patient-managed records, allowing clinicians some limited rights or inclusion of their content.
  • In the mid range will be health records that may evolve towards what we tend to think of as 'shared health records' or others with collaborative models combining content from individuals and clinicians under agreed terms and conditions.

Just as we have a clear and concise definition/s of the EHR as one that is owned,maintained and controlled by the clinician, in the interests of clarity I'd like to see a similar definition of an equivalent PHR - one that is owned, controlled and maintained by the individual. This definition is supported by the definition by Gartner in their Global Definitions of EHR, PHR, E-Prescribing and Other Terms for  Healthcare Providers (2008): “A PHR is a patient-owned and patient-controlled online record of medical information etc etc..." (Note that 'online' is clearly a delivery method and inappropriate for a PHR definition.)

I think that it is possible to define the EHR and 'pure' PHR as clear end points, and then we can allow for the huge variability in between, the domain of the 'hybrid' record. These names I have used may not be right or final but use them to consider distinguish between the concepts for now.

I also like the idea of describing the content scope for a PHR as having:

• breadth - encompassing health, wellness, development, welfare and concerns; plus
• depth - encompassing history of past events, actions and services; tracking and monitoring current health or activities; and goals and plans for future.

What do you think?

What on earth is openEHR?

My experience in eHealth started as a suburban General Practitioner using an EHR application for prescribing and clinical notes, and then I moved sideways, becoming involved in building proprietary clinical software and a Personal Health Record. From 2000 I worked for 4 years in a single company that owned that PHR plus a primary care clinical application and a hospital application - the intent being that data created in one could be transferred between the systems, but we found it wasn't that easy - for various reasons they all had different database structures, even within the same vendor! So if we have to do the same thing between disparate vendors in an environment that is more competitive than collaborative, the picture becomes infinitely more complicated. In more recent years, I have had my world view shifted from the traditional application-drive EHR to a data driven health record (note the deliberate lack of capitalization) - see my previous blog posts. Once we focus on getting the data right, capturing it or displaying it in the applications are just one of the many things we can do with the data.

Why? I first heard about openEHR nearly 10 years ago. I didn't understand openEHR at all initially, but there was something in the commonsense of getting the foundation data defined and standardized that resonated with me. Over time I have become convinced that openEHR provides an orthogonal approach to eHealth that has a very reasonable chance of success, and more importantly, of making a difference. I no longer believe that the traditional application-driven approach to electronic health information management is effective, economic or sustainable.

What is openEHR?

Think of openEHR as the open source health equivalent of the iPod/iPhone platform – a technical framework which will allow any compatible application, organization or provider to share 'plug and play' access to standardized data. This is openEHR’s innovation – the focus on ensuring that the underlying health data is correct, robust and trustworthy!

Rich health data definitions known as archetypes, are defined and agreed by the clinicians themselves to ensure that each piece of health information is unambiguously understood, ‘fit for purpose’ and can be dynamically used & reused to support wise and safe health choices, now and into the future. These same archetypes are also computable, so that when these common data definitions are shared, they act as a 'lingua franca', making it much simpler to capture, store, aggregate, query and exchange health information - effectively making the data 'sing and dance' and to flow according to privacy and access rules.

Developed over more than 15 years through international research, community input and implementations, openEHR is purpose-designed as a non-proprietary universal health record: application independent, yet supporting accurate and safe health information exchange between software programs, consumers, health care providers, organisations and researchers; and across the diverse requirements of private/public providers and regional, national and international jurisdictions.

Why openEHR?

• It is open source - break down the proprietary silos of data created by application vendors.
• It is the basis for the recently published ISO13606 standard for EHR extract. openEHR evolved and grew away from 13606 approx. 5 years ago as 13606 entered the CEN and ISO standards approval process; openEHR has subsequently progressed and developed as a direct result of implementation experience. At present openEHR is the commonest implementation pathway for nations mandated to adopt the 13606 standard.
• It is driven by an international open source community.
• It has been developed using a robust engineering process.
• The clinical content is driven by the domain experts - usually, but not limited to the clinicians themselves - through the Clinical Knowledge Manager.
• Archetypes are designed as maximal data sets for the universal use-case so the same data definitions can be used in any software application - whether a PHR, EHR, research project, clinical decision support system or running population queries.
• It is purpose-designed as a shared health record.
• The structured archetype definitions complement other standards-related work - for example the recent announcement of a collaborative work program between the openEHR Foundation and IHTSDO to explore how the SNOMED-CT and openEHR archetypes can be combined to provide a strong semantic solution for health information.

Who is using openEHR?

International momentum is building - current users noted on the openEHR website include commercial, government, academic, and non-profit organisations.

___________________

Current eHealth developments are progressing at a glacially slow rate because we are trying to develop interoperability by traditional and incremental methods. I'm increasingly sceptical that this is effective, economic or sustainable. And in fact, though direct experience I have become convinced that openEHR's orthogonal approach can make a significant difference. I now work with openEHR every day, including:

• alongside an international group of like-minded clinicians collaborating in their spare time in a Web2.0 application to develop, publish and govern the archetypes;
• with national eHealth programs who are seeking to build a library of clinical content definitions as a 'single source of truth' to mandate for use by vendors;
• with vendors who no longer have to reinvent the wheel but can take the published archetypes and re-use them within their systems; and
• with researchers trying to aggregate and integrate disparate data from multiple sources into one cohesive repository on which they can query their valuable data.

I'm not trying to sell you a software application like everyone else claiming an 'eHealth solution'; I'm trying to persuade you to take a look at an alternative approach to eHealth, to share a little of my vision and my passion!

Consider becoming part of an international open source community. Contribute and collaborate alongside other clinicians, informaticians and techies to build something bigger than all of us. Share a vision of how eHealth could work better and more effectively if we get the foundations for a universal health record consistent and solid.

It. is. all. about. standardizing. the. data.

Fractal Electronic Health Records?

Clinicians record their findings and conclusions remarkably efficiently on paper, recording the contextual variations succinctly and in a way that other clinicians can understand. Getting computers to do the same thing – to enable clinicians to record simply in the normal circumstances, but be able to cope with the complex and detailed where it is critically needed - is not a trivial task. Ensuring that a user interface reflects a clinician's work flow and captures the evolving requirements in a clinical consultation is extremely complex. Obviously computers are not as flexible as a human brain; they can only record what is pre-ordained in their programming. We clinicians should expect our electronic health record (EHR) applications to do be able to support our recording requirements and work flow however, in reality, there are very few clinical systems that do this well.

Identifying recurring patterns in clinical practice help to ensure our EHRs can record health information effectively. When we look closely, clinical medicine is fractal in nature.

What do we have to record, display, query and exchange in our EHRs? Lots of measurements such as Pulse, Temperature, Blood gases, Apgar Score, Height, and Weight are pretty straightforward. Those screens are a breeze - type in a couple of numbers and hit 'Save'. Evaluations, diagnoses and assessments are also pretty uncomplicated.

However it starts to get much more complicated when we start to explore history-taking and examination findings - where the bulk of the 'art of medicine' takes place.

Let's think of the evolving nature of a typical clinical consultation. It would be so nice if each patient walked into my consulting room with a single, neatly packaged problem for me to solve, but this is not the norm. In fact the majority arrive with the dreaded 'shopping list or, worse still, with multiple problems that are gradually revealed one by one throughout the consultation. So while computers will capture a linear work flow really well, the typical patient consultation is anything but linear.

But each of these problems will likely be recorded in a common pattern - reason for encounter, history of presenting complaint, systematic questioning, examination, differential diagnosis, investigations, diagnosis, management plan and follow-up.

Consider a simple skin examination. The clinician inspects the patient's back and finds an abnormality - a dark, warty lesion. They record its location, dimensions, shape, regularity, surrounding skin etc, and - oh oh - that there is an area within it with increased pigmentation. Then they focus on the hyperpigmented area - recording location, dimensions, shape, surrounding tissue etc. Then they take a photo for future reference and pull out the dermatoscope - recording yet again the location, dimensions, shape, surrounding tissue etc. There are repeating patterns identified here at increasing levels of granularity.

Recently I've been modeling the examination of the hand. Easy, I thought... at first. OK, we’ll use the general clinical principles to record inspection and palpation of the hand as a whole, including specific hand-related items such as presence of Duypuytren’s contracture, wasting of lumbricals plus circulation, sensation (pinprick, temperature, vibration etc), and strength. Then we need to potentially be able to examine in detail:

• per named finger – again inspection and palpation per digit, plus circulation, sensation, movement of each joint on that finger
• per named nerve eg median nerve distribution
• per named tendon
• per named joint – inspection, palpation and movement of each joint
• per named bone - palpation

And if we found something on inspection of the finger such as a nodule, we need to be able to inspect and palpate the nodule. And if there was a pigmented part of the nodule we'd be documenting it in a similar way to the wart on the back - inspect the pigmentation in detail, including an image of it for future reference. These are incredibly complex recording requirements.

Which way we view or prioritize these requirements will depend on the patient context and the expertise of the examiner. For example, recording needs for a hand examination by a General Practitioner will differ from that of a Rheumatologist or an Orthopaedic Surgeon. Consider also the plastic surgeon about to take a patient to surgery to repair a severed finger will absolutely need to be able to record a detailed breadth and depth of not only the hand and the finger but the digital vessels and nerves that will need their expert attention.

Do you get a sense of the fractal nature of medicine? Repeating patterns in the way we record health information:

• revealed as we repeat the work flow of a typical history and examination process; and
• revealed as we record our findings in more and more detail.

Content modeling for EHRs needs to reflect the fractal nature of clinical medicine accurately, both coarse and fine levels of granularity, and ensuring that the data capture is ‘fit for clinical purpose’.

Inspired by @samheard, as usual;-)

Web2.0 Clinicians – building clinical knowledge resources

After 5 collaborative review rounds by 18 clinicians and informaticians from 9 countries, today I have published the Clinical Synopsis archetype on the openEHR Clinical Knowledge Manager. The Clinical Knowledge Manager (CKM) is an online community putting the Web2.0 paradigm into practice for EHR development. From the CKM wiki...

"The openEHR Clinical Knowledge Manager is an international, online clinical knowledge resource – www.openEHR.org/knowledge. It has gathered an active Web 2.0 community of interested and motivated individuals focused on furthering an open and international approach to clinical informatics – an application- and message-independent lingua franca for sharing health information between individuals, clinicians and organisations; between applications, and across regional and national borders. All contributions to CKM is on a voluntary basis, and all CKM content is open source and freely available under a Creative Commons licence.

The core openEHR building block/knowledge artefact is known as an archetype. To a clinician an archetype is a computable definition of single, discrete clinical concept; yet to a software engineer it is a computable expression of a domain content model in the form of structured constraint statements, and based on a reference model. Both definitions are describing the same computable knowledge artefact and in practice, clinicians drive the development of the archetype and the engineers implement them in software."

CKM status

At time of writing the registered CKM community numbers 433 individuals from 53 countries, with 184 volunteering to participate in archetype reviews and 50 volunteering to translate archetypes once the content is published. (Current user stats are here). It comprises a range of clinicians, health informaticians, software engineers, terminologists, researchers, students, policy makers, and administrators – and is open to anyone to join and participate. No consumers yet, although the models are designed to be used in PHRs as well. You can self-register by clicking on the link in the top right of the CKM screen.

There are over 250 archetypes currently available - most are still draft; some that are currently within the Team Review process; and a small number that have achieved consensus during Team Review of the clinical content and have been published. Others are in development in various projects and national programs from around the world and many will gradually be submitted into the CKM for international review and publication.

The priorities and focus of the current openEHR CKM archetype reviews are on achieving agreement and consensus on the 10 key archetypes that would support healthcare provision in a typical crisis situation.  Effectively these archetypes would contain clinical content that the openEHR community regard as the most important components of any Emergency Summary – the '10 archetypes that could save a life'!

Not surprisingly progress has been steady but a little slower than anticipated. Remember, all participants volunteer, including the editors and this is a relatively new activity. As such we are continually learning and refining the CKM tool and our processes. Most importantly, we are seeking to align the identified critical archetypes with the work that is being done in isolation by many standards groups and national bodies. Under review at the moment are probably the two hardest on which to achieve consensus – Adverse Reactions and the Problem/Diagnosis family. Medication orders is about to commence the review process.

Interestingly, the Adverse Reaction review is currently paused because following it's first review round, where it became clear that Adverse Reaction needs to be considered as part of a larger picture related to the modeling of all safety-related concepts. At present I am endeavoring to tease out the differences and overlap in theory and practice related to Adverse Events; Adverse Reactions; Adverse Drug Reactions; Warnings; Alerts; and Risk plus Adverse Event reporting to statutory authorities – it's complex and I can't see where this has been done previously. In practice, most current EHRs try to mimic the way we record these concepts in paper records, but this is not easy. How we should replicate that critical 'ALLERGIC TO PENICILLIN' scrawled in red felt pen across the front of a paper record, so no-one misses it? To take our EHRs into the future we need a cohesive suite of concept definitions that will support data capture, viewing, querying and inferencing to support clinical decision support. So watch this space, and please let me know if you'd like to join in!

Modeling an entire EHR – is it achievable?

Many will consider that creating and agreeing all the clinical content for an EHR is an impossible task. However let's consider a couple of key things about openEHR:

1. The openEHR archetype is created as 'a maximal data set for a universal use case'. So in other words, everything we can think of about a single clinical concept for use in every possible clinical scenario. In the past we have struggled and fought about the inclusions in minimum data sets, however with a maximum data set everyone's priorities can be included. The innovation of openEHR is in achieving consensus on the data specifications through use of the maximum data set but allowing for clinical diversity and relevance by constraining the maximum data set down to a useful one for each clinical scenario through use of templates. I like to think of this as a little bit of 'magic – a bit like having your cake and eating it too!
2. While there are 350,000+ SNOMED terms, we do not anticipate 350,000 archetypes. In fact 10-20 will comprise most emergency or discharge summaries and as few as 50-100 archetypes could cover most of a typical primary care EHR. Most people are surprised that we need so few archetypes, and the key reason is that each archetype is about a concept, not an archetype per symptom or diagnosis. In fact there is a single symptom archetype and a single diagnosis archetype that will likely cover more than 90% of symptoms and diagnoses, by using a terminology such as SNOMED CT to identify the actual symptom or diagnosis itself. The power of structured content definitions (the archetypes) plus a terminology is a very powerful semantic combination.
3. We have started with the hardest archetypes – those in which nearly every stakeholder and jurisdiction will have an opinion. Once these key 10 archetypes are published, we anticipate that the momentum will increase.

Tim O'Reilly spoke of the Web2.0 being a 'harnessing the collective intelligence' and while in it's early days still, CKM is starting to do just that – to bring together experts from many profession domains, areas of expertise and geographical regions with a common goal. Grassroots clinicians are contributing alongside the technical experts – all contributions are gratefully received and are incorporated into the final published content models.

Please regard this as an open invitation to all to become involved. Self-register, and if you want to become involved in archetype review then 'adopt' the archetype/s of your choice!