What is a personal health record anyway?
- 20 October 2022
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.
Summary
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
5 Comments
1. Clinical records but also patient-contributed information, messages and correspondence, wearable data
2. Clinicians, patients and their carers
3. NHS providers (GPs and hospital clinicians), patients (especially those managing a long-term condition), their carers. They are in widespread use across the country
4. Technical standards to ensure data is held and exchanged using open formats. Untethered means it’s not part of an EPR but receives data from one or more of them – if the EPR changes an untethered PHR remains.
5. Clinical records – clinicians. Patient-contributed data, patients.
6. Yes interoperability is vital.
1. Yes thre is overlap. You don’t hold all EPR data in a PHR and you don’t take all PHR data into a PHR
2. A PHR is owned by the patient but can be managed by healthcare providers. The access is controlled by the patient. They obviously can access it themselves.
3. Known successful pathways are long term conditions where a patient is monitoring/managing in conjunction with a care teamor short term stuff such as an exchange of information on an episode of care such as hospital stay – may avoid a follow up appointment.
4. There are no absolute standards but exchange should be using things such as FHIR. An untethered platform is one the is not bound to a healthcare systems such as EPR and is therefore independent, so can be used to link to different apps or organization.
5. All inputters of data are to an extent responsible for its accuracy. It is important that authors data cannot be simply edited or overwritten.
6. Yes but that isn’t always the case
7. Your views are not worthless, but it is important to realise there is more in this than just a store and a view of data. In other words, the patient only tends to see what is going on on the surface.
Adrian
I am confused:
1. Give me some examples of data held in a PHR. Is there an overlap with stuff held in an EPR?
2.Who can access a PHR?
3 Quote me some people who actually use a PHR? Are the y GPs, Hospitals or what? Is their use widespread, or is it just a cult of enthusiasts?
4. What standards are used by the PHR “community” ( if there is such a thing as a PHR community)? What on earth is a “dedicated untethered platform”?
5. Who is responsible for the accuracy and usability of the data in the PHR?
6. Surely, interoperabilty has to be vital, if PHRs are to be useful at all to anybody?
7.Or have I got the wrong end of the stick, and my questions are rubbish? I am just a patient, and my views are therefore worthless!
There’s another important considertion: who is responsible for taking action in a PHR?
e.g. the patient – who “owns ” the PHR & controls who can access it – adds BP readings which are dangerously high, & require intervention.
Who has the responsibility to intervene or initiate the intervention?
& who is responsible if the patient entered data is *not* followed up & acted upon if there are adverse consequences for the patient?
If PHRs become common – & the “one truth” patient medical record – there will need to be a corresponding reorganisation of the clinical responsibilities – & systems to ensure that those with clinical responsibility don’t miss important additions to individual patient’s records, where there is no agreement as to who is responsible for such action.
I was expecting to see an example of the PHR you were about to describe. I am still none the wiser. Can you provide an example of what you envisage please.
Comments are closed.