...
If a resource type is not listed, then upstream resources (e.g. those provided to a Customer FHIR endpoint) are copied over to the Aggregated FHIR endpoint without being combined with any other resources.
What changes does the PKB Enricher make to resources before they are returned from the Aggregated FHIR endpoint?
Before a resource is returned from the Aggregated FHIR endpoint, the PKB Enricher makes the following changes:
Any specialty code for which a display name has been provided by the customer will have the relevant “display” element of the Coding set to that display name. This is a display-time replacement of the value on the persisted resource.
Which resources types can I access from the Aggregated FHIR endpoint?
...
Both extensions and profiles are represented by a FHIR StructureDefinition resource. The StructureDefinition page provides an overview of the PKB extensions and profiles.
What do the different time stamps mean and which ones should I be using?
Independently of any resource-specific content (e.g. the Appointment resource has a “start” element to indicate when the appointment starts), there are some metadata timestamps which can be found on most resources. These are outlined below.
May be sent by a Customer
This captures a human-centric time stamp of when this information was entered into the source system. When PKB migrates non-FHIR data to FHIR format, this extension is used for both [[Data Point.Entered Timestamp]] and [[Version Details.Entered Timestamp]], which capture equivalent concepts.
This is useful for determining how current the information is.
This is not affected by database maintenance tasks (re-migration and re-aggregation).
This extension can appear in meta.extension or on a specific element within the resource.
Customers may provide this extension (on the meta element only)
Must not be sent by a Customer
meta
extension
ex:createdAt
This captures a system-centric time stamp of when this resource was first created.
This is useful for determining when the resource was first available from the Aggregated FHIR endpoint.
This is not affected by database maintenance tasks (re-migration and re-aggregation).
This extension can only appear in meta.extension.
Customers must not provide this extension; this is maintained automatically by the server - any values provided to a Customer endpoint will be ignored.
The value is determined from the upstream resource using conditional logic: recorded-date if available, else meta.lastUpdated
This extension is helpful for use cases that need to:
determine a human-centric modification time stamp without being affected by any database maintenance tasks performed by PKB (re-migration and re-aggregation maintenance tasks will both cause the meta.lastUpdated time stamp to move forward on resources in the Aggregated endpoint, even though the human-centric modification time stamp of the content has not changed)
and determine that time stamp from a single attribute which uses a sensible default such that it can never be empty
Currently only populated on the Appointment resource, which is the only resource type for which such a use case currently exists.
This is not affected by database maintenance tasks (re-migration and re-aggregation).
This extension can only appear in meta.extension.
Customers must not provide this extension; this is maintained by PKB.
This captures when the resource was last updated.
It is useful for determining a system-centric modification time stamp; most real world use cases are likely to find one of the time-related extensions better suited for use in business logic. Since this is not an extension callers can query over this value.
This is affected by database maintenance tasks (re-migration and re-aggregation).
Customers must not provide this value; lastUpdated is always maintained by the server - any values provided to a Customer endpoint will be ignored.
Primarily used for non-clinical entities, this extension captures [[Version Details.Created Timestamp]], which represents the first time this entity was added to the medical record database and is not modified when that entity is changed over time. This is not to be confused with the ex:createdAt extension, which records when the FHIR resource was first created on the relevant server, which could be significantly different because pre-FHIR data will be migrated potentially a long time after it was first created in PKB.
This is useful for determining when the resource/element was first available in the medical record database (which might be significantly earlier than it was first available in the Aggregated FHIR endpoint).
This is not affected by database maintenance tasks (re-migration and re-aggregation).
This extension can appear in meta.extension or on a specific element within the resource.
Customers must not provide this extension; this is maintained by PKB.
This must not be used. It is identical in meaning to recorded-date.
This captures a system-centric time stamp indicating when this version of the resource was persisted into the medical record database, as captured by [[Data Point.Persisted Timestamp]] and [[Version Details.Persisted Timestamp]]. This is potentially significantly different from when it was entered in the source system, or even when it was received by PKB (there might be a processing delay).
This is useful for determining when this specific version of the resource/element was first available in the medical record database.
This is not affected by database maintenance tasks (re-migration and re-aggregation).
This extension can appear in meta.extension or on a specific element within the resource.
Customers must not provide this extension; this is maintained by PKB
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. Optionally, PKB can configure a default Organization to be used when the source is not provided explicitly. 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 informationwill use the default Organization. It is an error for there to be no managingOrganization on an integration with no default Organization configured; every resource sent to a Customer endpoint must have a source Organization.
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 codes that indicates the resource ID of the relevant source entities. For data sent to a Customer FHIR endpoint, this code represents . Customers should not set these values themselves; PKB will ensure the codes are set correctly. These codes are an implementation optimisation, e.g. 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)
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 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.
...