Technical architectures for Personal Health Records

To avoid your PHR becoming a data silo, it should be designed in line with:

• the roadmaps of your local Sustainability and Transformation Plan (STP), or Integrated Care System (ICS), to find out if any regional architectures are being designed 
• the designs of any Local Health and Care Record exemplar (LHCRe), as your decisions need to fit in with its remit to enable PHRs in its area

This will help you to support fully integrated care.

Tethered PHRs are: 

• provided to individuals by a health or care provider, like a local hospital 

• tightly connected to the system the provider uses to manage their organisation 

• often harder to make interoperable with other regional initiatives

An example might be a patient portal provided by the supplier of the hospital’s electronic medical record. 

A tethered patient’s user experience: 

• depends on the functionality available from the provider’s system supplier  

• will change if the provider changes their system supplier

• might need the patient to access multiple PHRs to manage their care, if they're being treated by multiple providers  

• offers no control for what the patient can do with the data about them, as it’s managed by the provider organisation 

• means patients can only interact with it in the way offered by the provider’s tethered system 

A tethered provider: 

• has a commercial relationship with a single supplier, for its system and PHR  

• can reduce the integration work needed to implement the PHR  

• will be more dependent on one or limited suppliers, which increases the risk of being locked in to a vendor 

• will base their patient engagement plans on what’s available from those suppliers

Untethered PHRs: 

• are the opposite of tethered PHRs  
• are standalone systems, provided by a health and care provider, or by an outside company  
• give individuals control over the data they collate and store
• give individuals control over who they share that data with, including health and care providers 

An example might be a medical data store on a phone, that an individual can use to share their health data with other apps or people. 

An untethered patient’s user experience: 

• is dependent on the functionality available from the PHR 
• is not restricted by the functionality of the organisation’s internal system, such as an electronic medical record 
• will not change if the provider changes their internal system 

An untethered provider: 

• can have different independent suppliers for its internal systems and PHR, giving the flexibility to implement the best approach  
• might face additional work and cost to integrate systems, if the PHR supplier hasn’t previously integrated with the internal system  
• will be less dependent on one supplier for their IT 
• can develop their PHR plans independently to their internal system plans

Untethered integrated PHRs are where health and care professionals can see information contributed by individuals, without having to access a different system to the one they use to see clinical information . 

Integrated PHRs allow patients to: 

• receive information into their PHR from health and care providers, over time, to build a complete view of their health and care, that includes information they’ve recorded themselves 
• choose and use the best health and care apps that meet their needs 
• reuse data across other apps, saving them from having to re-enter the same data multiple times 
• control what apps and which people have access to their data 
• reuse one set of user credentials across all their apps, making it easier to remember them  

Integrated PHRs allow providers to: 

• use off-the-shelf apps with individuals and integrate this information into the clinical or social care system 
• do a single integration with the PHR data platform, rather than integrate with each app 
• access information provided by an individual, as well as the information in their internal system, such as an electronic medical record 
• see all of the individual’s data and how the care provided is affecting that person’s health and care  

Untethered standalone PHRs are the opposite of untethered integrated PHRs, as:  

• they rarely have integration with internal systems used by health and care professionals 
• professionals must log into a separate system to access the data, if an individual has allowed it 

Standalone PHR applications:  

• allow individuals to choose and use the best health and care apps that suit them and their needs 
• might need individuals to enter the same data many times, into each app that they use, such as for blood pressure readings  
• might have to create and remember a separate username and password for each app they use, which could become difficult to manage 

Standalone PHR applications:  

• allow professionals to use off-the-shelf apps with individuals, which can mean starting to use them without waiting on integration 
• isolate data in the standalone apps, making it unavailable to the provider, preventing a full view of the individual
• will typically need professionals to create a separate username and password, to access patient information for each app 
• store data outside the medical or care record, meaning that other professionals would need separate access to the app to view the data 

There are 8 typical PHR architectures. These are sometimes also known as archetypes.

They are useful when planning or designing how to implement digital health and care tools, which allow individuals and professionals to share information.

We’ve found from our research that PHR implementation might combine more than one archetype. 

An organisation uses a system to run its organisational workflow and enables individuals to view some information it holds about them.  

For example, a healthcare organisation with an electronic medical record system used by health professionals, giving access to patients.  

Some tethered portals also allow the individual to perform a limited set of transactions. For example, to book an appointment or order a repeat prescription.

An organisation provides a limited number of apps or devices to individuals, which integrate directly with the organisation’s professional system.  

For example, a hospital might provide patients with a diabetes management app and a blood glucometer device, but the information from these devices is transferred for storage in the hospital’s electronic medical record (EMR). 

The app and glucometer might have to integrate with the EMR using methods defined by the supplier, in the absence of national standards.

An organisation offers a digital tool, like an app or a website, to individuals, but this tool doesn’t: 

• integrate with any professional systems 

• store any data it holds in a way that other apps can reuse it 

If professionals want to access the data provided by the individual, they have to access it through a different tool to their normal system.  

For example, a Clinical Commissioning Group offers GPs a diabetes self-management app to prescribe to patients, but the GP: 

• has to use a separate system to monitor those patients using the app 

• can’t monitor them through their own GP Practice system

This is similar to the standalone app archetype, but the individual can choose to reuse their data across more than one app. The apps aren’t directly connected to any professional system. 

For example, a Chronic Heart Disease (CHD) app records an individual’s blood pressure and stores it in the Apple HealthKit data platform.  

The individual uses another app to manage diabetes, which also is connected to Apple HealthKit. The same blood pressure data recorded in the CHD app is available to be reused by the diabetes app. 

A diabetes nurse accesses the blood pressure readings through the app, as there’s no access from their clinical system.

The individual downloads their health and care information from a professional system, like a secure hospital portal, as a structured file.  

This file can be uploaded to an app, for individuals to view the information themselves, or share it for their on-going care.  

An example of this archetype is the ‘Blue Button’ structured data format used in the USA.

Data are shared between a network of apps on a one-by-one basis.  

Data sharing contracts are created between each sending and receiving app.  

The individual accepts terms and conditions in the sending app, to authorise sharing their data with the receiving app.  

Health and care professionals access the individual’s data through the professionals interface available in one or more apps within the network.  

An example PHR network of apps is Withings Health Mate, My Fitness Pal and RunKeeper.

An individual stores their data in one place online and reuses this data across several apps. The individual is in control of how the data are shared. 

Professionals connect to one place online from their professional system, to get access to the data collected from these apps, rather than connecting with each separately. 

An example aggregator is Apple HealthKit, getting readings from a connected Blood Pressure monitor and the readings being available in a connected GP app.

This is an evolution of the PHR aggregator archetype.  

Data are collated in one place online, for the individual to reuse across other apps.  

The data are synchronised into the professional system, for technical, medical audit or analysis needs. 

The synchronised data are: 

• managed by the professional 

• not affected if the individual later deletes their copy