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

Service Design

Introduction

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

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 types of interactions. Each group contains the applicable transactions, as listed below:

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

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

Design Assumptions and Preconditions

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 section. 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 are responsible and 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.

Although likely required, this version of the specification does not provide detailed guidance on any other communication required for the proper triggering or re-evaluation of PSOM collection schedules by the PROMs provider. For example, treatment information such as planned or performed surgery procedures. Limited guidance is given in the Data Standards Wales PSOM CarePlan and examples on using the CarePlan resource to provide PSOM clinical relevant information. A future version of this guide may extend the CarePlan resource and interactions to hold this kind of information.

The PSOM FHIR service is based on the 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, ensuring any PROMs score provided is within a given range, 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 and PREMs 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.

The present design is focused on data flows between PROMs Providers and a Health Board. The assumption is that the proposed PSOM response message will be utilized by NDR to flow the PROMs and PREMs collection into the center (i.e. 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 prioritization to support PROMs and PREMs.

Providing PROM and PREM collections to the National Data Resource

Health Boards must be aware of both local and national PROMs and PREMs, as well as any questions flagged as sensitive during the receipt, processing and sending data to the NDR. The expectation is for PROMs/PREMs 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 PROM and PREMs 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 or PREM. Refer to the Questionnaire and Handling sensitive questions sections 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 PROM and PREM tools (i.e aligned to a DSCN) and 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 PROM and PREM 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 PROM tools (i.e. aligned to a DSCN) and local PROM tools (i.e. aligned to a LPDS) will result in only the national PROMs tools flowing to NDR.
  4. Any questions (in a PROMs/PREMs tool) marked as sensitive and 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 restricted to agreed 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.

State Tracking

The content of all transactions SHALL conform to the FHIR data model. Per transaction, the FHIR native .status and .intent elements are important to process the state of any given PSOM collection and the underlying PROMs and PREMs Tools. These .status elements should be populated and processed with care. A mapping per transaction to the relevant .status elements and their values is given below.

Transaction Type Relevant FHIR elements Applicable values
Requesting PROM/PREM collection CarePlan.status active
CarePlan.intent order
Task.status requested
Task.intent order
Providing PROM/PREM collection Task.status accepted | completed | cancelled
QuestionnaireResponse.status in-progress | completed | amended | entered-in-error | stopped
Cancelling PROM/PREM collection CarePlan.status on-hold | revoked | entered-in-error
Task.status cancelled
Updating patient administration information All Patient elements mapped by the metadata DSCN of the Patient Details section Any value that can be placed in the applicable Patient elements
Patient.deceased[x] .deceasedBoolean = true or .deceasedDateTime is populated

Exchange mechanism

FHIR defines the 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. Choosing the right exchange mechanism depends on the specific needs of the actors involved in the transaction. The manner of data exchange for transaction groups 1 and 2 is at the discretion of the Health Board and PROMs vendor, as the level of integration between these actors may vary. Thuis guide provides an example of how the exchange can be accomplished through the FHIR messaging paradigm, 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. Regardless of the mechanism selected, it is important that the exchanged data conforms to the FHIR data model described in this chapter.

Conversely, interactions between Health Board and NDR SHALL follow the FHIR messaging paradigm. This interaction is a standardized exchange and is consistent with other Data Standards Wales use cases (e.g., EPMA to CDR). The FHIR messaging section provides details on the FHIR messaging for the interactions between Health Board and NDR. The exact details on NDR's API details will follow in a future version.

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 organization 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.

A message consists of a Bundle identified by the type "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.

For example a PROMS-Request message will be a FHIR Bundle consisting of

  • one MessageHeader resource with an eventCoding proms-response;
  • one Patient resource;
  • one CarePlan resource;
  • zero, one or more Task resource(s);
  • any referenced supportive resources, e.g. Patient, Organization.

Here is an example of a PROMs Request message and PROMs Response message

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 under .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 four defined transactions:

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

One message type can fall under 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 PSOM collection. If the patient has not been registered in the PROMs provider system, the patient is conditionally registered. 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 or PREMs 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 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 PSOM collection request.
patient-update The Health Board updates Patient administration information, for example when a patient has died.
The PROMs provider interacting with the Health Board psom-response The PROMs provider shares updates and/or results related to the PSOM collection. This message is sent whenever the PROMs provider wishes to provide an update regarding the PSOM collection. This may include when they have 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 PSOM collection request.
patient-update The PROMs provider updates patient administration information, for example when a patient has died.
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 the only the national collection of PROMs and PREMs (i.e aligned to a DSCN) flow into NDR. For this purpose, Health Boards may need to remove, adjust and 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 PSOM collection request has been cancelled.
The National Data Resource interacting with the Health Board psom-response The National Data Resource sends national PSOM from patient treatment Health Board to patient's resident Health Board.

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. This operation accepts a message, processes it according to the definition of the event in the message header, and returns a 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 only 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 end of each profile page in the PSOM Implementation Guide available on Simplifier. 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.