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.

Health Board and PROMs provider

Health Board interacting with PROMs provider

The following three interactions are defined:

  • Requesting PROMs collection
  • Cancelling PROMs collection
  • Updating patient administration information

Requesting PROMs collection

To initiate a PROMs collection, the Health Board sends a request message to the PROMs provider. 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. The request 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.

Actors

Interaction type Transaction Actor
Requesting PROMs collection [PUSH] Send PROMs collection request Health Board
Receive PROMs collection request PROMs provider

Request message

The PSOM-Request message will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = psom-request;
  • one CarePlan resource with
    • .status = active;
    • .intent = order;
  • zero, one or more Task resource(s) with
    • .status = requested;
    • .intent = order;
  • one Patient resource;
  • any referenced supportive resources, e.g. Practitioner, Organization.

Example

Health Board requests PROMs collection for a Myeloma pathway

Response message

After receiving the request message, the PROMs provider either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Received message contains unavailable PROMs version;
    • Received message violates pathway restrictions e.g. age;
    • Missing information;
    • Duplicate collection requests.

Note that the exact way in which a PROMs provider processes and validates the request message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the provider utilises a queueing mechanism and validates the content of the request message at a later point in time.

Cancelling PROMs collection

To cancel a PROMs collection, the Health Board sends the PROMS provider a cancellation message.

Actors

Interaction type Transaction Actor
Cancelling PROMs collection [PUSH] Send PROMs collection cancellation Health Board
Receive PROMs collection cancellation PROMs provider

Request message

The PSOM-Cancellation message will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = psom-cancellation;
  • one CarePlan resource with
    • .status = revoked;
    • .intent = order;
  • zero, one or more Task resource(s) with
    • .status = cancelled;
    • .intent = order;
  • one Patient resource;
  • any referenced supportive resources, e.g. Practitioner, Organization.

Example

Health Board cancels a Myeloma pathway

Response message

After receiving the cancellation message, the PROMs provider either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Missing information;
    • Duplicate cancellation requests.

Note that the exact way in which a PROMs provider processes and validates the cancellation message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the provider utilises a queueing mechanism and validates the content of the cancellation message at a later point in time.

Updating patient administration information

To update patient administration information, the Health Board sends an update message to the PROMs provider, for example when a patient is deceased.

Actors

Interaction type Transaction Actor
Updating patient administration information [PUSH] Send updated patient information Health Board
Receive updated patient information PROMs provider

Request message

The PSOM-PatientUpdate message will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = patient-update;
  • one Patient resource containing updated values in Patient elements mapped by the Metadata DSCN of the Patient Details section.

Example

Health Board updates patient information

Response message

After receiving the update message, the PROMs provider either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Missing information.

Note that the exact way in which a PROMs provider processes and validates the update message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the provider utilises a queueing mechanism and validates the content of the update message at a later point in time.

PROMs provider interacting with the Health Board

The following three interactions are defined:

  • Providing PROMs collection
  • Cancelling PROMs collection
  • Updating patient administration information

Providing PROMs collection

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

Actors

Interaction type Transaction Actor
Providing PROMs collection [PUSH] Send PROMs collection PROMs provider
Receive PROMs collection Health Board

Request message

The PSOM-Response message will will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = psom-response;
  • one CarePlan resource with
    • .status = active;
    • .intent = order;
  • zero, one or more Task resource(s) with
    • .status = accepted | in-progress | completed;
    • .intent = order;
  • one Patient resource;
  • any referenced supportive resources, e.g. Practitioner, Organization.

The MessageHeader.response may be provided as well to link the PROMs collection to the initial request.

Example

PROMs provider provides the Health Board with PROMs collection for a Myeloma pathway

Response message

After receiving the collection message, the Health Board either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Received message contains unavailable PROMs version;
    • Received message violates pathway restrictions e.g. age;
    • Missing information.

Note that the exact way in which a Health Board processes and validates the collection message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the Health Board utilises a queueing mechanism and validates the content of the collection message at a later point in time.

Cancelling PROMs collection

To cancel a PROMs collection, the PROMs provider sends the Health Board a cancellation message.

Actors

Interaction type Transaction Actor
Cancelling PROMs collection [PUSH] Send PROMs collection cancellation PROMs provider
Receive PROMs collection cancellation Health Board

Request Message

The PSOM-Cancellation message will will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = psom-cancellation;
  • one CarePlan resource with
    • .status = revoked;
    • .intent = order;
  • zero, one or more Task resource(s) with
    • .status = cancelled;
    • .intent = order;
  • one Patient resource;
  • any referenced supportive resources, e.g. Practitioner, Organization.

Example

PROMs provider cancels a Myeloma pathway

Response message

After receiving the cancellation message, the Health Board either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Missing information;
    • Duplicate cancellation requests.

Note that the exact way in which a Health Board processes and validates the cancellation message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the Health Board utilises a queueing mechanism and validates the content of the cancellation message at a later point in time.

Updating patient administration information

To update patient administration information, the PROMs provider sends an update message to the Health Board, for example when a patient is deceased.

Actors

Interaction type Transaction Actor
Update patient administration information [PUSH] Send updated patient information PROMS Provider
Receive updated patient information Health Board

Request message

The PSOM-PatientUpdate message will be a FHIR Bundle consisting of:

  • one MessageHeader resource with
    • .eventCoding.code = patient-update;
  • one Patient resource containing updated values in Patient elements mapped by the Metadata DSCN of the Patient Details section.

Example

PROMs provider updates patient information

Response message

After receiving the update message, the Health Board either:

  • (optionally) acknowledges the message, e.g. with an HTTP 200 OK with no body (in the case of RESTful exchange);
  • returns an error if the message cannot be processed, e.g. an HTTP 4xx or 5xx error (in the case of RESTful exchange). In this case one of the following exceptions could have been identified (refer to the Handling Exceptions page for more guidance):
    • Received message does not conform to the PSOM FHIR specifications;
    • Missing information.

Note that the exact way in which a Health Board processes and validates the update message could result in them sending both an acknowledgement message initially and an exception message subsequently. Ths scenario could for instance arise if the Health Board utilises a queueing mechanism and validates the content of the update message at a later point in time.