"We have the capability!"

We have had the technology for a purpose-built openEHR-compliant 'plug & play' platform for some time; standalone applications have been built, but just recently it appears that the practical reality of an multi-application platform is also about to happen. "We have the technology. We have the capability..." Stay tuned.

...Reminds me of my 1970's hero, Steve Austin, the Six Million Dollar Man. With apologies to Steve:

"We have the technology. We have the capability to make the world's first universal health platform. openEHR will be that platform. Better than ever before. Robust health data...application independent...semantically interoperable!"

[youtube http://www.youtube.com/watch?v=K7zNY0I5JNI&w=480&h=360]

Preserving health data integrity

How valuable do we really think health data is? How seriously do we take our responsibility to preserve the integrity of our health data? Probably not nearly as much as we should.

Consider the current situation of most clinicians or organisations when purchasing a clinical EHR system. What do they look for? Many possible answers are obvious, but there is one question that I suspect very few are asking. How many consider what data they will be able to export and convert to another format, preserving the current data integrity, at the end of the typical 5-10 year life span of the application? Am I wrong if I suggest it is not many at all?

Despite all the effort that we clinicians put into entering detailed data to create a quality health record we don't seem to often consider the " What next?" scenario. How much and precisely what data will we be able to safely extract, export, transfer or convert into the next, inevitable, clinical system? Ironically, we are simultaneously well aware that clinical systems have a limited technical life span.

Any and all of the health data in a health record is an incredibly valuable asset to the holder, to the patient (if these are not the same entities) and to those downstream with whom we may share it in the future - in terms of $$ invested; manpower resources used to capture, store, classify, update and maintain it; and not least the future value that comes from appropriate and safe clinical decisions being made upon the integrity of existing EHR data.

Yet we don't seem to consider it much... yet. However, as more clinicians are creating increasing amounts of isolated pockets of health data, we should be thinking about it very hard.

Every time we change systems we put our health data at risk - risk of absolute data loss and risk of possible corruption during the conversion. The integrity of health data cannot be guaranteed each time it is ported into a new system because current methods always require some kind of intervention - mapping, transformations, tweaking, 'cleaning', etc. Small errors can creep in with each data manipulation and which over time, can compromise the safety and value of our health data. On principle we know that the data should not be manipulated, but being limited by our traditional approach to siloed EHR applications, we have previously had little choice.

We need to change our approach and preserve the integrity of our health data at all costs. After all it is the only reason why we record any facts or activity in an electronic health record  - so we can use the data for direct patient care; share & exchange the data; aggregate and analyse the data, and use the data as the basis for clinical decision support.

We should not be focused on the application alone.

Apps will come and go, but we want our health data to persist - accurate and safe for clinical use - beyond the life span of any one clinical software application.

I've said this before, but it's worth saying many times over:

It's. all. about. the. data.

One of the key benefits of the openEHR paradigm is that the data specifications (the archetypes) are defined independently of any specific clinical system or application; are based on an open EHR architecture specification; and are publicly available in repositories such as the Clinical Knowledge Manager. It means that any data that is captured according to the archetype specification is directly usable by any and all archetype-compliant systems. Plus the data is no longer hard-wired into a proprietary application so that it is orders of magnitude easier to accurately share or transfer health data than it has before.

Clinical system vendors that don't directly embrace the archetype-technology may still 'archetype-aware', and can choose to use the archetype specifications as a means to understand the meaning of existing archetyped data and integrate it appropriately into their systems. Similarly they can map from their non-openEHR systems to the archetype specifications as a standardised method for data export and exchange.

The openEHR paradigm enables potential for archetype-compliant systems to share the same archetyped data repository - along the lines of an Apple platform 'plug & play' approach, with applications being added, removed or updated to suit the needs of the end-users, while the data persists intact. No more data conversions needed.

Adapted from Martin van der Meer, 2009

Now that's good news for our health data.

CIMI progress...

Just spreading the news... The Clinical Information Modelling Initiative met again recently and the minutes are now available from the early but rapidly evolving CIMI wiki site - http://www.cimiwiki.org

Intro from the latest CIMI minutes:

CIMI held its 5th group meeting in San Antonio from January 12 – 14, 2012. Over 35 people attended in person with an additional 5 participants attending via WebEx.

At this meeting, the group:

  • Established the criteria for membership and the process for adding members to the CIMI group
  • Authorised an interim executive committee
  • Determined a tentative schedule of meetings for 2012
  • Moved forward with the definition of the modeling framework
  • Formalized two task forces to begin the modeling work so that example models can be presented at the next meeting
  • Recognized the formation of a Glossary Group (lead to be announced)
  • Agreed to plans for utilizing existing tools to rapidly develop and test a candidate reference model and to create a small group of example CIMI models that build on the reference model work

Full Minutes are here

Are we there yet?

No, but we are definitely moving in the right direction... Conversations are happening that were uncommon generally, and downright rare in the US only 18 months ago. I've been rabbiting on for some time about the need for a 'universal health record - an application-independent core of shared and standardised health information into which a variety of 'enlightened' applications can 'plug & play'; thus breaking down the hold of the proprietary and 'not invented here' approach of proprietary clinical applications with which we battle most everywhere today.

So it was pleasing to see Margalit Gur-Arie's recent blog post on Arguments for a Universal Health Record. While I'm not convinced about the reality a single database (see my comments at the end of Margalit's post), I wholeheartedly endorse the principle of having a single approach to defining the data - this is a very powerful concept, and one that may well become a pivotal enabler to health IT innovation.

In addition, Kevin Coonan has started blogging in recent days - see his Summary of DCMs regarding principles of Detailed Clinical Models (aka DCMs). Now I know that Kevin's vision for an implementable HL7 DCM is totally different to the openEHR DCMs (=archetypes) that I work with. But we do agree on the basic principles about the basic attributes of these models that he has outlined in his blog post - it is quite a good summary, please read it.

Now these two bloggers are US-based - and this is significant because in the US there has been a huge emphasis on connecting between systems and exchange of document-based health information up until recent times. I view their postings as indicative of a growing trend toward the realisation that standardisation of clinical content is a necessary component for a successful health IT ecosystem in the (medium-longterm, sooner the better) future.

Note that "Detailed Clinical Models", is the current buzz phrase for any kind of model that might be standardised and shared but is also used very specifically for the HL7 DCMs currently in the midst of an interminable ballot process and the Australian national program's DCMs, which are actually openEHR archetypes being used as part of their initial specification process. "Detailed Clinical Models" is being used in many conversations rather blithely and with many not fully understanding the issues. On one hand it is positively raising awareness of our need to standardise content and on the other hand, it is confusing the issue as there are so many approaches. See my previous post about DCMs - clarifying the confusion.

It is worth flagging that there has been considerable (and I would also venture to say, rather premature) effort put in by a few to formalise principles for DCMs in the draft ISO13972 standard (Quality Requirements and Methodology for Detailed Clinical Models), currently out for ballot. My problem with this ISO work is that the DCM environment is relatively immature - there are many possible candidates with as many different approaches. It is also important to make clear that having multiple DCMs compliant with generic principles outlined in an ISO standard may mean that the quality of our published silos of "DCM made by formalism X" and "DCM made by formalism Y" models might be of higher quality, but it definitely will not solve our interoperability issues. For that you need a common reference model underpinning the models or, alternatively, a primary reference model with known and validated transformations between clinical model formalisms.

The more recent evolution of the CIMI group is really important in this current environment. It largely shares the principles that Kevin, openEHR and ISO13972 espouse - creation of standardised and shareable clinical content models, bound sensibly to terminology, as the basis for interoperability. These CIMI models will be computable and human readable; they will be based on a single Reference Model (yet to be finalised) and common data types (also yet to be finalised), and utilising the openEHR Archetype Definition Language (ADL) 1.5 as its initial formalism. Transformations of the resulting clinical models to other formalisms will be a priority to make sure that all systems can consume these models in the future. All will be managed in a governed repository and likely under the auspice of some kind of an executive group with expert teams providing practical oversight and management of models and model content.

Watch for news of the CIMI group. It has a influential initial core membership that embraces multiple national eHealth programs and standards bodies, plus all the key players with clinical modelling expertise - bringing all the heavy lifters in the clinical modelling environment into the same room and thrashing out a common approach to semantic interoperability. They met for 3 days recently prior to the HL7 meeting in San Antonio. The intent (and challenge) is to get all of this diverse group singing from the same hymn book! I believe they are about to launch a public website to allow for transparency which has not been easy in these earliest days. I will post it here as soon as it is available.

Maybe the planets are finally aligning...!

I have observed a significant change in the mind sets, conversations and expectations in this clinical modelling environment, over the past 5 years, and especially in the past 18 months. I am encouraged.

And my final 2c worth: in my view, the CIMI experience should inform the ISO DCM draft standard, rather than progressing the draft document based on largely academic assumptions about clinician engagement, repository requirements and model governance - there is so much we still need to learn before we lock it into a standard. I fear that we have put the cart before the horse.

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?

Clinical Knowledge Repository requirements

I've been hearing quite a lot of discussion recently about Clinical Knowledge Repositories and governance. Everyone has different ideas - ranging from sharing models via a simple subversion folder through to a purpose-built application managing governance of combinations of versioned knowledge assets (information models, terminology reference sets, derived artefacts, supporting documentation etc) in various states of publication. It depends what you want to achieve, I guess. In openEHR it became clear very quickly that we need the latter in order to provide a central resource with governance of cohesive release sets of assets and packages suitable for organisations and vendors to implement.

In our experience it is relatively simple to develop a repository with asset provenance and user management. What is somewhat harder is when you add in processes of collaboration and validation for these knowledge assets - this requires development of review and editorial processes and, ideally, display transparency and accountability on behalf of those managing the knowledge artefacts.

The most difficult scenario reflects meeting the requirements for practical implementation, where governance of configurable groups of various assets is required. In openEHR we have identified the need for cohesive release sets of archetypes, templates and terminology reference sets. This can be very complicated when each of the artefacts are in various states of publication and multiple versions are in use in 'on the ground' implementations. Add to this the need for parallel iso-semantic and/or derived models, supporting documents, and derived outputs in various stages of publication and you can see how quickly chaos can take over.

So, what does the Clinical Knowledge Manager do?

  1. CKM is an online application based on a digital asset management system to ensure that the models are easily accessed and managed within a strong governance framework.
  2. Focus:
    1. Accessible resource - creation of a searchable library or repository of clinical knowledge assets - in practice, a ‘one stop shop’ for EHR clinical content
    2. Collaboration Portal - for community involvement, and to ensure clinical models that are ‘fit for clinical use’
    3. Maintenance and governance of all clinical knowledge and related resources
  3. Processes to ensure:
    1. Asset management
      1. uploading, display, and distribution/downloading of all assets
      2. collaborative review of primary* assets  to validate appropriateness for clinical use
        1. content
        2. translation
        3. terminology binding
      3. publication life cycle and versioning of primary assets
      4. primary asset provenance, differential and change log
      5. automatic generation of secondary**/derived assets or, alternatively, upload and versioning when auto generation is not possible
      6. upload of associated***/related assets
      7. development of versioned release sets of primary assets for distribution
      8. identify related assets
      9. quality assessment of primary assets
      10. primary asset comparison/differentials including compatibility with existing data
      11. threaded discussion forum
      12. flexible search functionality
      13. coordinate Editorial activity
      14. share notification of assets to others eg via email, twitter etc
    2. User management
    3. Technical management
    4. Reporting
      1. Assets
      2. Users
      3. Editorial activity support

In current openEHR CKM the assets, as classified above, are:

  1. *Primary assets:
    1. Archetypes
    2. Templates
    3. Terminology Reference Set
  2. **Secondary assets:
    1. Mindmaps
    2. XML transforms
    3. plus ability to add transforms to many other formalisms, including CDA
  3. ***Associated assets:
    1. Design documents
    2. References
    3. Implementation guides
    4. Sample data
    5. Operational templates
    6. plus ability to add others as identified

While CKM is currently openEHR-focused - management of the openEHR artefacts was the original reason for it's development - with some work the same repository management, collaboration/validation and governance principles and processes, identified above, could be applied for any knowledge asset, including all flavors of detailed clinical models and other clinical knowledge assets being developed by CIMI, or HL7 etc. Yes, CKM is a currently a proprietary product, but only because it was the only way to progress the work at the time - business models can always potentially be changed :)

It will be interesting to see how thinking progresses in the CIMI group, and others who are going down this path - such as the HL7 templates registry and the OHT proposed Heart project.

We can keep re-inventing the wheel, take the 'not invented here' point of view or we can explore models to collaborate and enhance work already done.

Why the buzz about CIMI?

With the recent public statement from the Clinical Information Modelling Initiative (CIMI) my cynical heart feels a little flutter of excitement. Maybe, just maybe, we are on the brink of a significant disruption in eHealth. Personally I have found that the concept of standardising clinical content to be compelling and hence my choice to become involved in development of archetypes. During my openEHR journey over the past 5 or so years it has been very interesting to watch the changing attitudes internationally - from curiosity and 'odd one out'  through to "well, maybe there's something in this after all".

And now we have the CIMI announcement...

So what has been achieved? What should we celebrate and why?

At worst, we have had a line drawn in the sand: a prominent group of thought leaders in the international health informatics domain have gathered and, through a somewhat feisty process, recognised that a collaborative approach to the development of a single logical clinical content representation (the CIMI core reference model) is a desirable basis for interoperability across formalisms. Despite most of the participants having significant investment and loyalty to their own current methodology and flavor of clinical models, they have cast aside the usual 'not invented here' shackle and identified a common approach to an initial modelling formalism from which other models will be derived or developed. Whether any common clinical content models are eventually built or not, naming of ADL 1.5 and the openEHR constraint model as the initial formalism is a significant recognition of the longstanding work of the openEHR Foundation team - the early specifications emerged nearly 20 years ago.

At its idealistic best, it potentially opens up a new chapter for health informatics, one that deviates from the relatively safe path of incremental innovation that we have followed for so many years - the reliance on messages/documents/hubs to enable us to exchange health information. There is an opportunity to take a divergent path, a potentially transformational innovation, where the focus is on the data itself, and the message/document/EHR becomes more simply just the receptacle or vehicle for the data. It could give us a very real opportunity to store lifelong health information; simplify data exchange (whether by messages or documents), aggregation, querying and analysis; and support knowledge-based activities such as decision support - all because we will (hopefully) have non-proprietary, common, agreed and fully defined models of clinical content and known transformations between each formalism.

Progress during the next few months will be telling. In January 2012, immediately before the next HL7 meeting in San Antonio, the group will gather again to discuss next steps.

There is a very real risk that despite best intentions all of this will fade away to nothing. The list of participating organisations, including high profile standards organisations and national eHealth programs, is a veritable Who's Who of international health IT royalty, so they will all come with their own (organisational and individual) work experience, existing modelling resources, hope, enthusiasm, cynicism, political agendas, bias and alliances. It could be enough to sink the work of this fledgling group.

But many are battle-weary, having been trudging down this eHealth path for a long time - some now gradually realising that the glacial incremental innovation is not delivering the long-term sustainable answers required for creating 21st Century EHRs as they had once hoped. So maybe this could be the trigger to make CIMI fly!

I think that CIMI is a very bright spark on the health IT horizon. Let's hope that with the right management and governance it can be agilely nurtured into a major positive force for change. And in the future, when its governance is mature and processes robust, we can integrate CIMI into the formal standards processes.

Best of luck, CIMI. We're watching!

CIMI - initial public statement

The following public statement has been released by the Clinical Information Modelling Initiative today:

Public release

The Clinical Information Modeling Initiative is an international collaboration that is dedicated to providing a common format for detailed specifications for the representation of health information content so that semantically interoperable information may be created and shared in health records, messages and documents. CIMI has been holding meetings in various locations around the world since July, 2011. All funding and resources for these meetings have been provided by the participants. At its most recent meeting in London, 29 November - 1 December 2011, the group agreed on the following principles and approach.

Principles

  1. CIMI specifications will be freely available to all. The initial use cases will focus on the requirements of organisations involved in providing, funding, monitoring or governing healthcare and to providers of healthcare IT and healthcare IT standards as well as to national eHealth programs, professional organisations, health providers and clinical system developers.
  2. CIMI is committed to making these specifications available in a number of formats, beginning with the Archetype Definition Language (ADL) from the openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from the Object Management Group (OMG) with the intent that the users of these specifications can convert them into their local formats.
  3. CIMI is committed to transparency in its work product and process.

Approach

  • ADL 1.5 will be the initial formalism for representing clinical models in the repository.
    • CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
    • Modifications will be required and will be delivered by CIMI members on a frequent basis.
  • A set of UML stereotypes, XMI specifications and transformations will be concurrently developed using UML 2.0 and OCL as the constraint language.
  • A Work Plan for how the AOM and target reference models will be maintained and updated will be developed and approved by the end of January 2012.
    •  Lessons learned from the development and implementation of the HL7 Clinical Statement Pattern and HL7 RIM as well as from the Entry models of 13606, openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) initiative will inform baseline inputs into this process.
  • A plan for establishing a repository to maintain these models will continue to be developed by the group at its meeting in January.

Representatives from the following organizations participated in the construction of this statement of principles and plan:

Further Information:

In the future CIMI will provide information publicly on the Internet. For immediate further information, contact Stan Huff (stan.huff@imail.org)

CIMI & beyond...

The Clinical Information Modelling Initiative (#CIMI) is currently meeting in London. It comprises a significant group of healthcare IT stakeholders and was formed some months ago as an initiative by Dr Stan Huff. After a number of face to face meetings and email list exchanges, the intent is that at the end of this 3 day meeting there will be an agreed decision on a common clinical content modelling formalism/methodology for our Electronic Health Records. For background, from Sam Heard’s email to the openEHR email list on November 2, 2011:

The main topic I want to address is the international initiative to develop a standardised clinical modelling methodology. This has some IHTSDO secretarial support and is led by Dr Stan Huff of Intermountain Healthcare, a former HL7 Chairperson and co-founder of LOINC, who has been advocating a model-based approach for many years. The current approach at Intermountain has been influenced by openEHR and uses a two-level modelling approach. Stan has established a leadership group through trust and reputation, which includes a variety of agencies who have been working in the area and national eHealth programs or major initiatives who are interested in consuming the models. It has grown out of an HL7 Fresh Look initiative and is currently known as the Clinical Information Modelling Initiative (CIMI).

The group has committed to determining a single formalism for clinical modelling and ADL and openEHR are on the list of alternatives which is as follows:

  • Archetype Object Model/ADL 1.5 openEHR
  • CEN/ISO 13606 AOM ADL 1.4
  • UML 2.x + OCL + healthcare extensions
  • OWL 2.0 + healthcare profiles and extensions
  • MIF 2 + tools HL7 RIM – static model designer

Proponents of the five different approaches have been presenting to members of the group, who have a variety of experience in these matters. Fourteen organisations will cast a vote on the formalism to use including openEHR, Singapore, UK NHS, Results 4 Care, HL7, Canada Infoway, 13606 Association, Tolven, CDISC, GE/Intermountain, US Departments, CDISC, SMArt and Mitre.

At the preliminary vote, held recently on November 20, the two most popular options were openEHR ADL 1.5 and UML.

Today CIMI will vote on a proposal for either ADL 1.5 or UML to be adopted as the initial common formalism for use, and determine a road map for coordinated development of semantically interoperable clinical models into the future. The potential impact of this is huge and exciting. It could be a disruptive change in health IT.

We hold our collective breath!

Australia's PCEHR Challenge

Are you planning to participate when the Personally Controlled Health Record goes live in July 2012?

I've certainly been pondering what would make me interested to try it, in the first instance, and then to keep using it in an ongoing manner – in my roles as both a Clinician and as a Consumer.

In my previous blog post we can see the PCEHR positioned part way between a fully independent Personal Health Record and the Clinician's Electronic Health Record – a hybrid product bridging both domains and requiring an approach that cleverly manages the shared responsibility and mixed governance model.

The scope of the proposed PCEHR is outlined in the Concept of Operations document. A recent presentation [PDF] given at the HIC2011conference provides a summary of expected functionality.

Recently we've all seen many analyses about the demise of Google Health and over the past decade we've been able to see the difficulties faced by many Personal Health Records who have come and gone in the past decade or even longer. What have we learned? What are the takeaway messages? How can we leverage this momentum in a way that is positive for both consumers and clinicians and potentially transform the delivery of healthcare?

Let's make some general assumptions:

  • Core functionality is likely to remain largely as described in the ConOps document;
  • Privacy, Security and Authorisation will be dealt with appropriately; and
  • Internet skills of users will be taken into account in terms of clever and intelligent design and workflow.

In a previous post, I suggested that there are additional 3 concepts that need serious consideration if we are to be successful in the development of person-centric health records, such as the PCEHR.

  • Health is personal
  • Health is social
  • Need for liquid data

I've been pondering further and have modified these slightly. I want to explore at how we can make health data personally valuable, socially-connected and dynamic or liquid.

Adding value; making it personal

Take a look at any clinician's EHR and the actual data in itself is pretty static and uninteresting – proprietary data structures, HL7v2 messages, CDA documents; facts, evidence, assessments, plans; a sequence of temporal entries which could prove to be overwhelming when gathered over a lifetime. However it provides the necessary foundation on which innovative approaches could make that static data come become dynamic, to be re-used, leveraged for other purposes, to flow!

Data starts to come to life when we use it creatively to add value or to personalise it, rather than just presenting the raw facts and figures or the interminable lists. The key is to identify the 'hot buttons' for any and all users, clinician or consumer alike – those things that provide some value or personalisation benefit that is not otherwise available.

For the clinician to be engaged, they need to be able identify at least symmetrical, and preferably increased, value from any effort that they contribute to participating in the creation and maintenance of a shared electronic health record (EHR). This might be recognised in many ways including, but not limited to:

  • Leveraging the data itself – tools to put the data to use
    • the creation of views of the data that will better support their provision of care to their patients, such as health summaries (both automatic and curated) and up-to-date Medication, Problem and Adverse Reaction lists;
    • access to clinical decision support;
    • improved safety from generation of alerts; and
    • Secure exchange of patient information.
  • Increased opportunity for engagement
    • online consultations;
    • care coordination; and
    • answering questions via email or a shared portal.
  • Generate increased income from
    • creation of reminders for follow-up visits
    • online interactions eg repeat prescriptions, eReferrals and online consulations
  • Data available for quality improvement and clinical audit
  • Data available for research & population health

Yet this is clearly not without it's unique challenges - for example, JAHIMA's The Problems with Problem Lists! What is being proposed is not trivial at all!

Consider what will engage a patient to take more than a second look at their health record. Google Health creator, Adam Bosworth, in the short excerpt from the TechCrunch video on why Google Health failed, stated that people don't just want some place to store their health information – that they want something more. And Ross Koppel noted in his Google gave up on electronic personal health records, but we shouldn't blog post that "…while knowledge may be power, it isn't willpower." The challenge we face is how to add 'the something more'; to encourage the development of willpower.

Segmenting consumers is one approach to identifying 'hot buttons' that might trigger them to opt in and use the PCEHR:

  1. Well & Healthy – this is a tricky group to engage as they often see no reason to address any aspects of their health and are not motivated to change behaviour or seek treatment. Some may be interested in preventive health or tracking fitness or diet.;
  2. Worried Well – those who consider themselves at risk of illness and want to ensure that they are (or will be) OK, often tracking aspects of their health to be alert for issues or problems – some call them hypochondriacs;
  3. Chronically Ill – those living with an ongoing health condition or disability; and
  4. Acutely Ill – including recent life-changing diagnosis or event

Each group will have specific needs that need to be explored to ensure that despite registering, there is a persuasive reason for them to return and actively engage with the PCEHR content or value-added features.

While the 'hot buttons' for consumers might vary, there are common principles that could underpin any data made available and value-added services provided, such that consumers can use, and make sense of, their health information. Examples include:

  • Minimal data entry by the consumer – this will be a considerable barrier to entry;
  • Aggregation of information from multiple sources - creating a hub of health information in one place;
  • Information is interpreted, wherever possible to make it personal and relevant to the consumer
    • ...this is what it means for you...
    • ...this is what you should consider next...;
  • Information provided in non-medical or non-technical language, using consumer vocabulary whenever possible;
  • Provision of context for the information – for example, information about the pathology test sitting alongside the actual pathology test result; and
  • Comparison of the consumer's data alongside data from equivalent peers, for example the same age and sex, where this is safe and appropriate.
  • Consideration of the 'Games for Health' movement and the effort to leverage 'gamification' in non-game applications as a mechanism for getting users (especially Consumers) to register, participate and most importantly, support their ongoing engagement.

Socially-connected data?

Hmmm. Traditionally we tend to gravitate to the idea of privacy at all costs when it comes to health information, however what we really aspire to is making the right information available to the right person at the right time – the safe and secure facilitation of health information communication. That this might extend into the non-clinical space in some circumstances is challenging and somewhat contentious, especially in these relatively early days, but it is conceivable that our traditional, rather paternalistic health paradigm is about to undergo a considerable shakeup.

The area of Telehealth is certainly starting to gain traction between healthcare providers as an electronic proxy for transporting patients long distances for specialist care. Similarly there appears to be rising interest in online consultations and interactions between consumers and their healthcare providers including the re-ordering of prescriptions, requesting of repeat referrals and ability to ask questions via secure messaging. Clearly there are issues and constraints about these activities, but it is very likely that the incidence of consumer-clinician interactions will increase in the near future as consumers recognise the convenience and demand rises.

A person-centric health record that allows shared access from both providers and consumers can act as the hub for these communications. In addition, integration with the Clinician's information system can support the ability for notification to the consumer of availability of diagnostic test results, reminders, tests due, prescriptions due etc.

The social support imperative in health programs such as Quit Smoking and Weight loss have been well recognised for many years, and is a common strategy used in clinical practice. In recent times this is expanding beyond family and friends to the broader community via automated sharing of measurements to social networks such as Twitter. In addition we can consider some early wins in the non-medical sphere – for example, the online PatientsLikeMe community – where consumers are engaging with other consumers with similar issues and concerns. There is also some interesting research evolving about the value that is coming from consumer to consumer health advice – Managing the Personal Side of Health: How Patient Expertise Differs from Expertise of Clinicians. Contagion Health has developed the Get Up and Move program where consumers issue challenges each other to encourage increased activity and to promote exercise, facilitated by an online website, and Twitter.

A recent Pew Research Centre report, Peer-to-peer Healthcare stated: "If you enable an environment in which people can share, they will!" And Adam Bosworth made a clear statement that one reason Google Health failed was because it 'wasn't social' – that it was effectively an isolated silo of a consumer's health information. I suspect that we will see this social and connected aspect of healthcare evolving and become more prominent in coming years, as we understand the risks, benefits and potential.

Liquid or Dynamic Data?

One of the most interesting comments about the demise of Google Health was: "Google Health confronted a tower of healthcare information Babel. If health information could have been shared, Google would still be offering that service." That's a very strong statement – not only that the actual data itself was a significant issue, and more specifically, that it was not shareable.

So that requires us to ask how we can make data shareable. "Gimme my damn data" and "Let the data flow", some say - but the result is usually access to their own data in various proprietary formats but no opportunity to bring it together into one cohesive whole which can be used and leveraged to support their healthcare. I've blogged extensively already about the benefits of standardised, computable clinical content patterns known as archetypes – see What on earth is openEHR and Glide Path to Interoperability. To me this approach is simply common sense, and with the rising interest in development of Detailed Clinical Models, perhaps this view is coming closer to reality.

Until we create a lingua franca of health information we can't expect to be able to share health information accurately and unambiguously. We need agreed common clinical content definitions to support sharing of health data such that it can flow, be re-used and be used for additional purposes such as sharing information between applications – making the data dynamic.

As we work out how to approach this shared personal electronic record space, our options will be severely limited unless we have a coherent approach to the data structure and data entry. We need to:

  • Develop common data formats and rules for use that will support the flow of health information
  • Promote automatic entry and integration of data from multiple source systems – primary care EHR, Laboratory systems, government resources and, increasingly, consumer PHRs. Most will tolerate some manual entry of data if they receive some value in return, but don't underestimate the barrier to entry for both clinicians and consumers if they have to enter the same data in multiple places.

To participate, or not?

The core content of the PCEHR as per the ConOps is very clinician-oriented at present, clearly intended for the ultimate benefit of the patient, but focused on information that will be useful to share where multiple clinicians are participating in care or for use in an emergency. The nominated Primary Care clinician will be tasked with the upload and maintenance of the Shared Health Summary. Event Summaries can be uploaded (hopefully this will be automated earlier rather than later). PBS, MBS, ACIR and Organ Donor information will be integrated from Medicare sources.

All of this data will no doubt be extremely useful in some circumstances, but in itself may not be compelling enough to encourage frequent use by clinicians, nor provide them with they symmetrical value such they will need to maintain the Health Summary records. From an academic point of view the proposed ConOps is ticking all the correct boxes, however the big question is will that be enough to motivate clinicians to participate and then, more importantly, to stay involved?

Consumer engagement as described in the ConOps is fairly limited – ability to manually enter 'key information' about allergies and adverse reactions or medications; the location of an advance care directive and notes about health information that they wish to share. This is hardly enough to capture the imagination of many consumers. It is a real likelihood that those who do opt in may only use it once or twice, including manually entering some of their data, but find that there is not compelling reasons for them to return to their PCEHR record nor to encourage/demand that their Clinician participate.

We have an opportunity to turn the PCEHR into a dynamic person-centred health information hub – one that can be leveraged by clinicians and consumers, and for the benefit of the consumer's health and wellbeing in the most wholistic sense. In order to do so, the PCEHR needs to seriously consider prioritising an approach that ensures dynamic, personalised and/or value-added data; health information that can be shared and communicated clinically and socially; and dynamic data.

At all costs we must avoid:

  • a dry, impersonal tool that is ignored or infrequently used by any user, or used by only one type, rather than both consumers and clinicians in partnership;
  • barriers to entry for both consumers and clinicians;
  • a closed, inward-looking tool;
  • a silo of isolated health information operating as yet another 'tower of healthcare information Babel'.

This is our challenge!

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.

The DCM environment - a crowdsourcing initiative

There are a number of detailed clinical models available to choose from, from diverse backgrounds, for many differing purposes and with varying degrees of success and penetration. More are arriving on the scene as time goes on – only this week the Clinical Information Models from ONC in the US have been released for their first 2 week period of public comment, and I'd never heard of them before. I haven’t been able to find a single document pointing to an overview on available models – current or past. So, given the current activity development of a quality standard around detailed clinical models in ISO TC 215 and the number of models under development, I thought it timely to try to co-ordinate sourcing a picture of the detailed clinical model landscape.

Well aware that my understanding is limited to the openEHR archetypes I work with, I thought I’d take this opportunity to draw together some of my research and request some assistance from others to crowdsource a picture of the detailed clinical model environment that we operate within.

I have published my initial attempt as a Google doc, see below. The existing information needs to be verified; there are clearly many gaps that need to be filled in; and there are probably other DCMs to be added.

EDIT the DCM environment document...

Anyone can participate, and if you edit, please add your name/org/email to the Contributor list, so that attribution can be made.

Please feel free to edit; to add new DCMs; to correct and verify the facts. Add a column, suggest changes to structure where you see a need... Just make a comment, if you like.

You can clearly see all the gaps in our collective knowledge at present…

Let’s see if we can actually pull together a useful resource. The intent is collaboration to achieve a goal that is possibly greater than most of us can achieve by ourselves.

All contributions are gratefully received and can be freely shared with anyone who is interested.

The latest crowdsourced version of the document appears below. You will need to scroll to seen the entire content.

[googleapps domain="docs" dir="document/pub" query="id=11xGZs4drfwb7TY15Iwpk52UIxZcFhqMcMp1i3yV4To8&embedded=true" /]

________________________________________

Further Comment: 11 August 2011

I've been asked where this work is going and what is planned...

The answer is that I haven’t a specific plan.

To my knowledge there has been no environmental scan to explore what the range of models is, to my knowledge, so thought I’d try myself. I spent a day to develop the initial framework, sparse though it was. Googling was a very frustrating experience and finding out the information that we’re interested in from available websites was not easy.

Hence I thought I’d experiment with the crowd sourcing approach. I know there is a rising tide of interest in the generic concept of detailed clinical models and a lot of confusion about the work in ISO and HL7.

I hoped it might contribute to clarifying the situation and providing a concrete anchor on which to base discussions on detailed clinical models.

Worst case scenario, the final result may be little more than a brainstorming, however it will at least form the basis for anyone interested to launch a more rigorous research program, including potentially feeding into the ISO work. Best case scenario, we may have a significant resource. Final outcome will probably be somewhere in between.

I’m happy to leave it online as a general resource – it seems to have generated a lot of interest. I'm hopeful that it will keep evolving.

Photographs: Art or Technology?l

This week we had a photography- friend arrive on a flying visit from overseas - 48 hours on the ground, including the seminar in which he was participating. We took him down the Great Ocean Road - a glorious coastal road - last time we drove it was in a rented Porsche, top down, for the full experience. But that was February - there was no desire to repeat it in July! We left at 8am and arrived back at 10pm - it is a long drive... with some choice stops along the way for refreshments and to absorb the views.

Our friend had most of his camera kit with him - 2x semi-professional digital bodies and multiple lenses, including the extraordinary 14-24mm fish-eye. I had my, um, phone camera!

At the end of the day we were happy and exhausted. Our friend had over 750 shots, I had about 120 - mostly variations of Gibson's steps, the 12 Apostles and Loch Ard Gorge in the late afternoon light.

We talked at length about the camera gear, tempting me to invest in some new technology. My last significant purchases were Nikon F801 and accessories back somewhere around 1990! Film! Yet it did give me some fun playing around with black and white developing for a short window. I haven't used this camera for at least 10 years.

I've had a couple of the early digital cameras - mostly with very ho hum results in the early days.

In recent years I have been the proud owner of a very modest Panasonic Lumix point and shoot - 7MP, 10x optical zoom, super little Leica lens. It has been a brilliant camera to fling in my handbag on overseas business trips - always there to capture some little treasure to bring home as a memory of the trip.

I'd like to think that I approach my photography a little more seriously than just taking happy snaps, but I'm not too precious about it. My aesthetic has refined over time, and I particularly enjoy the experience when I venture out specifically with the aim of taking photos - it changes the way I view my world around me, and I really value that.

I was browsing through my photos this week, and uploaded of my travel-related photos to try out the photo section on Google+. My brief trip down memory lane of my travels in recent years was largely the result of my trusty Panasonic P&S. And while I didn't have the range of lenses and manual settings, I have somehow managed to capture some very pleasing shots. I guess it comes down to understanding light and composition better now, after all this time.

While I have been briefly tempted this week to get back into 'the gear', the burden of lugging it all over the world and worrying about it being stolen etc seems too onerous - just not worth the effort.

I've decided I'm going to stick with something 'middle of the road', that gives me enough manual control to make my hobby satisfying, but is easily transportable and can be with me at all times - that fits better with my priorities.

So while all the photos above have been taken on a mobile phone, maybe I'll look at updating my trusty Panasonic - it's is looking pretty battle worn now, the body showing evidence of it's adventures from many scratches and scrapes!

While the technology is necessary, for me it just a tool for me to exercise my art!

[slideshow]

Anatomy of a Procedure

ACTION archetypes are one of the harder concepts to grasp in the openEHR clinical modeling world. ACTIONs appear to be promising the world - allowing for recording all activities from planning, scheduling, postponing, cancelling, suspending, through to carrying out and completing an activity. While they may appear cumbersome at first, they are surprisingly elegant and fit for purpose... once you can twist your brain around them.

Consider ACTION archetypes as a walrus - awkward on land, but graceful in the water - well maybe the analogy is being stretched a little, but you get my drift.

Whatever you do, don't underestimate the power of these little clinical models. ACTIONs are designed to enable sophisticated tracking of activities being carried out in a distributed environment - perfect for managing care pathways between multiple providers in disparate locations - not an easy task.

Take a look at this slide show - my attempt to provide a concrete example of how a Procedure ACTION archetype will support documentation about how an INSTRUCTION or order for a Procedure (any procedure, potentially) is carried out in a shared electronic health record environment.

  • 'Pathway steps' are identified as the steps (not necessarily sequential) or clinical activities in which it makes sense to record some information in the health record.
  • The Data Elements that are identified in the 'Description' include any and all information that we may wish to record for any of the Pathway steps. For example, the data we need to record when we plan to perform a Procedure or the information required to record that the Procedure was performed or abandoned, including the reason for abandonment.

[slideshare id=8563247&doc=201107instructionsactions-110711064154-phpapp02]

 

Updated: August 17, 2011

PCEHR insights

Chris Pearce posted this to a closed email list yesterday. I think it provides a useful insight into plans for the Australian Personally Controlled Electronic Health Record (PCEHR) that is not otherwise obvious. The Documents he refers to are two NEHTA specifications that are being developed in consultation with professional bodies, related to the PCEHR Shared Health Summary and PCEHR Event Summary. With his permission:

An overview that you might find helpful in making a bit more sense of the documents. If you need more detail, you may need to go back to the concept of operations document.

The Shared Health Summary (SHS) intended to be a curated, validated record. Initially it was meant to come from general practice, but in the consultation process this has been modified - and is now the role of a 'nominated provider', who must be a health professional who is capable of understanding the continuing, comprehensive care aspect, medications and the like. It will require a mutual consent process.

The event summary was initially designed to pick up where the SHS (which is fixed at a point of time) left off - so if you had something that would alter the SHS, you could put it in the Event summary - so for example- GP loads SHS, then refers patient to specialist who diagnoses diabetes - so loads event summary with diagnosis of diabetes, Rx of metformin. The actual scope is part of the consultation process that ACHI is now involved in.

The third piece of the puzzle is a thing called the consolidated view - which is designed to bring the information together in a meaningful way - SHS, event summaries, discharge summaries, other clinical documents. Thus in the above example a third party would see a list of the current conditions that would include the ones from the SHS (clearly identified as to provenance) along with the ones from an event summary (and from consumer entered data.

But, it does mean that one can have a health summary (uncurated, or really curated at a different level) 'view' built up over time without the shared health summary.

Author: Associate Professor Christopher Pearce PhD MFM MBBS FRACGP FACRRM FAICD FACHI Director of Research, Melbourne East General Practice Network Adjunct Associate Professor in General Practice, Monash University Visiting Fellow, Australian National University Clinical Lead, National E-Health Transitional Authority

Archetype Quality II

In my previous post, I proposed a high level diagram representing the archetype development processes. Pondering on this process further, I am generally happy with the high-level steps identified although the implementation step should really outside the scope of determining quality criteria for the archetype itself; thus four identified processes remain:

  • Requirements gathering & analysis:
  • Design & build:
  • Collaboration & verification; &
  • Publication, maintenance & distribution.

The next logical steps are to:

  1. Identify all of the sub-processes involved including the full set of activities required to create, produce, maintain and distribute the final archetype, including the people, materials, tools and procedures;
  2. Identify all of the points within these sub-processes at which we can define quality criteria; and
  3. Identify the individual quality indicators with which we can measure or asses each of the quality criteria.

In addition, I'm increasingly of the opinion that we should utilise some of the ideas outlined by Kalra et al to assist us to be systematic in our identification of the quality criteria and indicators. Kalra et al proposed high level quality criteria (or statements that demonstrate ideal practice) in the following categories:

  • Business Requirements
  • Clinical Requirements
  • Technical Requirements
  • Information Governance Requirements
  • Repository Requirements

I've modified these criteria categories to:

  • Design requirements/methodology - identification of quality criteria related to the design of an archetype where it impacts on any or all of these four processes. Examples include: inclusive design (maximal data set for universal use case as the ideal, except where over-inclusiveness makes the model impractical, confusing or unsafe; minimisation of overlap with other models; minimisation of duplication of data elements in multiple archetypes; direct terminology bindings and use of terminology reference sets; precision and detail; granularity; include another archetype fragment; mandatory vs optional; metadata; authorship and references/evidence;
  • Business requirements - identification of quality criteria ensuring that the archetypes support the required activities for data storage, exchange, querying, comparative analysis, secondary use, and knowledge-based activities such as decision support for any or all of these four processes.
  • Stakeholder requirements - identification of quality criteria ensuring that stakeholder requirements are represented in the final archetypes. The term stakeholder is deliberately used here, rather than only referring to clinicians, as while the archetype methodology enables clinicians to actively participate they are not the only domain experts who should be contributing to the model. The quality criteria will possibly predominantly focused on the archetype content, but the archetypes will not only be used to support direct clinical care but also a range of other purposes. For example, to support distributed care, clinical decision support, data aggregation and reporting, comparative data analysis, population health planning etc. All potential stakeholders who will either use the data created by the archetypes or implement them should be included in the stakeholder category.
  • Technical requirements - identification of quality criteria ensuring that the archetypes are technically 'fit for purpose'. Examples include ensuring that they conform to the openEHR reference model specifications; represent existing standards specifications or data sets, as appropriate; and technical attributes such as data constraints, occurrence/cardinality and null flavors are represented accurately.
  • Information governance requirements (including repository activity) - identification of quality criteria to ensure strong governance of each archetype through it's life-cycle and maturity within a repository, and processes to support the publication and distribution of meaningful sets of archetypes. Examples include  archetype version management; identification of relationships, including dependence, to other archetypes or knowledge artifacts such as terminology subsets; currency of archetype; endorsement or certification by professional colleges or jurisdictions; implemented use in real systems; implementation guidance; identification of  gaps/overlaps of coverage in sets of archetypes; design documentation; sample data; transformations; and overall quality and safety assessment.

[Note: I have specifically excluded establishing quality criteria for the Clinical Knowledge Repository itself - this should be a separate process which determines governance policy and process for a range of clinical knowledge artifacts within a repository application - including archetypes, templates, terminology subsets, transformation to other semantically equivalent artifacts and inclusion of models from other modeling approaches.]

Each of these categories of requirements will need to be considered in each of the four processes of archetype development. A candidate framework for consideration might therefore be represented in the following table:

Design requirements/ methodology Business requirements Stakeholder requirements Technical requirements Information governance requirements
Requirements gathering & analysis  √  √  X
Design & Build  √  √  X
Collaboration & Verification  √  √   √   √   √
Publication, Maintenance & Distribution X  X   √   √    √

Quality criteria and the indicators that will be used to measure or assess them should be identified for each area in the table represented by a tick (√).

Some simple examples of criteria that can be applied to the 'Collaboration & Verification' process have been outlined in a previous post,. demonstrating practical indicators to measure and assess criteria related to the collaborative review process, evidence-basis and 'fit for purpose'.

Reference: 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))

Unambiguous data: Positive presence; positive absence

The bulk of openEHR archetype modelling is focused on how to record the positive presence of data – for example the diagnosis of diabetes or asthma, or orders for long-term beta blocker medication. When it is not possible to determine data values – the nature of clinical medicine being not so exact a science – 'null flavours' are used to mark an 'incapacity to obtain data', especially for a mandatory data point. The current openEHR null flavours are:

  • no information - "No information provided; nothing can be inferred as to the reason why, including whether there might be a possible applicable value or not";
  • unknown – "A possible value exists but is not provided";
  • masked – "The value has not been provided due to privacy settings"; and
  • not applicable – "No valid value exists for this data item".

If there is no data recorded at all, nor any null flavour, no conclusion can safely be drawn from the lack of data; there is a void in our knowledge.

And then there is the need to record things that are noticeably not present. Some approaches subscribe the notion of 'negation' – resulting in a somewhat awkward and potentially ambiguous statement that might go something along the lines of 'diagnosis of diabetes, not', potentially sitting closely alongside another selectable term of 'diagnosis of diabetes'. You can see that it is easy to get it wrong.

The openEHR preferred approach is to record the positive absence of data – an explicit and unambiguous statement of 'no history of diabetes' in an archetype with the explicit intent to record the absence of a diagnosis.

Specific absence of data needs to be recorded positively, where this is sensible:

  • To encourage unambiguous clinical records;
  • Assisting clinical decision support; and sometimes (unfortunately)
  • For medico-legal purposes.

Examples of global positive exclusion statements include:

  • No known adverse reactions
  • No surgical history
  • No significant family history
  • Not currently taking any medicines

Specific positive exclusion statements include:

  • No known allergy to penicillin (or <insert drug/plant/food/venom or other substance here>);
  • No family history of bowel cancer (or <insert diagnosis here>);
  • Not currently taking immunosuppressants (or); or
  • No pacemaker in situ.

Keep in mind that exclusion statements are only meaningful and relevant at the decision-making moment at which they are recorded. They have a fleeting temporal validity, and then the question has to be asked again – "Are you allergic to anything?"or "Have you ever had any serious illness or operations?".

Some examples:

  • Recording an absence of an adverse reaction event to penicillin becomes immediately obsolete when the patient suffers an anaphylactic reaction to the penicillin subsequently administered; or
  • The past history might reveal no previous diagnosis of asthma, yet asthma might be the cause for today's wheeze; or
  • In a Discharge Summary – 'Not currently taking any medications' is a vital piece of information for the patient's usual GP, yet that drug-free state might only be current until the first follow-up visit.

So exclusions cannot be relied upon for any future decision-making. They are just 'in the moment' statements that need to be re-asked and regularly updated in records (both paper and electronic) as part of routine clinical practise.

So while they may be valuable, does that mean we desire to model every possible negative statement positively? This is certainly not desirable, nor is it helpful. A pragmatic approach is to research those situations where explicitly modelling exclusion statements provide some obvious value; preferably those that will have consistent re-use or may be utilised in knowledge-based activities such as Clinical Decision Support (CDS) systems.

Improved outcomes may result if CDS systems prompt for the recording a positive statement of:

  • 'no known adverse reactions' prior to prescribing medicines; or
  • 'no history of asthma' prior to prescribing beta blockers.

Currently we have archetypes for recording the presence of an Adverse Reaction, a Problem/Diagnosis, Family History and Medicines. In addition we have a generic parent archetype for Exclusion (ie the positive absence) plus specialisations for Adverse Reaction, Medication, Family History and Problem/Diagnosis exclusions so far.  The generic Exclusion archetype can be used as a standardised way to record the more uncommon statements – 'Not (currently) pregnant' might be a candidate here. But if there are regular use cases identified, these too may warrant their own explicit archetypes to ensure that positive absence is recorded consistently and safely.

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:

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.

Quality indicators & the wisdom of crowds

Harnessing the 'wisdom of the crowd' has potential to more powerful than traditional quality processes for a determining the quality of our clinical content in EHRs - we need to learn how best to tap into that wisdom...