Know your data?

Recently I was reminded of some work we did a number of years ago. It involved a large research database, painstakingly collected over 20 years. The data was defined across a number of specialisations within a single clinical domain and represented in 83 data dictionaries stored in an Excel spreadsheet.

Data was collected based on a series of questionnaires, and we were told that successive data custodians had, true to human nature, made slight tweaks and updates to the questionnaires on multiple occasions. The data collected was actually evolving!

The only way to view the data was to open each of the 83 spreadsheets, painstakingly, one by one.

We were engaged to create archetypes to represent both the legacy data and the data that the research organisation wished to standardise to take forward.

So the activity of converting these data dictionaries - firstly to archetypes for each clinical concept, and then representing each data dictionary as a template - resulting in considerable insight into the quality and scope of the data that hadn't been available previously.

For example, the mind map below is an aggregation of the various ways that questions were asked about the topic of smoking.

Interestingly, what it showed was that no one individual in the organisation had full oversight of the detailed data in all of the data dictionaries.The development of the archetypes effectively provided a cross section of the data focusing on commonality at a clinical concept level and revealed insights into the whole data collection that was a major surprise to the research organisation. It triggered an internal review and major revision of their data.

Some of the issues apparent in this mind map are:

• A number of questions have been asked in slightly different ways, but with slight semantic variation, thus creating the old 'apples' vs 'pears' problem when all we wanted was a basket of apples;
• Often the data is abstracted and recorded in categories, rather than recording the actual, valuable raw data which could be used for multiple purposes, not just he purpose of the rigid categories;
• Some questions have 'munged' two questions together with a single True/False answer, resulting in somewhat ambiguous data; and
• Some questions are based on fixed intervals of time.

No doubt you will see other issues or have more variations of your own you could share in your systems.

And we have repeatedly seen a number of our clients undergo this same process, where archetypes help to reveal issues with enormously valuable data that had previously been obscured by spreadsheets and the like. The creation of archetypes and re-use of archetypes as consistent patterns for clinical content has an enormous positive impact on the quality of data that is subsequently collected.

And while harmonisation and pattern re-use within one organisation or project can be hard enough, standardisation between organisations or regions or national programs or even internationally has further challenges. It may take a while to achieve broader harmonisation but the benefits of interoperability will be palpable when we get there.

In the meantime the archetypes are a great way to trigger the necessary conversations between the clinicians, domain experts, organisations, vendors and other interested parties - getting a handle on our data is a human issue that needs dialogue and collaboration to solve.

Archetypes are a great way to get a handle on our data.

Oil & water: research & standards

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

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

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

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

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

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

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

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

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

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

Archetype quality I

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

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

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

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

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

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

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

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

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

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

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

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

For archetypes:

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

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

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

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

And it continues on...

Engaging Clinicians in Clinical Content (in Sarajevo)

Just browsing and found the link to our presentation for a paper the CKM team gave at the Medical Informatics Europe conference in Bosnia, 2009. Thought I'd share it here, in memory of an amazing conference and location:

MIE09: Engaging Clinicians in Clinical Content [PDF]

Our presentation:

[slideshare id=1958920&doc=engagingcliniciansinclinicalcontent-090906091020-phpapp02]

And the reference to Herding Cats is explained (a little) in the embedded video - actually an advertisement for EDS:

[youtube http://www.youtube.com/watch?v=Pk7yqlTMvp8&w=425&h=349]

I arrived after a 37 hour flight - Melbourne - London - Vienna - Sarajevo to join my Ocean CKM team - Ian McNicoll and Sebastian Garde. We presented our paper and also ran an openEHR workshop.

The conference was held at the Holiday Inn in Sarajevo - the hotel in which all the international journalists were holed up during the war, on 'Sniper Alley'.

Despite it being 14 years after the war had ended, raw emotions were palpable many times during the conference. That a pan-European conference was being held in his beloved Sarajevo under his auspice was a very overwhelming event for the Professor of Informatics and he was often seen in tears!

From my hotel room window in the centre of the city I could see 6 cemeteries.

Walking through the inner city we came across many cemeteries, thousands of marble gravestones with the majority representing the young men aged between 18 & 26.

Bullet holes were still very obvious on the walls of buildings.

Yet the city was vibrant, alive and welcoming.

I won't ever forget this visit.

Some photos of the experience:

An orthogonal question...

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

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

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

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

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

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

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

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.

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