MedMij FHIR Implementation Guide - eAfspraak, publication 2017.04
Introduction
This page describes how patient can manage their 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 in a later stage. The functional requirements for this use case can be found here.
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.
Introduction
The goal of this use case is to give patients an overview of their appointments with all health care 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.
Actors
| Actor | Role |
|---|---|
| Patient (using a PHR) | Request appointments from the XIS |
| Healthcare professional (using a XIS) | Serves appointments to the PHR |
Invocations
Client - PHR
Search for appointments
The PHR system can request the appointments using individual search interactions. The search interaction searches for appointments based on start date/time. The interaction can be performed by an HTTP GET as shown:
GET [base]/Appointment/?date=[date]
for more information on how to query on dates using FHIR see the FHIR search specification
examples:
retrieve appointments from 01-01-2018 onwards:
GET [base]/Appointment/?date=gt:2017-12-31
retrieve appointments from 01-01-2018 until 01-03-2018
GET [base]/Appointment/?date=ge:2018-01-01&date=lt:2018-03-01
| Name NL | Name EN | FHIR Resource | URL profile | Reference to section |
| Patient | Patient | Patient | http://fhir.nl/fhir/StructureDefinition/nl-core-patient |  Patient
|
| Zorgverlener | HealthProfessional | Practitioner | http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner | HealthProfessional
|
| Zorgaanbieder | HealthcareProvider | Organization | http://fhir.nl/fhir/StructureDefinition/nl-core-organization | HealthcareProvider
|
| Afspraak | Appointment | Appointment | http://nictiz.nl/fhir/StructureDefinition/eAfspraken-Appointment | Appointment
|
Server - XIS
Important sections of the FHIR specification for a server in this use case are the RESTful API section the search section.
Response on search request
If the search succeeds, the server SHALL return a 200 OK HTTP status code and the return content SHALL be a Bundle with type = searchset containing the results of the search as a collection of zero or more resources in a defined order. The result collection can be long, so servers may use paging. If they do, they SHALL use the method described below (adapted from RFC 5005 (Feed Paging and Archiving ) for breaking the collection into pages if appropriate. The server MAY also return an OperationOutcome resource within the searchset Bundle entries that contains additional information about the search; if one is sent it SHALL NOT include any issues with a fatal or error severity, and it SHALL be marked with a Bundle.entry.search.mode of outcome.
In order to allow the client to be confident about what search parameters were used as criteria by the server, the server SHALL return the parameters that were actually used to process the search. Applications processing search results SHALL check these returned values where necessary. For example, if the server did not support some of the filters specified in the search, a client might manually apply those filters to the retrieved result set, display a warning message to the user or take some other action.
Link to the relevant FHIR specification: http://hl7.org/fhir/STU3/http.html#search
Handling errors
If the search fails (cannot be executed, not that there is no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. A HTTP status code of 403 signifies that the server refused to perform the search, while other 4xx and 5xx codes signify that some sort of error has occurred. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. Note: An empty search result is not a failure.
In some cases, parameters may cause an error. For instance:
- A parameter may refer to a non-existent resource e.g.
GET [base]/Appointment?patient=101, where "101" does not exist - A parameter may refer to an unknown code e.g.
GET [base]/Appointment?appointment-type=83280, where the 83280 is not known to the server - A parameter may refer to a time that is out of scope e.g.
GET [base]/Appointment?date=le1995, where the system only has data going back to 2001 - A data time parameter may have incorrect format e.g.
GET [base]/Appointment?date=23%20May%202009 - A parameter may be unknown or unsupported
Where the content of the parameter is syntactically incorrect, servers SHOULD return an error. However, where the issue is a logical condition (e.g. unknown subject or code), the server SHOULD process the search, including processing the parameter - with the result of returning an empty search set, since the parameter cannot be satisfied.
In such cases, the search process MAY include an OperationOutcome in the search set that contains additional hints and warnings about the search process. This is included in the search results as an entry with search mode = outcome. Clients can use this information to improve future searches.
Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):
- 400 Bad Request - search could not be processed or failed basic FHIR validation rules
- 401 Not Authorized - authorization is required for the interaction that was attempted
- 404 Not Found - resource type not supported, or not a FHIR end-point
Link to relevant FHIR specification: http://hl7.org/fhir/STU3/search.html#errors
Interactions, operations, search parameters
Interactions
The following FHIR interactions are needed to retrieve appointment information:
Operations
No operations are defined or needed for this transaction.
Search parameters
| Name | Type | Description | Expression |
| date | date | Appointment date/time. | Appointment.start |