The shared record persists no data. It acts as a query proxy. Provider systems each expose a query API onto their patient records. Consumer systems query the shared record, which queries each provider system, amalgamating the results to present a consolidated response back to the consumer system.
- Simple, therefore likely to succeed, especially as an initial implementation where provider systems are available to query, e.g. via GPConnect for England General Practice systems.
- Records are stored once, within provider clinical systems, so no complex update or delete processes when the provider system is your clinical system.
- Consumer systems always access the latest/current data.
- Complex update processes when the provider system IS NOT your clinical system.
For example, if an allergy record shared by a system needs to be updated by another clinician from another care setting. The original record cannot be remotely updated, leaving two options;
- Implement a parallel process, manual or integrated, enabling one clinician to request a change to a record owned by another clinican who is using a different provider system.
- An updated record is created by the clinician and made available to the shared record. If the old and new records can be logically linked plus, if possible, marked as superseding, then the shared record can show these records as previous/current. What must be avoided is consumer systems treating these records as separate or duplicate. The specifics of how this could be done using the FHIR standard are being worked through.
- Consumer systems are always accessing the latest/current data, what is the definition of 'current'?
A consumer system may query by date, e.g.
effective=ge2020-05-11, which would return records dated from 11th May 2020. See the Query for Current Medication section within this guidance for a definition of 'current medication'.
- Resilience and availability of provider system query APIs.
If a provider system query API is temporarily unavailable then data from that system will not be accessible. The query response to the consumer system should include information for which provider system(s) were unable to be queried.
- Provider systems may be inconsistent with how they have implemented a standard such as FHIR.
Aligning to this implementation guidance will help mitigate against this risk. Some provider systems may expose medicines records events using transactional FHIR resources such as
MedicationDispense. Some provider systems may expose medicines records as
MedicationStatement resources, based on the underlying transactional FHIR resources such as
MedicationDispense. Some may do both, as is the case for the GPConnect implementation within England, that returns both
MedicationStatement resources for the patient's current medication.