FHIR Data Standards Wales for PSOM v1.0.0-rc3
Important: This is the release candidate of the FHIR Data Standards Wales for PSOM version 1.0.0-rc2 Implementation Guide. It is intended for trial use, and is published for early comment and feedback. Click here to give feedback.

PSOM FHIR Data Model

Data Model Overview

To provide guidance on how to map DSCNs, LPDSs and their Metadata concepts to HL7 FHIR, several use case-specific profiles have been created. These profiles have a traceable relationship with their Metadata DSCN counterpart(s) based on the element mapping mechanism in FHIR. The version of the Metadata DSCN used for the mapping is registered in the StructureDefinition.mapping.identity element. To relate a FHIR profile element to a concept from the Metadata DSCN, the Item Reference (e.g. MPRPX004X) is defined in the ElementDefinition.mapping. Certain Metadata DSCN elements map to an element within an existing generic profile as defined by Data Standards Wales, but these mappings are not present within those profiles. In such instances, an implicit mapping is added to the use case-specific profiles instead. These additional implicit mapping provide information about where the Metadata element is populated within the generic profiles.

The diagram below gives an overview of what FHIR resources are needed and how they are linked together for the collection and processing of PSOM data.

The FHIR data model consists of the resources:

  • CarePlan
  • Task
  • Patient
  • Organization
  • Practitioner
  • Location
  • Questionnaire
  • QuestionnaireResponse

For the CarePlan, Task and QuestionnaireResponse resources, specific PSOM profiles are created to capture elements of the Clinical Circumstance as well as the Collection Event, while several PSOM-specific Questionnaire instances have been created which represent the different PROMs Tools. The Patient, Practitioner, Organization and Location resources are based on existing Data Standards Wales Profiles and are used to capture administrative metadata.

DataModel

The responsibility for creating and populating resources in the data model is divided between the Health Board and the PROMs provider. The Health Board is responsible for generating the CarePlan, Task, Patient, Practitioner and Organization instances. The PROMs provider is responsible for creating the Task, QuestionnaireResponse, Organization and Location instances. Each party populates different elements of the metadata.

Note however that the above only specifies which party is initially responsible for populating the relevant elements. Both parties should be able to update existing resources, for instance whenever a PROM has been completed, the PROMs provider should be able to update the corresponding Task resource accordingly.

FHIR Resources

CarePlan

The DataStandardsWales-PSOM-CarePlan profile represents a patient’s Clinical Circumstance. Each CarePlan resource is used to group Collection Events and provides context by specifying the Pathway Type, the Referral ID and the Treatment Specialty.

The CarePlan may also point to resources that hold information on a patient's planned or performed appointments and performed procedures. This clinical-related information may function as a trigger for the PROMs provider to determine the appropriate scheduling of PROMs collection. The Originating Organisation is mapped to the .identifier.assigner of the CarePlan, as it plays an organising function throughout the Clinical Circumstance and provides the content of the CarePlan. The Senior Responsible Professional is the author of the CarePlan. This professional has responsibility for the patient within the pathway.

The PSOM CarePlan profile is derived from the UK Core CarePlan profile.

Task

A Collection Event serves as a trigger to prompt a patient to complete one or more PROMs Tools and to collect their answers and scores. Each instance conforming to the DataStandardsWales-PSOM-Task profile represents a PROMs Tool within a Collection Event. The Task is linked to from the CarePlan resource and contains input, such as a link to the Questionnaire that needs to be filled in, and output, i.e. a QuestionnaireResponse. The PROMs Trigger Event Type and the Event Location Code are also collected here.

The PSOM Task profile is derived from the UK Core Task profile.

Questionnaire

In the context of both DSCNs and LPDSs, the representation of a PROMs is manifested through a dedicated Questionnaire instance. The corresponding terminology resources are created using ValueSet and CodeSystem resources, which are linked within the Questionnaire instances. Furthermore, the Questionnaire consists of a structured set of questions that guide the collection of answers according to the DSCN/LPDS specifications.

The primary purpose of representing PROMs Tools as Questionnaire instances is to establish a canonical identifier for each PROMs Tool in the form of a URI. This URI serves as a linkage point connecting Tasks and QuestionnaireResponses to their corresponding Questionnaires.

Please note that, within the current PSOM data model design, the Questionnaire resource is not technically indispensable for the generation of a QuestionnaireResponse. Nevertheless, leveraging Questionnaire instances for PROMs Tools offers a significant advantage in terms of standardised and structured formatting. Each question within the Tool is encapsulated within the Questionnaire, uniquely identified by the Question Reference mapped to the .item.linkId elements. Moreover, the terminology used in the PROMs Tools has been represented in FHIR ValueSet and CodeSystem resources and is bound to the correct questions in the Questionnaire. This allows access to all definitions in a programmer-friendly manner.

It is important to note that the Questionnaire instances provide limited capabilities around rendering in the user interface of the PROMs provider platform. For example, the instances do not provide instructions on how questions should be displayed or how users should navigate through them. Refer to the PSOM-DSCN User Guide for further information on Questionnaire rendering.

QuestionnaireResponse

Each time a patient completes a PROMs Tool, an instance conforming to the DataStandardsWales-PSOM-QuestionnaireResponse profile is created, which represents a structured collection of answers to the corresponding Questionnaire. The PROMs provider provides the QuestionnaireResponse with an identifier and designates itself as the .identifier.assigner. The QuestionnaireResponse also contains the calculated scores, completion date and the language of the completed form. A Health Board can also use the same QuestionnaireResponse instance obtained from the PROMs provider, along with the additional metadata items required in the CarePlan, to flow the national collection of PROMs (i.e aligned to a DSCN) into NDR.

The PSOM QuestionnaireResponse profile is derived from the UK Core QuestionnaireResponse profile.

The diagram below is an example of how the CarePlan, Task, Questionnaire and QuestionnaireResponse are tied together in the context of Collection Events. The (content of the) Data Entry Questionnaire is explained in more detail below.

Proxyfilling

Administrative resources

The administrative metadata is captured using the Patient, PractitionerRole, Practitioner, Organization and Location resources. For these resources, the Data Standards Wales FHIR profiles are reused, and no PSOM-specific profiles are created.

Questionnaire versioning

PROMs Tools are subject to change over time, with alterations or additions made to their questions and answer options, as well as to the underlying algorithm used to calculate the scores. Any changes made to these Tools are recorded and disseminated through DSCNs and LPDSs. To accurately analyse PSOM data, it is crucial to determine which version of the Tool was filled out by the patient. This can be done by matching the Tool version with the DSCN or LPDS reference number.

The DSCN and LPDS reference numbers follow a specific convention, each consisting of a 7-digit code. This code is generated by combining the year of publication with a 3-digit sequential number. For example, a reference number such as '2022001' indicates that the document was the first one published in the year 2022. This reference number serves as a unique identifier for a DSCN or LPDS, making it suitable as a version number for the Tool.

In FHIR, the version of a PROMs Tool can be registered in the Questionnaire.version element. A Questionnaire is referenced from other resources by its canonical URL. To reference a particular version of a Questionnaire, users must combine the canonical URL and version using a pipe character in the format: [canonicalURL]|[version]. When users refer to a Questionnaire with just the .url, they automatically refer to the latest version.

However, the definition of 'latest version' may vary for a Health Board compared to what the PROMs provider may consider latest. For example, a PROMs provider serving multiple Health Boards might update to the latest DSCN before all the Health Boards have done so. Therefore, to ensure clarity about which version of the PROMs Tool is requested and collected, any references in the QuestionnaireResponse.questionnaire and Task.input.questionnaire SHALL always include a specific version.

To note:

  • The assumption is that all PROMs Tools will be registered with a version number.
  • Health Boards will be responsible for assigning version numbers to LPDSs and to ensure these reflect a consistent standard approach for the organisation.

Sensitive questions

Every PROM may include sensitive questions, such as the patient's experience with a healthcare professional (however, such questions are most likely part of PREMs). It is essential that the responses to these sensitive questions remain hidden when sent into the Health Board after collection. In some instances, they may also be considered for the overall analysis conducted by the NDR.

The Data Segmentation for Privacy project defined the Inline Security Label extension. This extension enables flagging elements with a security label, for example indicating their sensitivity, and SHALL be added to all relevant .item elements in both the Questionnaire and QuestionnaireResponse instances. The .valueCoding SHALL be populated with the code PDS from the InformationSensitivityPolicy ValueSet to indicate this data item contains sensitive information reported by the patient. Consequently, the Health Board's system can apply different processing logic to manage any data items marked as sensitive, including the users that can access such data and whether there is agreement for the data item to be forwarded to NDR.

The JSON snippet below is an example of a QuestionnaireResponse that contains the inline security extension to flag a question as sensitive.

        "item": 
                {
                    "linkId": "12345678",
                    "extension":  [
                        {
                            "url": "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
                            "valueCoding": {
                                "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                                "code": "PDS",
                                "display": "patient default information sensitivity"
                            }
                        }
                    ],
                    "answer":  [
                        {
                            "valueCoding": {
                                "system": "https://example/CodeSystem/example",
                                "code": "example",
                                "display": "example"
                            }
                        }
                    ]
                }

Proxy completion of Questionnaires

In certain situations, a patient may not be able to independently complete questionnaires, necessitating the involvement of a proxy, such as a family member or consultant. It is imperative for Health Boards to ensure that the information on who completed the questionnaires is accessible when analysing the responses obtained from the questionnaires.

The Data Entry Questionnaire is one of the Questionnaires scheduled within each collection event that allows to gather this type of information. It contains questions that capture specific details about the individual who completed the questionnaires. The answers for the Data Entry Questionnaire are only collected at the beginning of a new collection event. A collection event consists of one or more pathway-specific questionnaires, in addition to the Data Entry Questionnaire. It is expected that the PROMs provider will include, at a minimum, the QuestionnaireResponse for the Data Entry Questionnaire per collection event in the response to the Health Board. In addition to the aforementioned approach, the PROMs provider could further optimise by extracting the responses related to proxy completion and populate QuestionnaireResponse.source and QuestionnaireResponse.author.

As discussed in PSOM FHIR Data Model, every Task is linked to one Questionnaire. The answers are collected in a QuestionnaireReponse that is linked to the respective Task resource. All Tasks within one collection event share the same value for .reasonCode and .input:triggerEventDate. These values establish a distinctive combination that creates a coherent link between the outcomes of the Data Entry Questionnaire and the other questionnaires within a collective event.

General FHIR considerations

Use of the Reference data type

A key feature of FHIR is the ability of resources to reference each other. This is done using the Reference data type. This data type supports two modes of referencing:

  • Literal references, using the .reference element. In this case a relative or absolute REST endpoint containing the .id of the referenced resource is used. In a Bundle context, this may also be a reference to a Bundle.entry.fullUrl.
  • Logical references, using the .identifier element. Such a reference entails a match on the business identifier (.identifier) for the referenced resource, without specifying where to find the referenced resource.

The basic requirements for using references in this context are:

  • Either a literal or logical reference SHALL be specified, unless specified otherwise.
    • Literal references are preferred over logical references when multiple target resource types/profiles may be used.
    • Literal references SHALL be resolvable.
  • Relative references are preferred over absolute references.
  • A short description of the target resource SHOULD be included using the .display element.

Usage of ids and identifiers

Implementers are required to adhere to the specifications and Metadata DSCN when it comes to uniquely identifying FHIR instances. In cases where a local identifier is necessary, implementers are permitted to add one or more local identifiers. FHIR recognises two fields that are used to identify instances: .id and .identifier. Although these are both identifiers, they are unrelated and serve a completely different purpose:

The .id is the logical identifier, or technical identifier, akin to the id field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The .id has no further meaning outside of the server. The .identifier is a business identifier, which usually has a meaning outside of the server. Examples are a registration number of a healthcare provider, or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

When is identifier expected?

Systems that use an (internal) stable identifier to track information are encouraged to assign it to the .identifier element of FHIR instances when sending the resource, using a custom .identifier.system (e.g. a URL or OID that is under control of the sending organisation). The presence of this element helps receiving systems with re-identification and deduplication of resources, especially when the sender system does not natively support logical ids. Specific requirements for the usage of .identifier will be dictated on a use case basis by the particular profiles.

The JSON snippet below is an example of a CarePlan.identifier that contains an identifier assigned by a PROMs provider.

                "identifier":  [
                    {
                        "system": "urn:oid:2.16.840.1.113883.2.1.8.1.5.140",
                        "value": "12345678",
                        "assigner": {
                            "reference": "urn:uuid:fd3f7e8c-3cb2-4b4a-9b2b-d702bc32a905",
                            "display": "Cardiff and Vale University Health Board"
                        }
                    }

                ]

When is id expected?

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the .id element SHOULD always be present when dealing with instances that have a logical id, thus with instances on a server.