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:
CarePlanTaskPatientOrganizationPractitionerLocationQuestionnaireQuestionnaireResponse
For the CarePlan, Task, Questionnaire and QuestionnaireResponse, specific PSOM profiles are created to capture elements of the Clinical Circumstance as well as the Collection Event. The Patient, Organization, Practitioner and Location resources are based on existing Data Standards Wales Profiles and are used to capture administrative metadata.
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 and QuestionnaireResponse as well as the 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/PREM has been completed, the PROMs Provider should be able to update the corresponding Task resource accordingly.
FHIR Resources
CarePlan
The DataStandardsWales-PSOM-CarePlan represents a patient’s Clinical Circumstance. Each CarePlan resource is used to group Collection Events and provides context by specifying the Pathway type, the ReferralID 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 PSOM 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.
Task
A Collection Event serves as a trigger to prompt a patient to complete one or more PROMs or PREMs Tools and to collect their answers and scores. Each instance of DataStandardsWales-PSOM-Task represents a PROMs or PREMs Tool within a Collection Event. The Task is linked to the CarePlan resource and contains input, i.e. a link to the Questionnaire that needs to be filled in, and output, i.e. a QuestionnaireResponse. The PROMs Trigger Classification Code and the Event Location Code are also collected here.
Questionnaire
For both DSCNs and LPDSs, a PROMs or PREMs Tool is represented by a 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 and PREMs Tools as Questionnaire instances is to define a canonical identifier for each of these Tools in the form of a URI. This URI links a Task and QuestionnaireResponse to their corresponding Questionnaire.
Another significant benefit of using Questionnaire instances for the PROMs and PREMs Tools is to provide standardized and structured formatting. The Questionnaire contains each question within the Tool. Each question is uniquely identified with the Question Reference mapped to the .item.linkId elements. Moreover, the terminology used in the PROMs and PREMs 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 or PREMs Tool, an instance of DataStandardsWales-PSOM-QuestionnaireResponse 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 and PREMs (i.e aligned to a DSCN) into NDR.
Handling sensitive questions
Both PROMs and PREMs may include sensitive questions, such as the patient's experience with a healthcare professional and free form patient text. 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.
In the context of PREMs implementation, the extension 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"
}
}
]
}
Administrative resources
The administrative metadata is captured using the Patient, 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 and PREMs 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 analyze 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 adhere to a specific convention. Each reference number comprises two sections: the year of publication and a sequential number. For instance, a reference number like "2022 1" signifies 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 or PREMs 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 or PREMs 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 and PREMs 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.