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!Image

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?


5 thoughts on “The ultimate PHR?

  1. Pingback: The ultimate PHR? | Archetypical | Personal Health Records

  2. I think open sourcing is crucial in the future of eHealth, people know what they want, let them create it. I also think it is inevitable, as smartphones influence wanes and new technology replaces it, people will not be satisfied to leave their data behind.

    My those thoughts are that generally I agree as long as they are using the same data structures, interoperability will be easier (but I don’t think ‘easy’ by any means).

    The challenge remains, as with bohemoth systems, workflow. My mother and father, who cannot currently maintain a written list of medications they take on a daily basis are not going to start using a whizz bang new app because it is interoperable, but they just might if it were integrated to their workflow, their daily routine. Cultural change remains a more significant barrier to adoption than interoperability.

    • Hi Dash,

      Thanks for your comment.

      I want to distinguish between open source apps and open source specifications. I am proposing clinical information models built on open source specifications – such that these can be consumed by either proprietary or open source applications.

      Interoperability, by definition, is not easy – I totally agree. Until recently, we’ve approached it by using documents and messages or highly prescriptive messages alone. Now there is some momentum building around clinical modelling development, as you can see in some of my other posts. And despite the 20 years of R&D behind it, we are still in a relatively immature phase of practical model development – yet I am confident it is achievable in a realistic timeframe and not another 20 years before we get there!

      Workflow will make or break any application, totally agree again. It clearly has to be anticipated in design of the models, but will not be solved by the data structure alone.

      Cultural change is going to be a long slow process, as will be optimising user interfaces and learning how to make apps ‘sticky’ such that consumers keep using them. So much to learn!



  3. Heather, I immensely agree with your concept. It fits perfectly with what I’ve been talking and writing about in the past years (see: Patient 2.0 Empowerment
    The most “complicating” part is your remark: “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”. Once again, I totally agree with the concept that all elements have to be standardized in the same way as I have often pointed out that one record (EHR) can not exist without the other (PHR). However it also means that (output of) all devices will have to comply to similar standards, and when they are used for medical purposes devices/apps will have to be officially calibrated.
    As Dash correctly pointed out, awareness and education of both professionals and citizens will be a major part on how we can get this concept working.

    • Totally agree, Lodewijk – working on it! CKM and its archetypes are our not-so-secret weapon, so not entirely a ‘pie-in-the-sky’ idea. Standardisation of device data, or at least archetyping of specific device outputs until they are standardised, are part of archetype design scope as much as possible.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s