In a series of articles reflecting on 10 years of working with personal health records (PHRs), Kevin Hamer – who works as a freelance digital consultant and has spent 30 years in NHS IT innovation – starts with what they should look like.

The NHS Digital website carries a definition of what a personal health record is. It can be found here and is summarised as follows “a record is a PHR if”:

  • it’s secure, usable and online
  • it’s managed by the person who the record is about and they can add information to their PHR
  • it stores information about that person’s health, care and wellbeing
  • health and care sources can add information to the PHR

I have always found this ‘what is a PHR’ definition useful and it goes on to give useful advice on what anyone developing a PHR should consider but it does not mandate any particular aspect. The difficulty with this is that suppliers are in a position to ignore the advice but can still call their offering a PHR if it meets the bullet pointed definition.

What does a good PHR look like?

The PHR market and co-production initiatives are growing – this can be evidenced through the increasing functionality in the NHS app and conference stands showcasing more patient-facing services than seen before. I think this increasingly evolving space demands a revision of not only what is useful but what is needed. ‘What does a good PHR look like’ is perhaps a better question.

I think that use of NHS Login should be mandatory. We tend to dislike mandates that can mean anti-innovation but the NHS login is a perfect example of a sensible mandate. The NHS login should be rightly lauded as a real success and I increasingly see procurement documentation for PHR-like solutions demanding this as standard. We have a single federated identity, the creation or use of alternatives is nonsensical and I wouldn’t consider a patient facing solution to be a PHR if it didn’t have the national authentication service at the front door.

Untethered platform and ‘single use’ applications

The storage of all data on a single untethered platform that separates data from the application  would be next on my definition list. A patient portal built, for example, on top of an EPR should not be considered a PHR. My experience is that if the platform isn’t dedicated for PHRs, then it is difficult to implement transformational pathways via the platform.

I further worry that the current PHR definition means any healthcare application. This broadness opens the door for a proliferation of ‘single use case’ applications. The existence of such applications for dedicated purposes is not necessarily a bad thing but they are often disconnected, not using the NHS login for authentication and only store limited data for a particular condition. As a result, I don’t think these solutions should be considered a fit-for-purpose PHR.

On interoperability, we must also strive to define what good looks like. There have been instances where a supplier can state “we have FHIR APIs” and this is interpreted as acceptable interoperability. A good, useful and used PHR is typically a complex record and integration to other systems is not a simple business. I would ideally like to see a interop strategy from any supplier that details ‘this is our open approach’ with case studies that evidence such interop.

Delegate access and integrating the ‘every day’

A personal health record must also be fit for purpose in supporting the changes in the patient pathway and the patient’s condition over time. This demands the inclusion of functionality to delegate access to the record. There are a large number of care pathways that require not just the patient to interact with the service but also family and carers, sometimes on behalf of the patient. At the early stages of life we have digitised maternity, ‘red book’ and child health services and use cases that need delegated access go right through to degenerative conditions and end of life care.

A delegate access function not only enables others to have management of the record at appropriate times but also allow the records subject to add/remove access when needed. There must also be process to allow for safeguarding incidents that can adjust delegated rulesets appropriately. At this stage, it might all start to sound a bit complex but I’m afraid, if we are to do this properly and safely, it is complex.

Finally, a PHR needs to offer simple integration to consumer wearables and apps that are part of our every day. The proliferation of apps and devices can again mean that this is potentially complex and not necessarily easy. However, when considering what clinicians and patients want – a holistic view of the patients health in a single record – I feel this is a necessity. I have seen one supplier take the approach of integrating their PHR platform with the cloud platform of each app/wearable supplier. This eases the burden as it enables all devices/apps that store data on the supplier cloud to automatically integrate with the PHR and somewhat simplifies the effort involved.


In consideration of everything discussed here,  I propose an updated set of bullet points for our PHR definition:

  • it’s secure, usable and online – accessed using NHS Login
  • it stores information about that person’s health, care and wellbeing
  • the information is stored on a dedicated untethered PHR platform
  • it’s managed by the person who the record is about and they can add information to their PHR
  • management can be delegated to others when appropriate
  • health and care sources can add information to the PHR, , including integration with consumer health care apps/devices