Archetype Re-use

Last Thursday & Friday @hughleslie and I presented a two day training course on openEHR clinical modelling. Introductory training typically starts with a day to provide an overview – the "what, why, how" about openEHR, a demo of the clinical modelling methodology and tooling, followed by setting the context about where and how it is being used around the world. Day Two is usually aimed at putting away the theoretical powerpoints and getting everyone involved - hands on modelling. At the end of Day One I asked the trainees to select something they will need to model in coming months and set it as our challenge for the next day. We talked about the possibility health or discharge summaries – that's pretty easy as we largely have the quite mature content for these and other continuity of care documents. What they actually sent through was an Antineoplastic Drug Administration Checklist, a Chemotherapy Ambulatory Care Nursing Intervention and Antineoplastic Drug Patient Assessment Tool! Sounded rather daunting! Although all very relevant to this group and the content they will have to create for the new oncology EHR they are building.

Perusing the Drug Checklist ifrst - it was easily apparent it going to need template comprising mostly ACTION archetypes but it meant starting with some fairly advanced modelling which wasn't the intent as an initial learning exercise.. The Patient Assessment Tool, primarily a checklist, had its own tricky issues about what to persist sensibly in an EHR. So we decided to leave these two for Day Three or Four or..!

So our practical modelling task was to represent the Chemotherapy Ambulatory Care Nursing Intervention form. The form had been sourced from another hospital as an example of an existing form and the initial part of the analysis involved working out the intent of the form .

What I've found over years is that we as human beings are very forgiving when it comes to filling out forms – no matter how bad they are, clinical staff still endeavour to fill them out as best they can, and usually do a pretty amazing job. How successful this is from a data point of view, is a matter for further debate and investigation, I guess. There is no doubt we have to do a better job when we try to represent these forms in electronic format.

We also discussed that this modelling and design process was an opportunity to streamline and refine workflow and records rather than perpetuating outmoded or inappropriate or plain wrong ways of doing things.

So, an outline of the openEHR modelling methodology as we used it:

1. Mind map the domain – identify the scope and level of detail required for modelling (in this case, representing just one paper form)
2. Identify:
   1. existing archetypes ready for re-use;
   2. existing archetypes requiring modification or specialisation; and
   3. new archetypes needing development
3. Specialise existing archetypes – in this case COMPOSITION.encounter to COMPOSITION.encounter-chemo with the addition of the Protocol/Cycle/Day of Cycle to the context
4. Modify existing archetypes – in this case we identified a new requirement for a SLOT to contain CTCAE archetypes (identical to the SLOT added to the EVALUATION.problem_diagnosis archetype for the same purpose). Now in a formal operational sense, we should specialise (and thus validly extend) the archetype for our local use, and submit a request to the governing body for our additional requirements to be added to the governed archetype as a backwards compatible revision.
5. Build new archetypes – in this case, an OBSERVATION for recording the state of the inserted intravenous access device. Don't take too much notice of the content – we didn't nail this content as correct by any means, but it was enough for use as an exercise to understand how to transfer our collective mind map thoughts directly to the Archetype Editor.
6. Build the template.

So by the end of the second day, the trainee modellers had worked through a real-life use-case including extended discussions about how to approach and analyse the data, and with their own hands were using the clinical modelling tooling to modify the existing, and create new, archetypes to suit their specific clinical purpose.

What surprised me, even after all this time and experience, was that even in a relatively 'new' domain, we already had the bulk of the archetypes defined and available in the NEHTA CKM. It just underlines the fact that standardised and clinically verified core clinical content can be re-used effectively time and time again in multiple clinical contexts.The only area in our modelling that was missing, in terms of content, was how to represent the nurses assessment of the IV device before administering chemo and that was not oncology specific but will be a universal nursing activity in any specialty or domain.

So what were we able to re-use from the NEHTA CKM?

• COMPOSITION.encounter
• EVALUATION.adverse_reaction – one instance per adverse reaction included in a adverse reaction list
• EVALUATION.clinical_synopsis
• EVALUATION.problem_diagnosis – one instance per diagnosis included in a problem list
• INSTRUCTION.request-referral – one instance per referral requested
• ACTION.health_education
• ACTION.procedure – with two instances for different purposes

…and now that we have a use-case we could consider requesting adding the following from the openEHR CKM to the NEHTA instance:

• OBSERVATION.story
• CLUSTER.symptom – with multiple instances for each symptom identified

And the major benefit from this methodology is that each archetype is freely available for use and re-use from a tightly governed library of models. This openEHR approach has been designed to specifically counter the traditional EHR development of locked-in, proprietary vendor data. An example of this problem is well explained in a timely and recent blog - The Stockholm Syndrome and EMRs! It is well worth a read. Increasingly, although not so obvious in the US, there is an increasing momentum and shift towards approaches that avoid health data lock-in and instead enable health information to be preserved, exchanged, aggregated, integrated and analysed in an open and non-proprietary format - this is liquid data; data that can flow.

The ultimate PHR?

I've been interested in the notion of a Personal Health Record for a long time. I was involved in the development of HotHealth, which launched at the end of 2000, a not-so-auspicious year, given the dot com crash! By the time HotHealth was completed , all the potential competitors identified in the pre-market environmental scan were defunct. It certainly wasn't easy to get any traction for HotHealth take-up and yet only recently it has been retired. For a couple of years it was successfully used at the Royal Children's Hospital, cut down and re-branded as BetterDiabetes to support teenagers self-manage their diabetes and communicate with their clinicians, but it wasn't sustained.

This is not an uncommon story for PHRs. It is somewhat comforting to see that the course of those such HealthVault and GoogleHealth have also not been smooth and fabulously successful :-)

Why is the PHR so hard?

In recent years I participated in the development of the ISO Technical Report 14292:2012: Personal health records -- Definition, scope and context. In this my major contribution seemed to be introducing the idea of a health information continuum.

However in the past year or so, my notion of an ideal PHR has moved on a little further again. It has arisen on the premise of a health record platform in which standardised health information persists independently of any one software application and can be accessed by any compliant applications, whether consumer- or clinician-focused. And the record of health information can be contributed to by any number of compliant systems - whether a clinical system, a PHR or smartphone app. The focus is on the data, the health record itself; not the applications. You will have seen a number of my previous posts, including here & here!

So, in this kind of new health data utopia, imagine if all my weights were automatically uploaded to my Weight app on my smartphone wirelessly each morning. Over time I could graph this and track my BMI etc. Useful stuff, and this can be done now - but only into dead-end silos of data within a given app.

And what if a new fandangled weight management application came along that I liked better - perhaps it provided more support to help me lose weight. And I want to lose weight. So I add the new app to my smartphone and, hey presto, it can immediately access all my previous weights - all because the data structure in both apps is identical. Thus the data can be unambiguously understood and computed upon within the second app without any data manipulation. Pretty cool. No more data silos; no more data loss. Simply delete the first app from the system, and elect to keep the data within my smartphone health record.

And as I add apps that suit my lifestyle, health needs, and fitness goals etc, I'm gradually accumulating important health information that is probably not available anywhere else. And consider that only I actually know what medicines I'm taking, including over the counter and herbals. The notion of a current medication list is really not in the remit of any clinician, but the motivated consumer! And so if I add an app to start to manage my medications or immunisations this data could be also used across in yet another compliant chronic disease support app for my diabetes or asthma or...

I can gradually build up a record of health information that is useful to me to manage my health, and that is also potentially useful to share with my healthcare providers.

Do you see the difference to current PHR systems?

I can choose apps that are 'best of breed' and applicable to my need or interest.

I'm not locked in to any one app, a mega app that contains stuff I don't want and will never use, with all the overheads and lack of flexibility.

I can 'plug & play' apps into my health record, able to change my mind if I find features, a user interface or workflow that I like better.

And yet the data remains ready for future use and potentially for sharing with my healthcare providers, if and when I choose. How cool is that?

Keep in mind that if those data structures were the same as being used by my clinician systems, then there is also potential for me to receive data from my clinicians and incorporate it into my PHR; similarly there is also potential for me to send data to my clinician and give them the choice of incorporating this into their systems - maybe my blood glucose records directly obtained from my glucometer, my weight measurements, etc. Maybe, one day, even MY current medicine list!

In this proposed flexible data environment we are avoiding the 'one size fits all', behemoth approach, which doesn't seem to have worked well in many situations, both clinical systems or personal health records. Best of all the data is preserved in the non-proprietary, shared format - the beginnings of a universal health record or, at least, a health record platform fully supporting data exchange.

What do you think?

To HIMSS12... or bust!

This blog, and hopefully some others following, will be about my thinking and considerations as I man an exhibition booth at the huge HIMSS12 conference for the first time next month… Well, we’ve committed. We’re bringing some of the key Ocean offerings all across the ocean to HIMSS12 in Las Vegas next month. If it was just another conference, I wouldn’t be writing about it. But this is a seriously daunting prospect for me. I’ve presented papers, organised workshops, and run conference booths in many places over the years – in Sarajevo, Göteborg, Stockholm, Capetown, Singapore, London, Brisbane, Sydney, Melbourne – but this is sooooooo different!

The equivalent conference here in Australia would gather 600-800 delegates, maybe 40-50 exhibition booths. Most European conferences seem to be a similar size, admittedly these are probably with a more academic emphasis, rather than such a strong commercial bent, which might explain some of the size difference. By comparison, last year’s HIMSS conference had 31,500 attendees and over 1000 exhibition booths – no incorrect zeros here - just mega huge!

I can’t even begin to imagine how one can accommodate so many people in one location. I have never even visited HIMSS before – we are relying heavily on second hand reports. You may start to understand my ‘deer in headlights’ sensation as we plan our first approach to the US market in this way.

Ocean's profile is much higher elsewhere internationally. Our activity in the London-based openEHR Foundation and our products/consulting skills have a reasonable profile in Australia and throughout much of Europe; and awareness is growing in Brazil as the first major region in South America. In many ways the US is the one of the last places for openEHR to make a significant impression – there are some pockets of understanding, but the limited uptake is clearly an orthogonal approach to the major commercial drivers in the US at present, however we are observing that this is slowly changing... hence our decision to run the gauntlet!

openEHR’s key objective is creation of a shareable, lifelong health record - the concept of an application-independent, multilingual, universal health record. The specification is founded upon the the notion of a health record as a collection of actual health information, in contrast to the common idea that a health record is an application-focused EHR or EMR. In the openEHR environment the emphasis is on the capture, storage, exchange and re-use of application-independent data based on shared definitions of clinical content – the archetypes and templates, bound to terminology. In openEHR we call them archetypes; in ISO, similar constructs are referred to as DCMs; and, most recently, there are the new models proposed by the CIMI initiative. It’s still all about the data!

So, we’re planning to showcase two products that have been designed and built to contribute to an openEHR-based health record - the Clinical Knowledge Manager (CKM), as the collective resource for the standardised clinical content, and OceanEHR, which provides the technical and medico-legal foundation for any openEHR-based health record – the EHR repository, health application platform and terminology services. In addition, we’ll be demonstrating Multiprac – an infection control system that uses the openEHR models and is built upon the OceanEHR foundation. So Multiprac is one of the first of a new generation of health record applications which share common clinical content.

This will be interesting experience as neither are probably the sort of product typical attendees will be looking for when visiting the HIMSS exhibition. So therein lies one of our major challenges – how to get in touch with the right market segment… on a budget!

We are seeking to engage with like-minded individuals or organisations who prioritise the health data itself and, in particular, those seeking to use shared and clinically verified definitions of data as a common means to:

• record and exchange health information;
• simplify aggregation of data and comparative analysis; and
• support knowledge-based activities.

These will likely be national health IT programs; jurisdictions; research institutions; secondary users of data; EHR application developers; and of course the clinicians who would like to participate in the archetype development process.

So far I have in my arsenal:

• The usual on-site marketing approach:
  • a booth - 13342
  • company and product-related material on the HIMSS Online Buyers Guide; and
  • marketing material – we have some plans for a simple flyer, with a mildly Australian flavour;
• Leverage our website, of course;
• Developing a Twitter plan for @oceaninfo specifically with activity in my @omowizard account to support it, and anticipating for some support from @openEHR – this will be a new strategy for me;
• And I’m working on development of a vaguely ‘secret weapon’ – well, hopefully my idea will add a little ‘viral’ something to the mix.

So all in all, this will definitely be learning exercise of exponential proportions.

To those of you who have done this before, I’m very keen to receive any insight or advice at this point. What suggestions do you have to assist a small non-US based company with non-mainstream products make an impact at HIMSS?

The health information continuum

The final draft version of ISO 251's Technical Report "Personal Health Records — Definition, Scope and Context" has just been sent for formal publication. I was involved in some of the later drafting, especially proposing the notion of a spectrum, or continuum of person-centric health records was. The latest iteration, here:

Healthcare organisations and healthcare systems are accountable for the content of EHRs that they control. Individuals have autonomy over records they choose to keep. However, in between these two strict views of an EHR and a PHR is a continuum of person-centric health records which may have varying degrees of information sharing and/or shared control, access and participation by the individual and their healthcare professionals. 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. Towards the PHR end of the spectrum 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 of this continuum there exist a growing plethora of person-centric health records that operate under collaborative models, combining content from individuals and healthcare professionals 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 professional with specified permissions being granted to the other party.

And the final diagram:

Australia's PCEHR is an evolving example of a person-centric health record aiming for that somewhat scary middle zone of shared responsibility and mixed governance - carrying with it enormous potential for changing the delivery of healthcare and surmounting enormous clinical, technical, cultural and social challenges.

What kind of things should we be considering?

How can we make the PCEHR a successful and vital component of modern healthcare delivery? What features and attributes will ensure that we steer clear of the approaches of previous failed projects and, instead, create some positive traction?

I've considered these issues for many years as I've watched the PHR/EHR domain wax and wane and I keep returning to 3 major factors that need to be considered from both the consumer and the clinician points of view:

• Health is personal
• Health is social
• Liquid data

These are the big brush stroke items that need to be front and centre when we are designing person-centric health records.  Will post some more thoughts soon.

Modelling pregnancy

How to go about using openEHR archetypes to model a shared pregnancy record? Step 1:  Analyse the existing resources; identify each of the discrete clinical concepts that contribute to the whole record.

24 clinical concepts have been identified within this example Pregnancy Health Record.

Step 2: Map clinical concepts to archetypes

Map them to existing archetypes or determine which new ones we need. Determine the state of the existing archetypes – do we need to modify or enhance with additional requirements? Consider all possible use cases for each archetype – the end result will be better if we can be as inclusive as possible for all clinical scenarios.

The archetypes identified for this Pregnancy record are:

Clinical Concept	Comment	Corresponding archetype concept name NOTE: is linked to the actual archetype in a CKM instance
Antenatal Plan	An overarching plan for the patient's antenatal care	Antenatal Plan <INSTRUCTION.antenatal_plan>
Information Provided	Details of each piece of health education information discussed or provided to patient	Information Provided <ACTION.health_education>
Social Summary		Social Summary <EVALUATION.social_summary>
Adverse Reaction List	Adverse Reaction list is made up of multiple Adverse Reaction entries	Adverse Reaction <EVALUATION.adverse_reaction>
Family History List	Family History list is made up of multiple Family History entries	Family History <EVALUATION.family_history>
Diagnosis	Problem lists, whether current or past are made up of multiple Problem/Diagnosis entries – the same data pattern will be used in all instances	Problem/Diagnosis <EVALUATION.problem_diagnosis>
Problem/Diagnosis List
Recent Problem/Diagnosis List
Procedure list	Procedure list is made up of multiple Procedure entries	Procedure <ACTION.procedure>
Smoking consumption		Tobacco use <OBSERVATION.substance_use-tobacco>
Alcohol consumption		Alcohol consumption <OBSERVATION.substance_use-alcohol>
Obstetric Summary		Obstetric summary <EVALUATION.obstetric_summary>
Pregnancy Summary	An evolving summary of key data about a single pregnancy – either current or past	Pregnancy summary <EVALUATION.pregnancy_summary>
Examination Findings		Examination Findings <OBSERVATION.exam> Examination of the uterus <CLUSTER.exam-uterus> Examination of the fetus <CLUSTER.exam-fetus>
Current Medication List	Medication list is made up of multiple Medication instruction entries	Medication instruction <INSTRUCTION.medication>
Medication administered		Medication action <ACTION.medication>
Height		Height/Length <OBSERVATION.height>
Weight		Body weight <OBSERVATION.body_weight>
Body Mass Index		Body Mass Index <OBSERVATION.body_mass_index>
Blood Pressure		Blood Pressure <OBSERVATION.blood_pressure>
Fetal Movements		Fetal Movements <OBSERVATION.fetal_movements>
Fetal heart sounds		Heart rate and rhythm <OBSERVATION.heart_rate>
Urinalysis	The pattern for urinalysis is identical to the pathology test results, and in some cases will be performed in the lab, so the same pattern will be used	Pathology test result <OBSERVATION.pathology_test>
Pathology Test results
Ultrasound results		Imaging examination result <OBSERVATION.imaging_exam>

KEY: Pink archetype names indicate those that are early drafts. Green archetype names indicate those that are reasonably mature – through previous reviews within CKM Red archetype names indicate those yet to be developed.

Step 3: CKM Review

Within CKM each archetype will undergo review rounds by a range of clinicians, terminologists, software engineers, informaticians and other interested experts. The purpose of each review round will be to fine-tune each archetype so that it meets the requirements for each stakeholder group.

CKM Videos:

• CKM Introduction
• CKM Archetype Reviews

Step 4: Create an openEHR template

Once community consensus is reached within CKM, the archetypes will be aggregated and constrained in a template to accurately meet the specific use-case requirements for this particular Pregnancy Health Record. Each bold, black heading in the the following screenshot represents an archetype. The Pregnancy Summary archetype has been opened up to see the details. Black text indicates data elements that will be utilised in this use case; grey text indicates inactive data elements.

Other groups may use the same archetypes aggregated in a different order and constrained in a different way to represent their version of the Pregnancy Health Record. As the data in both Pregnancy Records is being recorded according to the same pattern, dictated by the underlying archetype, the information can be exchanged without ambiguity or loss of meaning.

Archetype quality I

Up until recently clinical content models, such as archetypes, have been regarded as a novelty; watched from the sidelines with interest from many but not regarded as mainstream. However now that they are increasingly being adopted by jurisdictions and used in real systems, modellers need to change their approach to include processes, methodologies and quality criteria that ensure that the models are robust, credible and fit for purpose. There has been some work done identifying quality criteria for clinical models but there is no doubt that establishing quality criteria for clinical content models is still very much in its infancy:

• Kalra D, Tapuria A, Freriks G, Mennerat F, Devlies J (2008). Management and maintenance policies for EHR interoperability resources [36 pages] (Q-REC Project IST 027370 3.3 ). The European Commission: Brussels. (Last accessed May 28, 2011)

• There has been some slowly progressing work in ISO TC 215 - ISO 13972 Health Informatics: Detailed Clinical Models. Recently it has been split into two separate components, not yet publicly available:
• Part 1. Quality processes regarding detailed clinical model development, governance, publishing and maintenance; and
• Part II - Quality attributes of detailed clinical models

Most of the work on quality of clinical models has been based largely on theory, with few groups having practical experience in developing and managing collections of clinical models, other than in local implementations.

In 2007, Ocean Informatics participated in a significant pilot project. The recommendations were published in the NHS CFH Pilot Study 2007 Summary Report. My own analysis, conducted in December 2007, revealed that there were 691 archetypes within the NHS repository. Of these, 570 were archetypes for unique clinical concepts, with the remainder reflecting multiple versions of the same concept. In fact, for 90 unique concepts there were 207 archetypes that needed rationalisation – most of these had only two versions however one archetype was represented in five versions! We needed better processes!

Towards the end of 2007 a small team within Ocean commenced building an online tool, the Clinical Knowledge Manager to:

• function as a clinical knowledge repository for openEHR archetypes and templates and, later, terminology subsets;
• manage the life-cycle of registered artefacts, especially the archetype content – from draft, through team review to published, deprecated and rejected. Also terminology binding and language translations;
• governance of the artefacts.

In July 2008 we started uploading archetypes to the openEHR CKM, including many of the best from the NHS pilot project. Over the following months we added archetypes and templates; recruited users; and started archetype reviews. All activity was voluntary – both from reviewers and editors. Progress has thus been slower than we would have liked and somewhat episodic but provided early evidence that a transparent, crowd sourced verification of the archetypes was achievable.

In early 2010, Sweden's Clinical Knowledge Manager had its first archetypes uploaded.

In November 2010, a NEHTA instance of the CKM was launched, supporting Australia's development of Detailed Clinical Models for the national eHealth priorities. This is where most collaborative activity is occurring internationally at present.

In this context, I have pondered the issues around clinical knowledge governance now for a number of years, and gradually our team has developed considerable insight into clinical knowledge governance – the requirements, solutions and thorny issues. To be perfectly honest, the more we delve into knowledge governance, the more complicated we realise it to be – the challenge and the journey continues; a lot is yet to be solved :)

It is relatively easy to identify the high level processes in the development of clinical knowledge artifacts, each of which requires identification of quality criteria and measurable indicators to ensure that the final artifacts are fit for purpose and safe to use in our EHR systems. The process is similar for both archetypes and templates; plus the Requirements gathering and Analysis components are applicable to any single overarching project as well.

For archetypes:

The harder task is that for each of these steps, there are multiple quality criteria that need to be determined, and for each criterion it will be necessary to be able to assess and/or measure them through identifiable quality indicators.

Ideally a quality indicator is a measurement or fact about the clinical model. In some situations it will be necessary to include additional assessments manually performed by qualified experts.

If an indicator can be automatically derived from the Clinical Knowledge Manager (CKM), it ensures that up-to-date assessments of the models are instantly available as the models evolve (such as this Blood Pressure archetype example), and more importantly, without reliance on manual human intervention. However while assessments that do need to be assessed by an expert human – for example, compliance to existing specifications or standards – add valuable depth and richness to the overall quality assessment, they also add a vulnerability due to the need for skilled human resources to not only conduct the assessment, but to apply consistent methodologies during the assessment; these will be much more difficult to sustain.

Assessment of whether the indicators actually satisfy the quality criteria should also ideally be as objective as possible, however our reality is that it will probably more often be subjective and vary depending on the nature of the archetype concept itself. The process cannot be automated, nor can there be a single set of indicators or criteria that will determine the quality of every archetype. We need to ensure appropriate oversight to archetype development, ensuring that a quality process has actually been followed and utilise quality indicators to determine if the quality criteria have been met - on an archetype by archetype basis.

And it continues on...

Clinical modeling: academic vs practical

In a comment on the previous DCM post,  Gordon Tomes sent a link to an interesting 2009 academic paper by Scheuermann, Ceusters & Smith - Toward an Ontological Treatment of Disease and Diagnosis [PDF] There is a place for this 'pure', academic approach as a means to seek clarity in definitions, but a telling sentence in the paper for me is: "Thus we do not claim that ‘disease’ as here defined denotes what clinician in every case refer to when they use the term ‘disease’. Rather, our definitions are designed to make clear that such clinical use is often ambiguous."

This is totally right, but despite the apparent ambiguity this clinicians still manage :)

The approach for archetypes/DCMs is not to get tied up in these definitional knots unnecessarily but to concentrate on consensus building around the structure of the data. Use of ontologies and definitions are key elements in designing and modelling archetypes but the resulting models should not be based on academic theory but on existing clinical practice and processes. Our EHRs need to represent what clinicians actually need to do in order to provide care. Sometimes we need to be practical and pragmatic. For example, I once challenged a dissenter to build a Blood Pressure archetype based purely using SNOMED codes - the result was a nonsense, a model that he agreed was not useable by clinicians.

The approach to building the Problem/Diagnosis archetype has not been to try to differentiate these two terms pedantically. Many have tried to separate a 'Problem' from a 'Diagnosis' for years with little success - no point waiting for this to be resolved, it probably won't. And even if we did make a theoretical decision on a definition for each, the clinicians would still likely classify the way they always did, not the way the academics or standards-makers would like them to do it!

In the  collaborative CKM reviews for the NEHTA Problem/Diagnosis archetype we have been able to observe that clinicians and other stakeholders have achieved some consensus around the structured data required to represent the concepts of a problem plus the addition of some extra optional data elements to represent formal diagnoses. After completing only four review rounds, the discussion now is focused on finessing the metadata and descriptions, not on debating the structure of the model.

Clinicians may still go round in circles arguing about what constitutes an actual problem vs a diagnosis - for example, some may classify  heartburn as a problem, others as diagnosis. No matter. By using a single model to represent both we can ensure that no matter how heartburn may be labelled by any individual clinician, we can easily query and find the data in a health record, and in addition there is a single common model to be referenced by clinical decision support engines.

A small success, maybe.

openEHR: interoperability or systems?

Thomas Beale (CTO of Ocean Informatics and chair of the Architecture Review Board of the openEHR Foundation) posted these two paragraphs as part of the background for his recent Woland's Cat post - The Null Flavour debate - part I. It is an important statement that I don't want to get lost amongst other discussion, so I've reposted it here:

An initial comment I will make is that there is a notion that openEHR is ‘about defining systems’ whereas HL7 ‘is about interoperability’. This is incorrect. openEHR is primarily about solving the information interoperability problem in health, and it addresses all information, regardless of whether it is inside a system or in a message. (It does define some reference model semantics specific to the notion of ‘storing information’, mainly around versioning and auditing, but this has nothing to do with the main interoperability emphasis.)

To see that openEHR is about generalised interoperability, all that is needed is to consider a lab archetype such as Lipid studies in the Clinical Knowledge Manager. This archetype defines a possible structure of a Lipids lab test result, in terms of basic information model primitives (Entry, History, Cluster, Element etc). In the openEHR approach, we use this same model as the formal definition of this kind of information is in a message travelling ‘between systems’, in a database or on the screen within a ‘system’. This is one of the great benefits of openEHR: messages are not done differently from everything else. Neither is interoperability of data in messages between systems different from that of data between applications or other parts of a ‘system’.

Making sense of 'Severity'

'Severity' is a pretty simple clinical concept, isn't it? I thought so too until I first sat down to create a single, re-usable archetype to represent 'Severity'. I soon discovered that I had significantly underestimated it - the challenge was greater than appeared at first glance.

The archetype development process is usually relatively straight forward - a brain dump of all related information into a mind map, followed by rearranging the mind map until sensible patterns emerge. They usually do, but not this time.

However, the more I investigated and researched, the more I could see that clinicians express severity in a variety of ways, sometimes mixing and 'munging' various concepts together in such a way that humans can easily make sense of it, but it is much harder to represent in a way that is both clinically sensible and computable.

The simple trio of 'Mild', 'Moderate' and 'Severe' is commonly used as a gradation to express the severity of a condition, injury or adverse event. Occasionally these are defined for a given condition or injury, however most often these are subjective and there should be concern that one clinician's mild might be another's moderate. Some also include intermediate terms, such as 'Mild-to-moderate' and 'Moderate-to-severe', but one has to begin to be concerned if these more subtle differences make the judgement even more unreliable, especially if we need to exchange information between systems.

Others add 'Trivial' – is this less than 'Mild'? By how much? Is there a true gradation here? And what of 'Extreme'? Still others add 'Life-threatening' and 'Death' – but are these really expressing severity? Or are they expressing clinical impact or even an outcome?

When exploring severity I found examples of severity expressed by clinicians in many ways. This list is by no means exhaustive:

• Pain – expressed as intensity, often including a visual analogue scale as a means to record it ie rate from 0-10
• Burns – describing percentage of body involved e.g. >80% burns
• Burns – describing the depth of burn by degree e.g. first degree
• Perineal tears – describe the extent and damage by degree – e.g. second degree tear
• Facial tic – expressed in using frequency e.g. occasional through to unrelenting
• Cancer – expressed as a grade, clinical or pathological
• Rash – extent or percentage of a limb or torso covered.
• Minor or major
• Mild, disabling life-threatening
• Relative severity – better, worse etc
• Functional impact – ordinary activity, slight limitation, marked limitation, inability to perform any physical activity
• Short or long term persistence
• Acute or chronic

In practice, clinicians can work interchangeably with any of these expressions and make reasonable clinical sense of it. The challenge when creating archetypes, and other computable models, is to ensure that clinicians can express what they need in a health record, exchange that information safely with other clinicians, allow for knowledge-based activities such as decision support.

In addition, there also needs to be a clear distinction between 'severity' and other, related qualifiers that provide additional context about 'seriousness' of the condition, injury or adverse reaction. These sometimes get thrown into the mix as well, including:

• Clinical impact (or significance);
• Clinical treatment required; and
• Outcomes.

Clinical impact/significance might include:

• None - No clinical effect observed
• Insignificant - Little noticeable clinical effect observed.
• Significant - Obvious clinical effect observed
• Life-threatening - Life-threatening effect observed
• Death – Individual died.

Immediate clinical treatment required might include:

• No treatment
• Required clinician consultation
• Required hospitalisation
• Required Intensive Care Unit

Outcomes might include:

• Recovered/resolved
• Recovering/resolving
• Not recovered/resolved
• Fatal

Then there are those that recovered or the condition resolved but there were other sequelae such as congenital anomalies in an unborn child...

Severity ain't simple.

Over time, and repeatedly returning to it when modelling it in various archetypes including Adverse Reaction and Problem/Diagnosis, I've come to the conclusion that I don't think it is useful or helpful for us to model 'severity' in a single, re-usable archetype. It seems to work better as a single qualifier element within archetypes – then we can bind it in to terminology value sets that are useful for that specific archetype concept and for the use-case context.

When a clinical knowledge pattern is easily identified, creating an archetype is easy - the archetype almost writes itself! So over time I've learned not to try to force the modelling. Some archetypes 'work'; some, like this one, just don't.

Anatomy of an archetype

With this blog I want to establish a simple baseline statement or overview about openEHR archetypes, aggregated from other posts and publications – a reference point if you like – from which we can journey further and in more detail into the issues around clinical modelling using specific archetypes. Archetypes are a strong basis for data liquidity. Create the archetype once, agree through peer-review, re-use when and where required – the foundation for a 'universal health record'.

Definition:

Formal Definition

An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model. openEHR archetypes are based on the openEHR reference model. Archetypes are all expressed in the same formalism. In general, they are defined for wide re-use, however, they can be specialized to include local particularities. They can accommodate any number of natural languages and terminologies. [Archetype Definitions and Principles]

Clinician's 'lay' definition:

An archetype is a structured, computable specification for one single, discrete clinical concept. - much simpler!

Each archetype is a rich health data specification, defined and agreed by the clinicians themselves to ensure that each model is 'fit for clinical purpose'. Collectively these archetypes together can create an electronic health record 'lingua franca', or an example of PCAST report's 'Universal Exchange Language (although archetypes are not limited only to exchange of health information).

Archetypes can be used to model a range of clinical concepts:

• Simple and straightforward - such as 'Blood Pressure'; 'Body Weight'; or 'Symptom'; or
• Complex, compound concepts - such as 'Medication order', or recording how a 'Procedure' has been carried out.

Purpose

Archetypes are:

• Potential 'agents for change' – allowing knowledge-driven EHRs as an orthogonal approach to EHR development.
• The basis for a coherent and consistent approach for the whole continuum of clinical care and related activities:
  • Recording, storing and querying health information in electronic health information;
  • Exchanging health information - the broader the agreement & governance, the greater the potential for interoperability;
  • Data aggregation;
  • Knowledge-based activities; and
  • Comparative data analysis.

Using archetypes requires:

• A change of mindset – no longer silos of data; no longer message and document driven.
• Upfront planning & coordination in development of archetypes, but not necessarily more time
• CLINICIAN LEADERSHIP & ENGAGEMENT
  • To ensure the quality of clinical data in our EHRs
  • To warrant the clinical data is safe & 'fit for purpose'

Design

Each archetype is designed:

• As a maximal data set effectively everything one can think of about a clinical concept in all situations by the consumer and any and all providers. This design intent is pragmatically constrained to be sensible in some situations, however good archetype design will always ensure that the full model can be achieved through nesting of additional archetypes to create the maximal dataset/universal use-case ideal.
• For the 'universal use-case' – for re-use in any and all scenarios, from use at home, to primary care, community care, hospital care, secondary use and for research.

Each archetype needs to represent the variety of data that is required to represent the information required for all aspects of clinical care and related activities, including:

• The ability to capture both free-text vs structured data;
• Normal statements such as "Nil significant" or "NAD";
• Graphable data;
• Images – eg a homunculus, or a surgical diagram;
• Multimedia including photos, video and audio or an ECG wave format;
• Questionnaires, checklists etc

Think about how the clinician may record the data: different clinicians will need differing approaches to recording their health information and the models need to allow for this clinical diversity. Some will prefer to use more free text and others more structure; some need more detail than others; we need to capture current requirements for recording and exchange while keeping in mind what might be best practice in the near and distant future.

The best designers, without a doubt, have a clinical background. I have seen clinicians and non-clinicians given identical clinical content, but the archetypes produces are surprisingly different. Clinician modellers definitely model their domain better than those who are not familiar with clinical practice. They are perhaps better able to envision the fractal nature of medicine and take that in to account in creating archetypes, especially the complex areas which require nesting of archetypes within each other to capture the depth and richness required in the models.

Integration with terminologies such as SNOMED, ICD or LOINC are strategic and important – the structure of an archetype is not enough to represent clinical information adequately, and similarly terminology alone is inadequate. However the combination of terminology within an archetype structure, by naming elements or provision of value sets, is semantically very powerful. There is still considerable work to be done to determine how to represent the information overlap – that which can be expressed either in the archetype structure itself or via terminology. This remains a 'grey zone' and is a pressing area for collaboration or research.

Archetype classes – support clinician's processes

There are four main categories of archetypes that are useful to understand – each corresponding to classes in the openEHR Reference Model.

1.  Compositions – which correspond to commonly used clinical documents, such as 'antenatal visit' or 'care plan'. 2.  Sections – these are effectively used to assist with human navigation within EHRs and correspond to document headings, for example 'antenatal examination' or 'summary'.

3.  Entries – these are the most common and are fundamental building blocks of EHRs. There are four main types of Entry archetypes:

• Observations – recording measurable or observable data e.g. blood pressure, symptoms or weight;
• Evaluations – recording clinically interpreted findings e.g. adverse event, diagnosis or assessment of risk;
• Instructions – recording the initiation of a workflow process, such as a medication order or referral;
• Actions – recording clinical activities e.g. procedure or medication administration. Actions complement the instruction and can record the ensuing state of the instruction, such as 'completed' or 'cancelled'.

4. Clusters

Lifecycle & Governance

The Clinical Knowledge Manager (CKM) – www.openEHR.org/knowledge - is an international, online clinical knowledge repository under the auspice of the openEHR Foundation that provides:

• Access to a library of cohesive archetypes and related knowledge artefacts;
• Peer review, life cycle management & publication process via a Web 2.0 approach for clinical content, terminology binding, terminology reference set binding and translations;
• Clinical Knowledge governance underpinned by a digital asset management system and providing:
  • Provenance, audit trails, validation checking
  • Release sets for implementation

Archetypes are freely available under a Creative Commons license.

Use

The need for EHRs to be able to represent clinical diversity is absolutely underrated. Existing EHR systems corral clinicians into certain types of recording etc, but for safety we need more diverse ways for clinicians to record what they need for patient care, and also to ensure that what is exchanged is appropriate for the patient and their individual circumstances. A 'one size fits all' document approach to emergency summaries or messages can be potentially unsafe. Elderly, pregnancy, chronic disease, paediatrics are extremely common examples where there are specific additional requirements needed to summary data sets

Templates are computable specifications for a specific clinical scenario or use-case. The openEHR paradigm takes the governed and agreed archetypes from CKM and creates clinically useful specifications that can be implemented in systems by:

• Aggregating the necessary archetypes together; and
• Constraining the maximal dataset archetypes so that only relevant data elements are active.

Examples include all clinical content required for a specific Message, Document, Clinical consultation or Report e.g. a histopathology report, a referral, an antenatal visit or a discharge summary.

In this way we can, in colloquial terms, 'have our cake and eat it too'. At the same time, CKM ensures tight clinical knowledge governance, yet templates allow for expression of clinician diversity.

Benefits

Archetypes provide a 'glide path' to knowledge-level interoperability of health information. They can:

• Bootstrap new application development – a source of agreed clinical content, avoid re-inventing the wheel for each vendor, organisation or project;
• Provide a forward 'roadmap' for existing applications – supporting gradual transition from proprietary silos to common data representations, perhaps via mapping to common messages as an interim step;
• Support data integration – the means to migrate valuable silos of legacy data to a common, re-usable representation
• Enable data aggregation & comparative analysis – the basis for ensuring 'apples' are 'apples', not 'oranges';
• Simplify messaging – keep message content consistent with EHR content;
• Enable knowledge-based activities eg Clinical Decision Support Systems – consistent & coherent; create once, re-use in all systems.

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.

Can clinicians agree?

There have been a number of robust discussions in recent weeks around the claim that clinicians achieve consensus around computable definitions for clinical content. All discussions have been with MDs, some with substantial experience in various international standards organisations. All have been extremely sceptical...

The first challenge: "—What is a heart attack?” - and the response, —“5 clinicians, 6 answers” – and they are probably very accurate!

The second: —“What is an issue vs problem vs diagnosis?” - I'm told that this has been an unresolved issue in HL7 for 5 years+!

—And the third, from an obstetrician: “The midwives want all this rubbish that we don’t” - perhaps an unfortunate way of expressing the absolutely correct need for different clinicians to have screens presented that are relevant to the patient and the immediate clinical task at hand. —Different clinicians have different needs.

—However these are all essentially HUMAN PROBLEMS! Issues about communications, synonyms, value sets, screen display/layout. IT will not solve these issues - as always, the clinicians need to work out the issues amongst themselves. So where CAN we achieve consensus?

Within the openEHR Clinical Knowledge Manager environment we are gaining some traction in achieving clinician agreement to the structure required to define clinical concepts as archetypes – the ‘first principles’ of clinical concepts, if you like. The approach is inclusive of everyone's needs and requirements, rather than requiring an arbitrary decision on the minimum data set or a priority data set - so we aim, as best we can, for a maximum data set.

For example, the framework to express a Diagnosis is largely not contentious:

• Diagnosis name
• Status
• Date of initial onset
• Age at initial onset
• Severity
• Clinical description
• Anatomical location
• Aetiology
• Occurrences
• Exacerbations
• Related problems
• Date of Resolution
• Age at resolution
• Diagnostic criteria

And for a Symptom:

• Symptom name
• Description
• Character
• Duration
• Variation
• Severity
• Current intensity
• Precipitating factors
• Modifying factors
• Course
• Aetiology
• Occurrences
• Previous episodes
• Associated symptoms

This notion of achieving clinician (and other domain expert) consensus and standardisation of clinical concepts is a major focus of the openEHR archetype work.

Bear in mind that while agreement can be achieved on the clinical content structure, this is only the first step in ensuring that clinicians are able to enter, retrieve and exchange meaningful clinical data.

So if we can achieve consensus around these archetypes, do clinicians then have to agree on a standard Discharge Summary or Antenatal Record or Report? The answer: only if is useful to do so. Clinical diversity can be allowed if the archetype pool is stable & governed/managed. By tightly governing the archetypes at international or national level, these are effectively the common 'lingua franca' that enables sharing of health information.

Template creation is the next openEHR layer - these aggregate the archetypes together to represent the requirements for a specific clinical activity and then constrain them down from their fully inclusive state to something that is 'fit for use' for a given clinician in a given clinical situation. Terminology subsets are also integrated in appropriate places into the archetypes (sometimes) and templates (usually) to round out the expressiveness needed by computable clinical models in clinical care - neither the structure nor the terminology can do this in isolation.

Once a critical mass of these archetypes are published we will be able to support a breadth clinical diversity across eHealth projects - the need for rigid, inflexible messages and documents to support any health information exchange has been largely overcome. Clinicians will only need to agree these types of messages or documents where there is a measurable benefit for doing so, and at all other times they can focus on ensuring that they express their archetype-based clinical records as flexibly as they need to for patient care. Sure, the human factors remain unresolved - but not even the most perfect EHR will solve these issues!

So can clinicians agree? Yes! It is happening in many areas related to data structure, creating a solid framework for our electronic health records. Archetypes are the tightly managed building blocks; templates enable safe and flexible expression of clinical and patient records - allowing the best of both worlds, both governance AND clinical diversity to flourish... and the clinicians are finally able to actively participate in shaping their EHRs.

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]

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

Gimme an… uhr?

What do we have? You can have all the messages, connect-a-thons and profiles that you like - certainly you will achieve short- to medium-term connectivity wins but it is not enough. It is not sustainable and clinicians want and need to share relevant data when it is needed. Predetermined messages and documents will be a great start, but it's not enough.

You can invest huge resources in terminology - we definitely need it - but terminology in isolation is also not enough.

You can demand all the 'damn data' that you want, but non-standardised data will still largely not be computable - largely limited to read-only access.

What do we want?

We hear talk about:

• shared electronic health records;
• semantic interoperability; and
• health data liquidity.

Essentially these phrases describe different aspects of the same 'elephant in the room'; just using different jargon...

We expect our healthcare professionals to be able to safely exchange important health information. To have the right health information available at the right place at the right time. To prevent us repeating our health histories ad nauseum. In fact a huge percentage of patients assume that we can already do this! But we can't... yet. Shared health records are not easy.

What do we need?

A single data-driven "universal health record", an uhr! And please note the deliberate lack of capitals.

What on earth is an uhr, I hear you quite reasonably ask...? A uhr is simply a non-proprietary pool of standardised health data which can be used for any purpose we want - PHR, EHR, EMR, SEHR, IEHR, research, epidemiology, reporting & stats, shared care, clinical decision support & more. There is no particular EHR application associated with it; in fact it works with any and every software program, vendor and healthcare provider.

The key (and I say it yet again)... it's. all. about. the. data.

In addition, and supported by:

• Collaboration at international, national, jurisdictional or organisation level to share and re-use the clinical data definitions, so that our health information can similarly be shared.
• Clinicians driving the clinical content definitions - reflecting the information they need for recording health care for themselves and their patients, ensuring that EHRs are 'fit for purpose'. Terminology integrated with these structured clinical content definitions to unambiguously define the building blocks of the health record.

As a result:

• Message structures required for data exchange become more about the wrapper and less about content - much easier to negotiate and maintain.
• Vendors no longer have clinicians locked-in to proprietary data silos
• Tools used to do 'clever stuff' with our data need only to be built once to conform to these agreed clinical data definitions - think decision support, reporting, data repositories, and integration. Now that takes away a lot of the barriers we strive to overcome!
• Data in a common format can be exchanged between systems - data liquidity becomes a reality, flowing to where it is needed and according to authorisation and access permissions.

Gimme a universal health record. Gimme my damn, um,... uhr, and let my data flow...

And so,  I archetype;-)

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

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?

PHRs: still a powerful grassroots approach to eHealth

In 1999 four clinicians and an ex-CIO gathered around my kitchen table and week by week we hatched a plan for a Personal Health Record (PHR) which we hoped could revolutionise healthcare. At that time a PHR was not at all mainstream. Very few clinicians we spoke to thought it was a good idea at all. Many held a very paternalistic view that patients were not capable to handle their health information, and that a PHR would not ever be trusted as a useful resource (- for some reason a verbal a history was acceptable but a patient entered record of some sort was not)! Patients were also pretty passive and had to be convinced that they could be supported to manage their health information in a similar way that they managed their finances! In January 2000, those last heady days of the dot-com era we started development in earnest, then rode the rollercoaster and navigated the fallout of the dot-com crash. HotHealth was launched in November 2000. My clinical colleagues were still not very enthusiastic about the concept. The business model was not easy. Large companies, health insurers, hospitals, pharmaceutical companies - everyone could see how a PHR would be 'useful', but none would commit. The funding dried up and it/we were acquired by listed company in 2002.

In the US, there were a fair number of PHRs in 2000, maybe even as many as 50. DrKoop.com (now apparently HealthCentral) was the clear leader at the time; WebMD is probably the only significant one remaining. Our annual market research for competitors showed a huge turnover - PHRs were appearing and disappearing at a great rate!

But the evidence was starting to come in and support the concept - Kate Lorig's work at Stanford on supported self-management in arthritis was working well on paper and face-to-face. We applied some of these principles to HotHealth plus health summaries, prevention plans, wellness promotion, quality health information etc - the kinds of features we are used to seeing in PHRs now.

Well, HotHealth still exists and has had some modest success, mostly in the spin off of a PHR for older children and teenagers with insulin dependent diabetes which ran between 2003 and 2005 - Betterdiabetes - but it never blossomed as I had hoped. Was it the timing? Was it the business model? Was Australia too small a market. Yes to all of these, and much more - it was harder than we anticipated.

In 2005 I was asked to write a commentary in Australian Health Review - "The patient’s memory stick may complement electronic health records"(PDF of full text). Re-reading it now, I can't help but be disappointed that not a lot has really changed in terms of integration and data exchange between clinicians and patients. We have made some small progress, but I thought the revolution would have happened by now.

Amusingly I think that my final paragraph in that commentary, written back in September 2005, still stands true.

"A grassroots push by consumers wishing to hold, own and manage their own health information has the potential to make relatively quick, inexpensive and significant changes to the way healthcare is delivered, to support and encourage consumer input to their own health information record, and kick-start electronic health record development in Australia. And eventually when our individual PHRs evolve to amalgamate and integrate with the HealthConnect* implementation, we will all be beneficiaries of an integrated and interoperable health system, meeting the needs of all participants in a timely manner, and most importantly enhancing health outcomes, and minimising risk."

It's just been a longer journey that I first thought!

Reflecting today, I think that those four words in bold - "grassroots push by consumers" - are important. Health care consumers are now better educated and equipped than ever before to decide what it is that they want from eHealth. Let's complement the top-down national program approach with a powerful, bottom-up, consumer-driven kickstart to eHealth!

More than just requesting our data in a readable format, more than collecting a heap of printed pages or folders of pdfs, we should be requesting our data be in a format that we can do something with, data that we can actually re-use. Think of all the little bits of health information that have been created and left behind after each consultation with your family doctor and at each hospital visit. And of course don't forget your dentist and physio, your naturopath who also prescribes for you nor the doctor you saw only once while on holiday in some far off place. Think of what we could do with all that data; if we could only aggregate all of these snippets of information together. The PHR is the most likely place for our fragmented data to come together; the result being a broader, deeper and richer record than could be achieved by any one provider!

I still firmly believe that Personal Health Records have the potential to transform the way we deliver health care. It may take longer than we all anticipate but the PHR is a very powerful grassroots approach to eHealth. Be patient;-)

*HealthConnect was Australia's eHealth program at the time - now totally MIA and no evidence of it exists online!

Why Is The Shared EHR So Hard?

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

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

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

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

Let's explore some of these issues:

1. Technical

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

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

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

2. Human interaction and activities

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

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

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

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

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

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

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

3. Information exchange

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

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

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

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

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

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

Acknowledgments: Dr Sam Heard and Dr Hugh Leslie