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.

Service Design

Interoperable support for workflow execution is a more advanced FHIR activity, as it involves not just data standardisation but also process, role, and activity standardisation across systems. Even without utilising FHIR for workflow execution, it is crucial to standardise workflow-related data elements, such as connecting events or results to their authorising orders, linking parent and child steps, and identifying the protocol followed by a pathway.

Design Assumptions and Preconditions

The service design is underpinned by certain assumptions and preconditions, needed for seamless interoperability. It is anticipated that actors will select the appropriate exchange mechanism based on their specific requirements. FHIR defines different methods for exchanging data between systems, such as a RESTful API, messaging, documents and services. Each of these approaches can be used to exchange information, and each has its own strengths and weaknesses and applicability. The manner of data exchange between Health Boards and PROMs providers is at their discretion, as the level of integration between these actors may vary. Irrespective of the chosen mechanism, adherence to the PSOM Data Model is imperative to ensure data integrity and compatibility.

Additionally, PROMs can be collected by Health Boards through third-party enterprise systems. It is important to clarify that interactions between third-party systems and Health Boards are outside the scope of this Implementation Guide. It is assumed that Health Boards and third-party systems can establish the necessary integration between themselves.

Conversely, interactions between Health Board and NDR will follow the FHIR messaging paradigm which is consistent with other Data Standards Wales use cases (e.g. EPMA to CDR). Consequently, transaction guidance given for Health Board and PROMs provider follow the messaging paradigm. The assumption is that the proposed PSOM response message can be utilised by NDR to flow the PROMs collection into the NDR FHIR MESSAGE STORE and then onto relevant application services such as IS, WCP, WCCIS, etc. Likewise, the same message will be used to flow PROMs from patient treatment Health Board to their resident Health Board. It is understood that the NDR design requires further consideration and prioritisation to support PROMs. However, as mentioned earlier, individual actors have the flexibility to diverge and adopt the exchange pattern that best aligns with their implementation nuances.

It is assumed that the actors can make a secure connection. This guide does not provide information on finding the right actor nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, whose context has been established using an authentication mechanism. The authentication mechanism shall be defined by NHS Wales and is out of scope for this IG. Each actor is required to perform filtering based on the patient associated with the context for the request, so only the records associated with the authenticated patient are exchanged. For general security considerations refer to the Security section in the FHIR specification.

All actors have to be able to retrieve the correct version of the PSOM DCSN and LPDS definitions and terminology from the packages published on Simplifier.net.

It is assumed that the PROMs provider should first have received a PSOM request message (including a created CarePlan instance) before being able to send a response. The rationale for this is that the response message should contain the right metadata, populated in the CarePlan and Task resources, for the Health Board to relate the PSOM results to the correct pathway. No guidance is given on how to handle patients that are already in a PSOM pathway upon implementation of this integration. This guide does not address the Health Board's internal triggers for initiation of any transaction.

PROMs providers may use treatment information such as planned or performed surgery procedures to trigger or re-evaluate PROMs collection schedules. Limited guidance is given in the Data Standards Wales PSOM CarePlan profile (within the .activity element) and examples on using the CarePlan resource to provide PSOM clinical relevant information. A future version of these specifications may extend the CarePlan resource and interactions to hold this kind of information.

The PSOM FHIR service is based on the Patient Administration System (PAS) and/or the PROMs provider managing the schedule for collecting PROMs. Moreover, the PSOM FHIR service has limited rules to validate the data contents, including data format and generated scores. For example, to ensure any PROMs score provided is within a given range, it will be a Health Board/Trust and PROMs provider responsibility to include any validation rules.

The design of the PSOM FHIR service is based on use in secondary care settings, potentially supporting PROMs collection. However, further review will be required if the proposed FHIR service is to be extended for use in primary care, community and social care settings.

Actors and transactions

This section presents transactions involving the following three actors:

  • PROMs providers
  • Health Boards (and Trusts)
  • National Data Resource

There are four transactions groups and four interaction types. Each transaction group contains the applicable transactions type(s), as listed below:

  1. The Health Board interacting with PROMs provider;
    • Requesting PROMs collection
    • Cancelling PROMs collection
    • Updating patient administration information
  2. The PROMs provider interacting with the Health Board;
    • Providing PROMs collection
    • Cancelling PROMs collection
    • Updating patient administration information
  3. The Health Board interacting with National Data Resource;
    • Providing PROMs collection
    • Cancelling PROMs collection
  4. The National Data Resource interacting with the Health Board;
    • Providing PROMs collection

The diagram below depicts the different transaction groups and their actors to collect and exchange PROMs.

ServiceDesign

An actor might be unable to process a transaction due to errors or because of technical or business rules. Refer to the section on handling exceptions for more details on how to handle errors.

Providing PROMs collections to the National Data Resource

Health Boards must be aware of both local and national PROMs, as well as any questions flagged as sensitive during the receipt of data, while processing data and while sending data to the NDR. The expectation is for PROMs collection to flow from Providers into Health Board in near real-time and then onto NDR in near real-time. It is mandatory to review the QuestionnaireResponse within the PROMs collection received from the PROMs provider. The review must include an inspection on the associated Questionnaire definition and the presence of any sensitivity flag. The Questionnaire definition delineates whether the data originates from a local or national PROM. Refer to the Questionnaire and Handling sensitive questions sections on the PSOM FHIR Data Model page for more information.

Health Boards are tasked with ensuring that only agreed data sets flow to the NDR. This may require some form of pipeline to review questionnaire response messages to determine the action to be taken. The following details some of the use cases associated with what will flow into NDR. The final rules will be provided in the supporting PROMs Pathway Guides:

  1. All national PROMs Tools (i.e aligned to a DSCN) that are aligned with a national PROMs pathway guide will flow to NDR. In these instances, any PROMs metadata attributes missing from the CarePlan resource will be populated before the data flows to NDR.
  2. Any PROMs Tools aligned to a LPDS (i.e. marked with a 'ZZ' document reference prefix) will remain in the Health Board.
  3. Any question sets that contain both national PROMs Tools (i.e. aligned to a DSCN) and local PROMs Tools (i.e. aligned to a LPDS) will result in only the national PROMs Tools flowing to NDR.
  4. Any questions (in a PROMs Tool) marked as sensitive for which the pathway guide states the question is to flow, will flow into NDR. In all other cases sensitive questions will remain in the Health Board and will be restricted to authorised users.

An illustrated use case sequence diagram example based on some of the above rules is depicted below:

To facilitate the above use cases, Health Boards will need to include relevant logic to modify, enrich, or remove certain results obtained from the PROMs provider. Alternatively, they may choose to generate an entirely new QuestionnaireResponse message using the data stored in their datastore. However, it should be noted that this guidance does not cover the procedures for populating any other PROMs metadata required by the NDR within the CarePlan. For further information on the appropriate message definitions, please refer to the Message types section below.

Exchange mechanism

This guide provides an example on how the exchange can be accomplished through the FHIR messaging paradigm. Note that it serves as an illustration only, and for reasons already stated, it is not mandatory to implement this approach between the PROMs provider and the Health Board.

In addition to the FHIR messaging paradigm, this guide also provides limited guidance on a RESTful approach.

FHIR Messaging

FHIR messaging differs from FHIR RESTful in that all the resources are sent to the recipient in one interaction. All the resources are handled in a single package and the receiving organisation can handle them according to local procedures. FHIR messaging is very similar to the messaging used in HL7v2 and HL7v3, hence the term traditional messaging.

In FHIR Messaging, a 'request message' consists of a Bundle of resources where Bundle.type is equal to message, with the first resource in the Bundle being a MessageHeader resource. The MessageHeader resource has a code - the message event - that identifies the nature of the request message, and it also carries additional request metadata. The other resources in the Bundle depend on the type of the request.

The receiver processes the request and returns a 'response message' which is also a Bundle of resources where Bundle.type is equal to message. The first resource in the Bundle is a MessageHeader resource in which .response contains the outcome of processing the message and any additional response resources required (e.g. an OperationOutcome in .response.details).

MessageDefinition

The MessageDefinition resource defines the types of message bundles that are used for exchanging PSOM information, including message event codes and focal resources. A list of supported message event codes can be found on .event[x]in the DataStandardsWales-PSOM-MessageDefinition profile. This profile describes the minimum requirements for all message types defined within the scope of this project (explained in more detail in the next section). For every message, an instance of the MessageDefinition resource is provided in the Simplifier project that structurally defines the message.

Message Types

The following message types have been defined for the defined transactions:

  1. psom-request;
  2. psom-response;
  3. psom-cancellation;
  4. patient-update;
  5. exception-response.

One message type possibly belongs to multiple transaction groups if their content is similar, and they have a similar function. For example, the psom-response message is sent from a PROMs provider to a Health Board and is also used to ‘forward’ data from Health Board to National Data Resource. The table below illustrates what message types are (re)used in which transaction groups.

Transaction group Message type Description
Health Board interacting with PROMs provider psom-request The Health Board requests the PROMs provider to initiate the PROMs collection. If the patient has not yet been registered in the PROMs provider system upon receiving the request message, the patient is registered before any other action is taken. This message is sent when enrolling a patient in a PSOM pathway or when the Health Board sends an ad hoc PSOM request for any additional PROMs Tool that needs to be completed. This includes when the patient has had any form of surgery or any other event that could trigger a PROM, for instance an outpatient appointment. In the case of an additional PSOM request message, the CarePlan is updated to include additional Task references, which are also included in the message Bundle.
psom-cancellation The Health Board cancels a PROMs collection request.
patient-update The Health Board updates Patient administration information, for example when a patient is deceased.
The PROMs provider interacting with the Health Board psom-response The PROMs provider shares updates and/or results related to the PROMs collection. This message is sent whenever the PROMs provider wishes to provide an update regarding the PROMs collection. This may include when it has created Tasks based on the patient's pathway that still need to be completed. The PROMs provider updates the CarePlan resource by adding references to any additional Task resources it takes responsibility for, and includes all relevant resources in the message Bundle.
psom-cancellation The PROMs provider cancels a PROMs collection request.
patient-update The PROMs provider updates patient administration information, for example when a patient is deceased.
The Health Board interacting with National Data Resource psom-response The Health Board sends (or 'forwards') collected PSOM results to the National Data Resource. Health Boards need to ensure that of the collected PROMs only the national ones (i.e those aligned to a DSCN) flow into NDR. For this purpose, Health Boards may need to remove, adjust and/or enrich the collected results from the PROMs provider or generate a complete new message from what is persisted in their datastore.
psom-cancellation The Health Board notifies the National Data Resource that a PROMs collection request has been cancelled.
The National Data Resource interacting with the Health Board psom-response The National Data Resource sends collected national PSOM resuls from the patient's treatment Health Board to the patient's resident Health Board.
All actors exception-response This message type is used to communicate exceptions. It is a general message code and can be used by all actors. More guidance on how to apply this message type can be found on the handling exceptions page.

Method for sending messages

This guide assumes that content will be delivered from one application to another by some delivery mechanism, and then one or more responses will be returned to the source application. The exact mechanism of transfer is irrelevant to this specification, but may include file transfer, HTTP-based transfer, MLLP (HL7 minimal lower layer protocol), MQ series messaging or anything else. The only requirement for the transfer layer is that requests are sent to a known location and responses are returned to the source of the request.

The simplest way to handle messages where there are also RESTful interactions occurring is to use the $process-message operation. This operation accepts a message, processes it according to the definition of the event in the MessageHeader, and returns one or more response messages.

Message Response

Received messages are processed and, based on its result, an appropriate response is sent back to the sending application. The response may for instance consist of an applicable HTTP response code. No specific response messages have been defined.

RESTful exchange

Besides the messaging paradigm, a FHIR-based form-filling workflow across different systems on a national level can be designed using a full RESTful approach. The RESTful approach is a widely adopted approach, due to its flexibility, interoperability and scalability. Inspiration for such a design can be taken form FHIR’s workflow module, in particular Option F. Besides the FHIR core specifications, SDC is a well-established implementation guide for handling Questionnaires and QuestionnaireResponses. The SDC workflow specification also contains a section on the form-filling workflow. This implementation guide does not provide further details on the implementation of a RESTful approach as it is out of scope for this particular use case.

While none of the predefined transactions involve search interactions, it's anticipated that users may want to incorporate search interactions within their own implementations. For instance, a Health Board may want to explore PSOM-related resources within their own FHIR server as a part of quality assurance for received data.

Therefore, this guide aims to provide general recommendations and examples on performing search interactions related to PSOM metadata, as well as SearchParameter resources for any missing search parameters not covered by the FHIR specification. Users of this guide are expected to be familiar with the FHIR RESTful search specification. This guide is not intended to be a tutorial on that subject. Moreover, it is not mandatory to implement the recommended search capabilities and it is at the actor's discretion to do so.

Specific search suggestions are provided for each PSOM profile and can be found at the bottom of each profile page in this guide. For the most relevant metadata elements, an example search query is given. Please note, these examples do not demonstrate combinations of multiple search parameters, even though it's possible to combine parameters. General guidance on the use of search parameters can be found in the FHIR specification. Lastly, this guide does not provide any instructions for search result parameters, modifiers, and operators.