What is the vision for an Open Health platform?

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

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

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

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

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

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

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

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

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

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

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

Time for a revolution, me thinks!

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

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

Why is the health information domain different?

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

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

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

Information-driven EHRs

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

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

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

The openEHR paradigm

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

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

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

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

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

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

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

Current CKM functionality includes:

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

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

Benefits of a collaborative, data-driven approach

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

Benefits for stakeholders

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

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

Benefits for patients

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

Benefits for national programs and other jurisdictions

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

Benefits for application developers

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

Benefits for secondary users of data

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

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

The (surprise) influence of social networking

I've just arrived back from Medinfo2010 in Cape Town and been intrigued to see the power of social networking in action. Business networking did not exist in my world until I started work within a KPMG Consulting JV in the heady days of 2000, immediately before the dotcom crash. Rather naive and idealistic, straight out of my native General Practice, I watched one of the sales team actively seek out his contacts and regularly catch up for coffee or lunch. It puzzled me at the time as these contacts often had nothing to do with his day-to-day sales responsibilities, yet he nurtured these relationships carefully & deliberately, teaching me that most sales and related opportunities are formed on a basis of solid relationships and trust. Ironically, I'm not sure that I actually saw him make a sale for our software offering at the time, but later I observed that he moved on to his next role entirely because of his network of relationships.

In the past 2 years I have been involved in fostering clinician collaboration in the openEHR Clinical Knowledge Manager. As part of my personal research I made myself a previously non-existent Facebook account and started tweeting. It has been an interesting journey, particularly with Twitter, watching how unknown groups of individuals build together into a semblance of community based on similar interests. My area of interest has been around health IT in general - especially electronic health records, personal health records and quality of health data - and in particular sharing information about my day-to-day world of openEHR, archetypes and clinician engagement in electronic health records. Over time I worked out how to find the tweets that fitted my areas of interest, gradually refining and filtering them into a relevant information feed. These days I receive a great overview of happenings in the eHealth domain through the tweets of the 300-ish people I follow. If they start tweeting about what they ate for breakfast and such trivia, I have a very low tolerance for unfollowing them, unless they amuse me in other ways - I rather like the power of the 'unfollow'!

The active component of Twitter has been interesting to explore. I have made contact with some very interesting and like-minded people from all over the world; most are US-based, with a number in Europe and South America, and surprisingly few locally here in Australia. I struggle to be pithy and witty, usually resorting usually to re-share eHealth-related articles and information that interest me. Over time, I have slowly built up a following who also seem interested in similar topics, much to my surprise.

In the past couple of years I have been privileged to travel to some European and Australian conferences and international ISO standards meetings. At each meeting I have met up with a few people tweeting from the meeting or found existing contacts on Twitter and continued communications between meetings - new friendships begun and existing friendships consolidated.

This recent meeting was a little different.

Firstly, fellow tweeps with whom I was building some friendship and trust actively introduced me to influential contacts of their own. The credibility of these introductions have opened doors that I could never have achieved on my own and may turn out to be significant opportunities in furthering my collaborative work with clinicians. I am trying to keep my excitement under some control until we can confirm that the promises made will actually be delivered;-) Too many times I've seen ambitious promises disappear into the ether, so... for now, we wait and dialogue. Keep you posted! In return I was able to introduce some of my contacts, so hopefully an overall win-win experience for all, twitter-driven.

Secondly, I had the surreal experience of people coming up and introducing themselves, not knowing my real name, but addressing my by my twitter 'handle' - I presume the recognition being the result of tweeting directly from the conference and my photo. My non-Twitter companions were rather surprised to hear me being addressed as 'omowizard' - it took a little time to explain!

I've participated in LinkedIn for years and it has been a very passive, unengaging experience - no connectivity apart from inviting others to link and being invited back. Facebook I keep predominantly limited to friends and family. Twitter however is an active and evolving community and it has provided new opportunities for meaningful connectedness to individuals who have common interests or drivers. It is a much more positive experience - I both share and receive - and the community as a whole becomes a richer resource.

How cool is that! It is fun, and I suspect I'm just a little addicted8-|

The state of the CKM!

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

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

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

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

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

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

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

Current CKM functionality includes:

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

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

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

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

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

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

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

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

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

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

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

Special thanks to Sam Heard for his editorial assistance.

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

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

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

Is your clinical data 'fit for purpose'?

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

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

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

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

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

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

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

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

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

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

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

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

My conclusion - clinical experience matters!

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

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

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

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

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

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

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

How can colleges drive eHealth?

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

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

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

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

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

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

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

Control of the PHR

Pondering my last post further... While our reality is that there are both individual- and clinician-focused PHRs, in any PHR where there is co-located content (i.e. of both individual- and healthcare provider-origins) there needs to be a final, single arbiter of content, quality and control. While the ideal is that this should be as shared and collaborative as possible, my personal feeling is that in the long term, successful PHRs will be those with the individual at the helm, with the clinician/s participating as a key partner.

In addition, a PHR controlled by an individual is more likely to succeed and be used by healthcare providers if there are sound data management processes underlying the PHR to support sound data stewardship for all participants. We can't underestimate the importance of ensuring that provenance of data is transparent, and that contributions to the PHR from external sources such as laboratory reports or discharge summaries remain intact and unedited etc. This is not a technical problem, but requires intelligent PHR design. Both individuals and healthcare providers need to be comfortable with how the individual's data is managed and represented, ensuring protection of the integrity and traceability of externally sourced data, and allowing the individual to annotate or tag data with their own comments or concerns.

Provision of healthcare has traditionally been quite a paternalistic process. We clinicians have acted as stewards on behalf of our patients. Interestingly in my discussions with consumers even in recent years, many are happy for this status quo to continue, not feeling confident or competent to control or manage their health information. Yet ironically these are the same people who operate their own financial affairs, bank online, shop online, email, tweet and blog. Transitioning the control of health information back to the individual may not be as easy as we anticipate. Most groups anticipate that the consumer will be willing to take over as soon as we make their health information available to them. I think that the reality might be more challenging and not without controversy. It will require education processes to support the transition for both the individual and the healthcare provider.

We can pull out that old chestnut and as clinicians declare that data in a health record can't be relied upon unless it has been entered by a clinician, however once you look at any amount of EHR data you will realise that clinician-entered data is not necessarily synonymous with quality. In counterpoint there are an increasing number of clinicians who can tell stories where their patients were able to correct their data when viewing a share computer monitory in a consultation.

I will vote optimistically and promote the case for individual's to control their PHRs. Individuals are best positioned to act as the central integrator for the broadest range of healthcare providers who participate in their care, and I view the adding their own data as a bonus. The broader, the deeper, the richer an individual's health information is, potentially the better the care that can be provided for them.

The sum is greater than the (isolated EHR) parts, let's not undervalue that – encourage individual-controlled PHRs, but always with sound data stewardship as the highest priority.

Defining the PHR – take II

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

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

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

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

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

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

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

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

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

Acknowledgement: Prof Dipak Kalra, CHIME, University College London

Connect with openEHR

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

So... Where to start?

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

• Archetypes 101 - Leslie, Heard; 2006

• The openEHR advantage - Pishev, 2006

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

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

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

And of course:

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

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

• Twitter

  • Follow the openEHR Foundation - @openEHR

  • Follow CKM announcements - @openEHR_ckm

  • Search for #openEHR

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

Defining the PHR

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

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

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

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

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

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

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

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

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

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

What do you think?

What on earth is openEHR?

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

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

What is openEHR?

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

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

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

Why openEHR?

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

Who is using openEHR?

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

___________________

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

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

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

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

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

Going on a Banksy Hunt...

I spent a total of 19 weeks living away from family in London during 2007. Much of that time was spent by myself, and I ended up walking and exploring - the main task being to locate Banksy pieces. It really started just as something to do to keep me active and to soak up the essence of a different city. Armed with a Banksy Walking Guide that I bought on eBay, I set out on a number of days and walked for miles, finding many stencils around the East End. Some had been buffed; some were hidden behind fences; some just sitting there just like the picture in the book.

Oddly, you could even recognise others who were doing a similar thing and conversations started as you pointed someone to an obscure Banksy that they had missed - a temporary camaraderie in a strange city!

Subsequently, I have also found a few Banksy stencils locally in Melbourne, funnily most are just in the streets around my home and on shop fronts that I walk past each day.

Today I've just posted the last of my Banksy photos to Flickr - Banksy's skeleton car on display behind the Old Truman Brewery back in November 2007 - not sure about it's current status. You can see all my Banksy collection in an online set, Going on a Banksy Hunt if you are so inclined.

It has been an interesting exercise  to seek out and learn a little about Banksy. Clearly there are many more Banksy streetart photos that are chronicled on Flickr and other online sites, and many people that know much more about Banksy than me, but it has been an interesting journey.  So just saying...

Fractal Electronic Health Records?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inspired by @samheard, as usual;-)

The unexpected beauty of a REAL book

Following my visit to the US in October last year, I came home to Australia bearing the latest Kindle very proudly. We are definitely a family that gets excited about gadgets, and this was one of the first international Kindles available - delivered straight to my Raleigh hotel room the day after release on Amazon.com.

I read a couple of books on it before Christmas, but the experience was unfortunately a little underwhelming; the conclusion being that it was slower and much more clunky than the much beloved iPhone. Without realizing it I had gradually been abandoning print for screen.

Then, for Christmas, I received a most beautiful limited edition, hardcover of the latest book by one of my favorite authors.

The cover was beautifully decorated - none of this cheap old slipcover nonsense - and there was one of those semi-transparent pages adjacent to the title page. Have you ever actually owned a book with one of those?

The final, perfect touch - my numbered book was signed by the author.

Now the story was every bit as good as I'd hoped and I lay in bed reading for indulgent hours - a treat I hadn't pursued for some time.

To my surprise I still occasionally find myself reminiscing about that sweet reading experience. Holding that beautifully crafted book in my hands was an unexpectedly sensual experience and it still sends a little shiver down my spine;-)

Web2.0 Clinicians – building clinical knowledge resources

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

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

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

CKM status

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

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

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

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

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

Modeling an entire EHR – is it achievable?

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

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

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

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

All Blood Pressures are not created equal! (Part II)

Following on from the previous post... If we want to compare and review blood pressure (BP) over time from all sources and clinical situations, then they need to be recorded in a consistent manner. We also need a common structure to facilitate accurate data exchange without manipulation.

Most systems have a proprietary database comprising a home-grown data structure – so if there are 'n' thousands of clinical vendors in existence, there are probably way more than 'n' thousands of technical approaches to specifying the clinical documentation and process that are so familiar to you. HealthVault is one that publishes its data specifications publicly but most private companies are not so open.

There are also a number of approaches that are proposing use of common data structures to support health information sharing. You can see some of my thoughts on this in previous posts – and in my opinion this is definitely the way to go if you want/need to do smart and active things with health data. Some examples are HL7 templates and openEHR archetypes.

Let's take a look at some publicly available representations of Blood Pressure...

On the right is the Microsoft HealthVault Blood Pressure specification (click image to enlarge):

It's largely in 'techspeak', although if you examine the specification itself you will find only three clinical elements:

• Systolic
• Diastolic and...
• Pulse!

Ouch... Pulse is usually independent of BP measurement for most clinicians, even if it may commonly be measured simultaneously. This model cannot currently capture event the basice clinical requirements identified in the previous post - not even recording that a large cuff was used for an obese patient, to indicate whether the measurement is accurate and able to be interpreted confidently. This model is really not rich enough to cater with our clinical recording requirements for Blood Pressure.

At right is a HL7 model for Blood Pressure (click image to enlarge):

Umm... maybe a little difficult to understand. It's hard to see the scope of the content, and almost impossible for clinicians to have input into, which is a significant issue in terms of achieving accessible and high quality data definitions.

Finally, openEHR has a number of ways of representing the data model for Blood Pressure. It is a maximal data set intending to capture all information about Blood Pressure measurements for all the clinical and research situations described previously, and more.

On the right is the simplest representation of the openEHR blood pressure archetype – displaying the content in a non-technical way so that all clinicians can focus and comment on the  clinical content itself.

At right is another way that the same BP archetype is displayed to clinicians and informaticians - specifically used when seeking detailed comments about the clinical content on a per element basis during collaborative online archetype reviews. While it may help to have an understanding of data types eg Text or Quantity or Date, no deep understanding of openEHR is required of participants.

In the interests of full disclosure, I have been intimately involved in the development of the openEHR Blood Pressure archetype which has been developed and agreed with a lot of clinical input, and places a lot of emphasis on being approachable by clinicians and incorporating their feedback.  The representations you see here are not perfect, but grassroots clinicians are participating actively in online reviews of archetypes.  The blood pressure archetype was published after consensus was reached on the content by 30 clinicians, informaticians and engineers from 13 countries.

There is no doubt that at first glance the archetype may appear too rich. One of the key differentiators in openEHR is the capability to take this maximum data set and activate/display only the parts that are relevant to the clinical scenario requirements eg for primary care or a paediatric patient. This detailed discussion is out of the scope of this post, and will be left until a later date.

The focus of the health IT domain has largely been technical. Involvement of clinicians has often been token or as a secondary process.  It is critical for successful development of EHR systems that clinicians are able to be actively involved in development and quality control of the clinical content that underpins these systems - clinicians need to request involvement. At the same time, the health IT domain needs to 'un-technify' eHealth - clinicians need support to participate, so that more than just a few elite informaticians can view these data structures and contribute to their development and quality review.

In these two posts we have explored a little about the scope of clinical models and their representation. Yet again, this is still only the tip of the iceberg re health data. The list goes on, including the use of terminology and the non-trivial technical requirements that are required to underpin these clinical models so that we have know exactly what this data means - far more complex than can be supplied by a simple XML model. Now that really starts to open a can of worms... for later!

All Blood Pressures are not created equal! (Part I)

Clinicians, have you ever had a look at the data structures underpinning your EHR - the models of clinical content? If you don't understand the principles of what your data structure is then your EHR may not do, or ever be able to do, all the things you need it to do to record your clinical notes. You need a sense of what is 'under the bonnet' and what its capabilities are. Take Blood Pressure as an example. It is probably the most easily understood clinical concept to both clinicians and patients. We clinicians tend to think of it as a very simple measurement to record on paper, and we expect our EHR applications to do it in a similar way.

So let's brainstorm about what we need to record blood pressure. The typical primary care provider such as a General Practitioner or Nurse will record the Systolic and Diastolic pressures, plus maybe a blood pressure cuff size if it is different to the 'normal' cuff, and position of the patient if recording a postural drop. This is straightforward, 'bread and butter' stuff for clinicians.

So the base data requirements are:

• Systolic – a quantity that is a pressure, measured in millimeters of mercury (mmHg)
• Diastolic – ditto
• Cuff size – most will measure using a 'normal' adult cuff, recording a size only if they use a larger or smaller cuff.
• Position – most patients in primary care will be sitting; most in hospital will be reclining

While this may cater for the large majority of our BP measurements, there are other less common situations where it is critical that BP be recorded appropriately and in context. So we need a data specification that also caters for the following situations where BP is measured, such as:

• The cardiologist or exercise physiologist may need additional data about the level of exertion for use in stress testing or research. A BP measured at rest needs to be interpreted differently to that recorded after jogging for 10 minutes.
• Recording a series of BP readings over a 24 hour period to determine the 24 hour average, plus knowing the patient's concurrent sleep status – this is now regarded as key diagnostic criteria for diagnosis of hypertension in Europe.
• Measuring data from home BP machines – many of these actually record the Mean Arterial Pressure and use an algorithm to determine the Systolic/Diastolic readings displayed.
• Automatic BP measuring every 5 minutes during surgery or an admission to Intensive Care by 'the machine that goes beep'.
• Paramedics taking a measurement of a trapped patient at the scene of an car accident.

Other questions might be clinically significant in some circumstances include:

• What Korotkoff sound was used?
• What about the implications for paediatric measurement?
• Where was the measurement taken? Which limb? Finger vs upper arm?
• How was it taken – auscultation; palpation, machine; or invasive?
• What about pregnant women who need to have their BP measured with lateral tilt to get a true reading – do we need to record that detail?

It may be very important to have this information recorded in some situations.

Maybe blood pressure is maybe not so simple, after all.

Clinicians understand clinical nuances well, recording the contextual variations appropriately in paper records – in fact it is so ingrained that it is almost done on autopilot. The problem arises in trying to get computers to do the same thing – to record simply in the usual circumstances but be able to cope with the complex and detailed where it is critically needed.

So, we need to have some understanding about the capabilities of our EHR systems.  Most systems only cater for little beyond the basic four requirements. Yet most of these additional requirements that we have identified are useful or necessary at other times to ensure unambiguous BP recording.

The mind map at left captures the basic versus the 'ideal' requirements. The 'ideal list may seem excessive to some. Yet if our EHR system could cater for this, then we could record all nuances of BP accurately and share them unambiguously if they share the same underlying structure - primary care to secondary care; PHR to EHR to research; patient to clinicians. So then, the 'art of the EHR' is to present the right amount of information and the right context to the clinician to let them record what they need - not too much for the common simple BP reading, but more when necessary.

Here we have started to explore the tip of the iceberg – the content scope of one common clinical measurement. The essential message here is that we clinicians need to have some understanding of what is 'under the bonnet' of our EHR systems. What may be adequate for the commonest situation is not necessarily enough for recording the complexities of clinical care.

Part II starts to explore clinician engagement in content models...