Core technical components of Personal Health Records (PHRs)

Personal Health Records (PHRs) are formed by different types of technical components.

These include:

• security services, for audit, authentication, registration and access authorisation 
• user functionality available to patients, including trusted information sources 
• data services, for data storage, data access using APIs and data synchronisation 
• device connectivity, for connecting services 

Audit 

A PHR should offer citizens the ability to see a record of who has accessed data in their Personal Health Record.  

This should give the citizen confidence that their data has been used appropriately. Citizens can remove access from those they no longer want to share their information with. 

This audit data should include: 

• use by any other apps that have been authorised by the citizen to access their data 

• what types of data have been accessed 

Authentication 

Citizen authentication 

Citizens need to prove their identity, to access and contribute to their records securely.  

NHS login is a service that offers citizens a way to prove who they are and to create a secure digital identity.

This identity can then be used to access any digital NHS services which use NHS login, including PHRs.  

A PHR should use NHS login. Email [email protected] to register your interest in using NHS login in your PHR. 

Health and care professional authentication 

Health and Care Professionals (HCPs) might directly access the citizen data in the PHR, with the citizen’s permission. 

Each HCP’s identity needs to be verified to securely access this citizen data. 

NHS Identity is a service being created to prove the digital identity for HCPs and should be used by your PHR once available. 

Registration

The citizen needs to register onto your PHR platform, to have an account on it.  

This registration process is simplified for PHRs that use NHS login, as most of it is completed when the citizen registers for it.  

An NHS login digital identity might not be enough alone to grant a citizen access to a PHR. That access might need to be authorised by clinicians. 

The PHR provider will need to develop a way for that access to be authorised.

Access authorisation

The PHR should also provide the citizen with a way to choose: 

• to share all or some aspects of the information in their PHR, with others that they choose to authorise  

• the level of access that others will be granted, like read-only access or write access 

Health and care professional should be identified by their NHS Identity, when granting them access. 

Family, friends and carers gain access differently, such as by an email invitation. 

Data-driven functionality 

Some PHRs are solely databases of health and care data used by the citizen, but are not apps themselves. The data is accessed through an app, outside of the PHR. 

Apple Healthkit for example is a database of health information for a citizen. It can be used by more than one app, but it doesn’t provide any user functionality itself. The functionality is provided by whichever app the citizen chooses, like the Apple Health app or a fitness tracking app. 

Some PHRs provide both the database of health information and ways to access and use it, like Patients Know Best or My Medical Record. These PHRs also allow access to the data from other apps. 

You can find more details in our PHR functionality checklist.

Trusted information sources 

Data displayed in the PHR doesn’t necessarily help citizens to understand what it means. Any information shown alongside the data will need to be trusted, evidence-based medical information.  

Showing a list of medications on their own for example doesn’t help the citizen to understand what those medications are trying to treat, or what any side effects might be. 

Your PHR should use content from the NHS website where available and other content assured by the NHS Information Standard where appropriate. NHS widgets and tools are also available to add to your PHR. 

Visit NHS APIs on the NHS API Developer Portal to find details of how to pull in content from the NHS website. 

Data storage 

Your PHR will need a way to store information so that: 

1. it can be retrieved 

2. the source can be verified 

The data storage should assure those using the data that it has not been modified since it was originally written, or shows when and by whom if it has been modified. 

Data access

Data stored in the PHR must be retrievable and usable by third party applications, through an open API (application programming interface).  

Open APIs are publicly available for developers to access. These allow other authorised applications to read from and write to the PHR.  

The API provided by the PHR should be based on HL7 FHIR (Health Level 7 Fast Healthcare Interoperability Resources) and use HL7 FHIR APIs tailored for use in England.  

These are known as CareConnect Profiles and are being defined by INTEROPen, a collection of NHS organisations and suppliers, to define interoperability standards using FHIR for PHRs and other systems.  

Data synchronisation

Some or all of the citizen data held in the PHR might need to be copied into a clinical system, or regional data platform such as a LHCR (local health care record). 

This would depend on your approach to interoperability, your chosen PHR architecture and the citizen having given their permission. 

Your PHR would need to provide a component that synchronises data between those platforms.

PHRs will allow citizens to store information they are recording from other apps and wearable devices, like continuous glucose monitors or heart rate monitors.  

This will allow clinicians in the citizen's care team to view how the citizen is managing their health. 

Organisations providing PHRs will need a way for those tools to connect securely to the PHR platform, so that the data can be uploaded automatically. 

You can integrate with devices individually, or there are suppliers that can offer integration with a wide range of devices as a service. 

These apps and devices should adopt open interoperability APIs. This will allow data to be uploaded from these apps and devices, without the need for additional software.