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.
Provider systems may have to additionally provide a query API that can return historic records. A consumer system may ask for historic records via a data constraint such as
effective=ge2020-05-11, i.e. records dated from 11th May 2020.
Where a federated shared record only returns 'current' data by default then a bespoke query parameter such as
history=true may be an option.
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.
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.