Provenance operation describes the server-side operations required to populate, cache and return Provenance information (Practitioner and Organisation information) for all Reasonable Adjustment Flag components on Spine via the FHIR® Reasonable Adjustments API
Important: This site is under active development by NHS Digital and is intended to provide all the technical resources you need to successfully develop applications using the FHIR® Reasonable Adjustments API. This project is being developed using an agile methodology so iterative updates to content will be added on a regular basis.
Warning: This site is provided for information only and is intended for those engaged with NHS Digital. It is advised not to develop against these specifications until a formal announcement has been made.
Provenance
All Reasonable Adjustment resources are to be populated with Provenance details on creation to support clinical safety and audit recording.
- Consent and Flag resources are populated server-side.
- Due to their different data structure, Condition resource Provenance must be recorded client-side. The Provenance resources are contained within the List.
NB: List resources do NOT record Provenance.
To illustrate, on Create of a resource e.g. a Flag resource (i.e. an Adjustment)
- ClientSystem submits the practitioner’s URPId as part of the Create request JWT token
- Spine determines Practitioner, Organization details based on the URPId
- Resource’s Provenance is populated with a display representation of the Practitioner, Organization details
- Resource is persisted
- Create response issued to ClientSystem - usually with the created resource as body
[To be clear, on Create, client-side a RARecord Resource will contain no Provenance information.
Similarly, on Update, Provenance information regarding the updater is produced etc. as part of the Update operation.]
Fine detail of the structure and content of the contained Provenance resource is on the Profile page under RARecord-Provenance-1