...
Both extensions and profiles are represented by a FHIR StructureDefinition resource. The StructureDefinition page provides an overview of the PKB extensions and profiles.
How does source tracking work?
Resource types sent to a Customer FHIR endpoint which are to form part of the patient’s record always have some way of referring to the patient (e.g. Condition.subject, Appointment.participant). The Customer can optionally declare the source of such data by ensuring the target Patient resource uses Patient.managingOrganization to refer to an Organization which represents the source of the data. The PKB web interface will display the name of this Organization as the “source”. Note that in this way a single Customer can provide data from multiple Organizations on the same endpoint.
If no managingOrganization is present, the PKB web interface will not display any source information.
The details of the managingOrganization are controlled by the Customer; this information is not authenticated by PKB.
The managingOrganization is not populated on a Patient returned from the Aggregated FHIR endpoint, because Patient is a resource type that is merged and source-tracking on merged resource types is handled differently (see below).
meta.security contains a code that indicates the resource ID of the relevant source entities. For data sent to a Customer FHIR endpoint, this code represents an implementation optimisation, removing the need for a caller to fetch the chained managingOrganization. For data migrated from a non-FHIR input route, the migration process will ensure this code is populated correctly. Note that these codes are not populated for resource types that are merged, because source-tracking on merged resource types is handled differently (see below). The possible code systems are:
source-organization (note that this refers to a FHIR Organization resource which may or may not correspond to a PKB Organisation)
source-patient
source-practitioner
source-team
The http://fhir.patientsknowbest.com/structuredefinition/upstream extension adds an additional level of source tracking, by tracking which of the upstream endpoints the information returned by the Aggregated FHIR endpoint actually came from.
For resource types that are not merged, this extension is added to the top level of the resource. Unlike the managingOrganization details (and hence the the resource ID codes found in meta.security) the upstream extension does represent authenticated information (i.e. connections to the Customer endpoint are authenticated; this extension captures the identifier of the endpoint, which is not within the control of the sender).
For resource types that are merged, this extension is added to each element that gets added to the merged resource returned from the Aggregated FHIR endpoint. If multiple sources have the same information, it is possible for there to be multiple upstream extensions on the same element.
The extension contains 2 elements:
upstream-source-id. A textual identifier of the upstream endpoint on which the source resource can be found.
upstream-resource-id. The resource type and resource id of the upstream source resource (e.g. Patient/d9190fed-382d-40ee-bf50-f9ce23981cfc)