informatiestandaarden - Gebruikersbijdragen [nl]

MedMij:V2019.01 FHIR BGZ 2017

2019-03-20T15:19:35Z

Tessa van Stijn: /* Handling errors */

{{#customtitle:MedMij FHIR Implementation Guide: BgZ 2.1.0}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:BGZ_icoon.png |link=|links|90px|Use case BgZ 2017|Patient Summary (BgZ)]]
<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 1013 224 212 [[MedMij:V2019.01_OntwerpBGZ_2017|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

==Introduction==
[[Bestand:Functioneel-02.png|link=MedMij:V2019.01_Ontwerpen |100px|rechts|Functional design|Go to functional design]]

The program ‘Registratie aan de bron’ (Data capture at the point of Care) has defined Health and Care Information models ([https://zibs.nl/wiki/HCIM_Mainpage HCIMs] (English) or [https://zibs.nl/wiki/ZIB_Hoofdpagina ZIBs] (Dutch)) for The Netherlands. Next to these HCIMs, the program ‘Registratie aan de bron’ also made a selection of these HCIMs into the so-called ‘Basisgegevensset Zorg’ (Common Clinical Dataset, a Dutch version of a ‘patient summary’, further referred to as ‘BgZ’). The BgZ serves as a minimal healthcare dataset that is always appropriate for caregivers in order to provide continuity of care for a patient and can be seen as a representation of a patient summary.

A subselection of the published [https://zibs.nl/wiki/HCIM_Release_2017(EN) HCIMs release 2017] constitute the [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.0.pdf BgZ 2017]. The BgZ makes a subselection of the information concepts within the HCIMs or restricts the HCIMs to a certain category. For example, only include the general practitioner of the patient or only the last known value of 'X'. MedMij created FHIR profiles that represent these HCIMs completely if no existing and usable profiles were available. The profiles represent their entire respective HCIM, to make them applicable in a broader context than a patient summary or even the MedMij context. An overview of the profiles can be found at the [[MedMij:V2019.01_FHIR_BGZ_2017#List_of_StructureDefinitions|list of StructureDefinitions]].

The patient journey of [https://www.nictiz.nl/ehealth/MedMij Thomas van Beek], provides a patients context for exchanging a patient summary from a healthcare provider's system (XIS) to a personal health record (PHR). MedMij created a [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2019.01_Ontwerpen functional design] of the BgZ use case. This use case consists of enabling a patient to view his own BgZ in a PHR. This page will elaborate further on the HL7 FHIR details needed to exchange the BgZ information using FHIR.

==Actors involved==
{| class="wikitable"
! colspan="2" style="text-align:left;" | Actors
! colspan="2" style="text-align:left;" | Systems
! colspan="2" style="text-align:left;" | FHIR Capability Statements
|-
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
! style="text-align:left;" |Name
! style="text-align:left;" |Description
|-
| Patient
| The user of a personal healthcare enviorment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/bgz2017-clientcapabilities CapabilityStatement: Client]
| FHIR Client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/CapabilityStatement/bgz2017-servercapabilities CapabilityStatement: Server]
| FHIR Server requirements
|}

==Boundaries and Relationships==
The BgZ 2017 use case follows the BgZ 1.0 use case. The difference between the two is the underlying HCIMs, which have been upgraded from release 2015 to release 2017.

Release notes can be found here:https://github.com/Nictiz/Nictiz-STU3-Zib2017/raw/master/ReleaseNotes%20FHIR%20profielen%20ZIB2017.pdf

The BgZ use case has similarities and differences with other use cases such as Medication Process, Vital Signs and Lab Results. These use cases use the same HCIM based FHIR profiles for exchanging information. The BgZ use case covers practically all profiles included in the other use cases. However, the BgZ differs in the scope of the actual health information content that should be exchanged. For example, the BgZ conveys only the last known lab result of each type while the Lab Results use case may cover all known information.

==List of invocations==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]

This FHIR implementation guide assumes that the PHR system is able to make a connection to the XIS that contains the patients BgZ information. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'Afsprakenstelsel'].

===Client - PHR===
The PHR system requests the BgZ using individual search interactions. The BgZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgZ, the client can use multiple individual search operations based on specified search queries. The interaction can be performed by an HTTP GET or command as shown:

<code>GET [base]/[type]/{?[parameters]{&_format=[mime-type]}}</code>

The table below shows in the first four columns the BgZ sections, the HCIMs that constitute those sections and the specific content of the BgZ. The last column shows the FHIR search queries to obtain the BgZ information. These queries are based on StructureDefinitions listed in [[#List_of_StructureDefinitions| this section]].

{{FHIR-IG-Afsprakenstelsel-Note}}

{| class="wikitable collapsible" width="100%" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | #
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ Section
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Content
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Example Search URL
|-
| 1
| Patient information
| Patient
| Identification, birthdate, gender, deceasedindicator, contact details, marital status, and general practitioner (practitioner or organization)
| <pre>GET [base]/Patient?_include=Patient:general-practitioner</pre>
|-
| 2
| Payment details
| Payer
| Insurance information
| <pre>GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization</pre>
|-
| rowspan="2" | 3
| rowspan="2" | Treatment Directives
| TreatmentDirective
| Known treatment directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105</pre>
|-
| AdvanceDirective
| Known advance directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107</pre>
|-
| 4
| Contactperson
| ContactPerson
| First relation/contact
| <pre style="font-style: italic;">see Patient</pre>
|-
| 5
| Functional status
| FunctionalOrMentalStatus
| Last known functional / mental status
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006</pre>
|-
| 6
| Problems
| Concern
| All known problems
| <pre>GET [base]/Condition</pre>
|-
| rowspan="5" | 7
| rowspan="5" | Social history
| LivingSituation
| Current living situation
| <pre>GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006</pre>
|-
| DrugUse
| All known drug use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006</pre>
|-
| AlcoholUse
| All known alcohol use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003</pre>
|-
| TobaccoUse
| All known tobacco use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008</pre>
|-
| NutritionAdvice
| All known current dietary recommendations
| <pre>GET [base]/NutritionOrder?status=active</pre>
|-
| 8
| Alerts
| Alert
| All known alerts
| <pre>GET [base]/Flag</pre>
|-
| 9
| Allergies
| AllergyIntolerance
| All known information regarding allergies
| <pre>GET [base]/AllergyIntolerance</pre>
|-
| rowspan="3" | 10
| rowspan="3" | Medication
| MedicationUse
| Known medication use
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication</pre>
|-
| MedicationAgreement
| Known medication agreements
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication</pre>
|-
| AdministrationAgreement
| Known administration agreements
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication</pre>
|-
| 11
| Medical aids
| MedicalAid
| All known medical aids
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device</pre>
|-
| 12
| Vaccinations
| Vaccination
| All known vaccinations
| <pre>GET [base]/Immunization?status=completed</pre>
|-
| rowspan="3" | 13
| rowspan="3" | Vital signs
| BloodPressure
| Last known blood pressure
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9</pre>
|-
| BodyWeight
| Last known body weight
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7</pre>
|-
| BodyHeight
| Last known body height
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9</pre>
|-
| 14
| Results
| LaboratoryTestResult
| Last known laboratory results per type
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen</pre>
|-
| 15
| Procedures
| Procedure
| All surgical procedures
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003</pre>
|-
| 16
| Encounters
| Contact
| All hospital admissions (no outpatient contacts)
| <pre>GET [base]/Encounter?class=http://hl7.org/fhir/v3/ActCode|IMP,http://hl7.org/fhir/v3/ActCode|ACUTE,http://hl7.org/fhir/v3/ActCode|NONAC</pre>
|-
| rowspan="5" | 17
| rowspan="5" | Planned care
| rowspan="5" | PlannedCareActivity
| rowspan="5" | All known planned care activities <nowiki>[</nowiki> [[#MM-115|*]] <nowiki>]</nowiki>
| <pre>GET [base]/ProcedureRequest?status=active</pre>
|-
| <pre>GET [base]/ImmunizationRecommendation</pre>
|-
| <pre style="text-decoration: line-through;">GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&status=in-progress,preparation&_include=MedicationDispense:medication</pre>
|-
| <pre>GET [base]/DeviceRequest?status=active&_include=DeviceRequest:device</pre>
|-
| <pre>GET [base]/Appointment?status=booked,pending,proposed</pre>
|-
| 18
| General practitioner
| HealthProfessional
| General Practitioner of the patient
| <pre style="font-style: italic;">see Patient</pre>
|}

===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] and [http://hl7.org/fhir/STU3/operations.html operation section] (for the nlast operation).

====Response to resource requests====
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 returned content SHALL conform to the StructureDefinition applicable for the specific HCIM request. The list of a StructureDefinitions relevant for this use case is shown in the following paragraph: [[#List_of_StructureDefinitions | List of StructureDefinitions]]

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

In the case of a RESTful search, these parameters are encoded in the self-link in the bundle that is returned:
<pre>
<link>
<relation value="self"/>
<url value="http://example.org/Patient?identifier=[Patient-ID]/>
</link>
</pre>

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. The HTTP status code 404 is returned if a XIS did not implement an endpoint used in a request by a PHR. When the search fails, a server SHOULD return an OperationOutcome detailing the cause of the failure. For example, in case of a not implemented FHIR endpoint, the OperationOutcome would state that the resource type is not supported. Note: an empty search result is not a failure.

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

In some cases, parameters may cause an error. For instance:

* A parameter may refer to a non-existent resource e.g. <code>GET [base]/Observation?subject=101</code>, where "101" does not exist
* A parameter may refer to an unknown code e.g. <code>GET [base]/Observation?code=loinc|1234-1</code>, where the LOINC code "1234-1" is not known to the server
* A parameter may refer to a time that is out of scope e.g. <code>GET [base]/Condition?onset=le1995</code>, where the system only has data going back to 2001
* A parameter may use an illegal or unacceptable modifier e.g. <code>GET [base]/Condition?onset:text=1995</code>, where the modifier cannot be processed by the server
* A date/time parameter may have incorrect format e.g. <code>GET [base]/Condition?onset=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.

Link to relevant FHIR specification: http://hl7.org/fhir/STU3/search.html#errors

==Interactions, operations, search parameters==

===Interactions===

The following logical interactions are needed for the BgZ use case:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
The following [http://hl7.org/fhir/STU3/operations.html operation] is needed for this use case.
* [http://hl7.org/fhir/STU3/observation-operations.html#lastn Last N Observations Query]

The lastn query meets the common need for searching for the most recent or last n=number of observations for a subject. For example, retrieving the last 5 temperatures for a patient to view trends or fetching the most recent laboratory results or vital signs. The link will provide more detailed information and examples regarding this operation.

===Search parameters===
The following search parameter types and search result parameters need to be supported for this use case.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
** Including modifier 'in'
* [http://hl7.org/fhir/STU3/search.html#reference reference]

Search result parameters:
* [http://hl7.org/fhir/STU3/search.html#include _include]
* [http://hl7.org/fhir/STU3/search.html#include _revinclude]

==List of StructureDefinitions==
The profiles represent their entire respective HCIM, to make them applicable in a broader context than the exchange of BgZ or a MedMij context. An example of reuse of existing profiles are those of the patient administration resources and vital signs.

{{NoteBoxPackage|https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017/1.1.0|1.1.0|MedMij:V2019.01_FHIR_IG}}

{| class="wikitable" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Section
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | ZIB NL
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | FHIR Resource
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR Profile
|-
| 01
| Patient
| #ZIB Patient|Patient
| Patient
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| rowspan="3" |02
| rowspan="3" | Betaler
| rowspan="3" | Payer
| Coverage
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Payer http://nictiz.nl/fhir/StructureDefinition/zib-Payer]
|-
| Organization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|-
| Patient
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| rowspan="2" |03
| BehandelAanwijzing
| TreatmentDirective
| Consent
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective]
|-
| Wilsverklaring
| AdvanceDirective
| Consent
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective]
|-
| 04
| Contactpersoon
| ContactPerson
| Patient.contact
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient]
|-
| 05
| Funct. OfMentaleStatus
| FunctionalOrMentalStatus
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus]
|-
| 06
| Probleem
| Problem
| Condition
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Problem http://nictiz.nl/fhir/StructureDefinition/zib-Problem]
|-
| rowspan="5" | 07
| Woonsituatie
| LivingSituation
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation]
|-
| DrugsGebruik
| DrugUse
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse]
|-
| AlcoholGebruik
| AlcoholUse
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse]
|-
| TabakGebruik
| TobaccoUse
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse]
|-
| Voedingsadvies
| NutritionAdvice
| NutritionOrder
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice]
|-
| 08
| Alert
| Alert
| Flag
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Alert http://nictiz.nl/fhir/StructureDefinition/zib-Alert]
|-
| 09
| AllergieIntolerantie
| AllergyIntolerance
| AllergyIntolerance
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance]
|-
| rowspan="3" | 10
| rowspan="3" | MedicatieGebruik
| MedicationUse
| MedicationStatement
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse]
|-
| MedicationAgreement
| MedicationRequest
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement]
|-
| AdministrationAgreement
| MedicationDispense
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement]
|-
| rowspan="2" | 11
| rowspan="2" | MedischHulpmiddel
| rowspan="2" | MedicalDevice
| Device
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct]
|-
| DeviceUseStatement
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice]
|-
| rowspan="2" | 12
| rowspan="2" | Vaccinatie
| rowspan="2" | Vaccination
| Immunization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination]
|-
| ImmunizationRecommendation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation]
|-
| rowspan="3" | 13
| Bloeddruk
| BloodPressure
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure]
|-
| LichaamsGewicht
| BodyWeight
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight]
|-
| LichaamsLengte
| BodyHeight
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight]
|-
| rowspan="2" | 14
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| Observation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation]
|-
| Specimen
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen]
|-
| 15
| Verrichting
| Procedure
| Procedure
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Procedure http://nictiz.nl/fhir/StructureDefinition/zib-Procedure]
|-
| 16
| Contact
| Encounter
| Encounter
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-Encounter http://nictiz.nl/fhir/StructureDefinition/zib-Encounter]
|-
| rowspan="5" | 17
| rowspan="5" | GeplandeZorgActiviteit
| rowspan="5" | PlannedCareActivity
| ProcedureRequest
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest]
|-
| MedicationDispense <nowiki>[</nowiki> [[#MM-115|*]] <nowiki>]</nowiki>
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement]
|-
| ImmunizationRecommendation
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation]
|-
| DeviceRequest
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceRequest http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceRequest]
|-
| Appointment
| [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment]
|-
| rowspan="3" | 18
| rowspan="2" | Zorgverlener
| rowspan="2" | HealthProfessional
| Practitioner
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner]
|-
| PractitionerRole
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole]
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| [https://simplifier.net/resolve?target=simplifier&canonical=http://fhir.nl/fhir/StructureDefinition/nl-core-organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization]
|}

==Terminology, NamingSystems, Mappings==

===Terminology===
Relevant value sets can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ValueSet using the ValueSet category]. All resources can be downloaded in a .zip in XML or JSON format. In the .zip, the value sets are stored in the directory 'value sets'.

===NamingSystems===
Relevant NamingSystems can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=NamingSystem using the NamingSystem category].

===Mappings===
Relevant HCIM to FHIR value set mappings can be found [https://simplifier.net/NictizSTU3-Zib2017/~resources?category=ConceptMap using the ConceptMap category].
All profiles include HCIM mappings. HCIM concepts are mapped to the corresponding FHIR elements using the HCIMs concept id. The top of the StructureDefinition contains meta information regarding the HCIM mapping, such as the name and uri of the HCIM. In the StructureDefinition elements, the corresponding HCIM ID is given including the mapping meta information id. This is illustrated in the following example.

<pre>
<StructureDefinition>
<id value="nl-core-patient" />
.....
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<uri value="https://zibs.nl/wiki/Patient-v3.1(2017EN)"/>
<name value="HCIM Patient-v3.1(2017EN)"/>
</mapping>
.....
<element id="Patient.name">
<path value="Patient.name" />
<short value="NameInformation" />
<alias value="Naamgegevens" />
<type>
<code value="HumanName" />
<profile value="http://fhir.nl/fhir/StructureDefinition/nl-core-humanname" />
</type>
<mapping>
<identity value="hcim-patient-v3.1-2017EN"/>
<map value="NL-CM:0.1.6"/>
</mapping>
</element>
.....
</StructureDefinition>
</pre>

=Annex: Document history=
==Release notes==
Release notes can be found on the [[MedMij:V2019.01_OntwerpBGZ_2017#Release_notes|functional design page]].

==History==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Date
!style="text-align:left;"|Description
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"| '''*''' [https://bits.nictiz.nl/browse/MM-115 MM-115] Solved inconsistency in the List of StructureDefinitions. Also we will no longer check PlannedCareActivityForTransfer for MedicationAdministration in section 17 Zorgplan, because we found it was unimplementable as-is. Presumed solution will come from a future HCIM release
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 11-03-2019
| style="background-color: white;"|
*Publication of changes in version 2019.01, conform release notes
*Moved release notes to functional design page
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 18-10-2018
| style="background-color: white;"| Corrected SNOMED code in search url for FunctionalOrMantalStatus
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 15-10-2018
| style="background-color: white;"| Added version in title, and document history
|}
[[categorie:MedMij FHIR Use Cases]]

MedMij:Vprepub-2019.01 FHIR BGZ 2017

2019-03-20T15:19:35Z

Tessa van Stijn: /* Handling errors */

Handleiding Wiki documentatie

2017-02-21T17:01:31Z

Tessa van Stijn: Verduidelijking mbt het gebruik van PUSH / PULL in de naam van een transactie

Daar waar het specificeren plaatsvindt in ART-DECOR, wordt Wiki gebruikt om een functionele beschrijving te geven van de informatiestandaarden. Op de Wiki pagina wordt, naast het functioneel ontwerp van de informatiestandaard, ook de verbinding gelegd naar o.a. de bijbehorende richtlijnen en zorgstandaarden. Vanuit de Wiki pagina is het mogelijk om door te klikken naar de bijbehorende specificaties in ART-DECOR.

=Opbouw Wiki pagina’s=

De Wiki pagina’s voor de verschillende informatiestandaarden zijn qua opbouw gelijk aan elkaar. Weliswaar kan de wijze waarop de pagina’s per informatiestandaard al dan niet gevuld zijn per informatiestandaard verschillen. Zo kan bij een informatiestandaard sprake zijn van meerdere kaders en uitgangspunten in tegenstelling tot een andere informatiestandaard, kan het zijn dat optionele hoofdstukken al dan niet gevuld zijn en is het mogelijk dat een informatiestandaard uit één of meerdere use cases bestaat. De Wiki pagina’s bestaan generiek uit onderstaande hoofdstukken, waarbij middels “...” is aangegeven dat informatiestandaard specifiek aanvullingen mogelijk zijn. Met ”(optioneel)” is aangegeven dat deze hoofdstukken niet voor alle informatiestandaarden gevuld hoeven te zijn.

:1. [[#Inleiding|Inleiding]]
::1.1 [[#Inleiding->Algemeen|Algemeen]]
::1.2 [[#Inleiding->Doelgroep|Doelgroep]]
::1.3 [[#Inleiding->Kaders & Uitgangspunten|Kaders & Uitgangspunten]]
:::1.3.1 [[#Inleiding->Kaders & Uitgangspunten->Richtlijn|Richtlijn]]
:::1.3.2 [[#Inleiding->Kaders & Uitgangspunten->Infrastructuur|Infrastructuur]]
:::1.3.3 ...
::1.4 [[#Inleiding->Kwalificatie|Kwalificatie]]
:2. [[#Use cases|Use case(s)]]
::2.1 [[#Use cases->Use case X|Use case X]]
:::2.1.1 [[#Use cases->Use case X->Procesbeschrijving|Procesbeschrijving]]
:::2.1.2 [[#Use cases->Use case X->Bedrijfsrollen|Bedrijfsrollen]]
:::2.1.3 [[#Use cases->Use case X->Systemen & Systeemrollen|Systemen & Systeemrollen]]
:::2.1.4 [[#Use cases->Use case X->Transacties & Transactiegroepen|Transacties & Transactiegroepen]]
::2.2 ...
:3. [[#Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)|Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)]]
:4. [[#Verantwoordelijkheden voor informatie (optioneel)|Verantwoordelijkheden voor informatie (optioneel)]]
:5. [[#Afschermen van gegevens (optioneel)|Afschermen van gegevens (optioneel)]]
:6. [[#Infrastructuur (optioneel)|Infrastructuur (optioneel)]]
:7. ...
:8. [[#Referenties|Referenties]]
:9. [[#Paginahistorie|Paginahistorie]]

Klik [https://informatiestandaarden.nictiz.nl/wiki/Format_Wiki_documentatie hier] voor de pagina waarin dit format is uitgewerkt t.b.v. het opstellen van een nieuwe Wiki pagina. Door de brontekst van het format te kopiëren en de tekst in hoofdletters te vervangen door de benodigde informatie, kan een Wiki pagina opgesteld worden.

=Pagina onderdelen van Wiki pagina’s=
Onderstaande subhoofdstukken geven een korte beschrijving van alle pagina onderdelen waaruit een Wiki pagina is opgebouwd.

==Inleiding==

De inleiding van een Wiki pagina geeft een informatiestandaard specifieke beschrijving, zonder in te zoomen op de concrete use cases die onderdeel zijn van de informatiestandaard. De beschrijving is opgesplitst in verschillende subhoofdstukken, waaronder ''Algemeen'', ''Doelgroep'', ''Kaders & Uitgangspunten en Infrastructuur''.

==Inleiding->Algemeen==

Een algemene toelichting op de Wiki pagina waarin wordt aangegeven dat de pagina een functioneel ontwerp voor een bepaalde informatiestandaard is. Tevens wordt de context waarin de pagina door de lezer geplaatst moet worden nader toegelicht.

==Inleiding->Doelgroep==

Een opsomming van de doelgroepen waarvoor de Wiki pagina is opgesteld, veelal zijn dit de volgende personen en organisaties: productmanagers, architecten, ontwerpers en testers van XIS-leveranciers, regio-organisaties en vertegenwoordigers van zorgverleners. Indien sprake is van een doelgroep per use case, wordt deze hier aangegeven.

==Inleiding->Kaders & Uitgangspunten==

De kaders en uitgangspunten van de Wiki pagina waarbij de beschrijving is opgesplitst in verschillende subhoofdstukken, waaronder Richtlijn, Infrastructuur en Kwalificatie.

==Inleiding->Kaders & Uitgangspunten->Richtlijn==

Een beschrijving van, incl. referentie naar, de richtlijn die als uitgangspunt voor de informatiestandaard gebruikt is.

==Inleiding->Kaders & Uitgangspunten->Infrastructuur==

Een tekstuele toelichting waarin kan worden aangegeven dat de informatiestandaard infrastructuur onafhankelijk is. Infrastructuur specifieke informatie is opgenomen in een ander hoofdstuk.

==Inleiding->Kwalificatie==
Indien sprake is van een kwalificatiemogelijkheid bij Nictiz voor de informatiestandaard, wordt hier een referentie opgenomen naar de pagina waar meer informatie is terug te vinden over kwalificaties.

==Use cases==
Een informatiestandaard kan bestaan uit één of meerdere use cases. Iedere use case koppelt met een scenario in ART-DECOR.

==Use cases->Use case X==
In dit hoofdstuk wordt een beschrijving gegeven van één (van de) use case(s) waarvan voor deze informatiestandaard sprake is. De Use case X wordt vervangen door de naam van de use case.
De beschrijving is opgesplitst in verschillende subhoofdstukken, namelijk: ''Procesbeschrijving'', ''Bedrijfsrollen'', ''Systemen & Systeemrollen'' en ''Transacties & Transactiegroepen''.

==Use cases->Use case X->Procesbeschrijving==
Een beschrijving van het zorgproces waar de use case betrekking op heeft. De zaken die reeds beschreven zijn, bijv. in de richtlijnen die als uitgangspunt zijn gebruikt, worden niet in zijn geheel herhaald in de procesbeschrijving. Hier worden alleen zaken beschreven die benodigd zijn om het scenario in ART-DECOR (behorende bij deze use case) in context te plaatsen. Eventueel kan hier zowel de huidige als toekomstige situatie beschreven worden.

==Use cases->Use case X->Bedrijfsrollen==
Een opsomming van de bedrijfsrollen die bij het proces van deze use case betrokken zijn. Bedrijfsrol is een type “actor” en betreft de functionele rollen die bij het proces betrokken zijn. In dit hoofdstuk worden dan ook geen systeemrollen vermeld, maar de rol die een persoon en/of organisatie(delen) vervuld zoals bijv. een voorschrijver en/of een meldkamer. Op basis van een UML Activity diagram wordt in dit hoofdstuk een overzicht geboden van alle activiteiten die in het proces worden uitgevoerd, opgesplitst naar de verschillende bedrijfsrollen.

==Use cases->Use case X->Systemen & Systeemrollen==
Een opsomming van de informatiesystemen die door de bedrijfsrollen gebruikt worden. De systemen worden benoemd naar hun functionele aard. Vervolgens wordt per informatiesysteem opgesomd welke systeemrollen dit systeem vervuld.
Een systeemrol is een functie die het systeem vervuld en wordt in ART-DECOR als “actor” gevuld als onderdeel van een transactie (zie ook volgend hoofdstuk). De naamgeving van de systeemrol is afhankelijk van het type transactie (push/pull) waarbij een systeemrol betrokken is.

Een systeem kan één of meerdere van de volgende systeemrollen vervullen:
*Sturend Systeem;
*Ontvangend Systeem;
*Raadplegend Systeem;
*Beschikbaarstellend Systeem.

De samenhang tussen deze systeemrollen is:
*Sturend Systeem stuurt gegevens naar het Ontvangend Systeem;
*Ontvangend Systeem ontvangt gegevens van een Sturend Systeem;
*Raadplegend Systeem vraagt gegevens op bij een Beschikbaarstellend Systeem;
*Beschikbaarstellend Systeem stuurt de gevraagde gegevens naar een Raadplegend Systeem.

De naamgeving van systeemrollen is informatiestandaard overstijgend afgestemd, waarbij is afgesproken dat iedere systeemrol een unieke code [***-***] heeft. Deze code is opgebouwd uit twee sub-codes, waarbij de *** voor het verbindingsstreepje staan voor de eerste/logische letters van de informatiestandaard. Voor de informatiestandaard ''Acute Zorg Proces'' is dit bijv. AZP. De *** na het verbindingsstreepje staan voor de eerste/logische letters van het type overdrachtsbericht. Dit zijn drie letters, waarbij de eerste twee letters de eerste/logische letters van de transactienaam zijn (bijv. ''SP'' voor ''Spoedbericht'') en de laatste letter staat voor de generieke systeemrol (bijv. ''S'' voor ''Sturend Systeem''). Zo ontstaat bijvoorbeeld ''AZP-SPS'': Acute Zorg Proces – Spoedbericht Sturend Systeem.

Per systeem wordt in dit hoofdstuk één UML Component diagram opgenomen, waarin de verschillende systeemrollen worden getoond zodat voor een leverancier van een systeem inzichtelijk is welke systeemrollen zijn/haar systeem bevat in het kader van de desbetreffende use case. Er wordt gekwalificeerd op basis van systeem.

In ART-DECOR worden de systeemrollen in detail beschreven; dit blijft in dit hoofdstuk achterwegen, er vindt slechts een verwijzing plaats naar ART-DECOR.

==Use cases->Use case X->Transacties & Transactiegroepen==
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties, een verzameling van transacties (bijvoorbeeld een vraag- en antwoordbericht) vormt een zogeheten transactiegroep.

De naam van de transactie wordt bepaald aan de hand van het soort transactie, waarbij binnen een transactiegroep sprake is van:
*Sturen en Ontvangen;
*Raadplegen en Beschikbaarstellen.
Het soort transactie wordt gevolgd door het soort bericht dat wordt uitgewisseld, bijv. Spoedbericht. Zo ontstaat bijvoorbeeld ''Sturen Spoedbericht''.

De naam van de transactiegroep wordt bepaald door het soort bericht dat wordt uitgewisseld (bijv. Spoedbericht) gevolgd door een indicator voor het type transactie hoofdletters, tussen haakjes ((PUSH), (PULL)).
*Sturen en Ontvangen -> PUSH.
*Raadplegen en Beschikbaarstellen -> PULL.
Zo ontstaat bijvoorbeeld ''Spoedbericht PUSH''.
Het betreft de situaties waarbij een indicator eenduidig is bepaald voor het type transactie. In de situaties waarbij geen keuze is gemaakt voor een indicator voor het type transactie (zoals bijv. sommige CDA standaarden die alleen de inhoud en syntax beschrijven maar geen uitspraak doen over het type transactie) bevat de naam van een transactie geen PUSH- of PULL- deel.

De transacties die tussen de systeemrollen plaatsvinden, incl. bijbehorende berichtspecificaties staan niet in dit functioneel ontwerp (en dus niet op de Wiki pagina) uitgewerkt, er vindt slechts een verwijzing plaats naar ART-DECOR.

ART-DECOR beschrijft bij de scenario’s uit welke gegevenselementen een transactie bestaat en wat de cardinaliteit van deze elementen is. Voor de daadwerkelijke uitwisseling wordt gebruik gemaakt van de HL7-specifieke realisatie van deze “logische” berichten in de vorm van templates.

Dit hoofdstuk toont een UML Use Case diagram waarin de verschillende bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroepen, zoals eerder op de Wiki pagina beschreven, aan elkaar gelinkt worden. Op deze manier wordt inzichtelijk hoe de functionele specificaties (bedrijfsrollen, activiteiten) uiteindelijk mappen op de technische specificaties (systeemrollen, transacties, transactiegroepen) in ART-DECOR.

==Aanwijzingen / eisen voor functionaliteit van systemen (optioneel)==
Een beschrijving van de aanwijzingen/eisen voor functionaliteit van systemen zoals die tijdens de ontwikkeling van een informatiestandaard geïdentificeerd worden en waaraan de systemen dan ook moeten voldoen.

==Verantwoordelijkheden voor informatie (optioneel)==
Een uiteenzetting van de verantwoordelijkheden voor informatie die in het kader van de informatiestandaard wordt overgedragen. In dit hoofdstuk kan inzichtelijk gemaakt worden welke bedrijfsrol wanneer de inhouds- en beheerverantwoordelijkheid heeft voor geleverde medische informatie binnen het proces.

==Afschermen van gegevens (optioneel)==
Indien in het kader van de informatiestandaard afspraken zijn gemaakt omtrent het afschermen van gegevens, kunnen deze afspraken in dit hoofdstuk beschreven worden.

==Infrastructuur (optioneel)==
Mocht voor de informatiestandaard sprake zijn van een specifieke infrastructuur waarop de informatie die in de informatiestandaard is gespecificeerd wordt uitgewisseld, kan in dit hoofdstuk de infrastructuur kort worden benoemd en een referentie opgenomen worden naar aanvullende documentatie bij de aanbieder van de infrastructuur in kwestie.

==Referenties==
Een overzicht met referenties waar naar verwezen wordt in het functioneel ontwerp.

==Paginahistorie==
De pagina historie behorende bij de Wiki pagina. De paginahistorie wordt bijgehouden wanneer bijv. errata verwerkt zijn in de reeds gepubliceerde Wiki pagina. Bij het uitbrengen van een nieuwe versie van de informatiestandaard, zal een nieuwe Wiki pagina (incl. bijbehorend versienummer) worden gepubliceerd. Daarbij wordt deze tabel dan aangevuld met een omschrijving van de doorgevoerde wijzigingen.