MedMij:V2020.01/FHIR eAfspraak: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(HOTFIX: Use exact version in new NoteBoxPackage template)
k (Beveiligde "MedMij:V2020.01/FHIR eAfspraak": Protect production page from accidental edits ([Bewerken=Alleen beheerders toestaan] (vervalt niet) [Hernoemen=Alleen beheerders toestaan] (vervalt niet)))
 
(19 tussenliggende versies door 5 gebruikers niet weergegeven)
Regel 1: Regel 1:
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
−
{{DISPLAYTITLE:MedMij FHIR Implementation Guide - eAfspraak {{VersieInfo|eAfspraak|release=V2019.01}}}}
+
{{DISPLAYTITLE:MedMij FHIR Implementation Guide - eAfspraak {{VersieInfo|eAfspraak}}}}
−
{{MedMij:Vprepub/Issuebox_FHIR_IG}}
+
{{MedMij:V2020.01/Issuebox_FHIR_IG}}
  
 
[[Bestand:EAfspraak_icoon_zonder_tekst.png |link=|links |87px|eAfspraak]]  
 
[[Bestand:EAfspraak_icoon_zonder_tekst.png |link=|links |87px|eAfspraak]]  
Regel 7: Regel 7:
 
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch   
 
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch   
 
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]                 
 
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]                 
−
circle 1013 224 212 [[MedMij:Vprepub/OntwerpeAfspraken|Functioneel]]                 
+
circle 1013 224 212 [[MedMij:V2020.01/OntwerpeAfspraken|Functioneel]]                 
−
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]                 
+
circle 1787 230 212 [[MedMij:V2020.01/FHIR_IG|Technisch]]                 
 
desc none                     
 
desc none                     
 
</imagemap>
 
</imagemap>
Regel 16: Regel 16:
 
=Introduction=
 
=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.  
 
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 [[MedMij:Vprepub/Ontwerpen|functional design]].
+
The functional requirements for this use case can be found in the [[MedMij:V2020.01/Ontwerpen|functional design]].
 +
 
 +
'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:V2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].
  
 
=Use case: retrieve appointments=
 
=Use case: retrieve appointments=
 
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |128px|Go to Afsprakenstelsel]]
 
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |128px|Go to Afsprakenstelsel]]
 
{{FHIR-IG-Afsprakenstelsel-Note}}
 
{{FHIR-IG-Afsprakenstelsel-Note}}
−
 
−
 
  
 
==Introduction==
 
==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.
 
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.
  
−
==Actors==
+
==Actors involved==
−
{| class="wikitable" "cellpadding="10"
+
{| class="wikitable"
−
! style="text-align:left;"| '''Actor'''
+
! colspan="3" style="text-align:left;" | Actors
−
! style="text-align:left;"| '''Role'''
+
! colspan="2" style="text-align:left;" | Systems
 +
! colspan="2" style="text-align:left;" | FHIR Capability Statements
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
+
! style="text-align:left;" |Name
−
|style="background-color: white;vertical-align:top;"|Request appointments from the XIS
+
! style="text-align:left;" |Description
 +
! style="text-align:left;" |Role
 +
! style="text-align:left;" |Name
 +
! style="text-align:left;" |Description
 +
! style="text-align:left;" |Name
 +
! style="text-align:left;" |Description
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
+
| Patient
−
|style="background-color: white;vertical-align:top;"|Serves appointments to the PHR
+
| The user of a personal healthcare environment.
 +
| Request appointments from the XIS
 +
| PHR
 +
| Personal health record
 +
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eappointment-clientcapabilities|nictiz.fhir.nl.stu3.eafspraak|pkgVersion=1.0.5|title=CapabilityStatement: Client}}
 +
| FHIR Client requirements
 +
|-
 +
| Healthcare professional
 +
| The user of a XIS
 +
|Serves appointments to the PHR
 +
| XIS
 +
| Healthcare information system
 +
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/eappointment-servercapabilities|nictiz.fhir.nl.stu3.eafspraak|pkgVersion=1.0.5|title=CapabilityStatement: Server}}
 +
| FHIR Server requirements
 
|}
 
|}
  
Regel 43: Regel 62:
  
 
====Search for appointments ====
 
====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:
+
The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTful] and [http://hl7.org/fhir/search.html search] specification against the XIS's Appointment endpoint. This search query URL is configurable by the PHR and has the following format:
 +
 +
<pre>GET [base]/Appointment?date=[date]</pre>
  
−
<code>GET [base]/Appointment/?date=[date]</code>
+
The PHR may use, and the XIS shall be capable of processing, the following parameters to configure the search query:
−
 
+
{| class="wikitable"
−
for more information on how to query on dates using FHIR see [http://hl7.org/fhir/stu3/search.html#date| the FHIR search specification]
+
! colspan="4" style="font-weight: bold; text-align:left;" | Observation
−
 
+
|-
−
'''examples:'''
+
| style="font-weight: bold;" | Name
−
 
+
| style="font-weight: bold;" | Type
−
retrieve appointments with a start date/time from 01-01-2018 onwards:
+
| style="font-weight: bold;" | Description
−
 
+
| style="font-weight: bold;" | Example
−
<code>GET [base]/Appointment/?date=gt2017-12-31</code>
 
−
 
 
−
retrieve appointments with a start date/time from 01-01-2018 until 01-03-2018
 
−
 
 
−
<code>GET [base]/Appointment/?date=ge2018-01-01&date=lt2018-03-01</code>
 
−
 
 
−
===Server - XIS===
 
−
Important sections of the FHIR specification for a server in this use case are the [http://hl7.org/fhir/STU3/http.html#2.21.0 RESTful API section] the [http://hl7.org/fhir/STU3/search.html search section].
 
−
 
 
−
====Response on search request====
 
−
If the search succeeds, the server SHALL return a 200 OK HTTP status code and the returned 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 [http://hl7.org/fhir/operationoutcome.html 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 are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome. An 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. <code>GET [base]/Appointment?patient=101</code>, where "101" does not exist
 
−
* A parameter may refer to an unknown code e.g. <code>GET [base]/Appointment?appointment-type=83280</code>, where the 83280 is not known to the server
 
−
* A parameter may refer to a time that is out of scope e.g. <code>GET [base]/Appointment?date=le1995</code>, where the system only has data going back to 2001
 
−
* A date/time parameter may have incorrect format e.g. <code>GET [base]/Appointment?date=23%20May%202009</code>
 
−
* 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:
 
−
* [http://hl7.org/fhir/STU3/http.html#search Search]
 
−
 
 
−
===<span id="Operations1"></span>Operations===
 
−
No operations are defined or needed for this transaction.
 
−
 
 
−
===Search parameters===
 
−
{| class="wikitable" width="1400px"
 
−
|-style="background-color: #1F497D; color: white; font-weight: bold; "
 
−
|Name||Type||Description||Expression
 
−
|-style="vertical-align:top; background-color: #E3E3E3;  
 
 
|-
 
|-
 +
| [https://www.hl7.org/fhir/stu3/appointment.html#search <code>date</code>]
 
| date
 
| date
−
| [http://hl7.org/fhir/stu3/search.html#date date]
+
| Appointment date/time based on '''start''' date/time.
−
| Appointment date/time.
+
| Retrieve appointments with a start date/time from 01-01-2018 onwards:
−
| Appointment.start
+
<pre>GET [base]/Appointment?date=gt2017-12-31</pre>
 +
Retrieve appointments with start date/time from 01-01-2018 until 01-03-2018:
 +
<pre>GET [base]/Appointment?date=ge2018-01-01&date=lt2018-03-01</pre>
 
|-
 
|-
 
|}
 
|}
  
−
==Profiles==
+
===Server - XIS===
 +
The returned data to the PHR should conform to the HCIMs and their associate profiles listed in the table below.
  
−
{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.eafspraak|p2=nictiz.fhir.nl.stu3.zib2017}}
+
{{MedMij:V2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.eafspraak|v1Min=1.0.0|p2=nictiz.fhir.nl.stu3.zib2017|v2Min=2.0.0}}
  
 
{| class="wikitable" width="1400px"
 
{| class="wikitable" width="1400px"
Regel 126: Regel 100:
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| Zorgverlener
+
| rowspan="2" | Zorgverlener
−
| HealthProfessional
+
| rowspan="2" | HealthProfessional
 
| Practitioner
 
| Practitioner
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| Zorgaanbieder
+
| PractitionerRole
−
| HealthcareProvider
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
−
| Organization
 
−
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
−
|-
 
−
| Afspraak
 
−
| Appointment
 
−
| Appointment
 
−
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
 
−
|-
 
−
|}
 
−
 
 
−
==Examples==
 
−
{{Sjabloon:Voorbeelden}}
 
−
 
 
−
=Use case: book an appointment=
 
−
 
 
−
==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.
 
−
 
 
−
==Actors==
 
−
{| class="wikitable" "cellpadding="10"
 
−
! style="text-align:left;"| '''Actor'''
 
−
! style="text-align:left;"| '''Role'''
 
−
|-
 
−
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
 
−
|style="background-color: white;vertical-align:top;"|Book appointment
 
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
+
| rowspan="2" | Zorgaanbieder
−
|style="background-color: white;vertical-align:top;"|Handles appointment request
+
| rowspan="2" | HealthcareProvider
−
|}
 
−
 
 
−
==Invocations==
 
−
===Client - PHR===
 
−
 
 
−
====Search for available slots ====
 
−
The PHR system can request available slots using the [[#Operations2|<code>$prefetch</code> 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:
 
−
 
 
−
<code>POST [base]/Slot/$prefetch</code>
 
−
 
 
−
The optional input parameters can be put in the request body using the Parameters resource. The full specification of the <code>$prefetch</code> operation is described here:
 
−
[[#Operations2|$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'''
 
−
 
 
−
<pre>
 
−
{
 
−
  "resourceType": "Parameters",
 
−
  "parameter": [
 
−
    {
 
−
      "name": "start",
 
−
      "valueDateTime" : "2017-07-15T20:00:00Z"
 
−
    },
 
−
    {
 
−
      "name": "end",
 
−
        "valueDateTime" : "2017-07-17T20:00:00Z"
 
−
    }
 
−
]
 
−
}
 
−
</pre>
 
−
 
 
−
A Bundle containing the available Slot resources and an optional [http://hl7.org/fhir/stu3/operationoutcome.html OperationOutcome] resource can be expected as return.
 
−
 
 
−
For more information on how operations work using FHIR see [http://hl7.org/fhir/stu3/operations.html the FHIR search specification]
 
−
 
 
−
====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 [[#Operations2|$book operation]].
 
−
The operation can be performed by an HTTP POST as shown:
 
−
 
 
−
<code>POST [base]/Appointment/$book</code>
 
−
 
 
−
The full specification of the $book operation is described here:
 
−
[[#Operations2|$book operation]]
 
−
 
 
−
The proposed Appointment has to be put in the request body using the Parameters resource.
 
−
 
 
−
<pre>
 
−
{
 
−
  "resourceType": "Parameters",
 
−
  "parameter": [
 
−
      {
 
−
        "name": "appointment",
 
−
        "resource": {
 
−
            "resourceType": "Appointment",
 
−
            --snip--
 
−
        }
 
−
      },
 
−
  ]
 
−
}
 
−
</pre>
 
−
 
 
−
A Bundle containing an required Appointment resource with status "booked" or "cancelled" and an optional [http://hl7.org/fhir/stu3/operationoutcome OperationOutcome] resource can be expected as return.
 
−
 
 
−
===Server - XIS===
 
−
Important sections of the FHIR specification for a server in this use case are the [http://hl7.org/fhir/STU3/http.html#2.21.0 RESTful API section] and the [http://hl7.org/fhir/STU3/operations.html operations section].
 
−
 
 
−
====Serve available slots ====
 
−
A Client can fetch available slots using the <code>$prefetch</code> 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.
 
−
 
 
−
====Handle appointment booking request ====
 
−
A Client can propose an appointment to be booked using the <code>$book</code> 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.
 
−
 
 
−
====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 [http://hl7.org/fhir/parameters.html Parameters] format regardless of whether there is only one or there are multiple named out parameters.
 
−
However, the defined <code>$prefetch</code> 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 [http://hl7.org/fhir/bundle.html 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
 
−
 
 
−
==Interactions, operations, search parameters==
 
−
===Interactions===
 
−
The following FHIR interactions are needed to retrieve avaialable slots information:
 
−
* [http://hl7.org/fhir/STU3/http.html#operations Operations]
 
−
 
 
−
===<span id="Operations2"></span>Operations===
 
−
* '''$prefetch''' (Fetch available Slots): {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/eAfspraak-slot-prefetch|nictiz.fhir.nl.stu3.eafspraak}}
 
−
 
 
−
<html>
 
−
<iframe width="100%" height="500" src=https://www.simplifier.net/embed/render?id=NictizSTU3-ZIB2017/eafspraken-slot-find frameborder="1" align="middle"></iframe></html>
 
−
 
 
−
* '''$book''' (Book Appointment): {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/eAfspraak-appointment-book|nictiz.fhir.nl.stu3.eafspraak}}
 
−
 
 
−
<html>
 
−
<iframe width="100%" height="500" src=https://www.simplifier.net/embed/render?id=NictizSTU3-ZIB2017/eafspraken-appointment-book frameborder="1" align="middle"></iframe></html>
 
−
 
 
−
==Profiles==
 
−
 
 
−
{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.eafspraak|p2=nictiz.fhir.nl.stu3.zib2017}}
 
−
 
 
−
{| class="wikitable" width="1400px"
 
−
|-style="background-color: #1F497D; color: white; font-weight: bold; "
 
−
|Name NL||Name EN||FHIR Resource||URL profile
 
−
|-style="vertical-align:top; background-color: #E3E3E3;
 
−
|-
 
−
| Patient
 
−
| #Zib Patient|Patient
 
−
| Patient
 
−
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
 
−
|-
 
−
| Zorgverlener
 
−
| HealthProfessional
 
−
| Practitioner
 
−
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
 
−
|-
 
−
| Zorgaanbieder
 
−
| HealthcareProvider
 
 
| Organization
 
| Organization
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
 
|-
 
|-
−
| Afspraak
+
| Location
−
| Appointment
+
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-location|nictiz.fhir.nl.stu3.zib2017}}
−
| Appointment
 
−
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
 
−
|-
 
−
|-
 
−
| Slot
 
−
| Slot
 
−
| Slot
 
−
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Slot|nictiz.fhir.nl.stu3.eafspraak}}
 
−
|-
 
−
|}
 
−
 
 
−
==Examples==
 
−
{{Sjabloon:Voorbeelden}}
 
−
 
 
−
=Use case: cancel/reschedule an appointment=
 
−
 
 
−
==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.'''
 
−
 
 
−
==Actors==
 
−
{| class="wikitable" "cellpadding="10"
 
−
! style="text-align:left;"| '''Actor'''
 
−
! style="text-align:left;"| '''Role'''
 
−
|-
 
−
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
 
−
|style="background-color: white;vertical-align:top;"|Cancel appointment
 
−
|-
 
−
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
 
−
|style="background-color: white;vertical-align:top;"|Handles cancellation request
 
−
|}
 
−
 
 
−
==Invocations==
 
−
===Client - PHR===
 
−
 
 
−
====Search for available slots ====
 
−
The PHR system can request the cancellation of a specific appointment using the [[#Operations3|$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:
 
−
 
 
−
<code>POST [base]/Appointment/$cancel</code>
 
−
 
 
−
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:
 
−
[[#Operations3|<code>$prefetch</code> operation]]
 
−
 
 
−
 
 
−
'''example body'''
 
−
 
 
−
<pre>
 
−
{
 
−
  "resourceType": "Parameters",
 
−
  "parameter": [
 
−
      {
 
−
        "name": "appointment",
 
−
        "resource": {
 
−
            "resourceType": "Appointment",
 
−
            --snip--
 
−
        }
 
−
      },
 
−
  ]
 
−
}
 
−
</pre>
 
−
 
 
−
A Bundle containing the Appointment resources and an optional [http://hl7.org/fhir/stu3/operationoutcome.html 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 [http://hl7.org/fhir/stu3/operations.html the FHIR search specification]
 
−
 
 
−
===Server - XIS===
 
−
Important sections of the FHIR specification for a server in this use case are the [http://hl7.org/fhir/STU3/http.html#2.21.0 RESTful API section] and the [http://hl7.org/fhir/STU3/operations.html operations section].
 
−
 
 
−
====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.
 
−
 
 
−
====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 [http://hl7.org/fhir/parameters.html Parameters] format whether there is only one or there are multiple named out parameters.
 
−
However, the defined <code>$cancel</code> 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 [http://hl7.org/fhir/bundle.html 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
 
−
 
 
−
==Interactions, operations, search parameters==
 
−
===Interactions===
 
−
The following FHIR interactions are needed to retrieve avaialable slots information:
 
−
* [http://hl7.org/fhir/STU3/http.html#operations Operations]
 
−
 
 
−
===<span id="Operations3"></span>Operations===
 
−
* '''$cancel''' (Cancel Appointment): {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/eAfspraak-appointment-cancel|nictiz.fhir.nl.stu3.eafspraak}}
 
−
 
 
−
<html>
 
−
<iframe width="100%" height="500" src=https://simplifier.net/embed/render?id=NictizSTU3-ZIB2017/eafspraken-appointment-cancel frameborder="1" align="middle"></iframe></html>
 
−
 
 
−
==Profiles==
 
−
{| class="wikitable" width="1400px"
 
−
|-style="background-color: #1F497D; color: white; font-weight: bold; "
 
−
|Name NL||Name EN||FHIR Resource||URL profile
 
−
|-style="vertical-align:top; background-color: #E3E3E3;
 
 
|-
 
|-
 
| Afspraak
 
| Afspraak
Regel 393: Regel 121:
 
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
 
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
 
|-
 
|-
 +
<span id="LocationNotSuporrted"></span>{{NoteBox|If a Location is not registered as separate data in relation to Organization data at the source system (especially at General Practitioner Systems (Huisartsen Informatie Systeem)), a Location resource with minimal data should be constructed as a forwarder to the Organization resource where the Appointment will take place ([[MedMij:V2020.01/FHIR_eAfspraak-LocationExample|example]]).}}
 
|}
 
|}
−
 
−
==Examples==
 
−
{{Sjabloon:Voorbeelden}}
 
−
 
−
=Terminology, NamingSystems, Mappings=
 
−
 
−
===Terminology===
 
−
Relevant ValueSets can be found through the ValueSet bindings in the listed StructureDefinitions. All ValueSets can be found here [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet here] and can be downloaded as a .zip in XML or JSON format.
 
−
 
−
===NamingSystems===
 
−
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem here].
 
−
 
−
===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 [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap here].
 
−
 
−
An explanation about mappings can be found at [[MedMij:Vprepub/FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].
 
  
 
=Release notes=
 
=Release notes=
−
Release notes can be found on the [[MedMij:Vprepub/OntwerpeAfspraak#Release_notes| functional design page]].
+
Release notes can be found on the [[MedMij:V2020.01/OntwerpeAfspraak#Release_notes| functional design page]].

Huidige versie van 22 nov 2022 om 13:35



eAfspraak
Naar medmij.nl
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch

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

Go to Afsprakenstelsel

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 involved

Actors Systems FHIR Capability Statements
Name Description Role Name Description Name Description
Patient The user of a personal healthcare environment. Request appointments from the XIS PHR Personal health record Verwijzing.png CapabilityStatement: Client FHIR Client requirements
Healthcare professional The user of a XIS Serves appointments to the PHR XIS Healthcare information system Verwijzing.png CapabilityStatement: Server FHIR Server requirements

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.

Em.png

MedMij uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages:

Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

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
PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
Zorgaanbieder HealthcareProvider Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Location http://fhir.nl/fhir/StructureDefinition/nl-core-location
Afspraak Appointment Appointment http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment

Em.png

If a Location is not registered as separate data in relation to Organization data at the source system (especially at General Practitioner Systems (Huisartsen Informatie Systeem)), a Location resource with minimal data should be constructed as a forwarder to the Organization resource where the Appointment will take place (example).

3 Release notes

Release notes can be found on the functional design page.

Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=MedMij:V2020.01/FHIR_eAfspraak&oldid=144623"