Patient Care Coordination (PCC) Implementation Guide - Local Development build (v0.1.1-current) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
Patient Summary which is often presented as a clinical document and this is broken down into document sections
Patient Record Detail which gives deeper insight into the patient's health and is often queryable.
Shared Patient Records Overview
Most electronic patient records (EPR) are structured similarly around the entities listed under Patient Record Detail.
Use Cases
Actors / Systems involved:
Practitioner client application – the interface the healthcare professional uses.
PDS – Personal Demographics Service, used to look up patient details.
GP Connect (HTML) – a platform to access GP patient records in a standardised format.
EMIS IM1 – the GP practice’s local patient record system.
VH CDR – another clinical data repository, likely for records not in EMIS IM1.
IM1 PFS – EMIS interface for accessing GP system data (IM1 Patient Facing Service).
Practitioner access—local GP Surgery
Use Case: Local GP Surgery with EMIS IM1
Process flow
Lookup Patient: Practitioner client application queries the PDS to find the patient.
Identify that the patient’s GP practice uses EMIS IM1
Retrieve Patient Summary Record: Practitioner client application sends a request via GP Connect (HTML) to EMIS IM1 to retrieve the patient summary.
Display Summary Record: The summary information is displayed to the practitioner.
Optional – Retrieve Detailed Record (only if the practitioner requires more information)
Practitioner client application can request a detailed patient record from EMIS IM1.
If needed, it can also request additional detailed records from VH CDR for entities not covered by EMIS IM1.
Key points:
EMIS IM1 is the main source for the GP practice’s patient data.
VH CDR is used only when certain entities are missing from EMIS IM1.
Retrieval of a detailed record is optional and only done on demand by the practitioner.
Practitioner access—out-of-area GP Surgery
Use Case: Out of area GP Surgery
Process flow:
Lookup Patient: The practitioner client application queries the PDS to locate the patient.
Identify GP practice system: It is determined that the patient’s GP practice uses EMIS IM1.
Retrieve Patient Summary Record: Practitioner client application requests the summary record via GP Connect (HTML).
Display Summary Record: The summary information is presented to the practitioner.
Optional – Retrieve Detailed Record: If the practitioner needs more information, they can optionally request a detailed record from VH CDR.
Key points from the previous use case
This does not query EMIS IM1 directly for detailed records.
All detailed record retrieval (optional) is routed via VH CDR only.
This reflects an out-of-area scenario, where the GP’s own system isn’t directly accessible for more detailed data, so the VH CDR is used instead.
Patient access
Use Case: Patient registered at EMIS practice
Process flow
Lookup Patient: The patient’s client application queries PDS to locate the patient.
Identify GP practice system: It is determined that the patient’s GP practice uses EMIS.
Retrieve detailed record (initial retrieval): The application requests a detailed record from IM1 PFS.
Convert to summary record: The detailed record from EMIS is processed and converted into a summary record.
Display Summary Record: The summary record is displayed to the patient in the client application.
Optional – Retrieve Detailed Record (as required by patient): If the patient requests it, the system can:
Retrieve a detailed record from IM1 PFS (directly from EMIS).
Retrieve a detailed record from VH CDR for data held outside EMIS.
Key points from the previous use cases
The default retrieval for patients starts with a detailed record from EMIS, which is then summarised before display.
Patients can optionally request the full detailed record instead of just the summary.
VH CDR serves as an additional source for records that may not be available in EMIS.
Interfaces
Virtually uses a variety of interfaces to access data for both the Patient Summary and Patient Record Detail. Due to information governance such as user type (patient, pharmacist, GP, admin, etc) and organisation/care setting, which interfaces can be used varies.
All the external interfaces we use are facaded to use HL7 FHIR RESTful APIs to give consistent access to the data and are adapted to use the same Canonical Data Model which is detailed in this implementation guide as Resource Profiles.
Where practical, we have also followed international best practice in particular:
Are normally persisted as Observations, where the questions and answers are stored as individual Observations (code = the question and value = the answer). For more details on this pattern see FHIR Structured Data Capture.
Where the questions are not clinically coded (and there is no need for being able to query the questions), then these templates will often be persisted as is (i.e. FHIR QuestionnaireResponse).
Storing questions and answers as Observations is a good practice for clinical data, as it allows the data to be reused and is searchable in other contexts. UI/Data Capture focused persitence (i.e. Forms/Templates/Assessments/FHIR QuestionnaireResponse) is considered an architecture antipattern.
