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.