Skip to main content

Technical architectures for Personal Health Records

There are two types of Personal Health Records (PHRs): tethered and untethered. There are also 8 typical PHR architectures.

Fit in with regional strategies

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

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

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

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

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 

Typical PHR architectures

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. 

1. Tethered portal

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.

Tethered portal pros and cons

Tethered portals support pathways where: 

  • you want to provide patient record access with minimal organisational input or effort 
  • you haven’t built your electronic medical record (EMR) or shared care record yourself, using the best components available from different suppliers 
  • your EMR or shared care record system provider has a patient portal product, or a compatible 3rd party product is available 
  • your organisation is comfortable storing any citizen-provided information within your own systems 
  • providers do not wish to log on to a separate system to get access to data provided by citizens
  • you don’t have any plans to move your EMR or shared care record to another platform supplier 


They don't support pathways where: 

  • provider organisations want to use this solution for cross-organisation or cross-regional data sharing 
  • data capture from citizen-provided devices is anticipated

Tethered portal architectural considerations

Tethered portals are: 

  • low risk, as no bespoke integration is needed 
  • simple to implement 
  • a one-size-fits-all solution 
  • dependent on the supplier having a suitable product
  • a potential tie-in to the supplier


Be aware that:

  • you must make sure your organisation has access to the data in the system through open application programming interfaces (APIs),  to prevent risk of lock-in 
  • any change of your shared care record or EMR will change the tethered portal, due to the tight coupling between the two systems 
  • you need to check how this approach aligns with the Local Health and Care Record (LHCR) plan for PHRs across all providers in your area, if your organisation is part of a LHCR programme

2. Point-to-point apps

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.

Point-to-point app pros and cons

Point-to-point apps support pathways where: 

  • a limited number of applications or devices are to be used by citizens 
  • citizens do not need a copy of the data they have provided for other uses 
  • apps or devices are being provided to the citizen directly by the provider 


They don't support pathways where citizens need the choice of which apps or devices are used to capture data that feeds into the health and care system.

Point-to-point app architectural considerations

Point-to-point apps:

  • need a secure bespoke or 3rd party data access mechanism to be implemented by the provider, if your supplier doesn’t provide open APIs  
  • need additional integration effort for 3rd party app suppliers 
  • need providers to identify and separately authenticate each patient using each app, if the applications do not support the NHS login authentication service
  • might be tied to the EMR platform, which would restrict choice 

3. Standalone app

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

Standalone app pros and cons

This pattern applies to your solution if: 

  • you need to capture data from the citizen
  • your organisation wants to capture information from the citizen without waiting for EMR or shared care record integration 
  • you do not have integration capabilities in your organisation, or you do not wish to purchase these capabilities from a 3rd party organisation
  • a suitable app exists which provides a separate provider interface  

Standalone apps support pathways where: 

  • the data being collected does not need to become part of the clinical shared record
  • an existing application is particularly suitable for the pathway
  • no digital clinical system exists for the pathway 

They do not support pathways where: 

  • access to the citizen supplied data is needed through the EMR or Shared-Care Record 
  • the data being captured by the citizen through the app needs to be shared with other apps used by the citizen

4. Standalone PHR

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.

Standalone PHR pros and cons

Standalone PHRs supports pathways where: 

  • citizen-provided data is needed by the provider, but no suitable data repository is available within the EMR or Shared-Care Record
  • integration with the EMR or shared care record is not possible for technical or commercial reasons 

They do not support pathways where providers wish to see all data using the EMR or shared care record as their interface.

Standalone PHR architectural considerations

Standalone PHRs:

  • are quick to get a solution up and running and get value from the PHR 
  • are not dependent on integration with EMR or shared care record 
  • allow data integration to be phased in over time
  • do not have provider single sign-on (SSO) to the application, as providers need to remember another set of credentials to access the patient data
  • allow SSO or access to a provider directory of credentials to be phased in later, as part of integration 
  • might need to restrict access to the provider interface to clinical networks only

5. Standards-based file transfer

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.

Standards-based file transfer pros and cons

This pattern applies to your solution if:

  • a national or cross-organisational data transfer standard has been defined
  • the standard has been adopted by suppliers and there are products available that implement the standard

Standards-based file transfer supports pathways where standardised data transmission formats are defined and adopted by a significant number of supplier organisations supporting the pathway.

Standards-based file transfer architectural considerations

Standards-based file transfer typically:

  • supports downstream data dissemination from provider to citizen, or provider to provider
  • can be used for dissemination from citizen to alternative provider

6. PHR network

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.

PHR network pros and cons

PHR networks support pathways where:

  • a flexible approach to the apps used by the citizen is needed
  • established app or device ecosystems currently exist for the pathway  

They do not support pathways where a mandatory set of data is required from the citizen.

PHR network architectural considerations

PHR networks:

  • allow you to mix and match apps from different suppliers, as long as there is a data sharing agreement between them
  • require that data items to be shared are agreed between each sharing and receiving app
  • do not guarantee that data you need from one app will be available to be used by another app
  • can change at any time, when apps leave or join the network 

7. PHR aggregator

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.

PHR aggregator pros and cons

PHR aggregators support pathways where:

  • cross-organisational data sharing is not currently available 
  • barriers exist to sharing data between care providers 
  • citizens need the choice of how they capture their own data 
  • citizens need control of who they share their data with and to what level 

They do not support pathways where: 

  • care providers need a copy of citizen-provided data, if the citizen revokes the provider's access to their patient-held data
  • providers want to control the methods by which citizens capture information 

PHR aggregator architectural considerations

PHR aggregators: 

  • might dictate which citizen authentication providers are available, for example logging in via Facebook 
  • allow citizens, rather than care providers, to control who has access to their personal health data
  • allow citizens to revoke the care provider's access to the citizen's PHR data at any point

8. PHR sync

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

PHR sync pros and cons

PHR sync supports pathways where:

  • cross-organisational data sharing is not currently available
  • barriers exist to sharing data between care providers
  • citizens require the choice of how they capture their own data
  • citizens require control of who they share their data with and to what level
  • care providers need a copy of citizen-provided data if the citizen revoke the provider's access to their patient-held data

It does not support pathways where: 

  • providers want to control the methods by which citizens capture information 
  • providers do not want to be data controller for patient provided data

PHR sync architectural considerations

PHR sync: 

  • might dictate which citizen authentication providers are available, for example logging in via Facebook 
  • allow citizens, rather than care providers, to control who has access to their personal health data
  • allow citizens to revoke the care provider's access to the citizen's PHR data at any point, but the provider retains a copy

Further information

internal Personal Health Records adoption toolkit

This toolkit supports health and care organisations in England to commission, develop or manage Personal Health Records (PHRs) and other citizen-facing tools.

internal Developing a Personal Health Record

Find technical architectures and components, our functionality checklist, review standards and browse information governance guidelines.

Last edited: 19 October 2022 2:29 pm