The ultimate PHR?

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

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

Why is the PHR so hard?

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

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

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

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

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

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

Do you see the difference to current PHR systems?

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

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

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

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

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

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

What do you think?

The health information continuum

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

Healthcare organisations and healthcare systems are accountable for the content of EHRs that they control. Individuals have autonomy over records they choose to keep. However, in between these two strict views of an EHR and a PHR is a continuum of person-centric health records which may have varying degrees of information sharing and/or shared control, access and participation by the individual and their healthcare professionals. Toward the EHR end of the spectrum, some EHRs provide viewing access or annotation by the individual to some or all of the clinician’s EHR notes. Towards the PHR end of the spectrum some PHRs enable individuals to allow varying degrees of participation by authorised clinicians to their health information – from simple viewing of data through to write access to part or all of the PHR.

In the middle of this continuum there exist a growing plethora of person-centric health records that operate under collaborative models, combining content from individuals and healthcare professionals under agreed terms and conditions depending on the purpose of the health record. Control of the record may be shared, or parts controlled primarily by either the individual or the healthcare professional with specified permissions being granted to the other party.

And the final diagram:

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

What kind of things should we be considering?

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

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

• Health is personal
• Health is social
• Liquid data

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

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

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

Why is the health information domain different?

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

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

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

Information-driven EHRs

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

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

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

The openEHR paradigm

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

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

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

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

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

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

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

Current CKM functionality includes:

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

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

Benefits of a collaborative, data-driven approach

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

Benefits for stakeholders

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

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

Benefits for patients

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

Benefits for national programs and other jurisdictions

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

Benefits for application developers

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

Benefits for secondary users of data

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

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

Gimme an… uhr?

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

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

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

What do we want?

We hear talk about:

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

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

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

What do we need?

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

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

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

In addition, and supported by:

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

As a result:

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

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

And so,  I archetype;-)

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

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?

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!

Standardized, data-driven eHealth

What is an EHR? Most currently working within eHealth circles will have a ready answer, and the classic response will be something like "an EHR is a software application that is used by clinicians for provision of patient care". But think about it for a second...

What do we want from an electronic health record? It's not actually the application or the user interface or the workflow, but a record of health information in an electronic format.

And so what of the health information itself? What is it? What do we want? What should we want?

Let's work with these definitions: Data are the computable facts; while health information is the data after it is processed, organized, structured or presented in a given context so as to make it useful.

We definitely want health information that...

• Is available at the right time and the right place to the right person.
• Is accurate, detailed and of high quality.

I don't think there is much disagreement on these two points. How about these next suggestions?

We should also want health information that...

• Is a lifetime health record - cradle to grave. Health information that can be accumulated over time, aggregated from many sources to inform better care for ourselves, our patients and loved ones.
• Can be created in one place or by one provider and shared with others so that the meaning of the data is preserved and accurate.
• Can be dynamically and actively used - consisting of structured, atomized data that we can re-use and combine in different ways to improve our health and wellness. Documents or PDF's of our health information are useful as part of a passive record, but they are effectively a dead end - we can't do anything useful with big blobs of text except read them.
• Is not locked in to a proprietary vendor database; data should be in an open, non-proprietary format.
• Is a continuum of our health information across all aspects of healthcare and related activities, not fragmented silos of data artificially segmented for personal, clinical or secondary use purposes.
• Can be accessed via an EHR, EMR or PHR, SEHR or ICEHR - pick an acronym, any acronym!
• Can be accessed independent of any specific organizations, providers and geographical locations.
• Has had minimal transformation or manipulation. Keep in mind the Chinese Whispers effect! There is significant risk that important data can be lost or lose integrity with each data migration to a new software application or transformation between disparate systems.

It is a commercial reality that we continue to develop EHR applications in the traditional manner, building the greatest and 'best of breed' clinical software applications, with each EHR vendor doing it in their own proprietary way, as 'rugged individuals'! The resulting software usually has a rich functionality and a great user interface. It is likely that it does a fine job locally in the clinic, hospital or network on which it is installed. But what about regionally, nationally, internationally? Is it still working well if we take the big picture view? Sure, our EHR applications are full of data, but the data is isolated, fragmented, and limited in its use.

There is no doubt that all over the world, the health IT community are finding it unexpectedly hard to exchange health information between different applications - the effort and resources that are being poured into policy, research and pilots for health information exchange is enormous. Progress is glacially slow. If we want to exchange PDFs and documents, then we are doing well, but if we want our software to be able to do more than display text, to do clever things with our health information, then our data requirements are much more complex. If we want that data to be able to be shared, used in multiple applications then the current approach requiring data transformations and messaging paradigms won't be sustainable

Interestingly, the further we go down these paths many are realizing the need to change our emphasis away from the EHR application and towards the data. Back in November 2009, Clay Shirky wrote:

"This ability to separate data from transport and applications from data is the essential pre-condition for innovation — a group that has a valuable new idea for presentation of data for clinical use should not also be forced to think about the data encoding or the way the data are transported. Groups working on new data encodings should not be tied to a pre-existing suite of potential applications, nor should they have to change anything in the transport layer to send the new data out, and so on."

The bolded text, above, reflects my emphasis on an important statement. Confirming this approach, as recently as this week, Kibbe & Klepper also called for separation of the data from the applications and from the transport layer.

Change the focus to standardized, data-driven eHealth

So, innovation requires a new approach to data; a changing emphasis from application- or message-driven to data-driven eHealth. If we also insist on an open and standardized approach to health data specifications then we will be able to realize many additional advantages:

• A strong foundation of shareable and re-usable computable clinical content definitions on which to build coordinated and cohesive applications, messages, clinical decision support programs, and research activities. If we use common, standardized data definitions then the tasks of eHealth become orders of magnitude easier. Content definitions are created and agreed as the content is already specified and the processes become more generic
• An unambiguous and detailed understanding of what each piece of data means so we can do 'stuff' with it - a tight semantic 'handle'.
• A powerful enabler for managing the complex requirements involved in health data capture, integration, aggregation, inferencing and sharing.
• A continuum of our health information, independent of vendor, provider or organization - the real potential for lifelong health records, for the first time.

There is no doubt that this approach is orthogonal to the status quo and it will be challenging to many for logistical, financial and political reasons, but can we really afford to ignore this?

According to the European Commission's seminal 2009 report entitled "Semantic Interoperability for Better Health and Safer Healthcare: Research and Deployment Roadmap For Europe" (PDF, p16), standardizing the capture, representation and communication of clinical data requires three components to represent meaning: a generic reference model for representing clinical data, agreed clinical data structure definitions and clinical terminology systems. Potential standardized data definitions proposed are openEHR archetypes, ISO/EN 13606 Part 2 (which are simpler archetype structures), HL7 templates, generic templates and data sets.  Standardization of data is not 'pie in the sky' but an approach that has had significant research and implementation experience, particularly in Europe.

So, to consumers, clinicians, organizations, researchers and governments, the call should not only be "Gimme my damn data!" but give me standardized data that is application- and message-independent. Then we can actually start to use and re-use our data, not only as a detailed record of current and past health conditions, events and activities, but dynamically and pro-actively to inform and promote our future health and well-being.

PHRs: still a powerful grassroots approach to eHealth

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

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

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

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

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

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

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

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

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

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

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

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