MedMij:V2020.01/FHIR eAfspraak

MedMij:Vprepub/Issuebox FHIR IG

1 Introduction

This page describes how a patient can manage his health care related appointments in a MedMij context using the HL7 FHIR Standard. Initially, this guide will contain information on how to request existing appointment information. Guidance on how to create, update, or cancel appointments will be available here as well at a later stage. The functional requirements for this use case can be found in the functional design.

Note: This implementation guide builds on the general guidelines described in the use case overarching principles.

2 Use case: retrieve appointments

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway 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 returned. For this reason, search parameters should not be included for patient identification.

2.1 Introduction

The goal of this use case is to give patients an overview of their appointments with all healthcare providers. The appointment information that is shared with the patient will contain start and end date/time, location, type of appointment, patient instructions, health care professionals present. Below is described how a PHR can retrieve this information and how a XIS should make this information available.

2.2 Actors

Actor	Role
Patient (using a PHR)	Request appointments from the XIS
Healthcare professional (using a XIS)	Serves appointments to the PHR

2.3 Invocations

2.3.1 Client - PHR

2.3.1.1 Search for appointments

The PHR executes an HTTP GET conform to the FHIR RESTful and search specification against the XIS's Appointment endpoint. This search query URL is configurable by the PHR and has the following format:

GET [base]/Appointment?date=[date]

The PHR may use, and the XIS shall be capable of processing, the following parameters to configure the search query:

Observation
Name	Type	Description	Example
date	date	Appointment date/time based on start date/time.	Retrieve appointments with a start date/time from 01-01-2018 onwards: GET [base]/Appointment?date=gt2017-12-31 Retrieve appointments with start date/time from 01-01-2018 until 01-03-2018: GET [base]/Appointment?date=ge2018-01-01&date=lt2018-03-01

2.3.2 Server - XIS

The returned data to the PHR should conform to the HCIMS and their associate profiles listed in the table below.

Name NL	Name EN	FHIR Resource	URL profile
Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Afspraak	Appointment	Appointment	http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment

Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.

3 Use case: book an appointment

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway 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 returned. For this reason, search parameters should not be included for patient identification.

3.1 Introduction

The goal of this use case is to allow patients to book an appointment at a certain selected health care provider. Below is described how a PHR can send an appointment request and how a XIS should handle this.

3.2 Actors

Actor	Role
Patient (using a PHR)	Book appointment
Healthcare professional (using a XIS)	Handles appointment request

3.3 Invocations

3.3.1 Client - PHR

3.3.1.1 Search for available slots

The PHR system can request available slots using the $prefetch operation with optional input parameters on the Slot endpoint. This operation is a request for the XIS to calculate available slots, and return a Bundle with available slots. The operation can be performed by an HTTP POST as shown:

POST [base]/Slot/$prefetch

The optional input parameters can be put in the request body using the Parameters resource. The full specification of the $prefetch operation is described here: $prefetch operation

Below is an example of an operation that requests Slots with a start date/time between July 15th 8PM and July 17th 8PM:

example body

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "start",
      "valueDateTime" : "2017-07-15T20:00:00Z"
    },
    {
      "name": "end",
        "valueDateTime" : "2017-07-17T20:00:00Z"
    }
]
}

A Bundle containing the available Slot resources and an optional OperationOutcome resource can be expected as return.

For more information on how operations work using FHIR see the FHIR search specification

3.3.1.2 Book appointment

After fetching open Slots, an Appointment resource is created by the Client Application and is exchanged with the EHR. This Appointment will be the parameter for the $book operation. The operation can be performed by an HTTP POST as shown:

POST [base]/Appointment/$book

The full specification of the $book operation is described here: $book operation

The proposed Appointment has to be put in the request body using the Parameters resource.

{
   "resourceType": "Parameters",
   "parameter": [
      {
         "name": "appointment",
         "resource": {
            "resourceType": "Appointment",
            --snip--
         }
      },
   ]
}

A Bundle containing an required Appointment resource with status "booked" or "cancelled" and an optional OperationOutcome resource can be expected as return.

3.3.2 Server - XIS

3.3.2.1 Serve available slots

A Client can fetch available slots using the $prefetch operation. (See client section above for details). A server is expected to answer this operation with a Bundle containing the available Slots based on the clients' input parameters, and/or an optional OperationOutcome resource.

3.3.2.2 Handle appointment booking request

A Client can propose an appointment to be booked using the $book operation. (See client section above for details). A server is expected to answer this operation with a Bundle containing the proposed appointment with either a "booked" or "cancelled" status based on the XIS internal logic. The server can also send an optional OperationOutcome resource, containing a "success" or "error" explaining the result.

3.3.2.3 Response on operation request

If an operation succeeds, an HTTP Status success code is returned. This will usually be a 2xx code, though it may also be a 303 See Other. Other kinds of 3xx codes should be understood to indicate that the operation did not proceed, and the client will need to re-issue the operation if it can perform the redirection (e.g. may get redirected to an authentication step). User agents should note that servers may issue redirects, etc. to authenticate the client in response to an operation request. An HTTP status code of 4xx or 5xx indicates an error, and an OperationOutcome SHOULD be returned with details.

In general, an operation response uses the Parameters format regardless of whether there is only one or there are multiple named out parameters. However, the defined $prefetch operation only has one out parameters named "return". This means the parameters resource doesn't have to be used and the response is simply the resource itself. Which in this case is a Bundle resource of type "search-response", containing the requested resources.

The resources that are returned by the operation may be retained and made available in the resource repository on the operation server. In that case, the server will provide the identity of the resource in the returned resources. When resources that are not persisted are returned in the response, they will have no id property.

Link to the relevant FHIR specification: http://hl7.org/fhir/stu3/operations.html

3.4 Operations

3.4.1 $prefetch

• $prefetch (Fetch available Slots): http://nictiz.nl/fhir/OperationDefinition/eAfspraak-slot-prefetch

3.4.2 $book

• $book (Book Appointment): http://nictiz.nl/fhir/OperationDefinition/eAfspraak-appointment-book

3.5 Profiles

Name NL	Name EN	FHIR Resource	URL profile
Patient	Patient	Patient	http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Zorgverlener	HealthProfessional	Practitioner	http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
Zorgaanbieder	HealthcareProvider	Organization	http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Afspraak	Appointment	Appointment	http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment
Slot	Slot	Slot	http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Slot

Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.

4 Use case: cancel/reschedule an appointment

This FHIR implementation guide assumes that the PHR system is able to make a connection to the right XIS that contains the patient's information. It does not provide information on finding the right XIS nor does it provide information about security. Moreover, each transaction is performed in the context of a specific authenticated patient, for whose context (token) has been established using the authentication mechanisms described in the 'Afsprakenstelsel'. Each XIS Gateway 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 returned. For this reason, search parameters should not be included for patient identification.

4.1 Introduction

The goal of this use case is to allow patients to cancel a specific appointment. Below is described how a PHR can send a cancellation request and how a XIS should handle this.

Rescheduling is a combination of cancelling and re-booking an appointment. For booking an appointment, see the use case above.

4.2 Actors

Actor	Role
Patient (using a PHR)	Cancel appointment
Healthcare professional (using a XIS)	Handles cancellation request

4.3 Invocations

4.3.1 Client - PHR

4.3.1.1 Search for available slots

The PHR system can request the cancellation of a specific appointment using the $cancel operation with the appointment as input parameter on the Appointment endpoint. This operation is a request for the XIS to handle the request, and provide a Bundle resource with the Appointment resource (canceled or not) and an optional OperationOutcome slots as return. The operation can be performed by an HTTP POST as shown:

POST [base]/Appointment/$cancel

The optional input parameters can be put in the request body using the Parameters resource. The full specification of the $cancel operation is described here: $prefetch operation

example body

{
   "resourceType": "Parameters",
   "parameter": [
      {
         "name": "appointment",
         "resource": {
            "resourceType": "Appointment",
            --snip--
         }
      },
   ]
}

A Bundle containing the Appointment resources and an optional OperationOutcome resource can be expected as return. If the appointment was indeed cancelled, the returned Appointment resource will have a status of "cancelled". If not, the Appointment will be returned as is, and a explanation will be returned in an OperationOutcome resource, with an explanation.

For more information on how operations work using FHIR see the FHIR search specification

4.3.2 Server - XIS

Important sections of the FHIR specification for a server in this use case are the RESTful API section and the operations section.

4.3.2.1 Handle appointment cancellation request

A Client can propose an appointment to be booked using the $cancel operation. (See client section above for details). A server is expected to answer this operation with a Bundle containing the proposed appointment either unchanged (if the request was denied) or with a "cancelled" status (if the request was approved) based on the XIS's internal logic. The server can also send an optional OperationOutcome resource, containing a "success" or "error" explaining the result.

4.3.2.2 Response on operation request

If an operation succeeds, a HTTP Status success code is returned. This will usually be a 2xx code, though it may also be a 303 See Other. Other kinds of 3xx codes should be understood to indicate that the operation did not proceed, and the client will need to re-issue the operation if it can perform the redirection (e.g. may get redirected to an authentication step). User agents should note that servers may issue redirects, etc. to authenticate the client in response to an operation request. An HTTP status code of 4xx or 5xx indicates an error, and an OperationOutcome SHOULD be returned with details.

In general, an operation response uses the Parameters format whether there is only one or there are multiple named out parameters. However, the defined $cancel operation only has one out parameters named "return". This means the parameters don't have to be used and the response is simply the resource itself. Which in this case is a Bundle resource of type "search-response", containing the requested resources.

The resources that are returned by the operation may be retained and made available in the resource repository on the operation server. In that case, the server will provide the identity of the resource in the returned resources. When resources that are not persisted are returned in the response, they will have no id property.

Link to the relevant FHIR specification: http://hl7.org/fhir/stu3/operations.html

4.4 Operations

4.4.1 $cancel

• $cancel (Cancel Appointment): http://nictiz.nl/fhir/OperationDefinition/eAfspraak-appointment-cancel

4.5 Profiles

Name NL	Name EN	FHIR Resource	URL profile
Afspraak	Appointment	Appointment	http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment

4.6 Examples

Example instances of FHIR resources can be found on Simplifier. Please note: every effort has been made to ensure that the examples are correct and useful, but they are not a normative part of any information standard.

5 Terminology, NamingSystems, Mappings

5.1 Terminology

Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here here and can be downloaded as a .zip in XML or JSON format.

5.2 NamingSystems

Relevant NamingSystems can be found here.

5.3 Mappings

A FHIR ConceptMap resource is provided when a FHIR value set is used instead of a HCIM value set. A ConceptMap maps the values between the two value sets. These ConceptMaps can be found here.

An explanation about mappings can be found at Mapping of coded concepts.

6 Release notes

Release notes can be found on the functional design page.