FHIR® Conformance

Owned by Andrew Turner (Unlicensed)
Last updated: Dec 06, 2022 by Tom Pick (Unlicensed)
3 min read

Welcome

Welcome to the Patients Know Best FHIR® Conformance registry.

If you are looking for more general information about how to interact with the various FHIR endpoints supported by PKB, please see our introductory FHIR documentation.

Canonical URLs

Whenever PKB assigns a canonical URL to a FHIR concept, such as a custom search parameter or code set, then where possible this URL will resolve to a helpful page within this set of documentation.

For example, whenever we need to support the PKB-defined privacy labels in one of our FHIR endpoints we will typically represent that information as a Coding with a system of http://fhir.patientsknowbest.com/codesystem/privacy-label. That URL not only serves as a namespace identifier for the code value that can be checked programmatically, but will also resolve to a dedicated page within this documentation that explains where the code value comes from, and links out to other helpful information.

This set of documentation is currently hosted as HTML only. You are not able to retrieve a corresponding FHIR resource in a computer-readable format (e.g. JSON, XML) from this server. However, some conformance resources will be hosted on the server endpoints directly. Where this is the case, an example link is provided underneath the canonical URL at the top of the relevant page.

For example, the PKB-defined status query operation has a canonical URL of http://fhir.patientsknowbest.com/operation/status-query. It is not possible to retrieve a JSON-formatted representation of a corresponding OperationDefinition from this server, but the HTML page provides an illustrative link to the corresponding OperationDefinition on one of our production endpoints which supports this operation. The OperationDefinition can be retrieved (without authentication) from https://my.patientsknowbest.com/fhir/OperationDefinition/Patient-t-status-query?_format=json

Profiles and extensions

The conformance resources outlined in this documentation cover several different concepts, such as custom code systems, search parameters, and operations. Some are used by just a single endpoint type, whilst some are used across multiple endpoint types. However, they are all defined by PKB (i.e. they are taken from the fhir.patientsknowbest.com domain) and as such they will resolve to pages in this single set of documentation, which captures all PKB-defined FHIR conformance resources.

Profiles and extensions are both captured as StructureDefinitions, and deserve a special mention.

Extensions

Extensions allow PKB to return information that isn't captured by the core FHIR specification. For example, whether or not a patient has enabled the PKB-specific concept of Sharing Disabled is reflected on the Patient resource by the Sharing Disabled extension, identified by this canonical URL:

http://fhir.patientsknowbest.com/structuredefinition/sharing-disabled

Extensions are typically simple enough in structure that they can be re-used across all our different FHIR endpoint types without problem. For example, this single extension definition might be returned from both our Aggregated and Facade endpoints.

As a consequence, the naming conventions used for such extensions do not include a specific endpoint type.

Profiles

A more complex set of rules defining supported content across an entire resource are known as a "profile", and are also represented using a StructureDefinition resource.

For example, the information you should expect to receive in an Appointment resource from our Facade endpoint is defined by the PKB Facade Appointment StructureDefinition, identified by this canonical URL...

http://fhir.patientsknowbest.com/structuredefinition/facade-appointment

...whilst the information returned in an Appointment resource from our Aggregated endpoint might conform to the PKB Aggregated Appointment StructureDefinition, identifed by this canonical URL...

http://fhir.patientsknowbest.com/structuredefinition/aggregator-appointment

Since the supported content differs across our endpoint types, a profile is specific to the endpoint type that will make use of it.

As a consequence, the naming convention for such profiles do include the endpoint type that will make use of them.