informatiestandaarden - Gebruikersbijdragen [nl]

MedMij:Vprepub-2026.01/kw-MM-1.A-AIx-FHIR-OptioneleGegevens

2020-07-20T15:38:59Z

Update bot: Copy of V2019.01

===Optionele gegevens===
Deze systeemrol kent optionele gegevens, zie eventueel [[Handleiding_Kardinaliteiten_en_conformance|kardinaliteiten en conformance]].

Deze gegevens zijn formeel niet gespecificeerd in de 6.12 versie van de standaard en daarom is het ook niet verplicht om deze te ondersteunen in deze systeemrol. Het betreft echter gegevens die leveranciers - vanuit andere systeemrollen - meestal al wél ondersteunen. Het advies aan kwalificerende partijen is dan ook om deze gegevens ook voor deze systeemrol gewoon te ondersteunen. Om die reden hebben de kwalificatiescenario's wel vulling van deze gegevens. Wanneer een leverancier deze gegevens niet ondersteunt is dat voor kwalificatie van deze systeemrol géén reden tot afkeuring.

Het gaat om:
* Zorgverlener
**Naamgegevens
**Specialisme
**Adresgegevens
**Contactgegevens
**Zorgaanbieder
* Zorgaanbieder
**OrganisatieNaam
**OrganisatieLocatie
**AfdelingSpecialisme
**Contactgegevens
**Adresgegevens
**OrganisatieType

MedMij:Vprepub-2020.01/kw-MM-1.A-AIR-FHIR

2020-07-20T15:38:58Z

Update bot: Copy of V2019.01

{{DISPLAYTITLE:AllergieIntolerantie - kwalificatie - AllergieIntolerantieVertaling raadplegend systeem - Medicatiegerelateerde allergie- en intolerantiegegevensvertaling}}

= Inleiding =
Dit document beschrijft het te doorlopen script bij kwalificatie voor de systeemrol:
* ''AllergieIntolerantieVertaling raadplegend systeem'' - medicatiegerelateerde allergie- en intolerantiegegevensvertaling
De doelgroep van dit document is de leverancier die wil kwalificeren.
De kwalificatie wordt uitgevoerd met de Nictiz kwalificatiesimulator. Deze kwalificatiesimulator kan berichten
verzenden en ontvangen.

== Algemene voorwaarden voor kwalificatie ==
Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis en begrip van de aan de standaard gerelateerde zorginformatiebouwstenen (ZIB’s).
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardelijsten en andere referenties die de standaard gebruikt.
# Kennis en begrip en het naleven van de [[#Aandachtspunten_voor_inhoudelijke_gegevens|aandachtspunten]].
# De kwalificatiedocumentatie bevat de gegevens die de kwalificerende partij zelf invoert. '''''Onjuist ingevoerde gegevens''''' (ook tijd/datum et cetera) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de PGO gebruiker. De (kandidaat)deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Uit te voeren stappen ==
Voer – voor ieder scenario – de volgende stappen uit:
# Vraag de AllergieIntolerantieVertaling gegevens op voor een bepaalde persoon, zoals beschreven in de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].
# De kwalificatiesimulator zal de AllergieIntolerantieVertaling gegevens beschikbaarstellen. Deze gegevens komen overeen met de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].
# Ontvang en verwerk (gestructureerd opslaan in de database) de AllergieIntolerantieVertaling gegevens in het systeem.
# Maak schermafdrukken van de wijze waarop het PGO de AllergieIntolerantieVertaling gegevens toont, en leg deze vast in het [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling.zip|Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]].

== Op te leveren materialen ==
De op te leveren materialen bestaan voor alle scenario’s uit:
# de technische uitgaande berichten én
# schermafdrukken.
De schermafdrukken moeten duidelijk maken dat de medicatiegerelateerde allergie- en intolerantiegegevensvertaling juist getoond worden aan de
PGO gebruiker. De inhoud van de medicatiegerelateerde allergie- en intolerantiegegevensvertaling is gespecificeerd in de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].

== Leeswijzer ==
Ieder navolgend hoofdstuk beschrijft een set scenario’s met steeds dezelfde paragraafindeling:
# Doel en verwacht resultaat,
# Scenario’s.
=Aandachtspunten voor inhoudelijke gegevens=
Hieronder volgen een aantal belangrijke aandachtspunten.

==Persoonsgegevens==
Het onderdeel ‘Persoonsgegevens’ bevat algemene gegevens over de persoon zoals naam, adres en woonplaats, maar ook een (fictief) Burgerservicenummer (BSN). PGO’s mogen echter geen BSN verwerken. Een PGO behoort namelijk tot het persoonsdomein en valt daarom buiten wetgeving voor het zorgaanbiedersdomein. Een XIS mag ook geen BSN naar het persoonsdomein – en dus PGO’s - sturen.
Er is wel een fBSN (fictief BSN voor testdoeleinden) in de persoonsgegevens opgenomen, zodat ook een XIS zich voor deze rol kan kwalificeren.

==Specifieke gegevens==
Deze paragraaf bevat specifieke gegevens die de leverancier moet meegeven als AllergieIntolerantieVertaling raadplegend systeem.

==Gegevens AllergieIntolerantieVertaling==
Het onderdeel ‘Gegevens AllergieIntolerantieVertaling’ bevat de gegevens van de AllergieIntolerantieVertaling voor de betreffende personen. Dit gaat om het verwachte resultaat van de raadpleging.

===Algemeen===
Om AllergieIntolerantieVertaling goed te kunnen implementeren is kennis en gebruik van het [[MedMij:Vprepub/OntwerpAllergieIntolerantie#Use_case_2:_Raadplegen_medicatiegerelateerde_allergie-_en_intolerantiegegevensvertaling_door_pati.C3.ABnt|functioneel]] en [[MedMij:Vprepub/FHIR_AllergyIntolerance#Use_case:_Retrieve_AllergyIntolerance612ToFHIRConversion|technisch]] ontwerp vereist.

{{:MedMij:Vprepub/kw-MM-1.A-AIx-FHIR-OptioneleGegevens}}

===Raadplegend systeem===
Dit gaat om het verwachte resultaat van de raadpleging. Het gaat er voor een raadplegend systeem (zoals een PGO) om dat alle functioneel relevante informatie in samenhang getoond wordt.

Hoe de gebruikersschermen van een raadplegend systeem, zoals een PGO, er precies uitzien, is vrij in te vullen (immers: juist gebruikersvriendelijkheid is iets waarop PGO's moeten kunnen concurreren), mits alle informatie in de juiste samenhang met de juiste semantiek (betekenis) is terug te vinden.

====Medicatie codering en weergavenaam====
Alleen de weergavenaam van het geneesmiddel of stof hoeft getoond te worden.

===Datum T===
T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat 'T - 100 dagen' betekent dit: 100 dagen eerder dan de afgesproken datum.

= Raadplegen AllergieIntolerantieVertaling =
=== Doel en verwacht resultaat ===
{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Doel|| Verwacht resultaat
|-style="vertical-align:top;|style="background-color: white;"
|Aantonen dat het systeem AllergieIntolerantieVertaling gegevens kan raadplegen (alle scenario's) ||
Het systeem genereert technisch correcte berichten.
|-style="vertical-align:top; style="background-color: white;"
|Aantonen dat ontvangen AllergieIntolerantieVertaling gegevens correct worden getoond (scenario 1.1 en 1.2) ||
Het systeem ontvangt, verwerkt (gestructureerd opslaan in systeem) en toont de AllergieIntolerantieVertaling gegevens uit het retourbericht.
|-style="vertical-align:top; style="background-color: white;"
| Aantonen dat het systeem kan omgaan met een uitvraag voor de persoon waarvoor geen AllergieIntolerantieVertaling gegevens bekend zijn (scenario 1.3)||
Het systeem gaat hier correct mee om en maakt duidelijk dat er geen AllergieIntolerantieVertaling gegevens aanwezig zijn voor de persoon.
|}

=== Scenario’s ===

{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Scenario||Beschrijving
|-style="vertical-align:top;|style="background-color: white;"
|1.1 || Alle AllergieIntolerantieVertaling gegevens van een persoon.
|-style="vertical-align:top;|style="background-color: white;"
|1.2 || Alle AllergieIntolerantieVertaling gegevens van een persoon met de verschillende mogelijkheden voor AllergieIntolerantie status.
|-style="vertical-align:top; style="background-color: white;"
|1.3 || Een persoon zonder AllergieIntolerantieVertaling gegevens.
|}
Uitgangspunt: Het raadplegen van een XIS van één specifieke zorgaanbieder waarmee verbinding is gemaakt.

=Inhoudelijke gegevens=
{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-01-AlleOnderdelen}}

{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-02}}

{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-03}}

= Documenthistorie =
== Paginahistorie ==
{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Datum|| BITS issue||Omschrijving
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 26 februari 2020
|style="background-color: white;"|
[https://bits.nictiz.nl/browse/CIO-20 CIO-20]
|style="background-color: white;"|
Paragraaf 2.3.2 Optionele gegevens toegevoegd.
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 21 januari 2020
|style="background-color: white;"|
[https://bits.nictiz.nl/browse/CIO-14 CIO-14]<br/>[https://bits.nictiz.nl/browse/CIO-17 CIO-17]<br/>[https://bits.nictiz.nl/browse/CIO-18 CIO-18]
|style="background-color: white;"|
Inhoudelijke gegevens van scenario 1.1 en 1.2:<br/>Vanwege incompatibiliteit met medicatieproces 6.12 diverse contactgegevens verwijderd,<br/> adressen specifiek gemaakt met huisnummertoevoeging, zorgverlenersrol verwijderd, contactpersoon/relatie verwijderd.
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 18 oktober 2019
|style="background-color: white;"| -
|style="background-color: white;"|
*Eerste versie voor AllergieIntolerantieVertaling
*Het kwalificatiescript en addendum (inhoudelijke gegevens) zitten in één document
|-style="vertical-align:top; background-color: #E3E3E3;;"
|}

[[Categorie:Kwalificatie|A]]

MedMij:Vprepub-2020.01/kw-MM-1.A-AIB-FHIR

2020-07-20T15:38:58Z

Update bot: Copy of V2019.01

{{DISPLAYTITLE:AllergieIntolerantie - kwalificatie - AllergieIntolerantieVertaling beschikbaarstellend systeem - Medicatiegerelateerde allergie- en intolerantiegegevensvertaling}}

= Inleiding =
Dit document beschrijft het te doorlopen script bij kwalificatie voor de systeemrol:
* ''AllergieIntolerantieVertaling beschikbaarstellend systeem'' - medicatiegerelateerde allergie- en intolerantiegegevensvertaling
De doelgroep van dit document is de leverancier die wil kwalificeren.
De kwalificatie wordt uitgevoerd met de Nictiz kwalificatiesimulator. Deze kwalificatiesimulator kan berichten
verzenden en ontvangen.

== Algemene voorwaarden voor kwalificatie ==
Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie et cetera.
# Kennis en begrip van de aan de standaard gerelateerde zorginformatiebouwstenen (ZIB’s).
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardelijsten en andere referenties die de standaard gebruikt.
# Kennis en begrip en het naleven van de [[#Aandachtspunten_voor_inhoudelijke_gegevens|aandachtspunten]].
# De kwalificatiedocumentatie bevat de gegevens die de kwalificerende partij zelf invoert. '''''Onjuist ingevoerde gegevens''''' (ook tijd/datum et cetera) leiden tot vertraging en kunnen blokkerend zijn voor het kwalificatieproces.
# Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de PGO gebruiker. De (kandidaat)deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Uit te voeren stappen ==
Voer – voor ieder scenario – de volgende stappen uit:
# Registreer in het XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].
# Maak in het XIS de AllergieIntolerantieVertaling voor deze personen aan, gebruik hiervoor de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].
# Maak schermafdrukken van de in het XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantieVertaling.zip|Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]].
# Vanaf de kwalificatiesimulator (FHIR server) kan de uitvraag gegenereerd worden (door kwalificerende XIS zelf) conform de verschillende parameters (bijvoorbeeld voor een bepaalde persoon voor een bepaalde periode), zoals beschreven in de scenario’s.
# AllergieIntolerantieVertaling gegevens beschikbaarstellen conform de scenario’s.

== Op te leveren materialen ==
De op te leveren materialen bestaan voor alle scenario’s uit:
# de technische uitgaande berichten én
# schermafdrukken.
De schermafdrukken moeten duidelijk maken dat de medicatiegerelateerde allergie- en intolerantiegegevensvertaling juist getoond worden aan de
PGO gebruiker. De inhoud van de medicatiegerelateerde allergie- en intolerantiegegevensvertaling is gespecificeerd in de [[#Inhoudelijke_gegevens|inhoudelijke gegevens]].

== Leeswijzer ==
Ieder navolgend hoofdstuk beschrijft een set scenario’s met steeds dezelfde paragraafindeling:
# Doel en verwacht resultaat,
# Scenario’s.

=Aandachtspunten voor inhoudelijke gegevens=
Hieronder volgen een aantal belangrijke aandachtspunten.

==Persoonsgegevens==
Het onderdeel ‘Persoonsgegevens’ bevat algemene gegevens over de persoon zoals naam, adres en woonplaats, maar ook een (fictief) Burgerservicenummer (BSN). PGO’s mogen echter geen BSN verwerken. Een PGO behoort namelijk tot het persoonsdomein en valt daarom buiten wetgeving voor het zorgaanbiedersdomein. Een XIS mag ook geen BSN naar het persoonsdomein – en dus PGO’s - sturen.
Er is wel een fBSN (fictief BSN voor testdoeleinden) in de persoonsgegevens opgenomen, zodat ook een XIS zich voor deze rol kan kwalificeren.

==Specifieke gegevens==
Deze paragraaf bevat specifieke gegevens die de leverancier moet meegeven als AllergieIntolerantieVertaling beschikbaarstellend systeem.

==Gegevens AllergieIntolerantieVertaling==
Het onderdeel ‘Gegevens AllergieIntolerantieVertaling’ bevat de gegevens van de AllergieIntolerantieVertaling voor de betreffende personen. Dit gaat om het verwachte resultaat van de raadpleging.

===Algemeen===
Om AllergieIntolerantieVertaling goed te kunnen implementeren is kennis en gebruik van het [[MedMij:Vprepub/OntwerpAllergieIntolerantie#Use_case_2:_Raadplegen_medicatiegerelateerde_allergie-_en_intolerantiegegevensvertaling_door_pati.C3.ABnt|functioneel]] en [[MedMij:Vprepub/FHIR_AllergyIntolerance#Use_case:_Retrieve_AllergyIntolerance612ToFHIRConversion|technisch]] ontwerp vereist.

{{:MedMij:Vprepub/kw-MM-1.A-AIx-FHIR-OptioneleGegevens}}

===Beschikbaarstellend systeem===
Het beschikbaarstellend systeem voert de gegevens uit het addendum in het XIS in en levert de resulterende berichten op voor kwalificatie. Voor een beschikbaarstellend systeem geldt dat sommige gegevens door dit beschikbaarstellende systeem bepaald mogen worden:

*Zorgverlener, zorgaanbieder. Dit mag een eigen (test)zorgverlener en organisatie zijn.
*Identificatie van AllergieIntolerantie: verwacht wordt dat hier 'eigen' identificaties aan worden toegekend in een eigen identificatiesysteem (eigen OID).

===Datum T===
T is een datum die we tijdens de kwalificatie nader invullen / afspreken. Als ergens staat T-100D betekent dit: 100 dagen eerder dan de afgesproken datum.

= Beschikbaarstellen AllergieIntolerantieVertaling =
== Doel en verwacht resultaat ==
{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Doel|| Verwacht resultaat
|-style="vertical-align:top;|style="background-color: white;"
|Aantonen dat het systeem AllergieIntolerantieVertaling gegevens kan beschikbaarstellen (alle scenario's) || Het systeem genereert technisch correcte berichten.
|-style="vertical-align:top; style="background-color: white;"
|Aantonen dat het systeem kan omgaan met een bericht waarin meer dan één AllergieIntolerantieVertaling gegeven moet worden verstuurd (scenario 1.1 en 1.2) || Het systeem stelt de AllergieIntolerantieVertaling gegevens beschikbaar.
|-style="vertical-align:top;|style="background-color: white;"
|Aantonen dat het systeem kan omgaan met een uitvraag voor de persoon waarvoor géén AllergieIntolerantieVertaling gegevens bekend zijn (scenario 1.3) || Het systeem maakt kenbaar dat er geen AllergieIntolerantieVertaling gegevens aanwezig zijn voor de persoon.
|}

== Scenario’s ==

{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Scenario||Beschrijving
|-style="vertical-align:top;|style="background-color: white;"
|1.1 || Alle AllergieIntolerantieVertaling gegevens van een persoon.
|-style="vertical-align:top; style="background-color: white;"
|1.2 || Alle AllergieIntolerantieVertaling gegevens van een persoon met de verschillende mogelijkheden AllergieIntolerantie status.
|-style="vertical-align:top; style="background-color: white;"
|1.3 || Een persoon zonder AllergieIntolerantieVertaling gegevens.
|}

=Inhoudelijke gegevens=
{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-01-AlleOnderdelen}}

{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-02}}

{{#lst:MedMij:Vprepub/CIO1.0-AddendaInhoudelijkeGegevensAIV|CIO-03}}

= Documenthistorie =
== Paginahistorie ==
{| class="wikitable"
|-style="background-color: #1F497D;; color: white; text-align:left;"
| Datum|| BITS issue||Omschrijving
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 26 februari 2020
|style="background-color: white;"|
[https://bits.nictiz.nl/browse/CIO-20 CIO-20]
|style="background-color: white;"|
Paragraaf 2.3.2 Optionele gegevens toegevoegd.
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 21 januari 2020
|style="background-color: white;"|
[https://bits.nictiz.nl/browse/CIO-14 CIO-14]<br/>[https://bits.nictiz.nl/browse/CIO-17 CIO-17]<br/>[https://bits.nictiz.nl/browse/CIO-18 CIO-18]
|style="background-color: white;"|
Inhoudelijke gegevens van scenario 1.1 en 1.2:<br/>Vanwege incompatibiliteit met medicatieproces 6.12 diverse contactgegevens verwijderd,<br/> adressen specifiek gemaakt met huisnummertoevoeging, zorgverlenersrol verwijderd, contactpersoon/relatie verwijderd.
|-style="vertical-align:top; background-color: #E3E3E3;;"
| 18 oktober 2019
|style="background-color: white;"| -
|style="background-color: white;"|
*Eerste versie voor AllergieIntolerantieVertaling
*Het kwalificatiescript en addendum (inhoudelijke gegevens) zitten in één document
|-style="vertical-align:top; background-color: #E3E3E3;;"
|}

[[Categorie:Kwalificatie|A]]

MedMij:V2020.01/kw-MM-1.A-AIR-FHIR

2020-07-20T15:38:58Z

Update bot: Copy of V2019.01

MedMij:V2020.01/kw-MM-1.A-AIB-FHIR

2020-07-20T15:38:58Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/ToelichtingSubsidie

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

MedMij beantwoordt geen vragen over subsidievereisten. Vragen over de impulsfinanciering voor PGO leveranciers zijn te stellen via de daarvoor bestemde kanalen van het ministerie Volksgezondheid, Welzijn en Sport/DUS-I. Deze kanalen en nadere informatie over deze subsidieregeling zijn te vinden via de volgende link:
https://www.dus-i.nl/subsidies/impulsfinanciering-pgo-leveranciers.

=Bijlage: Documenthistorie=
==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 30 juli 2019
| style="background-color: white;"|
* Vervanging tekst door verwijzing naar website VWS/DUS-I
|-
| style="background-color: white;"| 11 maart 2019
| style="background-color: white;"|
* Nieuwe versies informatiestandaarden inclusief systeemrollen toegevoegd conform voorjaarsrelease 2019.01.
* Patchnummer van systeemrolcodes verwijderd.
* Informatiestandaard Basisgegevens GGZ 1.0 toegevoegd
|-
| style="background-color: white;"| 11 januari 2019
| style="background-color: white;"|
* Documenthistorie toegevoegd
* Medicatiegegevens variant tijdelijke systeemrollen toegevoegd
* Wijziging naam en systeemrollen informatiestandaard AllergieIntolerantie
* Versie systeemrollen PDF/A, Zelfmetingen bijgewerkt
|-
| style="background-color: white;"| 15 februari 2019
| style="background-color: white;"|
* Correctie naamgeving Medicatiegegevens verstrekkingenvariant
|-
|}

MedMij:Vprepub-2020.01/ToelichtingKwalificatieLangdurigeZorg

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

=Inleiding=
==Algemeen==
Hier vindt u informatie over de kwalificatie van de [[MedMij:Vprepub/OntwerpLangdurigeZorg|Basisgegevens Langdurige Zorg]] op basis van het [https://www.dus-i.nl/subsidies/inzicht InZicht programma] binnen MedMij.

Deze pagina beschrijft de eisen voor zowel de raadplegende als beschikbaarstellende systemen.

De kwalificatie is ingericht aan de hand van Basisgegevens Langdurige Zorg secties en de onderliggende zibs. De Basisgegevens Langdurige Zorg omvat 9 secties, en 14 onderliggende zibs.

==Doelgroep==
De doelgroep voor deze pagina bestaat uit:
* Productmanagers, architecten, ontwerpers, bouwers en testers van PGO en XIS-leveranciers, regio-organisaties en Nictiz;
* Vertegenwoordigers van patiënten, laboratoria en zorgverleners.

=Uitgangspunten=
==Uitgangspunten voor de kwalificatie systeemrol ‘Raadplegen Basisgegevens Langdurige Zorg’ (PGO)==
Hieronder volgen de uitgangspunten bij de kwalificatie van de systeemrol ‘Raadplegen Basisgegevens Langdurige Zorg’:

* De Basisgegevens Langdurige Zorg is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.

* Een PGO raadpleegt altijd de gehele Basisgegevens Langdurige Zorg en daarmee dus alle secties (altijd alle FHIR searches).

* Een PGO kan de gehele Basisgegevens Langdurige Zorg verwerken op technisch niveau. Dat geldt per zib voor alle onderliggende data-elementen (verplicht en optioneel). Voor het tonen zijn alleen de gegevens (verplicht en optioneel) nodig die zijn opgenomen in de transactie Raadplegen Basisgegevens Langdurige Zorg (zie de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/OntwerpLangdurigeZorg#Transacties_.26_Transactiegroepen transactie specificaties] op ART-DECOR).
{{#lst:MedMij:Vprepub/Kwalificatie|Uitganspunten_Systeemrol_Raadplegen}}

* Bij raadpleging Basisgegevens Langdurige Zorg wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
* Mocht een PGO alleen enkele losse secties van de Basisgegevens Langdurige Zorg willen raadplegen, dan kan een PGO dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dit staat dan los van systeemrol ‘raadplegen Basisgegevens Langdurige Zorg’.

* Bij Basisgegevens Langdurige Zorg raadpleging geldt soms een specifieke filtering voor een zib. Labuitslagen is binnen Basisgegevens Langdurige Zorg bijvoorbeeld beperkt tot de bekende klinische chemie bepalingen, en daarvan de laatste uitslag. Andere usecases voor labuitslagen kunnen vanuit de separate informatiestandaard labuitslagen ondersteund worden.

* De Basisgegevens Langdurige Zorg secties, en de volgorde daarvan, zoals ook aangehouden in de addenda van de kwalificatiescripts, bepalen niet ''hoe'' de gegevens moeten worden weergegeven en gesorteerd in een PGO. Voor kwalificatie moeten wel alle functionele data-elementen conform de dataset van de informatiestandaard getoond worden aan de gebruiker.

* In de addenda van de kwalificatiescripts kunnen voorbeelden met data-elementen uitgewerkt zijn, die via FHIR references resolved moeten worden. Bijvoorbeeld het specialisme van een zorgverlener bij een verrichting, dat via PractitionerRole opgehaald kan worden. In het geval dat een dergelijk voorbeeld is uitgewerkt, zal bij de kwalificatie ook gecontroleerd worden of de referentie correct 'resolved' is. Het uitgangspunt is dat alle references resolvable moeten zijn, niet ''dat'' ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een clickeable link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan 'resolven', eventueel zelfs in een nieuwe sessie (na de initiële 15 minuten). Meer informatie over het gebruik van FHIR references binnen MedMij is te vinden in de informatiestandaard overstijgende principes op de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/FHIR_IG#Use_of_the_reference_datatype technische ontwerp pagina].

==Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen Basisgegevens Langdurige Zorg’ (XIS)==
Hieronder volgen de uitgangspunten voor de kwalificatie van de systeemrol ‘Beschikbaarstellen Basisgegevens Langdurige Zorg’:
{{#lst:MedMij:Vprepub/Kwalificatie|Uitganspunten_Systeemrol_Beschikbaarstellen}}

* Mocht XIS alleen enkele losse secties van de Basisgegevens Langdurige Zorg beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert een XIS voor die informatiestandaard, maar niet voor Basisgegevens Langdurige Zorg. Dit komt overzichtelijkheid ten goede voor persoon en PGO.

* Voorafgaand aan kwalificatie wordt vastgesteld welke Basisgegevens Langdurige Zorg het XIS ondersteunt.
* Basisgegevens Langdurige Zorg gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.

* Idealiter ondersteunt een Basisgegevens Langdurige Zorg beschikbaarstellend systeem de gehele Basisgegevens Langdurige Zorg. Wel is het mogelijk dat, anders dan een PGO, in het zorgproces dat het XIS ondersteunt doorgaans niet de gehele Basisgegevens Langdurige Zorg vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben. Op grond hiervan is het mogelijk dat een XIS bepaalde data-elementen niet beschikbaar kan stellen.
**Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.

* Als een XIS na kwalificatie meer of minder Basisgegevens Langdurige Zorg secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].

* XIS leverancier ondersteunt ‘Beschikbaarstellen Basisgegevens Langdurige Zorg’ vanaf een bepaalde softwareversie. Deze versie kan binnen het [https://www.dus-i.nl/subsidies/inzicht InZicht programma] (module PGO) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

==Samenvatting==
De gehele Basisgegevens Langdurige Zorg wordt als usecase gehanteerd, en de kwalificatie is daarop ingericht.

Binnen MedMij kan worden gekwalificeerd voor de systeemrollen ‘raadplegen Basisgegevens Langdurige Zorg’ en ‘beschikbaarstellen Basisgegevens Langdurige Zorg’.

De gehele Basisgegevens Langdurige Zorg wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.

PGO kwalificeert als de gehele Basisgegevens Langdurige Zorg geraadpleegd, verwerkt en getoond kan worden.

XIS kwalificeert bij (technisch) beschikbaarstellen van alle 14 zibs, hiervoor geldt geen minimum (vulling wel afhankelijk van klinische relevantie).

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 06-04-2020
| style="background-color: white;"|
* Toevoegingen uitgangspunten bij Raadplegen en Beschikbaarstellen. Gerelateerd aan BITS-issue [https://bits.nictiz.nl/browse/MM-359 MM-359]
* o.a. punt over herkwalificatie ontbrak.
|-
|-
| style="background-color: white;"| 19-07-2019
| style="background-color: white;"|
* Tekstcorrectie ten aanzien van OperationOutcome. Gerelateerd aan BITS-issue [https://bits.nictiz.nl/browse/MM-358 MM-358]
* Paginahistorie toegevoegd.
|-

MedMij:Vprepub-2020.01/ToelichtingKwalificatieGGZ

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

=Inleiding=
==Algemeen==
Hier vindt u informatie over de kwalificatie van de [[MedMij:Vprepub/OntwerpGGZ|Basisgegevens GGZ]] op basis van het [https://www.vippggz.nl/ VIPP GGZ programma] binnen MedMij.

Deze pagina beschrijft de eisen voor zowel de raadplegende als beschikbaarstellende systemen.

De kwalificatie is ingericht aan de hand van Basisgegevens GGZ secties en de onderliggende zibs. De Basisgegevens GGZ omvat 10 secties, en 24 onderliggende zibs.

==Doelgroep==
De doelgroep voor deze pagina bestaat uit:
* Productmanagers, architecten, ontwerpers, bouwers en testers van PGO en XIS-leveranciers, regio-organisaties en Nictiz;
* Vertegenwoordigers van patiënten, laboratoria en zorgverleners.

=Uitgangspunten=
==Uitgangspunten voor de kwalificatie systeemrol ‘Raadplegen Basisgegevens GGZ’ (PGO)==
Hieronder volgen de uitgangspunten bij de kwalificatie van de systeemrol ‘Raadplegen Basisgegevens GGZ’:

* De Basisgegevens GGZ is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.

* Een PGO raadpleegt altijd de gehele Basisgegevens GGZ en daarmee dus alle secties (altijd alle FHIR searches).

* Een PGO kan de gehele Basisgegevens GGZ verwerken (gestructureerd opslaan in PGO database) en tonen. Dat geldt per zib voor alle onderliggende data-elementen (verplicht en optioneel).
{{#lst:MedMij:Vdraft_Kwalificatie|Uitganspunten_Systeemrol_Raadplegen}}

* Bij raadpleging Basisgegevens GGZ wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
* Mocht een PGO alleen enkele losse secties van de Basisgegevens GGZ willen raadplegen, dan kan een PGO dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dit staat dan los van systeemrol ‘raadplegen Basisgegevens GGZ’.

* Bij Basisgegevens GGZ raadpleging geldt soms een specifieke filtering voor een zib. Labuitslagen is binnen Basisgegevens GGZ bijvoorbeeld beperkt tot de bekende klinische chemie bepalingen, en daarvan de laatste uitslag. Andere usecases voor labuitslagen kunnen vanuit de separate informatiestandaard labuitslagen ondersteund worden.

* De Basisgegevens GGZ secties, en de volgorde daarvan, zoals ook aangehouden in de addenda van de kwalificatiescripts, bepalen niet ''hoe'' de gegevens moeten worden weergegeven en gesorteerd in een PGO. Voor kwalificatie moeten wel alle functionele data-elementen conform de dataset van de informatiestandaard getoond worden aan de gebruiker.

* In de addenda van de kwalificatiescripts kunnen voorbeelden met data-elementen uitgewerkt zijn, die via FHIR references resolved moeten worden. Bijvoorbeeld het specialisme van een zorgverlener bij een verrichting, dat via PractitionerRole opgehaald kan worden. In het geval dat een dergelijk voorbeeld is uitgewerkt, zal bij de kwalificatie ook gecontroleerd worden of de referentie correct 'resolved' is. Het uitgangspunt is dat alle references resolvable moeten zijn, niet ''dat'' ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een clickeable link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan 'resolven', eventueel zelfs in een nieuwe sessie (na de initiële 15 minuten). Meer informatie over het gebruik van FHIR references binnen MedMij is te vinden in de informatiestandaard overstijgende principes op de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_FHIR_IG#Use_of_the_reference_datatype technische ontwerp pagina].

==Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen Basisgegevens GGZ’ (XIS)==
Hieronder volgen de uitgangspunten voor de kwalificatie van de systeemrol ‘Beschikbaarstellen Basisgegevens GGZ’:
{{#lst:MedMij:Vdraft_Kwalificatie|Uitganspunten_Systeemrol_Beschikbaarstellen}}

* Mocht XIS alleen enkele losse secties van de Basisgegevens GGZ beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert een XIS voor die informatiestandaard, maar niet voor Basisgegevens GGZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.

* Voorafgaand aan kwalificatie wordt vastgesteld welke Basisgegevens GGZ het XIS ondersteunt.
* Basisgegevens GGZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.

* Idealiter ondersteunt een Basisgegevens GGZ beschikbaarstellend systeem de gehele Basisgegevens GGZ, maar om een XIS tegemoet te komen, kwalificeert een XIS bij ondersteuning van minimaal 90% oftewel 21 van de 24 onderliggende zibs. Dit wijkt bewust af van het uitgangspunt voor PGO, omdat in het zorgproces dat het XIS ondersteunt, doorgaans niet de gehele Basisgegevens GGZ vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben.
**NB: afhankelijk van de zorgsetting "ambulante zorg" versus "zorg met verblijf" is de zib VrijheidsbeperkendeMaatregelen niet verplicht (ambulant: totaal 23 zibs) of wel verplicht (verblijf: totaal 24 zibs). Voor deze zib geldt dat deze altijd bij de zorgsetting "zorg met verblijf" ingebouwd moet worden; de acceptabele marge van 90% geldt dus alleen voor de overige 23 zibs.
**Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.

* Als een XIS na kwalificatie meer of minder Basisgegevens GGZ secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].

* XIS leverancier ondersteunt ‘Beschikbaarstellen Basisgegevens GGZ’ vanaf een bepaalde softwareversie. Deze versie kan binnen het VIPP-programma (module A2) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

==Samenvatting==
De gehele Basisgegevens GGZ wordt als usecase gehanteerd, en de kwalificatie is daarop ingericht.

Binnen MedMij kan worden gekwalificeerd voor de systeemrollen ‘raadplegen Basisgegevens GGZ’ en ‘beschikbaarstellen Basisgegevens GGZ’.

De gehele Basisgegevens GGZ wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.

PGO kwalificeert als de gehele Basisgegevens GGZ geraadpleegd, verwerkt en getoond kan worden.

XIS kwalificeert bij beschikbaarstellen van minimaal 21 van de 24 onderliggende zibs.

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 06-04-2020
| style="background-color: white;"|
* Toevoegingen uitgangspunten bij Raadplegen en Beschikbaarstellen. Gerelateerd aan BITS-issue [https://bits.nictiz.nl/browse/MM-359 MM-359]
* o.a. punt over herkwalificatie ontbrak.
|-
|-
| style="background-color: white;"| 30-09-2019
| style="background-color: white;"|
* Tekstcorrectie ten aanzien van OperationOutcome. Gerelateerd aan BITS-issue [https://bits.nictiz.nl/browse/MM-358 MM-358]
* Paginahistorie toegevoegd.
|-

MedMij:Vprepub-2020.01/ToelichtingKwalificatieBgZ

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

{{MedMij:Vprepub/Issuebox}}

=Inleiding=
==Algemeen==
Hier vindt u informatie over de kwalificatie van de [https://www.registratieaandebron.nl/wat-is-registreren-aan-de-bron/de-kern-van-registreren-aan-de-bron/basisgegevensset/ Basisgegevensset Zorg], ofwel BgZ, binnen MedMij.

Deze pagina beschrijft de eisen voor zowel de raadplegende als beschikbaarstellende systemen.

De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. BgZ omvat 18 secties, en 28 onderliggende zibs.

==Doelgroep==
De doelgroep voor deze pagina bestaat uit:
* Productmanagers, architecten, ontwerpers, bouwers en testers van PGO en XIS-leveranciers, regio-organisaties en Nictiz;
* Vertegenwoordigers van patiënten, laboratoria en zorgverleners.

=Uitgangspunten=
==Uitgangspunten voor de kwalificatie systeemrol ‘Raadplegen BgZ’ (PGO)==
Hieronder volgen de uitgangspunten bij de kwalificatie van de systeemrol ‘Raadplegen BgZ’:

* De BgZ is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.

* Een PGO raadpleegt altijd de gehele BgZ en daarmee dus alle secties (altijd alle FHIR searches).

* Een PGO kan de gehele BgZ verwerken (gestructureerd opslaan in PGO database) en tonen. Dat geldt per zib voor alle onderliggende data-elementen (verplicht en optioneel).
{{#lst:MedMij:Vprepub/Kwalificatie|Uitganspunten_Systeemrol_Raadplegen}}

* Bij raadpleging BgZ wordt gebruik gemaakt van losse queries en niet van bundeling als batch, onder andere om aan performance bezwaren tegemoet te komen.
* Mocht een PGO alleen enkele losse secties van de BgZ willen raadplegen, dan kan een PGO dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dit staat dan los van systeemrol ‘raadplegen BgZ’.

* Bij BgZ raadpleging geldt soms een specifieke filtering voor een zib. Labuitslagen is binnen BgZ bijvoorbeeld beperkt tot de bekende klinische chemie bepalingen, en daarvan de laatste uitslag. Andere usecases voor labuitslagen kunnen vanuit de separate informatiestandaard labuitslagen ondersteund worden.

* De BgZ secties, en de volgorde daarvan, zoals ook aangehouden in de addenda van de kwalificatiescripts, bepalen niet ''hoe'' de gegevens moeten worden weergegeven en gesorteerd in een PGO. Voor kwalificatie moeten wel alle functionele data-elementen conform de dataset van de informatiestandaard getoond worden aan de gebruiker.

* In de addenda van de kwalificatiescripts kunnen voorbeelden met data-elementen uitgewerkt zijn, die via FHIR references resolved moeten worden. Bijvoorbeeld het specialisme van een zorgverlener bij een verrichting, dat via PractitionerRole opgehaald kan worden. In het geval dat een dergelijk voorbeeld is uitgewerkt, zal bij de kwalificatie ook gecontroleerd worden of de referentie correct 'resolved' is. Het uitgangspunt is dat alle references resolvable moeten zijn, niet ''dat'' ze resolved worden. Een PGO zou er ook voor kunnen kiezen om een clickeable link te tonen, waarmee een gebruiker (de persoon) desgewenst zelf kan 'resolven', eventueel zelfs in een nieuwe sessie (na de initiële 15 minuten). Meer informatie over het gebruik van FHIR references binnen MedMij is te vinden in de informatiestandaard overstijgende principes op de [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_FHIR_IG#Use_of_the_reference_datatype technische ontwerp pagina].

==Uitgangspunten voor de kwalificatie systeemrol ‘Beschikbaarstellen BgZ’ (XIS)==
Hieronder volgen de uitgangspunten voor de kwalificatie van de systeemrol ‘Beschikbaarstellen BgZ’:
{{#lst:MedMij:Vprepub/Kwalificatie|Uitganspunten_Systeemrol_Beschikbaarstellen}}

* Mocht XIS alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan XIS dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert een XIS voor die informatiestandaard, maar niet voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.

* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens het XIS ondersteunt.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.

* Idealiter ondersteunt een BgZ beschikbaarstellend systeem de gehele BgZ, maar om een XIS tegemoet te komen, kan een XIS kwalificatie starten bij ondersteuning van minimaal 14 van de 18 BgZ secties of 20 van de 28 onderliggende Zibs. Dit wijkt bewust af van het uitgangspunt voor PGO, omdat in het zorgproces dat het XIS ondersteunt, doorgaans niet de gehele BgZ vastgelegd hoeft te worden. In tegenstelling tot PGO waarin de persoon een zo compleet mogelijk overzicht van zorggegevens wil hebben. Tijdens de kwalificatie moet het XIS alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet het XIS slagen voor kwalificatie.
** Op technisch niveau moet per zib alle onderliggende data-elementen (verplicht en optioneel) ingebouwd zijn. De vulling van deze data-elementen is afhankelijk van de klinische relevantie bepaald door de use case.

* Als een XIS na kwalificatie meer of minder BgZ secties of zibs gaat ondersteunen leidt dit tot een wijziging van de applicatie die herkwalificatie noodzakelijk maakt. Meer informatie over herkwalificatie is te vinden op de [https://www.nictiz.nl/standaardisatie/kwalificatiecentrum/herkwalificatie herkwalificatie pagina].

* XIS leverancier ondersteunt ‘Beschikbaarstellen BgZ’ vanaf een bepaalde softwareversie. Deze versie kan binnen het VIPP-programma (module A3) gebruikt worden voor de bepaling van de financiering per ziekenhuis.

==Samenvatting==
De gehele BgZ wordt als usecase gehanteerd, en de kwalificatie is daarop ingericht.

Binnen MedMij kan worden gekwalificeerd voor de systeemrollen ‘raadplegen BgZ’ en ‘beschikbaarstellen BgZ’.

De gehele BgZ wordt geraadpleegd via losse queries. Er wordt geen gebruik gemaakt van FHIR bundle bij raadplegen en beschikbaarstellen.

PGO kwalificeert als de gehele BgZ geraadpleegd, verwerkt en getoond kan worden.

XIS kwalificeert bij beschikbaarstellen van minimaal 14 van de 18 BgZ secties. Of 20 van de 28 onderliggende zibs.

=Bijlage: Documenthistorie=

==Paginahistorie==
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Datum
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 30-09-2019
| style="background-color: white;"|
* Verwijderen zin over aanvulling specificaties OperationOutcomes ([https://bits.nictiz.nl/browse/MM-358 MM-358])
* Nadere uitwerking van de BgZ kwalificatietoelichting voor XIS ([https://bits.nictiz.nl/browse/MM-359 MM-359])
|-
| style="background-color: white;"| 15-04-2019
| style="background-color: white;"|
* Nadere toelichting ten aanzien van FHIR references toegevoegd. Gerelateerd aan BITS-issue ([https://bits.nictiz.nl/browse/MM-220 MM-220])
* Nadere toelichting ten aanzien van sortering BgZ secties toegevoegd. Gerelateerd aan BITS-issue ([https://bits.nictiz.nl/browse/MM-193 MM-193])
|-
| style="background-color: white;"| 02-11-2018
| style="background-color: white;"|
* Nadere toelichting zib data-elementen toegevoegd.
* Paginahistorie toegevoegd.
|-

MedMij:V2020.01/ToelichtingSubsidie

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

MedMij:V2020.01/ToelichtingKwalificatieLangdurigeZorg

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

MedMij:V2020.01/ToelichtingKwalificatieGGZ

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

MedMij:V2020.01/ToelichtingKwalificatieBgZ

2020-07-20T15:38:57Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/OntwerpeAfspraken

2020-07-20T15:38:56Z

Update bot: Copy of V2019.01

#DOORVERWIJZING [[MedMij:Vprepub/OntwerpeAfspraak]]

MedMij:V2020.01/OntwerpeAfspraken

2020-07-20T15:38:56Z

Update bot: Copy of V2019.01

#DOORVERWIJZING [[MedMij:Vprepub/OntwerpeAfspraak]]

MedMij:Vprepub-2020.01/OntwerpMedicatie

2020-07-20T15:38:53Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Medicatieproces {{VersieInfo|V2019.01|Medicatieproces}}}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:Medicatie_proces_Icoon.png |link=|links |85px|Medicatie Proces]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_MedicationProcess|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt in relatie tot de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/informatiestandaard-medicatieproces/ informatiestandaard Medicatieproces] (MP). Deze use cases zijn gebaseerd op versie 9.x van deze standaard. Deze standaard beschrijft de uitwisseling met de patiënt nog niet expliciet. Het doel van deze pagina is om de verschillende uitwisselingsscenario's van medicatiegegevens met de patiënt toe te voegen.

Het is het streven van het MedMij-programma om deze beschrijvingen toe te voegen aan de bestaande standaard voor Medicatieproces.

Zoals [[MedMij:Vprepub/Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij voor medicatiegegevens de bouwstenen uit de informatiestandaard Medicatieproces versie 9.x als leidraad voor de uitwisseling van informatie. Voor uitwisseling van medicatiegegevens gaat het om de volgende zibs:

*Patiënt;
*Zorgaanbieder;
*Zorgverlener;
*Medicatieafspraak;
*Verstrekkingsverzoek;
*Toedieningsafspraak;
*Verstrekking;
*Medicatiegebruik;
*Toediening.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub/Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=

==Use case: Raadplegen medicatieoverzicht door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan.
===Domein===
Medicatiegegevens in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatieoverzicht vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De informatie-elementen die van toepassing zijn, zijn gedefinieerd in ART-DECOR.
====Raadplegen medicatieoverzicht====
Informatie elementen in de vraag om medicatieoverzicht staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.147-2016-11-08T103441.html hier].

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om medicatieoverzicht.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.147-2016-11-08T103441.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen medicatieoverzicht====
Informatie elementen in medicatieoverzicht staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html hier].

Dit betreft de inhoud van het medicatieoverzicht.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil medicatieoverzicht raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medicatieoverzicht beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Medicatieoverzicht'''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity Diagram - Medicatieoverzicht.png|Activiteitendiagram Raadplegen Medicatieoverzicht]]

<font size = "1">'''Activiteitendiagram Raadplegen Medicatieoverzicht'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier].

Hieronder een aantal voor Roos relevante situaties waarbij het raadplegen van een medicatieoverzicht een rol speelt.

<blockquote>De afgelopen weken is Roos aan het tobben met haar gezondheid, ze houdt vocht vast achter haar longen en voelt zich niet goed. Haar gewicht begint toe te nemen en haar bloedsuikers zijn niet meer stabiel, en ze maakt een afspraak bij haar huisarts, dokter Jacobs, op 16 juli. Deze verhoogt na onderzoek haar vochtafdrijvende medicatie iets, en geeft haar een nieuw schema waarin staat hoeveel insuline zij extra moet spuiten als de bloedglucosewaarden boven een bepaalde waarde komen. Deze medicatiewijzigingen worden ook zichtbaar in een vernieuwd medicatieoverzicht van huisartsenpraktijk Jacobs/Kroonen, die de situatie op 16 juli weergeeft. Dit medicatieoverzicht kan zij inzien in haar persoonlijke gezondheidsomgeving. Dit geeft haar grip op haar situatie, ze weet waar zij aan toe is.</blockquote>

<blockquote>Het gaat slechter met Roos en op een nacht wordt ze erg benauwd wakker, daarnaast is ze duizelig. Ondanks aanpassingen van de medicatie neemt de benauwdheid niet af, het wordt eerder erger. Joost, haar man, neemt daarom contact op met de huisartsenpost en na overleg wordt besloten dat Roos naar het ziekenhuis moet komen. Een ambulance haalt haar op. Diezelfde nacht nog wordt ze opgenomen op de afdeling cardiologie van het Epidaurus ziekenhuis. Roos blijft een aantal weken onder behandeling en langzaam verbetert haar situatie. Roos wordt op 23 augustus ontslagen uit het Epidaurus ziekenhuis. Haar medicatie is gedurende haar opname verschillende keren aangepast. Bij ontslag maakt de ziekenhuisapotheker een op dat moment actueel medicatieoverzicht voor Roos. Dit medicatieoverzicht maakt het apothekerssysteem beschikbaar voor de persoonlijke gezonheidsomgeving van Roos. Roos kan nu via haar PGO dit medicatieoverzicht van 23 augustus van het Epidaurus ziekenhuis bekijken. Dit geeft haar meer grip op haar gezondheidssituatie.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt een medicatieoverzicht beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van medicatieoverzichten tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil het medicatieoverzicht inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een medicatieoverzicht op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om een medicatieoverzicht bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert een medicatieoverzicht op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om het medicatieoverzicht in te zien.

=====Post conditie=====
De patiënt heeft het medicatieoverzicht geraadpleegd via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de medicatieoverzichten van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| MedicatieoverzichtRaadplegend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|Medicatieproces}}-MOR-FHIR
| style="background-color: white;"| Raadplegen medicatieoverzicht bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| MedicatieoverzichtBeschikbaarstellend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|Medicatieproces}}-MOB-FHIR
| style="background-color: white;"| Beschikbaarstellen medicatieoverzicht aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Medicatieoverzicht (Totaal).png|Componenten diagram]]

<font size = "1">'''Componenten diagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Medicatieoverzicht (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen medicatieoverzicht
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|Medicatieproces}}-MOR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_MedicationProcess|Medicatieoverzicht in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen medicatieoverzicht
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|Medicatieproces}}-MOB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use Case Diagram - Medicatieoverzicht.png|Use case diagram raadplegen Medicatiegegevens]]

<font size = "1">'''Use case diagram</font>

==Use case: Raadplegen medicatiegegevens door patiënt==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan.
===Domein===
Medicatiegegevens in het domein van zorgaanbieders en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatiegegevens vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De informatie-elementen die van toepassing zijn, zijn gedefinieerd in de informatiestandaard voor Medicatieproces.
====Raadplegen medicatiegegevens====
Informatie elementen in de vraag om medicatiegegevens staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.136-2016-07-12T133747.html hier].

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om medicatiegegevens.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.136-2016-07-12T133747.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen medicatiegegevens====
Informatie elementen in medicatiegegevens staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.102-2016-03-23T163243.html hier].

Dit betreft de inhoud van de transactie met medicatiegegevens.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20180426T140905/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.102-2016-03-23T163243.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil medicatiegegevens raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medicatiegegevens beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Medicatiegegevens'''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity Diagram - Medicatiegegevens.png|Activiteitendiagram Raadplegen Medicatiegegevens]]

<font size = "1">'''Activiteitendiagram Raadplegen Medicatiegegevens'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier].

Hieronder een voor Roos relevante situatie waarbij het raadplegen van een medicatiegegevens een rol speelt.

<blockquote>Roos heeft de afgelopen tijd in verband met haar hartfalen en diabetes diverse wijzigingen in haar medicatie gehad. Dit is soms gedaan door de specialist en soms door de huisarts. De apotheker paste dan daarna ook soms de doseerinstructies aan, omdat er een ander product geleverd moest worden dan voorgeschreven was. Eigenlijk is Roos het overzicht een beetje kwijtgeraakt. Gelukkig heeft haar PGO wel de mogelijkheid om bij al haar zorgverleners medicatiegegevens op te vragen. Haar PGO kan dit aan haar presenteren in een overzichtelijk geheel. Roos kan nu controleren of ze al haar medicatie inneemt conform de laatste afspraken die hierover zijn gemaakt. Dit is voor Roos heel geruststellend.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt een medicatiegegevens beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van medicatiegegevens tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil medicatiegegevens inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een medicatiegegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om beschikbare medicatiegegevens bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert medicatiegegevens op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om medicatiegegevens in te zien.

=====Post conditie=====
De patiënt kan medicatiegegevens inzien via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de medicatiegegevens van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| MedicatiegegevensRaadplegend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|Medicatieproces}}-MGR-FHIR
| style="background-color: white;"| Raadplegen medicatiegegevens bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Medicatiegegevenseschikbaarstellend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|Medicatieproces}}-MGB-FHIR
| style="background-color: white;"| Beschikbaarstellen medicatiegegevens aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Medicatiegegevens (Totaal).png|Componenten diagram]]

<font size = "1">'''Componenten diagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Link naar technische specificatie'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Medicatiegegevens (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen medicatiegegevens
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|Medicatieproces}}-MGR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_MedicationProcess|Medicatiegegevens in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen medicatiegegevens
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|Medicatieproces}}-MGB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use Case Diagram - Medicatiegegevens.png|Use case diagram raadplegen Medicatieoverzicht]]

<font size = "1">'''Use case diagram</font>

==Use case: Raadplegen verstrekkingenvertaling (medicatieverstrekkingen van het LSP) door patiënt==
Dit is een tijdelijke use case om de periode te overbruggen dat zorgaanbieders Medicatieproces 9.0 nog niet ondersteunen.
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegegevens die over henzelf gaan. Deze use case gaat specifiek over het raadplegen van verstrekkingen zoals die op het [https://www.vzvz.nl/over-het-lsp Landelijk Schakelpunt] (LSP) worden uitgewisseld. Deze verstrekkingen zijn op het LSP in Medicatieproces versie 6.12 en dat betreft een HL7v3-messaging standaard. In deze use case worden deze gegevens voor het PGO geconverteerd naar FHIR-resources.

===Domein===
Medicatieverstrekkingen vanuit het LSP.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van een medicatiegegevens vanuit een zorgaanbiederssysteem (XIS), via het LSP - met behulp van een vertaling naar FHIR - naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO): we noemen dit verstrekkingenvertaling.
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De informatie-elementen die van toepassing zijn, zijn gedefinieerd in de informatiestandaard voor Medicatieproces 6.12 en de [[MedMij:V1.0_VerstrekkingenvertalingTransactie|bijbehorende vertaling]] naar het MP-9 datamodel. MP-6.12 verstrekkingen vertalen naar de MP-9 bouwstenen: toedieningsafspraak en verstrekking.

====Raadplegen verstrekkingenvertaling====
Informatie elementen in verstrekkingenvertaling staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.161-2018-11-29T135611.html hier].

Dit betreft de inhoud van de transactie met verstrekkingenvertaling.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.161-2018-11-29T135611.html frameborder="0" align="middle"></iframe>
</html>

====Beschikbaarstellen verstrekkingenvertaling====
Informatie elementen in verstrekkingenvertaling staan hieronder. Om deze informatie in een nieuwe tab te openen, klik [https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.162-2018-11-29T135611.html hier].

Dit betreft de inhoud van de transactie met verstrekkingenvertaling.

<html>
<iframe width="100%" height="500" src=https://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.162-2018-11-29T135611.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil verstrekkingenvertaling raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt verstrekkingenvertaling beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Verstrekkingenvertaling '''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity Diagram - Verstrekkingenvertaling.png|Activiteitendiagram Raadplegen Verstrekkingenvertaling]]

<font size = "1">'''Activiteitendiagram Raadplegen Verstrekkingenvertaling '''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier].

Hieronder een voor Roos relevante situatie waarbij het raadplegen van een verstrekkingenvertaling een rol speelt.

<blockquote>Roos heeft de afgelopen tijd in verband met haar hartfalen en diabetes diverse wijzigingen in haar medicatie gehad. Dit is soms gedaan door de specialist en soms door de huisarts. De apotheker paste dan daarna ook soms de doseerinstructies aan, omdat er een ander product geleverd moest worden dan voorgeschreven was. Eigenlijk is Roos het overzicht een beetje kwijtgeraakt. Gelukkig heeft haar PGO wel de mogelijkheid om bij haar zorgverleners verstrekkingenvertaling op te vragen. Haar PGO kan dit aan haar presenteren in een overzichtelijk geheel. Roos kan nu controleren of ze al haar medicatie inneemt conform de laatste afspraken die hierover zijn gemaakt. Dit is voor Roos heel geruststellend.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt verstrekkingenvertaling beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van medicatiegegevens tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil medicatiegegevens en/of verstrekkingenvertaling inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een gegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om beschikbare verstrekkingenvertaling bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert verstrekkingenvertaling op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om verstrekkingenvertaling in te zien.

=====Post conditie=====
De patiënt kan verstrekkingenvertaling inzien via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de verstrekkingenvertaling van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| VerstrekkingenvertalingRaadplegend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|MedicatieprocesVerstrekkingenvertaling}}-MGR-FHIR
| style="background-color: white;"| Raadplegen verstrekkingenvertaling bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Verstrekkingenvertalingbeschikbaarstellend
| style="background-color: white;"| MP-{{VersieInfo|V2019.01|MedicatieprocesVerstrekkingenvertaling}}-MGB-FHIR
| style="background-color: white;"| Beschikbaarstellen verstrekkingenvertaling aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component Diagram - Verstrekkingenvertaling (Totaal).png|Componenten diagram]]

<font size = "1">'''Componenten diagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Link naar technische specificatie'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Verstrekkingenvertaling (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen verstrekkingenvertaling
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|MedicatieprocesVerstrekkingenvertaling}}-MGR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_MedicationProcess|Verstrekkingenvertaling in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen verstrekkingenvertaling
|style="background-color: white;vertical-align:top;"|MP-{{VersieInfo|V2019.01|MedicatieprocesVerstrekkingenvertaling}}-MGB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use Case Diagram - Verstrekkingenvertaling.png|Use case diagram raadplegen Verstrekkingenvertaling]]

<font size = "1">'''Use case diagram</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub/Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
{{ReleaseNotes|release=9.0.7|package=2019.01 - Mei 2020|packageIssues=2|issues=35|MM-1115|MM-1097}}
{{ReleaseNotes|package=2019.01 - Maart 2020|packageIssues=3|MM-958|MM-940|MM-926}}
{{ReleaseNotes|package=2019.01 - Februari 2020|packageIssues=4|MM-901|MM-900|MM-899|MM-852}}
{{ReleaseNotes|package=2019.01 - Januari 2020|MM-467}}
{{ReleaseNotes|issues=3|package=2019.01 - November|MM-737|MM-729|MM-456}}
{{ReleaseNotes|package=2019.01 - Oktober|MM-593}}
{{ReleaseNotes|issues=7|package=2019.01 patch|MM-348|MM-347|MM-322|MM-307|MM-295|MM-258|MM-248}}
{{ReleaseNotes|issues=14|package=2019.01|MM-219|MM-164|MM-162|MM-134|MM-127|MM-118|MM-106|MM-102|MM-99|MM-98|MM-71|MM-48|MM-42|MM-41}}
{{ReleaseNotes|package=2018.06|release=9.0.6|issues=3|MM-128|MM-105|MM-23}}
|}

MedMij:V2020.01/OntwerpMedicatie

2020-07-20T15:38:53Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/OntwerpLangdurigeZorg

2020-07-20T15:38:52Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Basisgegevens Langdurige Zorg {{VersieInfo|V2019.01|BgLZ}} (op basis van zibs release 2017)}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:BgLZ-icon.png|link=|links|95px|Use case BgLZ|BgLZ]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_BGLZ|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van Basisgegevens Langdurige Zorg (BgLZ) op basis van een selectie zorginformatiebouwstenen (zibs) binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:Vprepub/Ontwerpen|hier]] gevonden worden.

Binnen het [https://www.dus-i.nl/subsidies/inzicht InZicht programma] (VIPP langdurige zorg) zijn een drietal modules opgenomen.
* Module PGO: de Basisgegevens Langdurige Zorg is bedoeld voor deze module
* Module [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht eOverdracht] (gericht op de verpleegkundige overdracht tussen zorgprofessionals)
* Module Medicatieveiligheid: hiervoor wordt verwezen naar het [[MedMij:Vprepub/OntwerpMedicatie| functioneel ontwerp]] voor [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0].

De Basisgegevens Langdurige Zorg bestaat uit gegevens die relevant zijn voor uitwisseling met patiënten binnen de langdurige zorg via hun [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO). De Basisgegevens Langdurige Zorg vertoont enige overlap met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset Zorg (BgZ)] en [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht eOverdracht] maar is zeker niet hetzelfde: zie [[MedMij:Vprepub/OntwerpLangdurigeZorg#Informatie| Informatie]] voor een nadere toelichting over het samenstellen van de inhoud.

Het doel van deze pagina is om de uitwisseling van de Basisgegevens Langdurige Zorg met de patiënt te omschrijven.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub/Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

===Specifieke informatie over deze kwalificatie===
Specifieke informatie over de kwalificatie van de transacties 'Raadplegen Langdurige Zorg' en 'Beschikbaarstellen Langdurige Zorg' is [[MedMij:Vprepub/ToelichtingKwalificatieLangdurigeZorg| hier]] te vinden.

=Use Cases=
==Use case 1: Raadplegen Basisgegevens Langdurige Zorg in persoonlijke gezondheidsomgeving==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de Basisgegevens Langdurige Zorg die over henzelf gaan.

=== Domein ===
Basisgegevens Langdurige Zorg in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de Basisgegevens Langdurige Zorg vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie,
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De Basisgegevens Langdurige Zorg bestaat uit een selectie van 14 zibs zoals te vinden in dit [[MedMij:Vprepub/InhoudLangdurigeZorg|overzicht]]. Deze zibs vormen samen een verzameling van gegevens die patiënten binnen de langdurige zorg zelf relevant vinden om via hun PGO in te zien, zoals bepaald tijdens een aantal veldverkenningen met zowel patiënten als zorgprofessionals. De Basisgegevens Langdurige Zorg komt voor een deel overeen met de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/basisgegevensset-zorg-bgz/ Basisgegevensset Zorg (BgZ)] en [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht/ eOverdracht], maar voor een deel ook niet: het gaat om drie aparte sets. Zie het [[MedMij:Vprepub/InhoudLangdurigeZorg|overzicht van de inhoud]] voor een nadere toelichting.

Medicatiegegevens vallen buiten de Basisgegevens Langdurige Zorg, omdat hiervoor gebruik wordt gemaakt van het reeds bestaande [https://www.nictiz.nl/programmas/medicatieproces Medicatieproces 9.0] (zie [[MedMij:Vprepub/OntwerpMedicatie|uitwisseling medicatiegegevens]] in PGO).

In de MedMij FHIR implementatiegids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/FHIR_BGLZ#List_of_StructureDefinitions overzicht] is te zien welk FHIR profiel bij welke zib hoort.

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil de eigen Basisgegevens Langdurige Zorg raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt de Basisgegevens Langdurige Zorg beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Basisgegevens Langdurige Zorg'''</font>

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Image:InzienLZ_activity.PNG|Activiteitendiagram Raadplegen Langdurige Zorg]]

<font size = "1">'''Activiteitendiagram Raadplegen Langdurige Zorg'''</font>

=== Procesbeschrijving ===
==== Patient journey - Kenneth van Someren ====
De 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren] beschrijft enkele momenten waarop je als patiënt zijnde inzicht kan of zou willen hebben in zijn/haar Basisgegevens Langdurige Zorg.

<blockquote>Op aanraden van zijn dochter heeft Kenneth nu ook een PGO, waarop hij kan zien wanneer de wijkverpleegkundige komt of de huishoudelijke hulp. Als het nodig is kan hij via zijn PGO doorgeven dat hij niet mee eet omdat hij bij een van zijn kinderen eet. De vrijwilligers van de bezorgdienst krijgen dit automatisch doorgegeven.</blockquote>

<blockquote>Hij krijgt een EVV-er (eerst verantwoordelijke verpleegkundige) toegewezen, die samen met Kenneth een zorgleefplan gaat opstellen. Zodra het zorgleefplan compleet is, komt dit beschikbaar in zijn PGO. Daarmee kan Kenneth goed zien welke afspraken er met de instelling zijn gemaakt.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case om gaat is:
* Het systeem van een zorgaanbieder (XIS) stelt de Basisgegevens Langdurige Zorg van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van de Basisgegevens Langdurige Zorg tussen het betreffende XIS en het eigen PGO.

De Basisgegevens Langdurige Zorg, of een gedeelte van de Basisgegevens Langdurige Zorg, welke de persoon wil inzien, bestaat en de zorgaanbieder wil deze beschikbaarstellen.
:Soms zijn er valide redenen om de Basisgegevens Langdurige Zorg, of gedeeltes daarvan, tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
:Een patiënt kan steeds zelf het initiatief nemen om de Basisgegevens Langdurige Zorg op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

===== Processtappen =====
* Het systeem van de patiënt (PGO) raadpleegt het systeem van de zorgaanbieder (XIS) voor de Basisgegevens Langdurige Zorg van de patiënt.
* Het systeem van de zorgaanbieder (XIS) maakt (een deel van) de Basisgegevens Langdurige Zorg beschikbaar voor de patiënt.
* De patiënt gebruikt de persoonlijke gezondheidsomgeving om de Basisgegevens Langdurige Zorg in te zien.

===== Postconditie =====
De persoon kan de Basisgegevens Langdurige Zorg inzien via een persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel de persoon als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de Basisgegevens Langdurige Zorg van zorgaanbieder naar de persoon.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeem
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Naam systeemrol
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Systeemrolcode
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| LZRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|BgLZ}}-LZR-FHIR
| style="background-color: white;"| Raadplegen Basisgegevens Langdurige Zorg bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| LZBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|BgLZ}}-LZB-FHIR
| style="background-color: white;"| Beschikbaarstellen Basisgegevens Langdurige Zorg aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:InzienLZ_component.PNG|Componenten diagram]]

<font size = "1">'''Componenten diagram van systemen en systeemrollen'''</font>

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactiegroep'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Transactie'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeemrolcode'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Systeem'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Bedrijfsrol'''
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Basisgegevens Langdurige Zorg (PULL)
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.58.4.2&effectiveDate=2019-04-09T16:33:35&language=*&ui=nl-NL&version=2019-09-04T10:21:41&format=html&hidecolumns=34567 Raadplegen Basisgegevens Langdurige Zorg]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|BgLZ}}-LZR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_BGLZ|Basisgegevens Langdurige Zorg in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/decor/services/RetrieveTransaction?id=2.16.840.1.113883.2.4.3.11.60.58.4.3&effectiveDate=2019-04-09T16:33:35&language=*&ui=nl-NL&version=2019-09-04T10:21:41&format=html&hidecolumns=34567 Beschikbaarstellen Basisgegevens Langdurige Zorg]
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|BgLZ}}-LZB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:InzienLZ_usecase.PNG|Use case diagram raadplegen Basisgegevens Langdurige Zorg]]

<font size = "1">'''Use case diagram raadplegen Basisgegevens Langdurige Zorg</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
|}

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:2019.01_Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving

{{ReleaseNotes|package=2019.01 - April|release=1.0.9|issues=3|MM-1059|MM-1025|MM-939}}
{{ReleaseNotes|package=2019.01 - Maart|release=1.0.7|issues=3|MM-997|MM-953|MM-931}}
|-
| style="background-color: white; | 2019.01 - November
| style="background-color: white; | 1.0.4
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-806 MM-806]
| style="background-color: white;"| Fixed MM-430: adjusted incorrect FHIRPath constraints, moved extension to Consent.extension and moved mappings in extension from extension.value[x].reference to extension.value[x] in zib-TreatmentDirective profile.
|-
| style="background-color: white; | 2019.01 - Oktober
| style="background-color: white; | 1.0.2
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-599 MM-599]
| style="background-color: white;"| URL value on detailCodeableConcept.coding.system in HCIM TreatmentObjective example was incorrect, changed to the correct value.
|-
| style="background-color: white; | 2019.01 - September
| style="background-color: white; | 1.0.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-358 MM-358]
| style="background-color: white;"| Tekstcorrectie op de kwalificatiepagina's van BgZ, GGZ en BgLZ.
|}

MedMij:Vprepub-2020.01/OntwerpLabresult

2020-07-20T15:38:52Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Laboratoriumresultaten {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:Labresultaten_icoon.png |link=|links |87px|MedMij_|Laboratoriumresultaten]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_LaboratoryResults|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft use cases voor de patiënt met relatie tot de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/laboratoria informatiestandaard labuitwisseling] (LAB).

Door IHE / Antilope is ook al werk gedaan voor beschrijving use cases voor uitwisseling van laboratoriumgegevens, deze zijn [https://usecase-repository.ihe-europe.net/use-cases?field_domain_value=LAB&field_scale_value=All&field_source_value=All hier] gepubliceerd. Op het moment van schrijven van deze documentatie heeft IHE twee verschillende use cases beschreven:
* Uitwisseling voor een laboratorium binnen een ziekenhuis: [https://usecase-repository.ihe-europe.net/content/request-and-results-distribution-workflow-laboratory-within-hospital Request and results distribution workflow for laboratory within a hospital]
* Nationale / regionale uitwisseling tussen zorgaanbieders / laboratoria: [https://usecase-repository.ihe-europe.net/content/request-and-results-sharing-workflow-laboratory-nationalregional-scale Request and results sharing workflow for laboratory on a National/regional scale]

Bovenstaande standaarden beschrijven de uitwisseling met de patiënt nog niet expliciet. Het doel van deze pagina is om de verschillende uitwisselingsscenario's van laboratoriumgegevens met de patiënt toe te voegen.

Het is het streven van het MedMij-programma om deze beschrijvingen toe te voegen aan de bestaande informatiestandaard Labuitwisseling.

Zoals [[MedMij:Vprepub/Ontwerpen|op deze pagina]] aangegeven, gebruikt MedMij de BGZ en de bijbehorende zibs als leidraad voor de uitwisseling van informatie. Voor uitwisseling van laboratoriumresultaten gaat het om de volgende zibs:
*Patiënt;
*Zorgaanbieder;
*Zorgverlener;
*OverdrachtLaboratoriumUitslag.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub/Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=

==Use case: Raadplegen laboratoriumresultaten in persoonlijke gezondheidsomgeving==
===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in laboratoriumresultaten die over henzelf gaan.
===Domein===
Laboratoriumgegevens in het domein van zorgaanbieders, laboratoria en patiënten.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van laboratoriumresultaten vanuit zorgaanbieder / laboratorium naar een patiënt. De zorgaanbieder / laboratorium is dus de bron van de gegevens.

Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
====Raadplegen laboratoriumresultaten====
Informatie-elementen in de vraag om laboratoriumresultaten zijn:
*periode (startdatum - einddatum) waarop het laboratoriumresultaat uitgevoerd was.

Dit betreft de filtermogelijkheden (query paramaters) in de vraag om laboratoriumresultaten.

====Beschikbaarstellen laboratoriumresultaat====
De volgende zorginformatiebouwstenen definiëren de informatie-elementen die van toepassing zijn:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*LaboratoriumUitslag v4.1

Informatie elementen in LaboratoriumUitslag staan [https://zibs.nl/wiki/LaboratoriumUitslag-v4.1(2017NL) hier].

Dit betreft de inhoud van ieder laboratoriumresultaat.

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil laboratoriumresultaten raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder / Laboratorium
|style="background-color: white;vertical-align:top;"|Stelt laboratoriumresultaten beschikbaar
|}
<font size = "1">'''Bedrijfsrollen Laboratoriumresultaten'''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity_Diagram_-_LaboratoriumResultaten.jpg|Activiteitendiagram Raadplegen laboratoriumresultaten ]]

<font size = "1">'''Activiteitendiagram Raadplegen laboratoriumresultaten'''</font>

===Procesbeschrijving===
===='Patient journey' - Thomas van Beek ====
Het verhaal van de 'patient journey' van Thomas van Beek vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf hier].

Hieronder een aantal voor Thomas relevante situaties waarbij het raadplegen van laboratoriumresultaten een rol speelt.

<blockquote>Eens per drie maanden heeft Thomas een controle in het ziekenhuis. Hij heeft dan een afspraak met afwisselend de internist of de diabetesverpleegkundige. Thomas moet een half uur voor zijn afspraak al aanwezig zijn in het ziekenhuis om bloed te laten prikken. Een waarde die onder andere bepaald wordt is de HbA1c waarde, hieraan is te zien wat de gemiddelde glucosewaarde over de afgelopen 3 maanden geweest is. De uitslag is binnen een half uur binnen. De zorgverlener vertelt Thomas de laboratoriumresultaten en wat die betekenen tijdens de afspraak. Het ziekenhuis informatiesysteem maakt de laboratoriumresultaten ook beschikbaar voor de persoonlijke gezondheidsomgeving van Thomas. Thomas kan de resultaten dan ook later nog eens nakijken als hij dat wil. Dit geeft hem meer grip op zijn gezondheidssituatie.</blockquote>

<blockquote>In april is het tijd voor de jaarlijkse, uitgebreide controle in het ziekenhuis in verband met diabetes. De controle zélf zal plaatsvinden op 12 april. Thomas moet een week daarvoor, op 5 april, bloed prikken en urine afgeven in het ziekenhuis. De resultaten van de laboratoriumonderzoeken moeten beschikbaar zijn vóór 12 april. Het ziekenhuis informatiesysteem heeft de resultaten beschikbaar gemaakt voor Thomas op 10 april. Thomas wil zich goed op zijn afspraak voorbereiden en raadpleegt op 11 april, via zijn PGO, deze laboratoriumresultaten. Hij krijgt zo vooraf al meer inzicht in zijn situatie. Zijn nierwaarden lijken hem afwijkend. Hij vraagt zich daarom af of de instelling van de medicatie misschien aangepast moet worden. Voor de zekerheid noteert hij deze vraag voor zijn internist. Zo kan hij goed voorbereid naar het ziekenhuis op 12 april.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het uitwisselen van laboratoriumresultaten tussen zorgaanbieder / laboratorium en patiënt.
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van laboratoriumresultaten tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

Er is een laboratoriumresultaat dat de patiënt wil raadplegen en dat de zorgaanbiederzorgaanbieder / laboratorium beschikbaar stelt.
:Soms zijn er valide redenen om bepaalde laboratoriumresultaten tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
:Een patiënt kan steeds zelf het initiatief nemen om laboratoriumresultaten op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

=====Proces stappen=====
*De patiënt vraagt om laboratoriumresultaten bij een zorgaanbieder / laboratorium.
*De zorgaanbieder / laboratorium levert laboratoriumresultaten op voor de patiënt.
*Patiënt ziet de laboratoriumresultaten in.

=====Post conditie=====
De patiënt heeft laboratoriumresultaten gezien.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de laboratoriumresultaten van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| LaboratoriumresultaatRaadplegend
| style="background-color: white;"| LAB-{{VersieInfo|V2019.01|Laboratoriumresultaten}}-LRR-FHIR
| style="background-color: white;"| Raadplegen Laboratoriumresultaat bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| LaboratoriumresultaatBeschikbaarstellend
| style="background-color: white;"| LAB-{{VersieInfo|V2019.01|Laboratoriumresultaten}}-LRB-FHIR
| style="background-color: white;"| Beschikbaarstellen Laboratoriumresultaat aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_LaboratoriumResultaten_(Totaal).jpg|Componenten diagram]]

<font size = "1">'''Componenten diagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Laboratoriumresultaten (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen laboratoriumresultaten
|style="background-color: white;vertical-align:top;"|LAB-{{VersieInfo|V2019.01|Laboratoriumresultaten}}-LRR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_LaboratoryResults|Laboratoriumresultaten in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen laboratoriumresultaten
|style="background-color: white;vertical-align:top;"|LAB-{{VersieInfo|V2019.01|Laboratoriumresultaten}}-LRB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder (laboratorium)
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_Case_Diagram_-_LaboratoriumResultaten.jpg|Use case diagram raadplegen laboratoriumresultaten]]

<font size = "1">'''Use case diagram</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub/Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
| rowspan = 2; style="background-color: white; | 2019.01 - September
| rowspan = 2; style="background-color: white; | 1.1.4
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-436 MM-436]
| style="background-color: white;"| Aanpassen ConceptMap InterpretatieVlaggenCodelijst-to-observation-interpretation.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-422 MM-422]
| style="background-color: white;"| Aanpassen conceptnaam ResultaatVlaggen naar InterpretatieVlaggen in FHIR profiel voor LaboratoryResults.
|-
|rowspan = 9; style="background-color: white;"| 2019.01
|rowspan = 3; style="background-color: white;"| 1.1.3
|style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-294 MM-294]
|style="background-color: white;"| Naam mapping binnen div. FHIR profielen aangepast conform zib: HCIM LaboratoryTestResult-v4.1(2017EN).
|-
|style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-247 MM-247]
|style="background-color: white;"| LastN operation niet nodig binnen use case LaboratoryResults
|-
|style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-205 MM-205]
|style="background-color: white;"| Verwijderen link naar Specimen in het technisch ontwerp van LaboratoryResults.
|-
| style="background-color: white;"| 1.1.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-206 MM-206]
| style="background-color: white;"| Reference vanuit Observation naar Specimen Isolate onjuist.
|-
| rowspan = 5; style="background-color: white;"| 1.1.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-142 MM-142]
| style="background-color: white;"| Onduidelijkheid in de modellering van de Aanvrager van een LaboratoriumUitslag.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-125 MM-125]
| style="background-color: white;"| Inconsistentie wiki vs simplifier.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-112 MM-112]
| style="background-color: white;"| Verwijzing in §2.4.1.2 naar zib OverdrachtLaboratoriumuitslag v1.2.2 (release 2015) gewijzigd in zib Laboratoriumuitslag v4.1 (release 2017). In het technisch ontwerp en FHIR-profielen werd deze al toegepast.
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-108 MM-108]
| style="background-color: white;"| use-case Collect (from XIS to PGO).
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-94 MM-94]
| style="background-color: white;"| Specimen microorganism en specimenSource mappen naar hetzelfde fhir element.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 1.0.1
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-66 MM-66]
| style="background-color: white;"| Update mappings LaboratoriumUitslag in DiagnosticReport en Observation.
|}

MedMij:V2020.01/OntwerpLangdurigeZorg

2020-07-20T15:38:52Z

Update bot: Copy of V2019.01

MedMij:V2020.01/OntwerpLabresult

2020-07-20T15:38:52Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/OntwerpBeelden

2020-07-20T15:38:51Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp Beelden {{VersieInfo|V2019.01|Beelden}}}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:beeldenIcoon.png|link=|87px |links||media]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_Images|Technisch]]
desc none
</imagemap>

=Inleiding=
==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan [[MedMij:Vprepub/Ontwerpen| hier]] gevonden worden.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub/Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Sturen beelden vanuit een PGO==
=== Doel en relevantie ===
*Het voor patiënten/ personen mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.
*Deze use case ondersteunt geen interactie met de patiënt middels het PGO. De zorgverlener kan niet online reageren op de gestuurde beelden. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.

=== Domein ===
Beelden in het domein van zorgaanbieders en patiënten/ personen.

=== Context ===
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een [[#persoonlijke-gezondheidsomgeving|persoonlijke gezondheidsomgeving]] (PGO) naar een zorgaanbiederssysteem (XIS). Deze pagina bevat (verwijzingen naar) beschrijvingen van:
* informatie,
* bedrijfsrollen (actoren),
* proces,
* systemen,
* systeemrollen,
* transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt: de beelden, bijbehorende meta-informatie per beeld en een mogelijk toelichting/ begeleidende tekst.

De informatie-elementen voor sturen en ontvangen van een beeld of collectie beelden staan in [http://decor.nictiz.nl/pub/beelden/bd-html-20190512T171559/tr-2.16.840.1.113883.2.4.3.11.60.54.4.2-2019-02-25T131649.html ART-DECOR Sturen Beelden].

==== Beeldformaat ====
*De ontvangende systemen dienen de volgende gegevensformaten te ondersteunen: JPEG, PNG, GIF en JP2. De PGO bepaalt zelf in welke van deze ondersteunende beeldformaten, de beelden worden verstuurd. De genoemde beeldformaten zijn ook de gegevensformaten, bestaande uit één frame, die door [[#DICOM-beeldformaten|DICOM standaard]] worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden. Beeldformaat DICOM is niet in scope voor deze use case.
*Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de [[#Exif|Exif standaard]]. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.

==== Frequentie sturen beeld(en) ====
*Met het oog op bijvoorbeeld een ''denial of service attack'' is de overweging geweest om de frequentie waarmee de patiënt beelden kan versturen te beperken. Besloten is om voorlopig geen beperkingen op te nemen in de standaard.

==== Grootte van beeld(en) ====
De maximale grootte van een beeld is 20 MB (voordat het Base64 encoded is). Een PGO kan één tot maximaal 3 beelden tegelijk sturen. De maximale grootte van een collectie beelden is 60 MB. Base64 codering maakt het resultaat 37% groter.

==== Toelichting ====
De patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.

==== Meta-informatie ====
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd. De specificatie van de meta-informatie wordt gegeven in de dataset en transactiebeschrijving. Daarnaast kent het FHIR profiel, verwezen vanuit het technisch ontwerp, nog een aantal verplichte concepten.
Deze use case houdt rekening met zelfstandige XIS-sen en met XIS-sen die zijn aangesloten op een XDS-netwerk door het bericht te voorzien van voldoende meta-informatie voor indexatie. Het correct indexeren van beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft een niet-normatieve implemenatierichtlijn middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil beelden sturen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Wil beelden ontvangen
|}
<font size = "1">'''Bedrijfsrollen sturen beelden'''</font>

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Image:Activity_Diagram_-_Sturen_Beelden.png|Activiteitendiagram sturen beelden]]

<font size = "1">'''Activiteitendiagram sturen beelden'''</font>

=== Procesbeschrijving ===
==== Patient Journey – Thomas van Beek ====
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek].
<blockquote>De afgelopen periode heeft Thomas wisselend last van eczeem. De vorige keer dat Thomas een dergelijke aanval had, waren de klachten al afgenomen op het moment dat de afspraak met de huisarts plaatsvond. Om de ernst van de klachten te kunnen inschatten heeft de huisarts gevraagd of Thomas in het vervolg een foto kan maken van de eczeem wanneer deze in alle ernst aanwezig zijn.
Vandaag is het weer zover. Bij het maken van de afspraak met de huisarts verzoekt de assistente of Thomas direct een foto kan maken en deze de huisarts wil toesturen. Thomas maakt foto's van onder andere zijn gezicht en upload deze naar zijn PGO. Een paar dagen na het versturen van de foto heeft hij een afspraak bij de huisarts. De foto's komen tijdens het consult ter sprake en een passende behandeling wordt gekozen.</blockquote>

==== Patient Journey – Kenneth van Someren ====
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patiënt journey van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Kenneth_van_Someren_MedMij.pdf Kenneth van Someren].

<blockquote>De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De wondverpleegkundige ziet de foto en vind het ook zorgelijk. Daarom maak ze direct een afspraak met Kenneth om de plek zelf te beoordelen. De volgende ochtend lukt dat al en die middag komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
* Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO. De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders.
* Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
* Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
** Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
* De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
* De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het PGO.

Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.

===== Preconditie =====
* De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van beelden tussen het eigen PGO en de betreffende XIS.
* De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
* Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
* De beelden bevinden zich in of zijn toegankelijk voor, het PGO

===== Processtappen =====
* Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
* Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.

===== Postconditie =====
* Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS-omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
* De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.

=== Systemen & Systeemrollen ===
Zowel de patiënt als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om beelden van de patiënt naar de zorgaanbieder.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Sturen van Beelden
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|Beelden}}-BES-FHIR
| style="background-color: white;"| Sturen van beelden naar zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Ontvangen van Beelden
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|Beelden}}-BEO-FHIR
| style="background-color: white;"| Ontvangen van beelden vanuit het PGO
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Sturen_Beelden_(Totaal).png|Componenten diagram]]

<font size = "1">'''Componenten diagram van systemen en systeemrollen'''</font>

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een stuur- en ontvangstbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|Beelden (PUSH)
|style="background-color: white;vertical-align:top;"|Sturen Beelden
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|Beelden}}-BES-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_Images |Beelden in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Ontvangen Beelden
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|Beelden}}-BEO-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_Case_Diagram_-_Sturen_Beelden.png|Use case diagram Sturen Beelden]]

<font size = "1">'''Use case diagram sturen beelden</font>

=Functionaliteit=

== Eisen en wensen ==
*'''Afstemming vooraf''': Tijdens de ontwikkeling van de informatiestandaard is er nagedacht over het opnemen van een verplichte checkbox die de patiënt moet aanvinken om aan te geven dat er afstemming is geweest met de zorgverlener. Uiteindelijk is besloten om deze eis niet op te nemen in de standaard omdat in de praktijk patiënt en zorgverlener altijd een context hebben waarin het sturen van de beelden past. Daarnaast is het uitgangspunt om de patiënt zo min mogelijk te laten invullen bij het sturen van een beeld.

== Niet functionele eisen en wensen ==
Het technisch ontwerp bevat een aantal verplichte (technische) data elementen die niet zijn opgenomen in de functionele dataset. Een aantal van deze velden zijn verplicht gesteld om compatibiliteit met XDS-netwerken te ondersteunen. Het gaat om de volgende elementen:

* Indentificatie van het beeld en collectie beelden
* Een hash van de data van het beeld

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| <span id="persoonlijke-gezondheidsomgeving">-</span>
| style="background-color: white;"| Persoonlijke Gezondheidsomgeving
| style="background-color: white;"|
| style="background-color: white;"| 06-12-2018
| style="background-color: white;"| https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/
| style="background-color: white;"| Patiëntenfederatie Nederland
|-
| style="background-color: white;"| <span id="DICOM-beeldformaten">-</span>
| style="background-color: white;"| Rendered Media Types
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3
| style="background-color: white;"| NEMA (DICOM)
|-
| style="background-color: white;"| <span id="Exif">-</span>
| style="background-color: white;"| Exif
| style="background-color: white;"|
| style="background-color: white;"| 10-12-2018
| style="background-color: white;"| https://en.wikipedia.org/wiki/Exif
| style="background-color: white;"| Wikipedia
|}

<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub/Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving

{{ReleaseNotes|package=2019.01 - April|release=1.0.6|issues=2|MM-1032|MM-954}}
{{ReleaseNotes|package=2019.01 - Maart|release=1.0.4|issues=1|MM-1007}}
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"|
|}

MedMij:V2020.01/OntwerpBeelden

2020-07-20T15:38:51Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/OntwerpAllergieIntolerantie

2020-07-20T15:38:50Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp AllergieIntolerantie {{VersieInfo|V2019.01|AllergieIntolerantie}}}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Allergie.png |link=|links |87px|Medicatie Proces]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_AllergyIntolerance|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor het raadplegen van allergie en intolerantie gegevens door een patiënt. De overkoepelende inleiding van de MedMij functionele ontwerpen kan [[MedMij:Vprepub/Ontwerpen| hier]] gevonden worden. Dit functioneel ontwerp is een toevoeging op de informatie standaard [https://www.nictiz.nl/standaardisatie/informatiestandaarden/medicatieveiligheid Medicatieveiligheid]. In [https://informatiestandaarden.nictiz.nl/wiki/mp:V6.12.3_Ontwerp_medicatieproces#Transactie_Condities_opvragen Medicatieproces v6.12.x] wordt beschreven hoe contra-indicaties, allergie en intolerantie gegevens tussen zorgverleners uitgewisseld worden. Dit ontwerp beschrijft hoe de patiënt allergie en intolerantie gegevens in een PGO kan inzien.

Voor uitwisseling van allergie en intolerantie gegevens worden de volgende zibs gebruikt:

* Patiënt;
* Zorgaanbieder;
* Zorgverlener;
* AllergieIntolerantie.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die [[MedMij:Vprepub/Ontwerpen#Doelgroep| hier]] gevonden kan worden.

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

=Use Cases=
==Use case 1: Raadplegen allergie- en intolerantiegegevens in persoonlijke gezondheidsomgeving==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in de geregistreerde allergieën en intoleranties die over henzelf gaan.

=== Domein ===
Allergie en intolerantie gegevens in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de allergie en intolerantiegegevens vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie,
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===

====Raadplegen allergie en intolerantie gegevens====
Er zijn geen specifieke filtermogelijkheden (query paramaters) gedefinieerd voor het raadplegen van allergie en intolerantie gegevens. Bij het raadplegen van allergie en intolerantie gegevens wordt om alle gegevens behorende bij de patiënt gevraagd.

====Beschikbaarstellen AllergieIntolerantiegegevens====
De volgende zorginformatiebouwstenen definiëren de informatie-elementen die van toepassing zijn:
*Patiënt
*Zorgverlener
*Zorgaanbieder
*AllergieIntolerantie

Dit betreft de inhoud van de transactie opleveren van allergie en intolerantiegegevens.

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil zijn AllergieIntolerantie gegevens raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt AllergieIntolerantie gegevens beschikbaar
|}
<font size = "1">'''Bedrijfsrollen AllergieIntolerantie'''</font>

Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Image:Activity_Diagram_-_AllergieIntolerantiegegevens_.jpg|Activiteitendiagram Raadplegen AllergieIntolerantiegegevens]]

<font size = "1">'''Activiteitendiagram Raadplegen AllergieIntolerantiegegevens'''</font>

=== Procesbeschrijving ===
==== Patient journey - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier].

Hieronder een voor Roos relevante situaties waarbij het raadplegen van een haar allergie en intolerantie gegevens een rol speelt.

<blockquote>Doordat Roos de huisarts toestemming heeft gegeven om haar gegevens te delen kan informatie worden uitgewisseld. Als er bijvoorbeeld iets in de medicatie wordt gewijzigd, dan ziet Roos dit in haar persoonlijke
gezondheidsomgeving terug. Maar ook oudere opgeslagen informatie kan roos raadplegen en opslaan in het PGO, zoals bijvoorbeeld haar bloeduitslagen en bekende allergieën.</blockquote>

<blockquote>Aangezien Roos alles netjes heeft bijgehouden in haar persoonlijke gezondheidsomgeving kan zij het ziekenhuis haar medicatiegegevens laten zien en laten uploaden naar het ziekenhuisinformatiesysteem. Hierdoor heeft de internist een snel en accuraat overzicht van de huidige medicatie van Roos. Ook heeft de internist inzicht in de hoeveelheid insuline die ze extra heeft gespoten toen haar bloedsuikers te hoog waren de afgelopen week. Roos autoriseert het ziekenhuis ook om haar laboratoriumwaarden in te zien, zo kunnen ze zien welke bloedwaarden ze de afgelopen tijd had. De internist merkt op dat Roos lichte verhoging heeft, en na onderzoek concludeert hij dat ze een blaasontsteking heeft. De internist ziet in het medicatieoverzicht van Roos' PGO dat zij allergisch is voor de antibiotica die meestal bij blaasontstekingen wordt gebruikt, waarna hij een ander middel voorschrijft. Doordat Roos eerder haar allergie- en intolerantiegegevens bij de huisarts heeft geraadpleegd was de internist op de hoogte van haar antibiotica allergie.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Het systeem van een zorgaanbieder (XIS) stelt AllergieIntolerantie gegevens van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van de AllergieIntolerantie gegevens tussen het betreffende XIS en het eigen PGO.

De AllergieIntolerantie gegevens welke de persoon wil inzien en dat de zorgaanbieder beschikbaar wil stellen.
:Een patiënt kan steeds zelf het initiatief nemen om de AllergieIntolerantie gegevens op te halen, maar het is ook mogelijk dat het PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

===== Proces stappen =====
* Het systeem van de persoon (PGO) raadpleegt de beschikbare AllergieIntolerantie gegevens .
* Het systeem van de zorgaanbieder (XIS) maakt de AllergieIntolerantie gegevens beschikbaar voor de persoon.
* De persoon gebruikt het PGO om zijn AllergieIntolerantie gegevens in te zien.

===== Post conditie =====
De persoon kan zijn AllergieIntolerantie gegevens inzien via het PGO.

=== Systemen & Systeemrollen ===
Zowel de persoon als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de allergie- en intolerantiegegevens van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| AllergyIntolerantiegegevensRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|AllergieIntolerantie1}}-AIR-FHIR
| style="background-color: white;"| Raadplegen allergie- en intolerantiegegevens bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| AllergyIntolerantiegegevensBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|AllergieIntolerantie1}}-AIB-FHIR
| style="background-color: white;"| Beschikbaarstellen allergie- en intolerantiegegevens aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_AllergieIntolerantiegegevens_(Totaal).jpg|Componenten diagram]]

<font size = "1">'''Componenten diagram van systemen en systeemrollen'''</font>

=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|AllergieIntolerantie gegevens (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen AllergieIntolerantie gegevens
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|AllergieIntolerantie1}}-AIR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_AllergyIntolerance|AllergieIntolerantie in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen AllergieIntolerantie gegevens
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|AllergieIntolerantie1}}-AIB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_Case_Diagram_-_AllergieIntolerantiegegevens_.jpg|Use case diagram inzien AllergieIntolerantiegegevens]]

<font size = "1">'''Use case diagram inzien AllergieIntolerantiegegevens</font>

==Use case 2: Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling door patiënt==
Dit is een alternatief voor use case 1 die zich beperkt tot het ontsluiten van medicatiegerelateerde allergie- en intolerantiegegevens die afkomstig zijn uit de [https://www.nictiz.nl/standaardisatie/informatiestandaarden/medicatieveiligheid/ informatiestandaard Medicatieproces 6.12].

===Doel en relevantie===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medicatiegerelateerde allergie- en intolerantiegegevens die over henzelf gaan. De medicatiegerelateerde allergie- en intolerantiegegevens van ICA (Intolerantie, Contra-indicaties en Allergieën) versie 6.12 betreffen een [http://decor.nictiz.nl/medicatieproces/mp-html-20181220T121121/tmp-2.16.840.1.113883.2.4.3.11.60.20.77.10.12-2013-08-19T000000.html HL7v3-messaging standaard]. Deze use case gaat uit van conversie van deze HL7v3-gegevens naar FHIR-resources.

===Domein===
Medicatiegerelateerde allergie- en intolerantiegegevens.

===Context===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van medicatiegerelateerde allergie- en intolerantiegegevens vanuit een zorgaanbiederssysteem (XIS) - met behulp van een vertaling naar FHIR - naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO): we noemen dit medicatiegerelateerde allergie- en intolerantiegegevensvertaling.
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.

===Informatie===
De informatie-elementen die van toepassing zijn, zijn gedefinieerd in ICA 6.12 en [[Mappingarchitectuur#Contraindicaties_en_overgevoeligheden_.28CIO.29|de bijbehorende vertaling]] naar het CIO-datamodel (Contra-indicaties en overgevoeligheden). De medicatiegerelateerde allergie- en intolerantiegegevens in ICA-6.12 zijn vertaald naar het CIO-datamodel voor het onderdeel AllergieIntolerantie. Eventuele negatieve (ontkennende) overgevoeligheden maken hier géén onderdeel van uit. Deze mogen ook officieel niet uitgewisseld worden volgens 6.12, maar als dit tóch gebeurt, worden deze uitgefilterd via de mapping.

====Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling====
Er zijn géén specifieke filtermogelijkheden (query parameters) gedefinieerd voor het raadplegen van medicatiegerelateerde allergie- en intolerantiegegevensvertaling. Bij het raadplegen van medicatiegerelateerde allergie- en intolerantiegegevensvertaling wordt om alle gegevens behorende bij de patiënt gevraagd.

====Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling====
Informatie elementen in medicatiegerelateerde allergie- en intolerantiegegevensvertaling staan hieronder. Deze informatie is ook in een [https://decor.nictiz.nl/pub/cio/cio-html-20200226T140246/tr-2.16.840.1.113883.2.4.3.11.60.26.4.6-2019-08-28T133341.html nieuw tabblad] te openen.

Dit betreft de inhoud van de transactie met medicatiegerelateerde allergie- en intolerantiegegevensvertaling.
Uitgangspunt voor de transactie zijn de concepten en kardinaliteiten van de zibs AllergieIntolerantie en de bijbehorende Patiënt, Zorgverlener, Zorgaanbieder, Contactpersoon. Afwijkingen hiervan zijn gedocumenteerd in [https://bits.nictiz.nl/browse/CIO-5 CIO-5].

<html>
<iframe width="100%" height="450" src=https://decor.nictiz.nl/pub/cio/cio-html-20200226T140246/tr-2.16.840.1.113883.2.4.3.11.60.26.4.6-2019-08-28T133341.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Deze use case kent twee bedrijfsrollen.

{| class="wikitable" "cellpadding="10" width="50%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:top;"|Wil medicatiegerelateerde allergie- en intolerantiegegevensvertaling raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|style="background-color: white;vertical-align:top;"|Stelt medicatiegerelateerde allergie- en intolerantiegegevensvertaling beschikbaar
|}
<font size = "1">'''Bedrijfsrollen medicatiegerelateerde allergie- en intolerantiegegevensvertaling '''</font>

Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.

[[Bestand:Activity_diagram_Raadplegen_medicatiegerelateerde_allergie-_en_intolerantiegegevensvertaling.png|Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]

<font size = "1">'''Activiteitendiagram Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling'''</font>

===Procesbeschrijving===
===='Patient journey' - Roos Dalstra ====
Het verhaal van de 'patient journey' van Roos Dalstra vindt u [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Roos_Dalstra_MedMij.pdf hier].

Hieronder een voor Roos relevante situatie waarbij het raadplegen van een medicatiegerelateerde allergie- en intolerantiegegevensvertaling een rol speelt.

<blockquote>De internist merkt op dat Roos lichte verhoging heeft, en na onderzoek concludeert hij dat ze een blaasontsteking heeft. Roos toont de internist het medicatieoverzicht in het PGO en hij ziet dat zij allergisch is voor de antibiotica die meestal bij blaasontstekingen wordt gebruikt, waarna hij een ander middel voorschrijft. Doordat Roos eerder haar medicatiegerelateerde allergie- en intolerantiegegevens bij de apotheek heeft geraadpleegd was de internist op de hoogte van haar antibiotica allergie.</blockquote>

====Proces====
Het stuk van het proces waar het in deze use case om gaat is:
*Het systeem van een zorgaanbieder (XIS) stelt medicatiegerelateerde allergie- en intolerantiegegevensvertaling beschikbaar aan het systeem van een patiënt (PGO).
*Een PGO heeft de mogelijkheid om deze medicatiegerelateerde allergie- en intolerantiegegevens op te vragen en dit te presenteren.
Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.
=====Preconditie=====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van allergie- en intolerantiegegevensvertaling tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.

De patiënt wil allergie- en intolerantiegegevensvertaling inzien en de zorgaanbieder stelt dit ook beschikbaar.
:Een patiënt kan steeds zelf het initiatief nemen om een gegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.

=====Proces stappen=====
*Het systeem van de patiënt (PGO) vraagt om beschikbare medicatiegerelateerde allergie- en intolerantiegegevensvertaling bij een XIS.
*Het systeem van de zorgaanbieder (XIS) levert medicatiegerelateerde allergie- en intolerantiegegevensvertaling op voor de patiënt.
*Patiënt gebruikt de persoonlijke gezondheidsomgeving om medicatiegerelateerde allergie- en intolerantiegegevensvertaling in te zien.

=====Post conditie=====
De patiënt kan medicatiegerelateerde allergie- en intolerantiegegevensvertaling inzien via de persoonlijke gezondheidsomgeving.

=== Systemen & Systeemrollen ===
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de medicatiegerelateerde allergie- en intolerantiegegevensvertaling van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| Medicatiegerelateerde allergie- en intolerantiegegevensvertaling
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|AllergieIntolerantieVertaling}}-AIR-FHIR
| style="background-color: white;"| Raadplegen medicatiegerelateerde allergie- en intolerantiegegevens bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| Medicatiegerelateerde allergie- en intolerantiegegevensvertaling
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|AllergieIntolerantieVertaling}}-AIB-FHIR
| style="background-color: white;"| Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevens aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:Component_Diagram_-_Medicatiegerelateerde allergie- en intolerantiegegevensvertaling.png|Componenten diagram]]

<font size = "1">'''Componenten diagram'''</font>

De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.

=== Transacties, Transactiegroepen en systeemrollen===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Link naar technische specificatie'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Medicatiegerelateerde allergie- en intolerantiegegevensvertaling (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|AllergieIntolerantieVertaling}}-AIR-FHIR
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_AllergyIntolerance#Use_case:_Retrieve_AllergyIntolerance612ToFHIRConversion|Medicatiegerelateerde allergie- en intolerantiegegevensvertaling in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling
|style="background-color: white;vertical-align:top;"|MM-{{VersieInfo|V2019.01|AllergieIntolerantieVertaling}}-AIB-FHIR
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:Use_case_diagram_raadplegen_Medicatiegerelateerde_allergie-_en_intolerantiegegevensvertaling.png|Use case diagram raadplegen Medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]

<font size = "1">'''Use case diagram</font>

=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| AUTEUR(S)
| style="background-color: white;"| TITEL
| style="background-color: white;"| VERSIE
| style="background-color: white;"| DATUM
| style="background-color: white;"| BRON
| style="background-color: white;"| ORGANISATIE
|}
<font size = "1">'''Referenties</font>

=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub/Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
{{ReleaseNotes|release=2.0.4|package=2019.01 - Maart 2020|packageIssues=1|issues=1|MM-926}}
|-
| rowspan = 1; style="background-color: white;"| 2019.01 - Januari 2020
| rowspan = 1; style="background-color: white;"| 2.0.3
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-492 MM-492]
| style="background-color: white;"| Added comment to AllergyIntolerance.comment in the HCIM Allergyintolerance FHIR profile to explain the mapping for ValueSet AllergieStatusCodelijst to AllergyIntolerance.clinicalStatus and AllergyIntolerance.verificationStatus. Added dataAbsentReason extension to AllergyIntolerance.verificationStatus.
|-
| rowspan = 2; style="background-color: white;"| 2019.01 - November
| rowspan = 2; style="background-color: white;"| 2.0.2
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-610 MM-610]
| style="background-color: white;"|
Added missing profiles for practitionerrole, organization and related-person. Removed the word 'medication' in favor of 'allergy intolerance'. In the [[MedMij:Vprepub/FHIR_AllergyIntolerance|technical specification]].
|-
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-498 MM-498]
| style="background-color: white;"| Added conceptmap for AllergyIntolerance.category to aid in mapping from HCIM AllergyIntolerance value set AllergieCategorieCodelijst to FHIR STU3 AllergyIntoleranceCategory.
|-
| style="background-color: white;"| 2019.01
| style="background-color: white;"| 2.0.0
| style="background-color: white;"| -
| style="background-color: white;"|
Use case toegevoegd: Raadplegen/beschikbaarstellen medicatiegerelateerde allergieIntolerantieVertaling.
|-
| style="background-color: white;"| 2018.06
| style="background-color: white;"| 1.0.0
| style="background-color: white;"| [https://bits.nictiz.nl/browse/MM-52 MM-52]
| style="background-color: white;"| AllergyIntolerantie filter op medicatieproces conditie geldigheidstermijn niet nodig
|}

MedMij:Vprepub-2020.01/OntwerpBGZ 2017

2020-07-20T15:38:50Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Functioneel Ontwerp BgZ {{VersieInfo|V2019.01|BgZ}} (op basis van zibs release 2017)}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:BGZ_icoon.png |link=|links |87px|Use case BgZ|Patient Summary (BgZ)]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_BGZ_2017|Technisch]]
desc none
</imagemap>

=Inleiding=

==Algemeen==
Deze pagina beschrijft het functioneel ontwerp voor de Basisgegevensset Zorg binnen MedMij.

De [https://www.registratieaandebron.nl/wat-is-registreren-aan-de-bron/de-kern-van-registreren-aan-de-bron/basisgegevensset/ Basisgegevensset Zorg], ofwel BgZ, is de minimale set van patiëntgegevens die specialisme, ziektebeeld en beroepsgroep overstijgend relevant is en die van belang is voor de continuïteit van zorg en is in Nederland door [https://www.registratieaandebron.nl 'Registratie aan de Bron'] gedefinieerd. Deze set aan patiëntgegevens wordt door alle zorgverleners hetzelfde vastgelegd. Hierdoor wordt uitwisseling van deze gegevens mogelijk gemaakt. De BgZ is gespiegeld aan de Europese Patient Summary.

De bekende use cases voor het uitwisselen van de BgZ zijn gericht op uitwisseling tussen zorgverleners voor spoedeisende hulp of ongeplande zorg. Tot op heden is uitwisseling vanuit het perspectief van de patiënt niet beschreven. Het doel van deze pagina is om de uitwisseling van de BgZ met de patiënt toe te voegen.

==Doelgroep==
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de [[MedMij:Vprepub/Ontwerpen#Doelgroep| MedMij functionele ontwerpen]].

==Kaders en uitgangspunten==
===Richtlijn===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Richtlijn| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Infrastructuur===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Infrastructuur| de algemene inleiding]] van de MedMij functionele ontwerpen.

===Geografische reikwijdte===
Geen nadere specificatie, anders dan genoemd in [[MedMij:Vprepub/Ontwerpen#Geografische_reikwijdte| de algemene inleiding]] van de MedMij functionele ontwerpen.

==Kwalificatie==
===Introductie===
{{#lst:MedMij:Vprepub/Kwalificatie|medmij_kwalificatie_introductie}}

===Specifieke informatie over deze kwalificatie===
Specifieke informatie over de kwalificatie van de transacties 'Raadplegen BgZ' en 'Beschikbaarstellen BgZ' is te vinden in [[MedMij:Vprepub/ToelichtingKwalificatieBgZ|Toelichting Kwalificatie BgZ]].

=Use Cases=
==Use case 1: Raadplegen Basisgegevensset Zorg in persoonlijke gezondheidsomgeving==
=== Doel en relevantie ===
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in gegevens uit de Basisgegevensset Zorg (BgZ) die over henzelf gaan.

=== Domein ===
Basisgegevensset Zorg in het domein van zorgaanbieders en patiënten.

=== Context ===
Het gaat om het elektronisch en gestructureerd beschikbaar maken van de BgZ vanuit een zorgaanbiederssysteem (XIS) naar een [https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ persoonlijke gezondheidsomgeving] (PGO).
Deze pagina bevat (verwijzingen naar) beschrijvingen van:
*informatie,
*bedrijfsrollen (actoren),
*proces,
*systemen,
*systeemrollen,
*transactiegroepen en transacties, inclusief de inhoud van deze transacties.

De beschrijving is infrastructuur-onafhankelijk.

=== Informatie ===
De [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ op basis van zibs release 2017] bestaat uit een selectie van 28 [https://zibs.nl/wiki/ZIB_Publicatie_2017(NL) zibs]. Deze zibs vormen samen een verzameling van patiëntgegevens die minimaal nodig is om patiënten continuïteit van zorg te kunnen bieden.

Deze use case gebruikt de structuur van 18 secties die is aangebracht in BgZ 2017. Hierin zijn de onderdelen gegroepeerd waaruit de BgZ is opgebouwd. Deze secties komen sterk overeen met de secties van [https://www.nictiz.nl/wp-content/uploads/2012/09/Alles-wat-je-wilt-weten-over-CCR-CCD-v1-0.pdf CCR/CCD] en maken het o.a. mogelijk om in de technische implementatie (bv FHIR) structuur aan te brengen. In de [[MedMij:Vprepub/FHIR_IG | MedMij FHIR implementatie gids]] staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit [[MedMij:Vprepub/FHIR_BGZ_2017#List_of_StructureDefinitions | overzicht]] is te zien welk FHIR profiel bij welke zib hoort.

Voor het gebruik van codestelsel geldt de [[MedMij:Vprepub/Ontwerpen#Richtlijn|algemene richtlijn]].

====Raadplegen BgZ====
Er zijn geen specifieke filtermogelijkheden (query parameters) gedefinieerd voor de BgZ. Bij het raadplegen van de BgZ wordt om alle gegevens behorende bij de patiënt gevraagd.

====Beschikbaarstellen BgZ====
Informatie-elementen in de BgZ staan hieronder. Deze informatie is ook in een [https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20190313T152910/tr-2.16.840.1.113883.2.4.3.11.60.42.4.37-2018-08-30T093049.html nieuw tabblad] te openen. Bij het beschikbaarstellen van de BgZ worden alle beschikbare gegevens behorende bij de patiënt beschikbaargesteld.

<html>
<iframe width="100%" height="800" src=https://decor.nictiz.nl/pub/bgz2017/bgz2017-html-20190313T152910/tr-2.16.840.1.113883.2.4.3.11.60.42.4.37-2018-08-30T093049.html frameborder="0" align="middle"></iframe>
</html>

=== Bedrijfsrollen ===
Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel.

{| class="wikitable" "cellpadding="10" width="100%"
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Activiteit'''
|-
|style="background-color: white;vertical-align:top;"|Patiënt (PGO)
|style="background-color: white;vertical-align:top;"|Wil de eigen BgZ raadplegen
|-
|style="background-color: white;vertical-align:top;"|Zorgaanbieder (XIS)
|style="background-color: white;vertical-align:top;"|Stelt de BgZ beschikbaar
|}


Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.

[[Bestand:InzienBGZ activity.PNG|Activiteitendiagram Raadplegen BgZ]]


=== Procesbeschrijving ===
==== Patient journey - Thomas van Beek ====
De 'patient journey' van [https://www.nictiz.nl/wp-content/uploads/2018/05/Casus_Thomas_van_Beek_MedMij.pdf Thomas van Beek] beschrijft enkele momenten waarop je als patiënt zijnde inzicht kan of zou willen hebben in zijn/haar BgZ.

<blockquote>Voor zijn afstuderen verhuist Thomas 9 maanden naar Groningen. Hij gaat daar bij een heel leuk bedrijf stagelopen. Om het voor hem makkelijk te maken en omdat hij een arts dicht in de buurt wil hebben, schrijft hij zich in bij het ziekenhuis in Groningen. Hiervoor moet het ziekenhuis in Amsterdam alle gegevens van Thomas overdragen aan het ziekenhuis in Groningen. Zo weet de nieuwe arts van Thomas precies wat het verloop van de diabetes is. Thomas is zelf eigenlijk wel nieuwsgierig naar zijn medische gegevens die verstuurd worden. In zijn PGO vindt hij de belangrijkste gegevens die over hem bekend zijn.</blockquote>

==== Proces ====
Het stuk van het proces waar het in deze use case omgaat is:
* Het systeem van een zorgaanbieder (XIS) stelt de BgZ van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.

===== Preconditie =====
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van de BgZ tussen het betreffende XIS en het eigen PGO.

De BgZ, of een gedeelte van de BgZ, welke de persoon wil inzien, bestaat en de zorgaanbieder (XIS) wil deze beschikbaarstellen.
:Soms zijn er valide redenen om de BgZ, of gedeeltes daarvan, tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
:Een patiënt kan steeds zelf het initiatief nemen om de BgZ op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.

===== Proces stappen =====
{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Stap
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| 01
| style="background-color: white;"| Het systeem van de patiënt (PGO) raadpleegt het systeem van de zorgaanbieder (XIS) voor de BgZ van de patiënt.
|-
| style="background-color: white;"| 02
| style="background-color: white;"| Het systeem van de zorgaanbieder (XIS) maakt (een deel van) de BgZ beschikbaar voor de patiënt.
|-
| style="background-color: white;"| 03
| style="background-color: white;"| De patiënt gebruikt de persoonlijke gezondheidsomgeving (PGO) om de BgZ in te zien.
|}

===== Post conditie =====
De persoon kan de Basisgegevensset Zorg inzien via een persoonlijke gezondheidsomgeving (PGO).

=== Systemen & Systeemrollen ===
Zowel patiënt als zorgaanbieder maken ieder gebruik van een informatiesysteem:
* PGO (patiënt)
* XIS (zorgaanbieder)

Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om de BgZ van zorgaanbieder naar de patiënt.

{| class="wikitable" "cellpadding="10"
!style="text-align:left;"|Systeem
!style="text-align:left;"|Naam systeemrol
!style="text-align:left;"|Systeemrolcode
!style="text-align:left;"|Omschrijving
|-
| style="background-color: white;"| PGO
| style="background-color: white;"| BGZRaadplegend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|BgZ}}-BZR-FHIR
| style="background-color: white;"| Raadplegen BgZ bij zorgaanbieder
|-
| style="background-color: white;"| XIS
| style="background-color: white;"| BGZBeschikbaarstellend
| style="background-color: white;"| MM-{{VersieInfo|V2019.01|BgZ}}-BZB-FHIR
| style="background-color: white;"| Beschikbaarstellen BgZ aan de patiënt
|-
|}

Zie ook onderstaande afbeelding.

[[Bestand:InzienBGZ_componenten.PNG|Componenten diagram]]


=== Transacties & Transactiegroepen ===
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transactiegroep'''
! style="text-align:left;"| '''Transactie'''
! style="text-align:left;"| '''Systeemrolcode'''
! style="text-align:left;"| '''Systeem'''
! style="text-align:left;"| '''Bedrijfsrol'''
! style="text-align:left;"| '''Technisch'''
|-
|style="background-color: white;vertical-align:middle;" rowspan="2"|BgZ (PULL)
|style="background-color: white;vertical-align:top;"|Raadplegen BgZ
|style="background-color: white;vertical-align:top;"|[[MedMij:Register_van_informatiestandaarden#Register_van_Informatiestandaarden|MM-{{VersieInfo|V2019.01|BgZ}}-BZR-FHIR]]
|style="background-color: white;vertical-align:top;"|PGO
|style="background-color: white;vertical-align:top;"|Patiënt
|style="background-color: white;vertical-align:middle;" rowspan="2"|[[MedMij:Vprepub/FHIR_BGZ_2017|BgZ in FHIR]]
|-
|style="background-color: white;vertical-align:top;"|Beschikbaarstellen BgZ
|style="background-color: white;vertical-align:top;"|[[MedMij:Register_van_informatiestandaarden#Register_van_Informatiestandaarden|MM-{{VersieInfo|V2019.01|BgZ}}-BZB-FHIR]]
|style="background-color: white;vertical-align:top;"|XIS
|style="background-color: white;vertical-align:top;"|Zorgaanbieder
|}

===Use case diagram===
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

[[Bestand:InzienBGZ_useCase.PNG|Use case diagram inzien BgZ]]


=Functionaliteit=
Er zijn geen aanwijzingen/eisen voor functionaliteit van de systemen.

=Verantwoordelijkheid voor informatie=
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.

=Afschermen van gegevens=
Er zijn geen afspraken over het afschermen van gegevens.

=Infrastructuur=
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.

=Referenties=

{| class="wikitable" "cellpadding="10" width="100%"
!style="text-align:left;"|Auteur(s)
!style="text-align:left;"|Titel
!style="text-align:left;"|Versie
!style="text-align:left;"|Datum
!style="text-align:left;"|Bron
!style="text-align:left;"|Organisatie
|-
| style="background-color: white;"| -
| style="background-color: white;"| Basisgegevensset Zorg
| style="background-color: white;"| -
| style="background-color: white;"| 12-08-2019
| style="background-color: white;"| [https://www.registratieaandebron.nl/alles-over-de-bgz/de-basisgegevensset-zorg Alles over de BgZ]
| style="background-color: white;"| Registratie aan de bron (RadB)
|-
| style="background-color: white;"| -
| style="background-color: white;"| BgZ - specificatie gebaseerd op zibs release 2017
| style="background-color: white;"| 1.1
| style="background-color: white;"| 19-04-2018
| style="background-color: white;"| [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf BgZ - specificatie gebaseerd op zibs release 2017]
| style="background-color: white;"| Registratie aan de bron (RadB)
|-
| style="background-color: white;"| Albert-Jan Spruyt & Jan A. Hazelzet
| style="background-color: white;"| Alles wat je wilt (moet) weten over CCR/CCD
| style="background-color: white;"| 1.0
| style="background-color: white;"| 13-09-2012
| style="background-color: white;"| [https://www.nictiz.nl/wp-content/uploads/2012/09/Alles-wat-je-wilt-weten-over-CCR-CCD-v1-0.pdf Alles wat je wilt (moet) weten over CCR/CCD]
| style="background-color: white;"| Nictiz
|}


=Release notes=

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de [[MedMij:Vprepub/Ontwerpen#Release_Notes|Ontwerpen landingspagina]] voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

{| class="wikitable" "cellpadding="10" style="background-color: white;"
!style="text-align:left;"|Release
!style="text-align:left;"|Versie
!style="text-align:left;"|BITS issue
!style="width:850px; text-align:left;"|Omschrijving
|-
{{ReleaseNotes|package=2019.01 - Mei 2020|release=2.1.14|issues=1|MM-1094}}
{{ReleaseNotes|package=2019.01 - April 2020|release=2.1.13|issues=3|MM-1025|MM-1003|MM-939}}
{{ReleaseNotes|package=2019.01 - Maart 2020|release=2.1.10|issues=4|MM-997|MM-953|MM-926|MM-657}}
{{ReleaseNotes|package=2019.01 - Februari 2020|release=2.1.9|issues=5|MM-901|MM-900|MM-852|MM-440|MM-414}}
{{ReleaseNotes|package=2019.01 - Januari 2020|release=2.1.8|issues=2|MM-492|MM-467}}
{{ReleaseNotes|package=2019.01 - November|packageIssues=3|release=2.1.7|MM-806}}
{{ReleaseNotes|release=2.1.6|issues=2|MM-729|MM-430}}
{{ReleaseNotes|package=2019.01 - Oktober|release=2.1.5|issues=2|MM-597|MM-594}}
{{ReleaseNotes|package=2019.01 - September|release=2.1.4|issues=5|MM-436|MM-425|MM-422|MM-359|MM-358}}
{{ReleaseNotes|package=2019.01|packageIssues=28|release=2.1.3|issues=6|MM-348|MM-346|MM-307|MM-294|MM-258|MM-248}}
{{ReleaseNotes|release=2.1.2|MM-219}}
{{ReleaseNotes|release=2.1.1|issues=2|MM-210|MM-206}}
{{ReleaseNotes|release=2.1.0|issues=19|MM-174|MM-161|MM-145|MM-144|MM-143|MM-142|MM-141|MM-134|MM-127|MM-125|MM-118|MM-115|MM-100|MM-99|MM-98|MM-94|MM-50|MM-42|MM-41}}
{{ReleaseNotes|package=2018.06|release=2.0.1|issues=6|MM-174|MM-128|MM-66|MM-55|MM-54|MM-23}}
|}

MedMij:V2020.01/OntwerpBGZ 2017

2020-07-20T15:38:50Z

Update bot: Copy of V2019.01

MedMij:V2020.01/OntwerpAllergieIntolerantie

2020-07-20T15:38:50Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/Kwalificatiemateriaal voor MedMij

2020-07-20T15:38:49Z

Update bot: Copy of V2019.01

#DOORVERWIJZING [[MedMij:Vprepub/Kwalificatie]]

MedMij:Vprepub-2020.01/Kwalificatie aansluiten

2020-07-20T15:38:49Z

Update bot: Copy of V2019.01

{{MedMij:Vprepub/Issuebox}}

===Doelgroep===
Doel van dit document is om een korte inleiding te geven aan leveranciers die willen starten met testen van een FHIR-zorgtoepassing.

Voor de uitwisseling van medische informatie maken zorgaanbieders gebruik van zorginformatiesystemen. Deze zogenaamde XIS-applicaties maken gebruik van informatiestandaarden zoals door MedMij worden ontwikkeld. MedMij biedt leveranciers de mogelijkheid hun producten en diensten te laten testen op correcte implementatie van informatiestandaarden.

===Aanmelden voor testen===
In de informatiestandaarden staat per zorgtoepassing beschreven met welke berichtstructuur en volgens welke eisen informatie wordt uitgewisseld.

U meldt zich aan voor testen door een e-mail te sturen naar [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

Zodra we uw aanmelding hebben ontvangen neemt de kwalificatie-coördinator contact met u op om afspraken te maken over het verloop van het testtraject.

NB: deze testen staan los van een formele kwalificatie. De scope tijdens testen is beperkter omdat er minder testen worden doorlopen dan tijdens een formele kwalificatie.

===Hoe verloopt het testproces?===

Tijdens testen worden een aantal fases doorlopen die hieronder zijn opgesomd.

Het traject verloopt als volgt:
* Leverancier meldt zich aan voor kwalificatie(s) (zie hierboven.
* Kwalificatiecentrum vraagt de leverancier om informatie om het testen te kunnen opzetten
* MedMij verstrekt inhoudelijke scripts die door de softwareleverancier doorlopen kunnen worden.
* MedMij verstrekt de gegevens om de applicatie aan te sluiten op de simulator (zie [[MedMij:Vprepub/Kwalificatie_aansluiten#Opzetten_connectiviteit|Opzetten connectiviteit]]).
* Leverancier meldt eigen organisatie en testsysteem aan bij de simulator.
* Kwalificatiecentrum biedt op verzoek hulp bij het koppelen van de applicatie naar de simulator
* Connectiviteit met de simulator wordt door de softwareleverancier en MedMij getest.
* Leverancier test zelfstandig op basis van scripts op de simulator en geeft aan klaar te zijn via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Indien van toepassing kan de leverancier extra materialen zoals screenshots insturen via email.
* Kwalificatiecentrum biedt op verzoek hulp bij het testen van de scripts.

====Testopzet DVP====
Bij testen waar de DVP het testobject is ziet de testopstelling er als volgt uit:

[[Bestand:Touchstone_DVP.png|link= |750px|Touchstone_DVP]]

De opzet is hier als volgt:
* De PGO/DVP is het testobject van de leverancier.
* Touchstone staat in het midden en stelt testen/testscripts, logging, validatie en overzicht beschikbaar.
* Daarachter staat een (WildFHIR) FHIR-server met de MedMij profielen en juiste testberichten, passend bij de testscripts.

====Testopzet DVZA====
Bij testen waar de DVZA het testobject is ziet de testopstelling er als volgt uit:

[[Bestand:Touchstone_DVZA.png|link= |550px|Touchstone_DVZA]]

De opzet is hier als volgt:
* Touchstone stelt testen/testscripts, logging, validatie en overzicht beschikbaar. Daarnaast is Touchstone ook een FHIR-client die interacties kan versturen volgens de testscripts.
* De DVZA is het testobject van de leverancier, in het algemeen een FHIR-server.

===Configureren simulator===
====Simulator====
MedMij organiseert testen zoveel mogelijk remote en via internet met behulp van een kwalificatiesimulator. MedMij gebruikt voor FHIR-testen de Touchstone simulator, zie https://touchstone.com

Het voordeel van het gebruik van deze tool is dat:
* Testen online kunnen gebeuren;
* Testen kunnen plaatsvinden op het moment dat het de softwareleverancier zelf uitkomt;
* Testen laagdrempelig is de focus ligt op de payload en infrastructurele zaken buiten scope van de test zijn;
* Meerdere testen tegelijkertijd kunnen plaatsvinden;
* De respons voorspelbaar is;
* De leverancier zelf inzicht heeft in de verstuurde berichten/documenten en validatieresultaten;
* De leverancier de mogelijkheid heeft om zichzelf te bevragen, of berichten naar zichzelf te sturen.

De simulator biedt tijdens de ontwikkeling de mogelijkheid om vooraf gedefinieerde inhoud terug te geven (zoals beschreven in de scripts). Hiermee kan de leverancier kijken of hij de data goed ontvangt en toont. Merk op dat hier vaak vaste inhoud teruggestuurd wordt. Ook kan de simulator het systeem bevragen in geval dat het systeem een bronsysteem is.

De simulator verzamelt informatie die van en naar een leverancier worden gecommuniceerd in een berichtenlog. Het is voor de leverancier mogelijk om zelf de berichtenlog in te zien, inclusief validatieresultaten.

Algemene opmerkingen over het gebruik van de simulator:
* de simulator is niet bedoeld voor loadtesten, maar voor inhoudelijke controles tegen informatiestandaarden;
* MedMij vraagt verantwoord gebruik van deze simulator, neem bij twijfel over gebruik contact op.

====Opzetten connectiviteit====
We vragen leveranciers om de onderstaande stappen uit te voeren.

Let op: we maken gebruiker van de TouchStone simulator. Hierbij is het nodig voor een leverancier om een eigen account aan te maken. TouchStone biedt hiervoor verschillende subscripties/licenties aan, zie https://touchstone.aegis.net/touchstone/subscription

De Open subscriptie biedt genoeg mogelijkheden om te kunnen testen en kwalificeren maar heeft de volgende restricties:
* Er kan maar 1 gebruiker registreren. Bespreek in de eigen organisatie eerst goed welke gebruiker geregistreerd gaat worden.
* Er is een limiet aan het aantal testen dat per dag kan worden uitgevoerd.
Neem graag contact op als hier vragen over zijn, of problemen bij worden ervaren.

=====Organisatie aanmaken=====
* Maak een account aan voor de organisatie, zie https://touchstone.aegis.net/touchstone/userguide/html/registration/index.html
NB: Name en Email is redelijk vrij in te vullen (mits het echte namen en E-mailadressen betreft). Let er wel op dat de naam voor de Organisatie een naam moet zijn die herkenbaar is binnen MedMij als toekomstige deelnemer. Als er bijvoorbeeld een onderontwikkelaar wordt ingeschakeld en die naam wordt gebruikt tijdens registratie als Organisatie, dan is binnen MedMij de relatie naar de verantwoordelijke toekomstige deelnemende leverancier niet altijd duidelijk, waarbij de kans bestaat dat het verzoek voor Joinen van Org Groupen wordt afgekeurd.
* Join de juiste Org Group voor testen:
Klik via Organizations, Org Groups
Kies de juiste Org Group om te joinen, in dit geval: '''MedMij-Testing'''
* NB: voor formele kwalificaties wordt er gebruik gemaakt van een 2e Org Group, genaamd: '''MedMij-Certify'''

[[Bestand:Aansluiten_org_group.png|link= |750px|Joinen van een Org Group]]
* Het kwalificatiecentrum zal vervolgens het verzoek voor joinen goedkeuren. Merk op dat hierbij goedkeuring van één van onze medewerkers nodig is en er dus korte tijd overheen kan gaan.
* Nadat goedkeuring is verleend dient de gebruiker, als deze nog is ingelogd, uit te loggen en opnieuw in te loggen.

=====Pas eventueel privacy-settings aan=====
Let op: TouchStone toont per default e-mailadressen en organisatie van geregistreerde gebruikers.
Pas eventueel de privacy-settings aan voor eigen gebruikers:
* Ga naar My Settings

[[Bestand:Aansluiten privacy settings.png|link= |750px|Aanpassen privacy settings]]

* Vink aan:
[[Bestand:Aansluiten privacy settings vink.png|link= |450px|Aanpassen privacy settings: Do not display my email]]
* Klik op Save Changes.

=====Testsysteem aanmaken=====
* Maak een testsysteem aan voor de eigen applicatie, zie https://touchstone.aegis.net/touchstone/userguide/html/test-systems/index.html
Bij het aanmaken graag de volgende instellingen gebruiken:
* Specification: FHIR 3.0.1
* Niet aanvinken: requires OAuth2
NB: we versturen wel degelijk een OAuth token, maar die configuratie vindt elders plaats.
* Can be viewed by: My organization groups
* Can be executed against by: My organization groups
* Supported profiles: maak de keuze tussen FHIR-client of FHIR-server
NB: als beide ondersteund wordt, is het aan te raden om daar 2 losse testsystemen voor op te zetten.

Het kwalificatiecentrum biedt op verzoek hulp bij het koppelen van de applicatie naar de simulator
Connectiviteit met de simulator wordt door de softwareleverancier en MedMij getest.

Neem graag even contact op als daar vragen over zijn.

===Gebruik simulator===
====Uitvoeren van testen====
Documentatie voor het uitvoeren van de testen is hier te zien: https://touchstone.aegis.net/touchstone/userguide/html/executing-tests/index.html

De leverancier kan zelfstandig testen op basis van scripts.
Indien van toepassing kan de leverancier extra materialen zoals screenshots insturen via email.
Het kwalificatiecentrum biedt op verzoek hulp bij het testen van de scripts.

Voor het uitvoeren van de tests kan (na inloggen) linksonder uit ‘Test Definitions’ een keuze worden gemaakt van de juiste testen.

[[Bestand:Aansluiten test definitions.png|link= |250px|Aansluiten test definitions]]

Klik onder ‘Test Definitions’ door naar:
* FHIRSandbox
** Nictiz
*** FHIR3-0-1-MM201901-Test (dit is de MedMij 2019.01 release)

In deze map zijn verschillende testen te vinden in het kader van MedMij testen.
Kies hierbij de juiste inhoudelijke rol en:
* PHR (= PGO) of
* XIS (= zorgaanbieder)

Selecteer de testen uit die map (meestal alle testen) dus select all, '''Create Test Setup'''.

[[Bestand:Aansluiten create test setup.png|link= |750px|Aansluiten create test setup]]

Bij het testen van '''PGO''' systemen moet de volgende informatie worden opgegeven:
* '''Origin''': Het eigen PGO test systeem.
* '''Destination''': Kies hierbij voor ‘Nictiz – Nictiz WildFHIR MedMij V201901 - FHIR 3.0.1’ (voor HTTP verkeer) of
* '''Destination''': Kies hierbij voor ‘Nictiz – Nictiz WildFHIR MedMij V201901 - TLS - FHIR 3.0.1’ (voor HTTPS/TLS verkeer)
NB: voor HTTPS/TLS wordt er gebruik gemaakt van Let's Encrypt certificaten.

Bij het testen van '''XIS''' systemen moet de volgende informatie worden opgegeven:
* '''Origin''': AEGIS.net, Inc - TouchstoneFHIR
* '''Destination''': Het eigen XIS test systeem.

Daarna: '''execute'''

[[Bestand:Aansluiten create test setup execute.png|link= |750px|Aansluiten create test setup execute]]

Zie verder de documentatie van Touchstone voor het inzien van test resultaten:
https://touchstone.aegis.net/touchstone/userguide/html/executing-tests/index.html

====Volgorde van testen====
Het kwalificatiescript vraagt om een vaste volgorde voor het uitvoeren van testen, waar de informatiestandaard mogelijk meer ruimte laat om dit ook in een andere volgorde te doorlopen.
Het is daarom van belang om bij het uitvoeren van testen op de kwalificatiesimulator de interacties uit te voeren '''in dezelfde volgorde''' waarin ze worden gevraagd worden in de testscripts.

====Testen en ophalen van references====
Antwoorden uit de kwalificatiesimulator bevatten soms references naar extra informatie.
Een voorbeeld uit de BGZ:
<code><reference value="Practitioner/medmij-bgz-practitioner-ts-02"/></code>

Die references zijn los op te halen bij de kwalificatiesimulator.
Merk op dat omdat er een bepaalde volgorde wordt gevraagd tijdens uitvoer van de testen, het tussendoor ophalen van references mogelijk kan ervoor zorgen dat een test faalt.
We raden in dat geval aan om:
* De references pas op te halen als de test op de kwalificatiesimulator is afgelopen. Het ophalen van references zal er dan niet meer voor zorgen dat testen falen.
Indien dat niet mogelijk is:
* Testen 2 keer uit te voeren:
** De test één keer uit te voeren zonder het ophalen van references. Het doel hierbij is om aan te tonen dat de applicatie de juiste interacties kan versturen die worden gevraagd in het testscript.
** De test een tweede keer uit te voeren, maar dan zonder dat hiervoor een testexecutie is gestart op de kwalificatiesimulator. Tijdens deze test kunnen dan wel alle references tussendoor worden opgehaald. Het doel van deze test is om aan te tonen dat de applicatie goed om kan goed met de inhoud verstuurd tijdens de test, inclusief de los op te halen references.

====Vragen over uitvoer van testscript====
Indien er vragen zijn over uitgevoerde testen is het voor ons van belang om gericht te kunnen terugvinden welke interacties er uitgewisseld zijn.
Bij contact hierover vragen wij daarom om (indien mogelijk) hiervoor een testexecution uit te voeren op de kwalificatiesimulator.
Neem bij vragen daarover graag altijd de link op naar de uitgevoerde testexecution uit de history van Touchstone.
Dat geeft de mogelijkheid om gericht te kijken naar een uitgevoerde test.

Een voorbeeld in schermprints:

Klikken naar '''History''' in Touchstone:

[[Bestand:Touchstone_history.png|link= |250px|Touchstone history.png]]

Ophalen van de link van de testexecution uit de History:

[[Bestand:Touchstone_history_link.png|link= |750px|Touchstone_history_link.png]]

De link van de testexecution ziet er dan bijvoorbeeld zo uit:
<code><nowiki>https://touchstone.aegis.net/touchstone/execution?exec=201904050520537715673006</nowiki></code>

===Mijn software is getest en nu?===
Geef graag aan als de testen zijn afgerond via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

MedMij:V2020.01/Kwalificatie aansluiten

2020-07-20T15:38:49Z

Update bot: Copy of V2019.01

MedMij:V2020.01/Kwalificatiemateriaal voor MedMij

2020-07-20T15:38:49Z

Update bot: Copy of V2019.01

#DOORVERWIJZING [[MedMij:Vprepub/Kwalificatie]]

MedMij:Vprepub-2020.01/Kwalificatie

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
<section begin=medmij_kwalificatie_introductie />
Op deze informatiestandaard is een Nictiz kwalificatie van toepassing.
Kwalificatie vindt plaats per systeemrol.

Enkele systeemrollen vallen binnen de 'subsidieregeling voor PGO-leveranciers (dienstverlener persoon)' die in 2018 is opgesteld door de Dienst Uitvoering Subsidie voor Instellingen. Welke systeemrollen dat betreft vindt u in [[MedMij:Vprepub/ToelichtingSubsidie| ToelichtingSubsidie]].

Voor meer informatie, stuur een mail naar 'kwalificatie@medmij.nl'.

Kwalificatiescripts en meer informatie over de kwalificatie is te vinden via de betreffende paragraaf op de [[MedMij:Vprepub/Kwalificatie#Kwalificatie_scripts|Kwalificatiepagina]].<section end=medmij_kwalificatie_introductie />

=Algemene voorwaarden voor kwalificatie=
Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van MedMij afsprakenstelsel.
# Kennis over de te gebruiken infrastructuur of het netwerk waarover uitgewisseld wordt en de toegang daartoe, inclusief authenticatie/autorisatie etc.
# Kennis en begrip van de betreffende MedMij informatiestandaard, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten en andere referenties die de informatiestandaard gebruikt.
# Kennis en begrip en het naleven van de aandachtspunten zoals beschreven in het document '''2. Addenda - Kwalificaties''' als bijlage bij de betreffende informatiestandaard.
# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie. Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
# '''Inhoudelijke informatie, beschreven in de informatiestandaard, moet altijd toegankelijk zijn voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Uitgangspunten voor kwalificatie=
In dit hoofdstuk worden de generieke uitgangspunten voor de kwalificatie per systeemrol uiteengezet. Per informatiestandaard kan het voorkomen dat er nog 'specifieke' uitgangspunten op van toepassing zijn, in dat geval, zijn deze opgenomen in een aparte paragraaf onder het hoofdstuk 'Kwalificatie' van het [[MedMij:Vprepub/Ontwerpen#Algemeen_2 | functioneel ontwerp]] van de informatiestandaard.

==Systeemrol 'Raadplegen' (PGO)==
Hieronder volgt het generieke uitgangspunt voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitganspunten_Systeemrol_Raadplegen />
* Een PGO biedt de persoon inzicht in de ontvangen respons. Als er géén gegevens beschikbaar gesteld worden, kan dat zijn omdat er geen informatie beschikbaar is in het XIS of vanwege een technische foutmelding. Er volgt bijvoorbeeld een foutmelding indien de resource, een specifieke zib, niet wordt ondersteund in het XIS. Het is een belangrijk inzicht voor de persoon als gegevens technisch niet beschikbaar gesteld kunnen worden.<section end=Uitganspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (XIS)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitganspunten_Systeemrol_Beschikbaarstellen />
* XIS geeft technisch correct antwoord op alle searches ongeacht of de gegevens in XIS beschikbaar zijn. XIS stelt alle gegevens beschikbaar voor zover aanwezig.

* Mochten gegevens niet beschikbaar gesteld kunnen worden, dan is uit de respons voor de persoon te herleiden waardoor dit veroorzaakt wordt:
**veroorzaakt door het ontbreken van de informatie
**veroorzaakt doordat het XIS dit technisch niet kan leveren.

* In het geval dat een vraag om gegevens goed wordt verwerkt door het XIS, volgt een respons met daarin 0 tot * FHIR resources die matchen aan de vraag. Als er dus 0 resources in zitten mag de persoon ervan uitgaan dat het XIS deze gegevens niet heeft, maar de vraag wel goed begrepen heeft.

* Als er technisch iets niet goed gaat, stuurt het XIS conform de specificaties een foutcode terug samen met een OperationOutcome, waarin de oorzaak wordt getoond. Bijvoorbeeld dat de resource, een specifieke zib, niet wordt ondersteund in het XIS. Deze moet ingebouwd worden door het XIS. Hierop wordt het XIS ook gekwalificeerd.<section end=Uitganspunten_Systeemrol_Beschikbaarstellen />

=Kwalificatie aansluiten op de kwalificatieomgeving=
MedMij biedt leveranciers de mogelijkheid hun producten en diensten te laten testen op correcte implementatie van informatiestandaarden.
Documentatie over hoe aan te sluiten is te vinden op: [[MedMij:Vprepub/Kwalificatie_aansluiten]]

=Gebruik van de simulator=

==Authorization tokens==
Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification]]<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

==Variable T datum==
Voor veel, straks alle, kwalificaties wordt er gebruik gemaakt van een variabele datum. Dit is de zogenoemde T datum welke is opgenomen in de functionele testscripts, met name in de addenda, en in de technische testscripts op Touchstone. Deze variabele datum wordt gebruikt om zo dicht mogelijk tegen een productiewaardig scenario te testen en te kwalificeren. Middels de variabele datum kunnen de testgegevens actueel blijven. Deze T datum komt op twee plekken terug, namelijk in de datumvelden van de testgegevens en in de datumparameters in de search URL's. In de volgende twee paragrafen wordt dit toegelicht.

===Kwalificatie test gegevens===
De functionele testscripts beschrijven in de addenda testgegevens waarin datum velden staan op basis van een T datum. Als ergens staat T – 100D betekent dit: 100 dagen eerder dan de datum die voor T geldt. Deze testgegevens uit de addenda worden vervolgens gebruikt om ofwel de Nictiz WildFHIR server te vullen of door kandidaat deelnemers om de testgegevens in het systeem te registreren.

Het vullen van de Nictiz WildFHIR server kon in het verleden door kandidaatdeelnemers gebeuren door het draaien van het 'load script' op basis van een op te geven variable T. Dit is nu in beheer genomen door het kwalificatie team.

'''Elke maandag wordt de Nictiz WildFHIR server geschoond en opnieuw gevuld met een testgegevens op basis van een T datum gelijk aan de datum van die maandag.'''

Bijvoorbeeld in 2019 is T datum in week 46 gelijk aan 11 november 2019.

===Parameters in de request URL's===
Bij sommige testscenario's wordt een datumfilter gebruikt. Deze datumfilters zijn ook op basis van de variabele T datum. Bij het uitvoeren van het testscript in Touchstone is het mogelijk om bij de setupfase de variabele T datum te geven. Deze T datum staat in relatie tot de testgegevens die op de Nictiz WildFHIR server of het eigen bronsysteem staan. De T datum die hier gebruikt dient te worden, is gelijk aan de datum van de maandag (waarop de gegevens geladen zijn).

Wanneer een andere T datum wordt gebruikt kan het voorkomen dat er geen of te weinig testgegevens terugkomen op de uitgevoerde test. Dit kan er toe leiden dat de test niet slaagt.

===Tijdnotatie===
Het meegeven van de tijd is bij de gestructureerde einddatum/tijd (dus niet de Resource.text, maar de velden met alleen de datum/tijd) verplicht in de standaard om eventuele verwarring tussen de precieze betekenis van "tot" en "tot en met" te voorkomen.

In de FHIR datatypes ''dateTime'' (indien uren en minuten worden gebruikt) en ''instant'' is de tijdzone verplicht. De tijdzone kan daarom niet worden weglaten uit de testgegevens.

Touchstone heeft helaas een beperking dat de Nederlandse tijdzone niet berekend kan worden bij een variabele datum. De tijdzone die nu in onze testgegevens staat, was een Nederlandse tijdzone bij de eerste keer invullen van dit scenario met concrete datums. Dit komt niet per definitie overeen met de geldende tijdzone in Nederland voor de (in een test-executie gebruikte, uiteindelijke) datum. In productie moet gerekend worden op een juiste tijdzone en het is dan ook juist om deze tijdzone gewoon te interpreteren, dit betekent dat de gegevens mogelijk soms een uur later of vroeger zijn dan in het addendum staat. Dit is geen reden voor afkeuren in kwalificatie.

=Kwalificatiescripts=
==Basisgegevensset Zorg 2.1==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ.zip|3. Aanleverformat - Raadplegen BgZ.zip]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden nu '''niet''' gebruikt voor kwalificatie. Op termijn zullen deze kwalificatiescripts de huidige vervangen.

* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ extended.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ extended.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BGZ extended.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ extended.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ Extended.pdf|2.Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ Extended.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ Extended.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ Extended.pdf]]

==Labuitwisseling 1.1==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]

==Medicatieproces 9.0 ==
:Een uitleg van medicatieproces voor PGO's die kwalificeren voor MedMij is beschikbaar in de vorm van:
::*[[Media:PGOsessie OpnameOnline.mp4 |Bestand (met mp4 opname) van uitleg Medicatieproces]] met bijbehorende
::*[[Media:PGOsessiesMedicatieproces_BijlageBijOnlineSessie.pdf|PowerPoint (in PDF)]].

:Diverse medicatieproces kwalificatiescripts zijn van toepassing voor zowel zorgverlener-patiënt (MedMij) als zorgverlener-zorgverlener gegevensuitwisseling. Deze kwalificatiescripts worden op één plek onderhouden en gepubliceerd. Via deze MedMij pagina wordt direct naar het betreffende kwalificatiescript verwezen (via de link).

===Medicatiegegevens===
:* [[Media:1.1 Kwalificatiescript Raadplegen medicatieafspraak907 v3.pdf|1.1. Kwalificatiescript - Raadplegen medicatieafspraak907.pdf]]
:* [[mp:V9.0.7_kwalificatie_medicatiegegevens_beschikbaarstellen_MA|1.1. Kwalificatiescript & Addenda - Beschikbaarstellen medicatieafspraak907]]
:* [[Media:1.2 Kwalificatiescript Raadplegen toedieningsafspraak907 v3.pdf|1.2. Kwalificatiescript - Raadplegen toedieningsafspraak907.pdf]]
:* [[Media:1.3 Kwalificatiescript Raadplegen medicatiegebruik907 v3.pdf|1.3. Kwalificatiescript - Raadplegen medicatiegebruik907.pdf]]
:* [[Media:1.4 Kwalificatiescript Raadplegen verstrekkingsverzoek907 v3.pdf|1.4. Kwalificatiescript - Raadplegen verstrekkingsverzoek907.pdf]]
:* [[mp:V9.0.7_kwalificatie_medicatiegegevens_beschikbaarstellen_VV|1.4. Kwalificatiescript & Addenda - Beschikbaarstellen verstrekkingsverzoek907]]
:* [[Media:1.5 Kwalificatiescript Raadplegen medicatieverstrekking907 v3.pdf|1.5. Kwalificatiescript - Raadplegen medicatieverstrekking907.pdf]]
:* [[Media:1.6 Kwalificatiescript Raadplegen medicatiegegevens AlleBouwstenen907 v3.pdf|1.6. Kwalificatiescript - Raadplegen medicatiegegevens AlleBouwstenen907.pdf]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumMedicatieafspraken|2.1. Addenda - Raadplegen medicatieafspraak907]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumToedieningsafspraken|2.2. Addenda - Raadplegen toedieningsafspraak907]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumMedicatiegebruik|2.3. Addenda - Raadplegen medicatiegebruik907]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumVerstrekkingsverzoeken|2.4. Addenda - Raadplegen verstrekkingsverzoek907]]
:* [[MedMij:V1.0_MP9.0.7KwalificatieAddendumVerstrekkingen|2.5. Addenda - Raadplegen medicatieverstrekking907]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumAlleBouwstenen|2.6. Addenda - Raadplegen medicatiegegevens AlleBouwstenen907]]
:* [[Media:Aanleverformat_-_Raadplegen_Medicatieafspraak.zip|3.1. Aanleverformat - Raadplegen medicatieafspraak907.zip]]
:* [[Media:Aanleverformat_-_Beschikbaarstellen_Medicatieafspraak.zip|3.1. Aanleverformat - Beschikbaarstellen medicatieafspraak907.zip]]
:* [[Media:Aanleverformat_-_Raadplegen_Toedieningsafspraak.zip|3.2. Aanleverformat - Raadplegen toedieningsafspraak907.zip]]
:* [[Media:Aanleverformat_-_Raadplegen_Medicatiegebruik.zip|3.3. Aanleverformat - Raadplegen medicatiegebruik907.zip]]
:* [[Media:Aanleverformat_-_Raadplegen_Verstrekkingsverzoek.zip|3.4. Aanleverformat - Raadplegen verstrekkingsverzoek907.zip]]
:* [[Media:Aanleverformat_-_Beschikbaarstellen_Verstrekkingsverzoek.zip|3.4. Aanleverformat - Beschikbaarstellen verstrekkingsverzoek907.zip]]
:* [[Media:Aanleverformat_-_Raadplegen_Medicatieverstrekking.zip|3.5. Aanleverformat - Raadplegen medicatieverstrekking907.zip]]
:* [[Media:Aanleverformat_-_Raadplegen_Medicatiegegevens.zip|3.6. Aanleverformat - Raadplegen medicatiegegevens AlleBouwstenen907.zip]]

===Medicatieoverzicht===
:* [[Media:Kwalificatiescript_Raadplegen_medicatieoverzicht907_v2.1.pdf|1. Kwalificatiescript - Raadplegen medicatieoverzicht907.pdf]]
:* [[mp:V9.0.7_kwalificatie_medicatieoverzicht_beschikbaarstellen_MA_BEPERKT|1. Kwalificatiescript & Addenda - Beschikbaarstellen medicatieoverzicht907 BEPERKT (alléén voor VIPP GGZ)]]
:* [[MedMij:V1.0_MP9.0.7-KwalificatieAddendumMedicatieoverzicht|2. Addenda - Raadplegen medicatieoverzicht907]]
:* [[Media:Aanleverformat_-_Raadplegen_Medicatieoverzicht.zip|3. Aanleverformat - Raadplegen medicatieoverzicht907.zip]]
:* [[Media:Aanleverformat_-_Beschikbaarstellen_Medicatieoverzicht.zip|3. Aanleverformat - Beschikbaarstellen medicatieoverzicht907 BEPERKT (alléén voor VIPP GGZ).zip]]

===Verstrekkingenvertaling===
:* [[Media:Kwalificatiescript_Raadplegen_verstrekkingenvertaling907_v1.2.pdf|1. Kwalificatiescript - Raadplegen verstrekkingenvertaling907.pdf]]
:* [[Media:Kwalificatiescript_Beschikbaarstellen_verstrekkingenvertaling907_v1.2.pdf|1. Kwalificatiescript - Beschikbaarstellen verstrekkingenvertaling907.pdf]]
:* [[MedMij:V1.0_MP9.A.0-AddendaInhoudelijkeGegevens|2. Addenda - Verstrekkingenvertaling907]]
:* [[Media:Aanleverformat_-_Raadplegen_Verstrekkingenvertaling.zip |3. Aanleverformat - Raadplegen Verstrekkingenvertaling907.zip]]
:* [[Media:Aanleverformat_-_Beschikbaarstellen_Verstrekkingenvertaling.zip |3. Aanleverformat - Beschikbaarstellen Verstrekkingenvertaling907.zip]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens.pdf|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens.pdf]]
* [[Media:2. Addenda - MedMij Beschikbaarstellen AllergieIntolerantie gegevens.pdf|2. Addenda - MedMij Beschikbaarstellen AllergieIntolerantie gegevens.pdf]]
* [[Media:2. Addenda - MedMij Raadplegen AllergieIntolerantie gegevens.pdf|2. Addenda - MedMij Raadplegen AllergieIntolerantie gegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]

===AllergieIntolerantieVertaling===
* [[MedMij:Vprepub/kw-MM-1.A-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]
* [[MedMij:Vprepub/kw-MM-1.A-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantieVertaling.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]

==eAfspraak 1.1==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf|1. Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen eAfspraak.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen eAfspraak.pdf]]
* [[Media:Aanleverformat - Raadplegen eAfspraak.zip|3. Aanleverformat - Raadplegen eAfspraak.zip]]
* [[Media:Aanleverformat - Beschikbaarstellen eAfspraak.zip|3. Aanleverformat - Beschikbaarstellen eAfspraak.zip]]

==Zelfmetingen 1.2==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen en Sturen Zelfmetingen.zip|3. Aanleverformat - Raadplegen en Sturen Zelfmetingen.zip]]

==PDF/A 2.0==
* [[Media:1._Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
* [[Media:1._Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Beschikbaarstellen_en_Ontvangen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen PDFA.pdf]]
* [[Media:2._Addenda_-_Kwalificatiescript_-_MedMij_Raadplegen_en_Sturen_PDFA.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen PDFA.pdf]]
* [[Media: Aanleverformat_-_Beschikbaarstellen_en_Ontvangen_PDFA.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen PDFA.zip]]
* [[Media: Aanleverformat_-_Raadplegen_en_Sturen_PDFA.zip|3. Aanleverformat - Raadplegen en Sturen PDFA.zip]]

==Huisartsgegevens 1.1==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]

==Basisgegevens GGZ 1.1==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]

==Beelden 1.0==
* [[Media:1. Kwalificatiescript - MedMij Ontvangen beelden.pdf|1. Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen beelden.pdf|1. Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen beelden.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:Aanleverformat - Ontvangen Beelden.zip|3. Aanleverformat - Ontvangen Beelden.zip]]
* [[Media:Aanleverformat - Sturen Beelden.zip|3. Aanleverformat - Sturen Beelden.zip]]

==Basisgegevens Langdurige Zorg 1.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]
* [[MedMij:V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.1|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.1]]
* [[MedMij:V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.2|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.2]]
* [[MedMij:V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
* [[Media:3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.pptx.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
* [[Media:3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.pptx.zip|3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.zip]]

==Vragenlijsten 1.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]

<section end=medmij_kwalificatiescripts />

[[Categorie:Kwalificatie]]

MedMij:Vprepub-2020.01/Issuebox FHIR IG

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/Issuebox

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

MedMij:V2020.01/Kwalificatie

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

MedMij:V2020.01/Issuebox FHIR IG

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

MedMij:V2020.01/Issuebox

2020-07-20T15:38:48Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/InhoudLangdurigeZorg

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

{{DISPLAYTITLE:Inhoud Basisgegevens Langdurige Zorg op basis van zibs release 2017}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:BgLZ-icon.png|link=|links|95px|Use case BgLZ|BgLZ]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_Care|Technisch]]
desc none
</imagemap>

=Toelichting=
Deze pagina hoort bij het [[MedMij:Vprepub/OntwerpLangdurigeZorg|Functioneel Ontwerp Basisgegevens Langdurige Zorg]].

De Basisgegevens Langdurige Zorg bestaat uit gegevens die patiënten binnen de langdurige zorg zelf relevant vinden om via hun PGO in te zien, zoals bepaald tijdens een aantal veldverkenningen met zowel patiënten als zorgprofessionals. De Basisgegevens Langdurige Zorg komt voor een deel overeen met de [https://www.nictiz.nl/standaarden/basisgegevensset-zorg Basisgegevensset Zorg (BgZ)] en [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht/ eOverdracht], maar voor een deel ook niet: het gaat om drie aparte sets. Zo wordt voor medicatiegegevens (wel onderdeel van de BgZ) verwezen naar de reeds bestaande informatiestandaard [https://www.nictiz.nl/Paginas/Informatiestandaard-Medicatieproces.aspx Medicatieproces 9.0]; deze vallen buiten de Basisgegevens Langdurige Zorg. Veel gegevens in zowel de BgZ en eOverdracht werden niet als relevant aangeduid voor uitwisseling met patiënten in de langdurige zorg en zijn dan ook weggelaten. Ook zijn er voor langdurige zorg relevante gegevens die in de BgZ missen (bijv. verpleegkundige interventies) maar wel in eOverdracht voorkomen.

Waar mogelijk (overlappende zibs) en passend binnen de langdurige zorg, is dezelfde indeling en inhoud van de BgZ overgenomen ter verdere ondersteuning van sector-overstijgende interoperabiliteit. Daarmee komen een aantal secties en onderdelen in onderstaande tabel direct overeen met de BgZ (zoals de sectie "Behandelrestricties"). Waar dit niet mogelijk en/of niet passend was, is een nieuwe indeling en inhoud voor de langdurige zorg bepaald gebaseerd op [https://www.nictiz.nl/standaardisatie/informatiestandaarden/verpleegkundige-overdracht/ eOverdracht] (zoals de nieuwe sectie "Verpleegkundig zorgplan") of de [[MedMij:Vprepub/OntwerpGGZ|Basisgegevens GGZ]] (zoals de nieuwe sectie "Zorgsetting").

Bij een groot aantal van de zibs is de inhoud verder aangescherpt voor datgene wat relevant is om te tonen in het PGO, zoals de zib Patiënt waarbij overlijdensgegevens zijn weggelaten; voor precieze specificaties op ART-DECOR, zie [[MedMij:Vprepub/OntwerpLangdurigeZorg#Transacties & Transactiegroepen| Transacties & Transactiegroepen]].

=Inhoud=

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Sectie
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Onderdeel
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Inhoud
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Naam bijbehorende zib
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Versie zib
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Kardinaliteit zib
|-
| style="background-color: white;"| '''Demografie en identificatie'''
| style="background-color: white;"| '''Patiëntengegevens'''
| style="background-color: white;"| NAW gegevens, BSN, geboortedatum, geslacht, contactgegevens van de patiënt; geen overlijdensgegevens
| style="background-color: white;"| [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patiënt]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 1..1
|-
| style="background-color: white;"| '''Behandelrestricties'''
| style="background-color: white;"| '''Behandelaanwijzingen'''
| style="background-color: white;"| Bekende behandelaanwijzingen
| style="background-color: white;"| [https://zibs.nl/wiki/BehandelAanwijzing-v3.1(2017NL) BehandelAanwijzing]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Wilsverklaringen'''
| style="background-color: white;"| Bekende wilsverklaringen
| style="background-color: white;"| [https://zibs.nl/wiki/Wilsverklaring-v3.1(2017NL) Wilsverklaring]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Contactpersonen'''
| style="background-color: white;"| '''Contactpersoon'''
| style="background-color: white;"| Eerste relatie/contactpersoon; geen adresgegevens
| style="background-color: white;"| [https://zibs.nl/wiki/Contactpersoon-v3.1(2017NL) Contactpersoon]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"| '''Klachten en diagnoses'''
| style="background-color: white;"| '''Problemen (incl. diagnoses)'''
| style="background-color: white;"| Bekende problemen van alle probleemtypen; geen verificatiestatus
| style="background-color: white;"| [https://zibs.nl/wiki/Probleem-v4.1(2017NL) Probleem]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Allergieën'''
| style="background-color: white;"| '''Allergie-intoleranties'''
| style="background-color: white;"| Bekende allergieën en intoleranties; selectie van gegevens (zie transactie specificaties)
| style="background-color: white;"| [https://zibs.nl/wiki/AllergieIntolerantie-v3.2(2017NL) AllergieIntolerantie]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Uitslagen'''
| style="background-color: white;"| '''Laboratoriumuitslagen'''
| style="background-color: white;"| Bekende klinische bepalingen, laatste uitslag; selectie van gegevens (zie transactie specificaties)
| style="background-color: white;"| [https://zibs.nl/wiki/LaboratoriumUitslag-v4.1(2017NL) LaboratoriumUitslag]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Verrichtingen'''
| style="background-color: white;"| '''Verrichtingen'''
| style="background-color: white;"| Bekende verrichtingen
| style="background-color: white;"| [https://zibs.nl/wiki/Verrichting-v4.1(2017NL) Verrichting]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Verpleegkundig zorgplan'''
| style="background-color: white;"| '''Doelen en interventies'''
| style="background-color: white;"| Verpleegkundige interventies behorend bij actuele problemen
| style="background-color: white;"| [https://zibs.nl/wiki/VerpleegkundigeInterventie-v3.2(2018NL) VerpleegkundigeInterventie]
| style="background-color: white;"| v3.2(2018NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"| Behandeldoelen (gewenst zorgresultaat) behorend bij verpleegkundige interventies
| style="background-color: white;"| [https://zibs.nl/wiki/Behandeldoel-v3.1(2017NL) Behandeldoel]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"| Medisch hulpmiddelen (bijv. verbandmiddelen) behorend bij verpleegkundige interventies; alleen producttype en anatomische locatie/lateraliteit
| style="background-color: white;"| [https://zibs.nl/wiki/MedischHulpmiddel-v3.1(2017NL) MedischHulpmiddel]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Uitkomsten'''
| style="background-color: white;"| Bekende uitkomsten (zorgresultaat) van zorg
| style="background-color: white;"| [https://zibs.nl/wiki/UitkomstVanZorg-v3.1(2017NL) UitkomstVanZorg]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"| '''Zorgsetting'''
| style="background-color: white;"| '''Huisarts'''
| style="background-color: white;"| De gegevens van de huisarts; geen ID, adres/contactgegevens
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Hoofdbehandelaar'''
| style="background-color: white;"| De gegevens van de hoofdbehandelaar; geen ID, adres/contactgegevens
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Overige behandelaars'''
| style="background-color: white;"| De gegevens van de overige behandelaars; geen ID, adres/contactgegevens
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Zorgaanbieder'''
| style="background-color: white;"| De gegevens van waar de behandeling plaatsvindt; geen ID
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgaanbieder-v3.1.1(2017NL) Zorgaanbieder]
| style="background-color: white;"| v3.1.1(2017NL)
| style="background-color: white;"| 0..*
|}

MedMij:Vprepub-2020.01/InhoudGGZ

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

{{DISPLAYTITLE:Inhoud Basisgegevens GGZ op basis van zibs release 2017}}
{{MedMij:Vprepub/Issuebox}}

[[Bestand:MedMij-GGZ-63.png |link=|links|80px|Use case GGZ|GGZ]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<imagemap>Bestand:Leeswijzer-technisch-banner 02 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/Ontwerpen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_GGZ|Technisch]]
desc none
</imagemap>

=Toelichting=
Deze pagina hoort bij het [[MedMij:Vprepub/OntwerpGGZ|Functioneel Ontwerp Basisgegevens GGZ]].

De Basisgegevens GGZ bestaat uit een selectie van reeds bestaande zorginformatiebouwstenen (zibs; publicatie 2017) die voor de GGZ sector geschikt zijn. Deze lijst komt voor een deel overeen met de [https://www.nictiz.nl/standaarden/basisgegevensset-zorg Basisgegevensset Zorg (BgZ)], voor een deel ook niet. Zo wordt voor medicatiegegevens verwezen naar de reeds bestaande informatiestandaard [https://www.nictiz.nl/Paginas/Informatiestandaard-Medicatieproces.aspx Medicatieproces 9.0]. Ook zijn er voor GGZ relevante gegevens die in de BgZ missen (bijv. juridische status en vrijheidsbeperkende maatregelen).

Waar mogelijk (overlappende zibs) en passend binnen de GGZ sector, is dezelfde indeling en inhoud van de BgZ overgenomen ter verdere ondersteuning van sector-overstijgende interoperabiliteit. Daarmee komen een aantal secties en onderdelen in onderstaande tabel direct overeen met de BgZ (zoals de sectie "Demografie en identificatie", "Financiële informatie", "Klachten en diagnoses"). Waar dit niet mogelijk en/of niet passend was, is een nieuwe indeling en inhoud voor de GGZ bepaald (zoals de nieuwe sectie "Middelengebruik" of aanvullende onderdelen in secties "Behandelrestricties" en "Sociale anamnese").

=Inhoud=

{| class="wikitable" "cellpadding="10"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Sectie
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Onderdeel
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Inhoud
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Naam bijbehorende zib
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Versie zib
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Kardinaliteit zib
|-
| style="background-color: white;"| '''Demografie en identificatie'''
| style="background-color: white;"| '''Patiëntengegevens'''
| style="background-color: white;"| NAW gegevens, BSN, geboortedatum, geslacht, overlijdensinformatie, contactgegevens van de patiënt
| style="background-color: white;"| [https://zibs.nl/wiki/Patient-v3.1(2017NL) Patiënt]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 1..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Burgerlijke staat'''
| style="background-color: white;"| Laatst bekende burgerlijke staat
| style="background-color: white;"| [https://zibs.nl/wiki/BurgerlijkeStaat-v3.0(2017NL) BurgerlijkeStaat]
| style="background-color: white;"| v3.0(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"| '''Financiële informatie'''
| style="background-color: white;"| '''Verzekeringsgegevens'''
| style="background-color: white;"| De verzekeringsgegevens van de patiënt
| style="background-color: white;"| [https://zibs.nl/wiki/Betaler-v3.1(2017NL) Betaler]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"| '''Behandelrestricties'''
| style="background-color: white;"| '''Behandelaanwijzingen'''
| style="background-color: white;"| Bekende behandelaanwijzingen
| style="background-color: white;"| [https://zibs.nl/wiki/BehandelAanwijzing-v3.1(2017NL) BehandelAanwijzing]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Wilsverklaringen'''
| style="background-color: white;"| Bekende wilsverklaringen
| style="background-color: white;"| [https://zibs.nl/wiki/Wilsverklaring-v3.1(2017NL) Wilsverklaring]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Juridische status'''
| style="background-color: white;"| Bekende juridische status en/of vertegenwoordiging
| style="background-color: white;"| JuridischeStatus (uit [https://zibs.nl/wiki/VrijheidsbeperkendeMaatregelen-v3.1(2017NL) VrijheidsbeperkendeMaatregelen])
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Vrijheidsbeperkende maatregelen'''
| style="background-color: white;"| Bekende vrijheidsbeperkende maatregelen
| style="background-color: white;"| [https://zibs.nl/wiki/VrijheidsbeperkendeMaatregelen-v3.1(2017NL) VrijheidsbeperkendeMaatregelen]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Contactpersonen'''
| style="background-color: white;"| '''Contactpersoon'''
| style="background-color: white;"| Eerste relatie/contactpersoon
| style="background-color: white;"| [https://zibs.nl/wiki/Contactpersoon-v3.1(2017NL) Contactpersoon]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"| '''Functionele status'''
| style="background-color: white;"| '''Functionele/mentale status'''
| style="background-color: white;"| Bekende functionele/mentale statussen
| style="background-color: white;"| [https://zibs.nl/wiki/FunctioneleOfMentaleStatus-v3.1(2017NL) FunctioneleOfMentaleStatus]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Klachten en diagnoses'''
| style="background-color: white;"| '''Problemen (incl. diagnoses)'''
| style="background-color: white;"| Bekende problemen van alle probleemtypen
| style="background-color: white;"| [https://zibs.nl/wiki/Probleem-v4.1(2017NL) Probleem]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Middelengebruik'''
| style="background-color: white;"| '''Drugsgebruik'''
| style="background-color: white;"| Bekend drugsgebruik
| style="background-color: white;"| [https://zibs.nl/wiki/DrugsGebruik-v3.2(2017NL) Drugsgebruik]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Alcoholgebruik'''
| style="background-color: white;"| Bekend alcoholgebruik
| style="background-color: white;"| [https://zibs.nl/wiki/AlcoholGebruik-v3.1(2017NL) Alcoholgebruik]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Tabakgebruik'''
| style="background-color: white;"| Bekend tabakgebruik
| style="background-color: white;"| [https://zibs.nl/wiki/TabakGebruik-v3.1(2017NL) Tabakgebruik]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Sociale anamnese'''
| style="background-color: white;"| '''Woonsituatie'''
| style="background-color: white;"| Laatst bekende woonsituatie
| style="background-color: white;"| [https://zibs.nl/wiki/Woonsituatie-v3.1(2017NL) Woonsituatie]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Gezinssituatie'''
| style="background-color: white;"| Bekende gezinssituaties
| style="background-color: white;"| [https://zibs.nl/wiki/Gezinssituatie-v3.0(2017NL) Gezinssituatie]
| style="background-color: white;"| v3.0(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"|
| style="background-color: white;"| (zib afhankelijk van leeftijd)
| style="background-color: white;"| [https://zibs.nl/wiki/GezinssituatieKind-v1.1(2017NL) GezinssituatieKind]
| style="background-color: white;"| v1.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Taalvaardigheid'''
| style="background-color: white;"| Bekende taalvaardigheden
| style="background-color: white;"| [https://zibs.nl/wiki/Taalvaardigheid-v3.1(2017NL) Taalvaardigheid]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Participatie in maatschappij'''
| style="background-color: white;"| Bekende participatie in maatschappij
| style="background-color: white;"| [https://zibs.nl/wiki/ParticipatieInMaatschappij-v3.1(2017NL) ParticipatieInMaatschappij]
| style="background-color: white;"| v3.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Hulp van anderen'''
| style="background-color: white;"| Bekende hulp van anderen
| style="background-color: white;"| [https://zibs.nl/wiki/HulpVanAnderen-v3.0(2017NL) HulpVanAnderen]
| style="background-color: white;"| v3.0(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Uitslagen'''
| style="background-color: white;"| '''Laboratoriumuitslagen'''
| style="background-color: white;"| Bekende klinische bepalingen (incl. medicatiespiegels bijv. lithium), laatste uitslag
| style="background-color: white;"| [https://zibs.nl/wiki/LaboratoriumUitslag-v4.1(2017NL) LaboratoriumUitslag]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Vragenlijsten'''
| style="background-color: white;"| Bekende vragenlijst uitslagen (bijv. HONOS, OQ-45, CQ index, 4DKL)
| style="background-color: white;"| [https://zibs.nl/wiki/AlgemeneMeting-v3.0(2017NL) AlgemeneMeting]
| style="background-color: white;"| v3.0(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Verrichtingen'''
| style="background-color: white;"| Bekende GGZ verrichtingen
| style="background-color: white;"| [https://zibs.nl/wiki/Verrichting-v4.1(2017NL) Verrichting]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Verslagen'''
| style="background-color: white;"| Bekende verslagen bij GGZ verrichtingen
| style="background-color: white;"| [https://zibs.nl/wiki/TekstUitslag-v4.1(2017NL) Tekstuitslag]
| style="background-color: white;"| v4.1(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"| '''Zorgsetting'''
| style="background-color: white;"| '''Huisarts'''
| style="background-color: white;"| De gegevens van de huisarts
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Regiebehandelaar'''
| style="background-color: white;"| De gegevens van de regie/hoofdbehandelaar
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..1
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Overige behandelaars'''
| style="background-color: white;"| De gegevens van de overige behandelaars
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| style="background-color: white;"| v3.2(2017NL)
| style="background-color: white;"| 0..*
|-
| style="background-color: white;"|
| style="background-color: white;"| '''Zorgaanbieder'''
| style="background-color: white;"| De gegevens van waar de behandeling plaatsvindt
| style="background-color: white;"| [https://zibs.nl/wiki/Zorgaanbieder-v3.1.1(2017NL) Zorgaanbieder]
| style="background-color: white;"| v3.1.1(2017NL)
| style="background-color: white;"| 0..*
|}

MedMij:Vprepub-2020.01/FHIR eAfspraak

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide - eAfspraak {{VersieInfo|V2019.01|eAfspraak}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}

[[Bestand:EAfspraak_icoon_zonder_tekst.png |link=|links |87px|eAfspraak]]
[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
<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:Vprepub/OntwerpeAfspraken|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=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 [[MedMij:Vprepub/Ontwerpen|functional design]].

=Use case: retrieve appointments=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |128px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==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.

==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;"|Request appointments from the XIS
|-
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|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:

<code>GET [base]/Appointment/?date=[date]</code>

for more information on how to query on dates using FHIR see [http://hl7.org/fhir/stu3/search.html#date| the FHIR search specification]

'''examples:'''

retrieve appointments with a start date/time from 01-01-2018 onwards:

<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;
|-
| date
| [http://hl7.org/fhir/stu3/search.html#date date]
| Appointment date/time.
| Appointment.start
|-
|}

==Profiles==

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| 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}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| Afspraak
| Appointment
| Appointment
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment}}
|-
|}

==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)
|style="background-color: white;vertical-align:top;"|Handles appointment request
|}

==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}}

<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}}

<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==

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| 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}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| Afspraak
| Appointment
| Appointment
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment}}
|-
|-
| Slot
| Slot
| Slot
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Slot}}
|-
|}

==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}}

<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
| Appointment
| Appointment
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment}}
|-
|}

==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 can be found on the [[MedMij:Vprepub/OntwerpeAfspraak#Release_notes| functional design page]].

MedMij:V2020.01/InhoudLangdurigeZorg

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

MedMij:V2020.01/InhoudGGZ

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

MedMij:V2020.01/FHIR eAfspraak

2020-07-20T15:38:47Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/FHIR VitalSigns

2020-07-20T15:38:46Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|V2019.01|Zelfmetingen}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Self-measurements_Icoon.png|link=|87px |links||Self-Measurements]]
<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:Vprepub/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This use case is mainly based on the HL7 FHIR vital signs specification - http://hl7.org/fhir/STU3/observation-vitalsigns.html. The HL7 FHIR vital signs specification is extended with profiles of zib concepts that represent vital signs. These profiles are derived from the official [http://hl7.org/fhir/observation-vitalsigns.html HL7 Vital Signs profiles]. The purpose of these profiles is to add additional concepts that are not in the vital sign profiles but are provided in the corresponding zib. Moreover, these derived profiles include zib to FHIR mappings.

'''Technical note:'''

Because the base [http://hl7.org/fhir/vitalsigns.html vital signs] profile constrains the <code>.code</code> and the <code>.component.code</code> to the datatype quantity it is not possible to add additional zib concepts. A GForge [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13796 issue] is created to address this problem. This issue will most likely be resolved with FHIR version STU4. However, to address this problem now the base vital signs panel is copied, the datatype constrains removed and published under a different canonical URL. The HL7 vital sign profiles bloodpressure, bodyweight, and oxygensaturation are copied, the StructureDefinition.baseDefinition adjusted and published under a different canonical URL because they are in the chain of derived profiles and the component.code needs to be used for these vital signs.

Use cases:
* [[MedMij:Vprepub/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub/FHIR_VitalSigns#Use_case:_Send_Vital_Signs|Send vital signs]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! 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 environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-clientcapabilities|CapabilityStatement: Client}}
| Vital Signs client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/vitalsigns-servercapabilities|CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve vital signs transaction is used by the PHR to retrieve vital signs from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Vital Signs(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request vital signs from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves vital signs to the PHR
|}

==Invocations==
===PHR: request message===
The request message represents an HTTP GET parameterized query from the PHR to the XIS.

====Trigger Events====
When the patient(PHR) wants to obtain vital signs, it issues a retrieve vital signs request message.

====Message Semantics====
'''Search'''

The PHR executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTfull] and [http://hl7.org/fhir/search.html search] specification against the XIS's Observation endpoint. This search query URL is configurable by the PHR and has the following format.

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

'''Search Parameters'''

The PHR may supply, and the XIS shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification search parameters of [http://hl7.org/fhir/STU3/observation.html#search Observation].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| category
| token
| The classification of the type of observation
|-
| code
| token
| The code of the observation type
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

'''Example searches'''

The PHR should be able to fetch all of a patient's vital signs by searching on:
# category (all vital signs),
# category and date,
# code (specific vital sign),
# code and date,
# code and Last N.

<pre>1. GET [base]/Observation?category=vital-signs
2. GET [base]/Observation?category=vital-signs&date=[date]{&date=[date]}
3. GET [base]/Observation?code[vital sign LOINC{,LOINC2,LOINC3,...}]
4. GET [base]/Observation?code=[vital sign LOINC{,LOINC2,LOINC3,...}]&date=[date]{&date=[date]}
5. GET [base]/Observation/$lastn?code[vital sign LOINC{,LOINC2,LOINC3,...}
</pre>
The following table lists vital signs that have a corresponding zib. The column 'LOINC code' shows the LOINC code that can be used in the search query. Other possible codes, including the codes mentioned here, can be found [http://hl7.org/fhir/STU3/observation-vitalsigns.html#vitals-table here].

{| class="wikitable"
|-style="font-weight: bold; "
||Zib ||LOINC code
|-
|BloodPressure||85354-9
|-
| BodyWeight||29463-7
|-
| BodyHeight||8302-2
|-
| BodyTemperature||8310-5
|-
| Oxygenation, saturation, SpO2||59408-5
|-
| HeartRate||8867-4
|-
| PulseRate||8889-8
|-
| BloodGlucose|| 41604-0 (fasting) <br/> 14743-9 (general) <br/> 14760-3 (post-meal)
|}

{{NoteBox|1= Known issue: the LOINC code '41604-0' for fasting BloodGlucose has been used in an incorrect way in MedMij qualification. To support future versions of the information standard, LOINC code '14770-2' should also be supported. More information can be found here: https://bits.nictiz.nl/browse/MM-476}}
=====Expected Actions=====
The XIS shall process the query to find and return the vital signs matching the provided query parameters.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a Bundle of matching vital signs Observation.

====Trigger Events====
The XIS completed processing of the retrieve vital signs request message.

====Message Semantics====
Based on the retrieve vital signs request message processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not vital signs are found or generated, the HTTP status code shall be 200.

''Response Class:''
* Status 200: successful operation
* Status 400: invalid parameter
* Status 401/4xx: unauthorized request
* Status 403: insufficient scope

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/observation-vitalsigns.html Vital Signs Profile]
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html Search]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message Resource content=====
The body of the response message shall be a Bundle of type 'searchset' containing all matching vital sign Observations as entries. If no Observations are found, a Bundle of type 'searchset' shall be returned without any Observation as entries.

In the table below, the vital sign zibs and their respective profiles are listed. Other vital signs profiles, without a corresponding zib, are can be found in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html HL7 FHIR specification.]

All returned resources to the PHR SHALL include their related profile canonical URL in the meta.profile element in order to show compliance. The Observation resources in the response message SHALL be a valid instance of these profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib name NL||style="width:150px;"|Zib name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure}}
|-
| LichaamsGewicht||BodyWeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight}}
|-
| LichaamsLengte||BodyHeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight}}
|-
| Lichaamstemperatuur||BodyTemperature||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature}}
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation}}
|-
| Hartfrequentie||HeartRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate}}
|-
| Polsfrequentie||PulseRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR processes the results according to application-defined rules.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [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 transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

=Use case: Send Vital Signs=

==Introduction==
The send vital signs transaction is used by the PHR to send vital signs to the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Send Vital Signs(PUSH)
|style="background-color: white;vertical-align:top;"|Send vital signs request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Sends vital signs to the XIS
|-
|style="background-color: white;vertical-align:top;"|Send vital signs response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Receives vital signs from the PHR
|}

==Invocations==
===PHR: request message===
The send vital sings request message uses the HTTP POST method on the target XIS's base.

====Trigger Events====
This message is invoked when the PHR needs to send one or more vital signs observations to the XIS.

====Message Semantics====
Because sending vital signs will most likely consist of multiple Observations, a batch/transaction transaction is used. This allows for creating a set of resources in a single interaction.

A batch interaction is performed by an HTTP POST command as shown:

<pre>POST [base] {?_format=[mime-type]}</pre>

The body of the post submission is a Bundle with Bundle.type = batch. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry (note: the request is optional, but SHOULD be present). Every bundle.entry creates a resource using an HTTP POST method. The resource of this entry shall be the vital sign observation.

'''Links:'''

* [http://hl7.org/fhir/STU3/http.html#transaction batch]
* [http://hl7.org/fhir/STU3/http.html#create create]

The vital signs data send to the XIS SHALL conform to the matching vital sign profile. The table below lists profiles that represent zibs that can be used for vital sign information exchange. If no matching vital sign zib profile is present, vital sign profiles listed in the [http://hl7.org/fhir/STU3/observation-vitalsigns.html FHIR specification] can be used. Other vital sign concepts are currently out of scope for this use case.

The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable" width="1200px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib name NL||style="width:150px;"|Zib name EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Bloeddruk||BloodPressure||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure}}
|-
| LichaamsGewicht||BodyWeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight}}
|-
| LichaamsLengte||BodyHeight||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight}}
|-
| Lichaamstemperatuur||BodyTemperature||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature}}
|-
| O2Saturatie||oxygenation, saturation, SpO2||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation}}
|-
| Hartfrequentie||HeartRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate}}
|-
| Polsfrequentie||PulseRate||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose}}
|-
|}
{{Sjabloon:Voorbeelden}}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

====Trigger Events====
The XIS completed processing of the send vital signs request message.

====Message Semantics====
The XIS SHALL return a Bundle with type set to batch-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error.

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 - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

Read more:
[http://hl7.org/fhir/STU3/http.html#create create]
[http://hl7.org/fhir/STU3/http.html#transaction batch]

====Expected Actions====
The PHR processes the results according to application-defined rules.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction batch/transaction]

===Operations===
No operations are defined or needed for this transaction.

===Search parameters===
No search parameters are defined or needed for this transaction.

=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 can be found on the [[MedMij:Vprepub/OntwerpZelfmetingen#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR Questionnaire and Questionnaire Response (Vragenlijsten)

2020-07-20T15:38:46Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: Questionnaires {{Sjabloon:VersieInfo|V2019.01|Vragenlijsten}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:vragenlijstenIcoon.png|link=|87px |links||media|Icoon vragenlijsten]]
<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:Vprepub/OntwerpVragenlijsten|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes the exchange of questionnaires and questionnaire responses within MedMij. A questionnaire is an organized collection of questions intended to solicit information from patients, providers or other individuals involved in the healthcare domain. A questionnaire may take the form of a straightforward flat list of questions, but may also be hierarchically organized in groups and sub-groups. Likewise, it can contain a wide range of question types, varying from simple fill-out fields to multiple-choice questions, scales and questions with dependency's to previous answers.

These questionnaires are captured using the FHIR Questionnaire resource, which defines the questions to be asked, their ordering and grouping, instructional text and the constraints on the answers. The results of a Questionnaire are communicated using the QuestionnaireResponse resource. To support the logistics of assigning and answering a questionnaire, a Task resource is used. In this IG, it will be referred to as "QuestionnaireProvisioningTask".

This information standard is inspired by the international [[MedMij:Vprepub/OntwerpVragenlijsten#sdc|Structured Data Capture (SDC)]] implementation guide and tries to follow it where possible. However, the first version of this information standard is more restricted than SDC; specifically, the possibility for a XIS to pre-populate the questionnaire response is omitted in this first version. Also, contrary to most other use cases for MedMij, no specific HCIM models have been identified for prescribing and answering questionnaires.

This IG is a technical representation of the [[MedMij:Vprepub/OntwerpVragenlijsten|functional design]] and follows the principles of the [[MedMij:Vprepub/FHIR_IG|general MedMij FHIR IG]].

=Actors involved=
The table shows the relevant actors, systems and FHIR CapabilityStatements. The CapabilityStatements demonstrate the minimum conformance requirements for the described use cases.

A XIS may choose to host the Questionnaire resource or may refer to an external repository, as long as this Questionnaire doesn't contain any personally identifiable information and this external repository adheres to the [[MedMij:Vprepub/FHIR_IG#Use_case_overarching_principles|overarching principles]] in the MedMij IG.

{| class="wikitable"
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Actors
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | Systems
! colspan="2" style="text-align:left; background-color: #4AB8A7; color: white; font-weight: bold;" | FHIR CapabilityStatements
|-
! 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 environment
| PHR
| Personal health record
* retrieves a QuestionnaireProvisioningTask
* retrieves a Questionnaire
* updates the QuestionnaireProvisioningTask
* sends the QuestionnaireResponse
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/questionnaires-clientcapabilities|CapabilityStatement: Client}}
| FHIR Client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
* provides a QuestionnaireProvisioningTask
* hosts a Questionnaire (optional)*
* receives updates to the QuestionnaireProvisioningTask
* receives the QuestionnaireResponse
| {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/questionnaires-servercapabilities|CapabilityStatement: Server}}
| FHIR Server requirements
|}

=Boundaries and relationships=
The MedMij use case for questionnaires overlaps partially with the uses cases described in the [http://hl7.org/fhir/us/sdc/ Structured Data Capture (SDC) IG]. Therefore, this IG tries to align as close as possible to the SDC IG. However, there are key differences that prevent the verbatim use of the SDC IG:
* The current use case is more restricted.
* The profiles for the MedMij use case reference HCIM based profiles for common resources like Patient, Practitioner, PractitionerRole and Organization.
* The interpretation of <code>mustSupport</code> and the use of <code>isModifier</code> in SDC differs fundamentally from other MedMij IG's and are therefore ignored in this IG.
* The <code>QuestionnaireResponse.author</code> tells who the person is that provided the answers. For the current MedMij use case it is restricted to a patient. The <code>QuestionnaireResponse.subject</code> tells who the answers apply to. For the current MedMij use case it may be a patient, organization, practitioner, medical device or a payer.

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

The order of invocations follows the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/OntwerpVragenlijsten functional design]. At first the questionnaire is assigned to the patient by a QuestionnaireProvisioningTask. The PHR extracts the reference to the Questionnaire resource from the "Questionnaire" slice in <code>Task.input</code> and retrieves it from the XIS or from an external server.

This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. 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/ 'MedMij Afsprakenstelsel'].

===Client searches QuestionnaireProvisioningTask - PHR===
Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR retrieves a QuestionnaireProvisioningTask containing a reference to the questionnaire from the XIS. The Task resource SHALL conform to the [[#FHIR_profiles|vl-QuestionnaireProvisioningTask profile]] and SHALL initially have <code>Task.status</code> set to "requested" (see [[#QuestionnaireProvisioningTask state machine]]). The Questionnaire resource SHALL be referenced using <code>valueReference.reference</code> of the "Questionnaire" slice in <code>Task.input</code>.

GET [base]/Task/?code=<nowiki>http://loinc.org|74468-0</nowiki>&status=requested

If the search operation fails (cannot be executed, not that there are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome (see [http://hl7.org/fhir/STU3/search.html#errors the FHIR documentation on search]).

=Use case: retrieve questionnaire=
==List of invocations==
===Client retrieves the Questionnaire resource - PHR===
Upon retrieving the QuestionnaireProvisioningTask, the PHR retrieves the Questionnaire resource referenced in the QuestionnaireProvisioningTask using a [https://www.hl7.org/fhir/stu3/http.html#read read operation]. This reference may live on the same base as the XIS or may be an external server.

GET ''Task.input:Questionnaire.valueReference.reference''

The Questionnaire resource SHALL conform to the [[#FHIR_profiles|Questionnaire profile]].

If this operation fails (after repeated attempts), the PHR should close the QuestionnaireProvisioningTask with status "failed" (see [[#Updating the QuestionnaireProvisioningTask]]). This closes the QuestionnaireProvisioningTask and ends the workflow (see [[#QuestionnaireProvisioningTask state machine]]).

=Use case: send questionnaire response=

==Client renders questionnaire form - PHR==
The PHR should present the questions defined in the retrieved Questionnaire resource to the user, in accordance with their type, overall structure of the questionnaire, and restrictions on the answers. MedMij defines the following minimal subset of [https://www.hl7.org/fhir/stu3/valueset-item-type.html Questionnaire item types] that a PHR MUST support:
* Group
* Display
* Boolean
* Decimal
* Integer
* Date / dateTime / time
* String / text
* Choice / open-choice, where the possible answers are defined using <code>option</code> elements
* Quantity

The following elements of the <code>Questionnaire.item</code> element MUST be supported:
* <code>Questionnaire.item.enableWhen</code>
* <code>Questionnaire.item.required</code>
* <code>Questionnaire.item.option</code>

In addition, the following extensions MUST be supported:
* [http://hl7.org/fhir/stu3/extension-minvalue.html minValue]
* [http://hl7.org/fhir/stu3/extension-maxvalue.html maxValue]
* [http://hl7.org/fhir/stu3/extension-minlength.html minLength]
* [https://www.hl7.org/fhir/stu3/extension-maxdecimalplaces.html maxDecimalPlaces]
* [https://www.hl7.org/fhir/stu3/extension-questionnaire-unit.html unit]

A PHR MAY support other Questionnaire item types as well. However, if a PHR is unable to process any one part in the Questionnaire, it MUST reject the Questionnaire altogether, see below.

'''Note''': for known questionnaires, a PHR may choose to use hardcoded over generated forms. However:
* A PHR implementing this information standard should always be able to generate a form for the minimal Questionnaire requirements.
* Currently, no coding system exists to identify known questionnaires. Known questionnaires might be recognized by the reference in the QuestionnaireProvisioningTask or by the Questionnaire.url field, which presents the canonical URL for the Questionnaire resource (even if it served elsewhere). Although the URL in the XIS reference or Questionnaire.url MUST be version specific, the PHR MUST check whether the referenced Questionnaire resource matches the one it has hardcoded
===Multiple-choice questions in FHIR===

Unfortunately, the FHIR core documention for the Questionnaire and QuestionnaireResponse resources is somewhat confusing and actually contains an error in the topic of multiple-choice questions. This section is meant to clarify the use of multiple-choice type questions in FHIR STU3.

In FHIR STU3 there are two scenarios for multiple-choice questions: in the first scenario, the answer MUST come from a list of predefined options, while in the second scenario, the user MAY alternatively provide a custom answer. In a Questionnaire resource, to define a multiple-choice question, <code>item.type</code> MUST be set to "choice" for the first scenario, or "open-choice" for the second scenario. The answer options MUST be defined using either:
* The <code>Questionnaire.item.options</code> element, which contains a reference to a ValueSet with the possible answers. '''Note''': support for this mechanism is not required for this information standard.
* Using one or more <code>Questionnaire.item.option</code> elements, with possible answers defined as <code>valueCode</code>. '''Note''': although the Questionnaire resource defines <code>item.option.value[x]</code> as a polymorphic element with multiple types, ''only coding is actually allowed''. In the relevant profile, this element is therefore restricted to the coding type.

Likewise, the QuestionnaireResponse resource should capture the answer using <code>QuestionnaireResponse.item.answer.valueCode</code>:
* If the user selects one of the predefined answers, it should be captured in the answer using the <code>code</code> (and if present, <code>system</code>) elements of the <code>valueCode</code>.
* If the question is of type "open-choice" and the user provides an alternative answer, it should be captured using the <code>display</code> element of the <code>valueCode</code>.

Questionnaire example:
<syntaxhighlight lang="xml">
<item>
<linkId value="example"/>
<text value="Example question"/>
<type value="choice"/>
<option>
<valueCoding>
<code value="EO1"/>
<display value="Example option 1"/>
</valueCoding>
</option>
<option>
<valueCoding>
<code value="EO2"/>
<display value="Example option 2"/>
</valueCoding>
</option>
</item>
</syntaxhighlight>

QuestionnaireResponse example:
<syntaxhighlight lang="xml">
<item>
<linkId value="example"/>
<answer>
<valueCoding>
<code value="EO1"/>
<display value="Example option 1"/>
</valueCoding>
</answer>
</item>
</syntaxhighlight>

==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 update the Task resource at the XIS and send the QuestionnaireResponse resource to the XIS. 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/ 'MedMij Afsprakenstelsel'].

===Client accepts or rejects the Questionnaire===
Upon retrieving the Questionnaire resource, the PHR SHOULD check if it is able to present a form that ''completely'' covers all the questions and structure and subsequently update the QuestionnaireProvisioningTask resource (see [[#Updating the QuestionnaireProvisioningTask]]):
* If the Questionnaire can be processed, Task.status SHALL be set to "accepted".
* If the Questionnaire cannot be processed, Task.status SHALL be set to "rejected". This closes the QuestionnaireProvisioningTask and ends the process (see [[#QuestionnaireProvisioningTask state machine]]).

===Client provides QuestionnaireResponse - PHR===
The answers to the questions in the Questionnaire resource are captured using an instance of the QuestionnaireResponse resource, which SHALL conform to the [[#FHIR_profiles|QuestionnaireResponse profile]]. If the PHR is unable to process the user response or in some other way is unable to create a QuestionnaireResponse resource, it should close the QuestionnaireProvisioningTask with status "failed" (see [[#Updating the QuestionnaireProvisioningTask]]). This closes the QuestionnaireProvisioningTask and ends the process (see [[#QuestionnaireProvisioningTask state machine]]).

Upon completion of the questionnaire by the user, the PHR system uses a [https://www.hl7.org/fhir/stu3/http.html#transaction transaction operation] to simultaneously:
* Send the QuestionnaireResponse resource to the XIS.
* Update the QuestionnaireProvisioningTask at the XIS to set <code>Task.output.valueReference</code> to the QuestionnaireResponse.
* Update the QuestionnaireProvisioningTask at the XIS to set <code>Task.status</code> to "completed".

A FHIR transaction is a POST command to the XIS endpoint:

POST [base]

The body of the POST operation SHALL be a Bundle resource with Bundle.type set to "transaction" that SHALL contain
* The QuestionnaireResponse resource as a <code>create</code> interaction.
* The original Task resource with the required changes in <code>Task.status</code> and <code>Task.output</code> as an <code>update</code> interaction (see [[#Updating the QuestionnaireProvisioningTask]]).

Example:
<syntaxhighlight lang="xml">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction"/>
<entry>
<resource>
<Task>
<id value="ORIGINAL_ID"/>
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/vl-QuestionnaireProvisioningTask"/>
</meta>
<status value="completed"/>
...
<output>
<type>
<text value="QuestionnaireResponse"/>
</type>
<valueReference>
<reference value="urn:uuid:e607a55c-194d-447a-8cc7-7ab90e3660c3"/>
<display value="Response to questionnaire XXX">
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>
<url value="Task/ORIGINAL_ID"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:e607a55c-194d-447a-8cc7-7ab90e3660c3"/>
<resource>
<QuestionnaireResponse>
<meta>
<profile value="http://nictiz.nl/fhir/StructureDefinition/vl-QuestionnaireResponse"/>
</meta>
...
</QuestionnaireResponse>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="QuestionnaireResponse"/>
</request>
</Bundle>
</syntaxhighlight>

If the server is able to process both resources, it SHALL return a HTTP 200 OK status code and SHALL also return a Bundle of type <code>transaction-response</code>, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. If the server is unable to process either of the resources, it SHALL not process any one of them and SHALL return an HTTP 400 or HTTP 500 type response. Also see the FHIR specification on [https://www.hl7.org/fhir/stu3/http.html#transaction-response transaction response].

'''Note''': updating the QuestionnaireResponse is not supported in the use case.

=Tracking the status using the QuestionnaireProvisioningTask=
==Introduction==
Retrieving the questionnaire and sending the answers are two separate use cases, but they are meant to be used back-to-back; the XIS that prescribes the questionnaire ultimately expects a response to it (and a questionnaire response is only sent in response to a prescription, at least in the current version of this information standard). To track the status of the prescription fulfillment, a Task resource at the XIS server is used, which transitions through various stages until completion.

It is the responsibility of the PHR to update the QuestionnaireProvisioningTask at the different stages in the life cycle of the questionnaire, using an update operation (see [[#Updating the QuestionnaireProvisioningTask]]). This implies that the the Task resource should be made accessible by the XIS server for these updates, at least for the expected lifetime of the fullfillment cycle. Additionally, the PHR may perform a [https://www.hl7.org/fhir/stu3/http.html#read read operation] of the Task resource at any time.

It is primarilly the responsibility of the PHR to bring the QuestionnaireProvisioningTask to a closed state. However, it is not guaranteed that the required update operation succeeds. If the PHR is unable to bring the QuestionnaireProvisioningTask to a closed state, the server may eventually close it because of business rules.

==QuestionnaireProvisioningTask state machine==
The Task resource can transition through the following states:
<pre>
/----------------/-------------------\
| | |
requested +--+-> accepted -+---> completed ----+---> X
| | | |
| \-------------\--> failed --------|
| |
\--> rejected -----------------------/
</pre>

Only the transitions shown here are allowed. The server SHOULD reject any update that attempts to perform an illegal transition. See [[#Updating the QuestionnaireProvisioningTask]].

==Updating the QuestionnaireProvisioningTask==
The Task resource at the XIS can be updated by the PHR using the [https://www.hl7.org/fhir/stu3/http.html#update FHIR update operation]. To perform this operation, the modified Task resource should be sent using a PUT operation:

PUT [base]/Task/''ORIGINAL_ID''

Where ORIGINAL_ID is the <code>Task.id</code> from the QuestionnaireProvisioningTask originally received from the XIS.

'''Note''': the Task resource SHOULD be sent completely and without changes, apart from the relevant modifications.

The server may be unable to accept an update the Task resource due to errors or because of business rules (e.g. because of an illegal status transition). In this case, the server SHOULD respond with a 400 type status code, accompanied by an OperationOutcome resource providing additional details (see [https://www.hl7.org/fhir/stu3/http.html#2.21.0.10.1 the FHIR documentation on rejecting updates]).

The PHR should try to recover from this response. If this is not possible, the PHR SHOULD attempt to update the status of the QuestionnaireProvisioningTask on the server to "failed" and stop further processing. If it is not possible to perform this update, the QuestionnaireProvisioningTask effectively remains in a stalled position. The server may eventually close it because of business rules.

=FHIR profiles, interactions, search parameters=

==FHIR profiles==

{{NoteBox|MedMij uses the FHIR packaging mechanism. This allows you to conveniently download examples, profiles and other conformance resources for the current standard and all packages it depends on. For more background information see the [[MedMij:Vprepub/FHIR_IG|the FHIR implementation guide]]. The latest Questionnaires package can be found [https://simplifier.net/nictizstu3-questionnaires/~packages at Simplifier]. It depends on [https://simplifier.net/NictizSTU3-Zib2017/~packages Nictiz package {{VersieInfo|V2019.01|package}}] and [https://simplifier.net/packages/hl7.fhir.uv.sdc/2.0.0 SDC package version 2.0.0].}}

{| class="wikitable" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | Canonical URL
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | FHIR resource
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:50px" | HCIM EN
|-
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
| Patient
| Patient
|-
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
| Practitioner
| rowspan="2" | HealthProfessional
|-
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole}}
| PractitionerRole
|-
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
| Organization
| HealthcareProvider
|-
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer}}
| Coverage
| Payer
|-
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice}}
| DeviceUseStatement
| MedicalDevice
|-
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vl-Questionnaire}}
| Questionnaire
|
|-
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vl-QuestionnaireResponse}}
| QuestionnaireResponse
|
|-
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vl-QuestionnaireProvisioningTask}}
| Task
|
|}

==Interactions==
The following logical interactions are needed for the Questionnaires information standard:
* [http://hl7.org/fhir/STU3/search.html Search] -- Task
* [http://hl7.org/fhir/STU3/http.html#update Update] -- Task
* [http://hl7.org/fhir/STU3/http.html#read Read] -- Questionnaire
* [http://hl7.org/fhir/STU3/http.html#create Create] -- QuestionnaireResponse

==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]

=Release notes=
Release notes can be found on the [[MedMij:Vprepub/OntwerpVragenlijsten#Release_notes| functional design page]].

MedMij:V2020.01/FHIR VitalSigns

2020-07-20T15:38:46Z

Update bot: Copy of V2019.01

MedMij:V2020.01/FHIR Questionnaire and Questionnaire Response (Vragenlijsten)

2020-07-20T15:38:46Z

Update bot: Copy of V2019.01

MedMij:Vprepub-2020.01/FHIR PDFA

2020-07-20T15:38:44Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|V2019.01|PDFA}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:PDF-A_icoon.png|link=|87px |links||PDF/A]]
<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:Vprepub/OntwerpPDFA|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]
MedMij specifies the format [http://www.pdfa.org/publication/pdfa-in-a-nutshell-2-0/ PDF/A] for exchanging unstructured documents containing health information. Forum Standaardisatie is a Dutch governmental organization that aims to stimulate the use of open standards. PDF/A is one of the standards that is recommended by Forum Standaardisatie. More information regarding PDF/A can be found here: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.

To achieve exchange of PDF/A files, MedMij adopts as much as possible from the Mobile access to Health Documents (MHD) profile from Integrating the Healthcare Enterprise (IHE) that defines a RESTful/HTTP interface to an [http://wiki.ihe.net/index.php/Cross-Enterprise_Document_Sharing XDS] environment using HL7 FHIR STU3 resources. The MHD profile is written to be content agnostic and as such is suitable for much more than PDF/A. For this use case, we have limited the scope to PDF/A. The next section summarizes MHD and contains references to IHE MHD specification. The following sections provides an adaptation of the MHD profile to specify exchange of PDF/A documents in a MedMij context.

When implementing PDF/A, a minimum compliance must be assumed. That is, PDF/A-1 and PDF/A-b is also permitted within this. For more information, see the wiki page on this: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions

===IHE MHD specification===
Mobile access to Health Documents (MHD) profile defines a simple HTTP RESTful interface to an XDS like environment, based on HL7 FHIR. It describes four transactions:
# submit submission sets, folders, new documents, and document metadata from the mobile device to a document receiver (Provide Document Bundle),
# find submission sets matching query parameters (Find Document Manifest),
# find document entries containing metadata based on query parameters (Find Document Reference),
# retrieve a copy of a specific document (Retrieve Document).
These transactions leverage the document content and format agnostic metadata concepts from XDS but simplify them for access by constrained environments such as mobile devices, or other resource-constrained systems. The MHD profile does not replace XDS. It can be used to allow mobile devices, or other resource-constrained systems, access to an XDS health information exchange.[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)]

'''Wiki:'''
[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD) Mobile acces to Health Document (MHD)]

'''Document:'''
[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf MHD Supplement] (Rev 2.4 July 24, 2018)

'''Additional Supplement:'''
[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_Appx-Z_Rev1.2_TI_2017-07_21.pdf Appendix Z on HL7 FHIR] (Rev 1.2 July 21, 2017)

=Actors and transactions involved=
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the full MHD specifications.
{| class="wikitable"
! colspan="2" style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | Persons
! colspan="2" style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | Systems
! colspan="2" style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | FHIR Capability Statements
|-
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Name
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Description
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Name
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Description
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Name
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" |Description
|-
| Patient
| The user of a personal healthcare environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|CapabilityStatement: Client}}
| PDFA FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|CapabilityStatement: Server}}
| PDFA FHIR Server requirements
|}
<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.

{| class="wikitable"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | Person
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | System
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | MHD Actors
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | MHD Transactions
|-
| rowspan="6" | Patient
|-
| rowspan="5" | PHR
|-
| rowspan="3" | Document Consumer
| Find Document Manifests [ITI-66]
|-
| Find Document References [ITI-67]
|-
| Retrieve Document [ITI-68]
|-
| Document Source
| Provide Document Bundle [ITI-65]
|-
| rowspan="6" | Healthcare provider
|-
| rowspan="5" | XIS
|-
| rowspan="3" | Document Responder
| Find Document Manifests [ITI-66]
|-
| Find Document References [ITI-67]
|-
| Retrieve Document [ITI-68]
|-
| Document Recipient
| Provide Document Bundle [ITI-65]
|}

=Use case: Find and retrieve existing PDF/A document(s)=

==Introduction==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

{{FHIR-IG-Afsprakenstelsel-Note}}

==Actors and transactions involved==
Table 1 shows the relevant actors, systems and FHIR capability statements in a MedMij context. The capability statements demonstrate the minimum requirements to be conformant to the full MHD specifications.
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! 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 environment.
| PHR
| Personal health record
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-clientcapabilities|CapabilityStatement: Client}}
| PDFA FHIR Client requirements
|-
| Healthcare Provider
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/pdfa-servercapabilities|CapabilityStatement: Server}}
| PDFA FHIR Server requirements
|}
<font size = "1">'''Table 1. Actors, systems and FHIR capability statements'''</font>

Table 2 shows the MHD actors and transactions in perspective of the systems used in a MedMij context.
{| class="wikitable"
! style="font-weight: bold; text-align:left;" | Person
! style="font-weight: bold; text-align:left;" | System
! style="font-weight: bold; text-align:left;" | MHD Actors
! style="font-weight: bold; text-align:left;" | MHD Transactions
|-
| rowspan="5" | Patient
|-
| rowspan="4" | PHR
|-
| rowspan="3" | Document Consumer
| Find Document Manifest
|-
| Find Document Reference
|-
| Retrieve Document
|-
| rowspan="5" | Healthcare provider
|-
| rowspan="4" | XIS
|-
| rowspan="3" | Document Responder
| Find Document Manifest
|-
| Find Document Reference
|-
| Retrieve Document
|}
<font size = "1">'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context'''</font>

===Transactions in scope===

* Find Document Manifests – This transaction is used to issue parameterized queries that result in a list of Document Manifest resources.
* Find Document References – This transaction is used to issue parameterized queries that produce a list of Document Reference resources.
* Retrieve Document – This transaction is used to get documents.

Document Consumer shall implement at least one transaction: Find Document Manifests, Find Document References, or Retrieve Document. Document Responder shall implement all transactions.

===Transactions out of scope===
The MHD profile specifies how to send documents from a Document Source to a Document Receiver using the Provide Document Bundle transaction. However, sending PDF/A documents is currently out of scope for the MedMij context. The 'Afsprakenstelsel' first focuses on pulling data from a XIS to a PHR before considering push transactions. In the future, specifications of sending PDF/A documents from a PHR will be added.

==Find and retrieve existing PDF/A document(s)==

===Find PDF/A or PDF/A collection===
Discovery of PDF/A documents is done with the MHD defined transaction 'Find Document Reference' or 'Find Document Manifest.' The Find Document Reference retrieves FHIR DocumentReference Resources that represents a single reference to document per resource, for example, one PDF/A file. The Find Document Manifest retrieves FHIR DocumentManifest Resources. A DocumentManifest Resource gathers a set of DocumentReference Resources into a single package together with metadata that applies to the collection.

The Document Consumer requests DocumentReference or DocumentManifest Resources, matching a set of criteria, from the Document Responder. The Document Responder returns DocumentReference or DocumentManifest Resources that match the search criteria provided by the Document Consumer.

====Request message====
'''Search'''

The Document Consumer executes an HTTP GET conform to the FHIR [http://hl7.org/fhir/http.html RESTfull] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.

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

Example query to search for DocumentReferences of type Discharge summary with a current status.
<pre>GET http://example.org/fhir/DocumentReference?type=http://loinc.org|18842-5&status=current</pre>

'''Search Parameters'''
The Document Consumer shall include search parameter status. The Document Consumer may supply, and the Document Responder shall be capable of processing, all query parameters listed below. These search parameters are a selection of the defined search parameters by the HL7 FHIR specification (search parameters: [http://hl7.org/fhir/STU3/documentreference.html#search DocumentReference], [http://hl7.org/fhir/STU3/documentmanifest.html#search DocumentManifest]). See also the HL7 FHIR STU3 specification for [http://www.hl7.org/fhir/STU3/search.html searching].
{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DocumentReference
! colspan="3" style="font-weight: bold; text-align:left;" | DocumentManifest
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| indexed
| date
| When this document reference was created
| created
| date
| When this document manifest created
|-
| author (author.given and author.family)
| string
| Who and/or what authored the document
| author (author.given and author.family)
| string
| Who and/or what authored the manifest
|-
| type
| token
| Kind of document (LOINC if possible)
| type
| token
| Kind of document set
|-
| class
| token
| Categorization of document
| source
| uri
| The source system/application/software
|-
| status
| token
| current / superseded
| status
| token
| current / superseded
|-
| setting
| token
| Additional details about where the content was created (e.g. clinical specialty)
|
|
|
|-
| period
| date
| Time of service that is being documented
|
|
|
|-
| facility
| token
| Kind of facility where patient was seen
|
|
|
|-
| event
| token
| Main clinical acts documented
|
|
|
|-
| securitylabel
| token
| Document security-tags
|
|
|
|-
| format
| token
| Format/content rules for the document
|
|
|
|-
| related-id
| token
| Identifier of related objects or events
|
|
|
|}

The PDF/A use cases within MedMij especially use of the search parameters '''indexed''' and '''status''' for DocumentReference and '''created''' and '''status''' for DocumentManifest.

====Response message====
The Document Responder shall process the query to discover the DocumentReference or DocumentManifest entries that match the search parameters given. The Document Responder returns an HTTP Status code appropriate to the processing as well as a Bundle including the matching DocumentReference or DocumentManifest Resources. When the Document Responder needs to report an error or warning, it shall use HTTP error response codes and should include a FHIR [http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] with more details on the failure or warning. If the request message is processed successfully, whether or not any DocumentReference or DocumentManifest Resources are found, the HTTP status code shall be 200.

* The Document Responder shall place into the ''''DocumentReference.content.attachment.url'''' element a full URL that can be used by the Document Consumer to retrieve the document using Retrieve Document transaction.
** The Document Responder shall only include references which are resolved through the Document Responder to maintain control over the authentication and authorization. The Document Responder shall only serve DocumentReference or DocumentManifest resources that contain a reference which the Document Consumer may resolve.
* The Document Responder shall return only PDF/A documents and shall place into the ''''DocumentReference.content.attachment.contentType'''' element the value 'application/pdf'.

'''Example of a response message'''

Example of a Bundle with 11 DocumentReference Resources. Only the first DocumentReference is displayed.

<pre>
<Bundle xmlns="http://hl7.org/fhir">
<id value="c0beb362-efc7-4cb9-b35a-c6cea0742156" />
<meta>
<versionId value="1498fcb4-af9c-404f-b445-e6634619df55" />
<lastUpdated value="2017-10-25T11:25:00.336+00:00" />
</meta>
<type value="searchset" />
<total value="11" />
<link>
<relation value="self" />
<url value="http://vonk.furore.com/DocumentReference?status=current" />
</link>
<entry>
<fullUrl value="http://vonk.furore.com/DocumentReference/c4f22730-bb5a-4f12-b4ef-c7bde0784426" />
<resource>
<DocumentReference xmlns="http://hl7.org/fhir">
<id value="example-pdfa-documentreference2" />
<meta>
<profile value="http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference"/>
</meta>
<contained>
<Practitioner>
<id value="p1"/>
<name>
<family value="Kneder"/>
<given value="B.">
<extension url="http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier">
<valueCode value="IN"/>
</extension>
</given>
</name>
</Practitioner>
</contained>
<masterIdentifier>
<system value="urn:ietf:rfc:3986" />
<value value="urn:oid:1.2.276.0.7230010.3.1.2.1787205428.3024.1522314975.220899" />
</masterIdentifier>
<identifier>
<system value="http://example-xis.org/fhir/NamingSystem/DocumentReferenceID"/>
<value value="963369"/>
</identifier>
<status value="current" />
<type>
<coding>
<system value="http://loinc.org/" />
<code value="34781-5" />
<display value="Infectious disease Consult note" />
</coding>
</type>
<class>
<coding>
<system value="http://loinc.org/" />
<code value="11488-4" />
<display value="Consult Note" />
</coding>
</class>
<subject>
<reference value="Patient/example-pdfa-kwalificatie1" />
</subject>
<indexed value="2017-04-08T15:26:01+01:00" />
<author>
<reference value="#p1" />
</author>
<description value="Infectious disease Consult note" />
<securityLabel>
<coding>
<system value="http://hl7.org/fhir/v3/Confidentiality" />
<code value="V" />
<display value="very restricted" />
</coding>
</securityLabel>
<content>
<attachment>
<contentType value="application/pdf" />
<language value="en" />
<url value="http://example-test-server.org/fhir/Binary/example-pdfa-binary2" />
<title value="Example PDF - Infectious disease Consult note"/>
</attachment>
</content>
</DocumentReference>
</resource>
<search>
<mode value="match" />
</search>
</entry>
.......
</pre>

===Retrieve PDF/A document===
After obtaining the location of the PDF/A document in the DocumentReference.content.attachment.url, the Document Consumer requests the document from the Document Responder. The Document Responder sequentially serves the PDF/A document to the Document Consumer. The context that was established in the initial request shall also apply when retrieving/serving the document contents.

====Request Message====
This message is an HTTP GET request to retrieve the document. See an example below.

<pre>GET http://example:9556/svc/fhir/Binary/1e404af3-077f-4bee-b7a6-a9be97e1ce32</pre>

The Document Consumer may provide an HTTP Accept header, according to the semantics of the HTTP protocols (see RFC2616, Section 14.1). The only MIME type assured to be returned is the
MIME type indicated in the 'DocumentReference.content.attachment.contentType'. Within MedMij this is set to 'application/pdf'. The HTTP If-Unmodified-Since header shall not be included in the GET request

====Response Message====
The Document Responder shall process the request message. The Document Responder returns an HTTP Status code appropriate to the processing as well as the content of the requested PDF/A document in the HTTP message-body.

The document may be placed inside a FHIR [http://hl7.org/fhir/STU3/binary.html Binary] resource if it is useful to handle pure binary content using the same framework as other resources. Binary resources behave slightly differently from all other resources on the RESTful API. Specifically, when a read request is made for the binary resource that doesn't explicitly specify the FHIR content types "application/fhir+xml" or "application/fhir+json", then the content should be returned using the content type stated in the resource. e.g. if the content type in the resource is "application/pdf", then the content should be returned as a PDF directly.[http://hl7.org/fhir/STU3/binary.html#rest]

When the Document Responder needs to report an error or warning, it shall use HTTP error response codes and should include a [http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] with more details on the failure or warning. If the Retrieve Document message is processed successfully the HTTP status code shall be 200.

'''Example of a response message'''
<pre><Binary>
<id value="1e404af3-077f-4bee-b7a6-a9be97e1ce32" />
<meta>
<versionId value="948f3653-c9a3-4831-bae5-f629319c194f" />
<lastUpdated value="2017-09-20T17:55:14.098+00:00" />
</meta>
<contentType value="application/pdf" />
<content value="JVBERi0xLjUNJeLjz9MNCjU1I........"/>
</Binary></pre>

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#search Search]
* [http://hl7.org/fhir/STU3/http.html#read Read]

===Operations===
There are no defined operations for this use case.

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

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#reference reference]
* [http://hl7.org/fhir/STU3/search.html#date date]
* [http://hl7.org/fhir/STU3/search.html#uri uri]

==List of StructureDefinitions==
IHE has defined StructureDefinitions and other Conformance resources applicable to this use case. The FHIR Implementation Guide on the '''[http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]''' lists these StructureDefinitions.

Find and retrieve existing PDF/A document transaction uses the following StructureDefinitions:

* DocumentReference from Query with Minimal Metadata (canonical URL {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference}})
* DocumentManifest (canonical URL {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.DocumentManifest}})

* Optionally: DocumentReference from Query with Comprehensive Metadata (canonical URL: {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Comprehensive.DocumentReference}}). This StructureDefinition has more mandatory field compared to Minimal Metadata and is used for XDS environments.

{{IssueBox|The IHE StructureDefinitions restrict the use of the .created element. This is a known issue and will be addressed in the R4 release of the profiles. This issue (CP-ITI-1100) can be found on the [http://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#FHIR_Implementation_Guide IHE MHD wiki]. Therefore the indexed element is used to capture creation time.}}

Next to the IHE MHD StructureDefinitions, MedMij uses the following HCIM StructureDefinitions for the response message.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|Zib name NL||Zib 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}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| -
| -
| DocumentManifest
| {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.DocumentManifest}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://ihe.net/fhir/StructureDefinition/IHE.MHD.Query.Minimal.DocumentReference}}
|}
{{Sjabloon:Voorbeelden}}

=Use case: Send PDF/A document(s)=

==Introduction==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
This section summarizes the IHE MHD profile to Send PDF/A document(s) in a MedMij context.

{{FHIR-IG-Afsprakenstelsel-Note}}

==Actors==
{| class="wikitable"
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | Person
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | System
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | MHD Actors
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;" | MHD Transactions
|-
| Patient
| PHR
| Document Source
| Provide Document Bundle [ITI-65]
|-
| Healthcare provider
| XIS
| Document Recipient
| Provide Document Bundle [ITI-65]
|}

==Send PDFA==
===PHR: Request message===
When the patient (PHR) wants to send one or more PDF/A documents, it issues a send PDFA request message.

The PHR initiates a FHIR transaction using a create action by sending an HTTP POST request, composed of a FHIR Bundle resource containing one DocumentManifest resource, one or more DocumentReference resources, one or more Binary resources, one Patient resource, and zero or more Practitioner resources to the XIS recipient. References to the FHIR specification for the required transaction and POST requests are given in the [[#Interactions.2C_operations.2C_search_parameters|interactions, operations and search parameters]] section below.

The PHR executes an HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base] {?_format=[mime-type]}
</pre>

'''Read more:'''
* [http://hl7.org/fhir/STU3/http.html#transaction transaction]
* [http://hl7.org/fhir/STU3/http.html#create create]

The resources in the message SHALL be a valid instance of the listed StructureDefinitions below. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

====Example - Bundle structure====
<pre>
<?xml version="1.0" encoding="UTF-8"?>
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction"/>
<entry>
<fullUrl value="urn:uuid:96cf0274-9b2c-4bdc-b4c4-cb46f7a07097"/>
<resource>
<Patient xmlns="http://hl7.org/fhir">

</Patient>
</resource>
<request>
<method value="POST"/>
<url value="Patient"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:278764fb-06b6-4f4f-8cef-4abaa3682111"/>
<resource>
<DocumentManifest xmlns="http://hl7.org/fhir">

</DocumentManifest>
</resource>
<request>
<method value="POST"/>
<url value="DocumentManifest"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:2aa911db-9117-4e4b-97e4-d2f09dd28111"/>
<resource>
<DocumentReference xmlns="http://hl7.org/fhir">

</DocumentReference>
</resource>
<request>
<method value="POST"/>
<url value="DocumentReference"/>
</request>
</entry>
<entry>
<fullUrl value="urn:uuid:6d035264-66ac-4df2-8bf8-d9a9bbf46111"/>
<resource>
<Binary xmlns="http://hl7.org/fhir" >

</Binary>
</resource>
<request>
<method value="POST"/>
<url value="Binary"/>
</request>
</entry>
</Bundle>

</pre>

===XIS: Response message===
The target XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

The target XIS SHALL return a Bundle with type set to transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

====Handling Errors====
When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.

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 - resource could not be parsed or failed basic FHIR validation rules
* 404 Not Found - resource type not supported, or not a FHIR end-point
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

Read more:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction transaction]

==Interactions, operations, search parameters==

===Interactions===
The following logical interactions are needed for this use case:
* [http://hl7.org/fhir/STU3/http.html#create create]
* [http://hl7.org/fhir/STU3/http.html#transaction transaction]

===Operations===
There are no defined operations for this use case.

===Search parameters===
No search parameters are needed for this use case.

==List of StructureDefinitions==

IHE has defined StructureDefinitions applicable to this use case. Although the IHE MHD Profile text (the published PDF) is Normative these conformance resources are labelled as Informative. Not all IHE MHD profiles are implementable as-is for the send use case because of errors that IHE does not intend to resolve in FHIR STU3, but instead, require updating to FHIR R4. MedMij is not ready upgrading to FHIR R4 for just this use case and has implemented the necessary fixes in the IHE FHIR STU3 profiles to support this use case. The IHE MHD profiles 'IHE.MHD.DocumentManifest' and 'IHE.MHD.ProvideDocumentBundle.Minimal' are therefore copied, adjusted for the known issues and released under Nictiz. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}
{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Zib name NL
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|Zib name EN
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|FHIR Resource
!style="background-color: #4AB8A7;; color: white; font-weight: bold; text-align:left; border: 1px solid black;"|URL profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| style="background-color: white;"| Patient
| #Zib Patient|Patient
| style="background-color: white;"| Patient
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
|-
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/Zorgverlener-v3.2(2017NL) Zorgverlener]
| rowspan="2" style="background-color: white;" | [https://zibs.nl/wiki/HealthProfessional-v3.2(2017EN) HealthProfessional]
| style="background-color: white;"| Practitioner
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole}}
|-
| style="background-color: white;"| Zorgaanbieder
| style="background-color: white;"| HealthcareProvider
| style="background-color: white;"| Organization
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| style="background-color: white;"| -
| style="background-color: white;"| -
| style="background-color: white;"| Bundle *
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.ProvideDocumentBundle.Minimal}}
|-
| style="background-color: white;"| -
| style="background-color: white;"| -
| style="background-color: white;"| DocumentManifest *
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest}}
|-
| style="background-color: white;"| -
| style="background-color: white;"| -
| style="background-color: white;"| DocumentReference
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Provide.Minimal.DocumentReference}}
|-
| style="background-color: white;"| -
| style="background-color: white;"| -
| style="background-color: white;"| List
| style="background-color: white;"| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.List}}
|}
'* Adjusted version of IHE MHD profiles by Nictiz.

{{Sjabloon:Voorbeelden}}

=Release notes=
Release notes can be found on the [[MedMij:Vprepub/OntwerpPDFA#Release_notes| functional design page]].

MedMij:Vprepub-2020.01/FHIR MedicationProcess

2020-07-20T15:38:44Z

Update bot: Copy of V2019.01

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Medication Process {{VersieInfo|V2019.01|Medicatieproces}}}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:Medication_Icoon.png|link=|85px|links|Use case Medication|Medication process]]
<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:Vprepub/OntwerpMedicatie|Functional]]
circle 1787 230 212 [[MedMij:Vprepub/FHIR_IG|Tecnical]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub/Ontwerpen |100px|rechts|Functional design|Go to functional design]]

This page describes patient's use cases, in a personal health record (PHR) context, in relation to the information standard [https://www.nictiz.nl/standaardisatie/informatiestandaarden/informatiestandaard-medicatieproces/ Medication Process] (MP). These use cases are based on version 9.x of this standard. Functional specification of these use cases are described in the [[MedMij:Vprepub/Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

The Medication Process information building blocks are adopted by 'Registratie aan de Bron' and converted to Health and Care Information models (HCIM), also called zibs. In order to exchange medication information between systems, FHIR representations of these HCIMs are made and used in the transactions described on this page.

Use cases:
* [[MedMij:Vprepub/FHIR_MedicationProcess#Use_case:_retrieve_medication_overview|Retrieve a medication overview]]
* [[MedMij:Vprepub/FHIR_MedicationProcess#Use_case:_retrieve_medication_information|Retrieve medication information]]
* [[MedMij:Vprepub/FHIR_MedicationProcess#Use_case:_retrieve_Dispense612ToFHIRConversion_from_the_LSP|Retrieve Dispense612ToFHIRConversion]]

=Actors involved=
{| class="wikitable"
! colspan="2" style="text-align:left;" | Persons
! 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]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/medication-clientcapabilities|CapabilityStatement: Client}}
| Medication process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/medication-servercapabilities|CapabilityStatement: Server}}
| Medication process server requirements
|}

=Use case: retrieve medication overview=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve medication overview transaction is used by the PHR to retrieve a medication overview from the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Medication Overview(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve medication overview request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request medication overview from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve medication overview response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves medication overview to the PHR
|}

==Invocations==
===PHR: request message===
This message uses an extended operation on the RESTful API to obtain a medication overview from a XIS. This operation is used because the XIS needs to play an active role in formulating the content of the response.

====Trigger Events====
When the patient (PHR) wants to obtain the current medication overview, it issues a retrieve medication overview request message.

====Message Semantics====
The PHR executes a medication-overview operation with HTTP POST against the XIS's base endpoint as shown below.

<pre>
POST [base]/$medication-overview
</pre>

=====Expected Actions=====
The XIS shall process the operation to find or generate and return the current medication overview.

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing of the operation as well as a Bundle of type 'searchset', containing one List and one Patient resource along with other resources that represent the Medication Overview.

====Trigger Events====
The XIS completed processing of the retrieve medication overview request message.

====Message Semantics====
Based on the medication-overview operation processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not a Medication Overview is found or generated, the HTTP status code shall be 200.

The body of the response message shall be a Bundle resource of type "searchset". The following section will elaborate on the content included.

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/operations.html Operations]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/operationoutcome.html OperationOutcome resource]

=====Message content=====
The outcome of the {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/Medication-Overview|medication-overview operation}} is the body of the medication overview request message. Successful processing of this operation should result in a Bundle recourse, containing one List and one Patient resource as entries along with all the resources that represent the current medication overview. These resources SHALL be referenced from the List resource. The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicatieoverzicht_en_afleidingsregels Medication Process specification]. The functional dataset of the medication overview can be found on [http://decor.nictiz.nl/medicatieproces/mp-html-20170829T141253/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.148-2016-11-08T103441.html decor.nictiz.nl].

<html>
<iframe width="750" frameborder="1" height="400" src=https://www.simplifier.net/embed/render?id=NictizSTU3-Zib2017/Medication-Overview frameborder="0" align="middle"></iframe>
</html>

The content in the response message SHALL be a valid instance of the following profiles. Clicking on the link will open the formal definition on Simplifier.net.

* '''Bundle profile:''' {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/Bundle-MedicationOverview}}
* '''List profile:''' {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/MedicationOverview}}

The Bundle profile represents the structure of the retrieve medication overview response message. The List profile represents the actual medication overview. The List contains the medication overview metadata and references to all resources that constitute the medication overview. These resources are included in the Bundle as entries. The Bundle.total value contains the number of matching HCIMs: MedicationUse, AdministrationAgreement and MedicationAgreement. Other included resources, such as Medication resources, are not included in the total. The returned Bundle has at least one List and one Patient resource.

All returned resources to the PHR, including the Bundle and List, SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance. The resources in the response message SHALL be a valid instance of these profiles. In the table below, the HCIMs that constitute the clinical content of the Medication Overview and their respective profiles are listed.

'''Note''' that the medication building blocks are grouped per 'medication treatment' conform the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling Medication Process specification]. Grouping SHALL be done by use of a 'medication treatment' identifier. This identifier shall be the same across different related medication resources that constitute a medication treatment. The {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Medication-MedicationTreatment|zib-Medication-MedicationTreatment extension}} is added to all medication profiles and can be used for this grouping purpose.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| #HCIM Patient|Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| Medicatiegebruik||MedicationUse||MedicationStatement|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse}}
|-
| Toedieningsafspraak||AdministrationAgreement||MedicationDispense|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement}}
|-
| Medicatieafspraak||MedicationAgreement||MedicationRequest|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement}}
|-
| Product||Product||Medication|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product}}
|-
| GebruiksInstructie||InstructionsForUse||Dosage (datatype)|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse}}
|-
|}

====Expected Actions====
The PHR processes the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources as mentioned in the former section.

==Interactions, operations, search parameters==
===Interactions===
No interactions are needed for the retrieve medication overview transaction.

===Operations===
The retrieve medication overview medication operation is used for this transaction. The formal definition can be found here:
* {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/MedicationOverview|Medication Overview}}

===Search parameters===
The following search parameter type needs to be supported for this transaction.

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]

=Use case: retrieve medication information=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The Retrieve Medication Information transaction is used by the PHR to retrieve medication information from the XIS. The PHR can use this transaction to retrieve the desired information by searching on specific medication building blocks.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Medication Information(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve medication information request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request medication information from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve medication information response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves medication information to the PHR
|}

==Invocations==
===PHR: request message===
This message uses the HTTP GET method parameterized query to obtain medication information from a XIS. Multiple different HTTP GET request messages may be needed to retrieve all medication information.

====Trigger Events====
When the patient (PHR) wants to obtain medication information matching various parameters, it issues a retrieve medication information request message.

====Message Semantics====
The PHR executes an HTTP GET against the XIS's medication FHIR endpoints. These endpoints can be one of the following:
* MedicationRequest
* MedicationDispense
* MedicationStatement

The search interaction is performed by an HTTP GET conform the [http://hl7.org/fhir/STU3/search.html FHIR search specification], as shown below. This URL is configurable by the PHR by configuring the query search parameters and search control parameters to modify the behaviour of the XIS such as response format, or pagination.

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

=====Search on category code=====
To distinguish the medication HCIMs between each other and between general medication resources, a fixed category coding has been added to the medication HCIM profiles (listed below in the Message content section). The fixed category code is solely used for indexing and retrieval of the HCIM building blocks.

=====Including other resources in searchresults=====
The PHR may request that the XIS return resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. This is useful when the PHR is searching on a clinical resource, but for every such resource returned, the client will also need the subject (Patient resource) or prescriber (Practitioner resource) or medication that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. Example search:

<pre>
GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication
</pre>

This search interaction finds all MedicationRequest that represent the HCIM MedicationAgreement and if present includes the referenced Medication resource.

====Query Search Parameters====
The PHR may supply, and the XIS SHALL be capable of processing, all query parameters listed in the table below. The XIS may choose to support additional query parameters beyond the subset listed below. Any additional query parameters supported shall be supported according to the core FHIR specification. Such additional parameters are considered out of scope for this transaction.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | MP9 search parameters
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
! style="font-weight: bold;text-align:left;" | FHIR resource
|-
| Identification
| Search on identifier.
| identifier
| MedicationRequest, MedicationDispense, MedicationStatement
|-
| Type
| Search on type of medication building block (HCIM).
| category '''*''' / '''**'''
| MedicationRequest, MedicationDispense, MedicationStatement
|-
| ProductCode
| Search on medication code.
| code
| MedicationRequest, MedicationDispense, MedicationStatement, Medication
|-
| UsePeriod
| Search on medication use in the past, present or future within the specified time period.
| periodofuse '''**'''
| MedicationDispense, MedicationRequest
|-
| DispensePeriod
| Returns all medication dispenses within the specific period.
| whenhandedover
| MedicationDispense
|-
| MedicationTreatment
| Search on the medication treatment identifier
| medicationtreatment '''**'''
| MedicationRequest, MedicationDispense, MedicationStatement, System Wide
|}

'''*''' The FHIR profiles that represent the medication building blocks contain fixed code values in the ''.category'' elements to allow searching on specific medication building blocks. FHIR resource MedicationDispense does not contain a 'category' search parameter in the FHIR specification. Custom search parameters are provided.

'''**''' The search parameter consists of a custom created FHIR search parameter not represented in the FHIR specification.

=====Custom Search Parameters=====

The following custom search parameters are defined for this use case:

* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-category}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse}} [[#Search_parameters_2|*]]
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-medicationtreatment}}

====Example Searches====

'''Identifier'''
<pre>1. [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448 </pre>
# Retrieves a MedicationRequest resource with the identifier 999922448.

'''Type'''
<pre>1. [base]/MedicationRequest
2. [base]/MedicationRequest?category=http://snomed.info/sct|16076005</pre>
# Retrieves all MedicationRequest resources.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement.

'''ProductCode'''
<pre>1. [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554
2. [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554&_include=MedicationRequest:medication
3. [base]/MedicationRequest?category=http://snomed.info/sct|16076005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554</pre>
# Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication.
# Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication and includes the Medication resource in the search results.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication

'''UsePeriod'''
<pre>1. [base]/MedicationRequest?periodofuse=ge2010-01-01
2. [base]/MedicationDispense?periodofuse=ge2010-01-01&periodofuse=le2011-12-31
3. [base]/MedicationRequest?category=http://snomed.info/sct|16076005&periodofuse=ge2010-01-01</pre>
# Retrieves all MedicationRequest resources that were in effect after 01-01-2010.
# Retrieves all MedicationDispense resources that were in effect within a 2 year period.
# Retrieves all MedicationRequest resources that represent a HCIM MedicationAgreement and were in effect after 01-01-2010.

'''DispensePeriod'''
<pre>1. [base]/MedicationDispense?whenhandedover=ge2010-01-01
2. [base]/MedicationDispense?whenhandedover=ge2010-01-01&whenhandedover=le2011-12-31
3. [base]/MedicationDispense?whenhandedover=ge2010-01-01&category=http://snomed.info/sct|373784005
</pre>
# Retrieves all MedicationDispense resources that were handed over after 01-01-2010.
# Retrieves all MedicationDispense resources that were handed over within a 2 year period.
# Retrieves all MedicationDispense resources that represent a HCIM Dispense and were handed over after 01-01-2010.

'''MedicationTreatment'''
{{NoteBox|1= Known issue: the second example search request on the server's base using the custom search parameter 'medicationtreatment' is not correct en potentially dangerous. Therefore this should not be implemented and used. Future versions of the information standard will not contain this request. It is expected that requests are made on the Resource type (first example) instead of the server base. More information can be found here: https://bits.nictiz.nl/browse/MM-560}}
<pre>1. [base]/MedicationRequest?medicationtreatment=http://example.nl/fhir/NamingSystem/medicationtreatment|1247848
2. [base]/?medicationtreatment=http://example.nl/fhir/NamingSystem/medicationtreatment|1247848 </pre>
# Retrieves all MedicationRequest resources that are part of the medication treatment 1247848.
# Retrieves all MedicationRequest, MedicationDispense, MedicationStatement resources that are part of the the medication treatment 1247848

=====Expected Actions=====
The XIS shall process the query to discover the medication information that match the search parameters given.

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching medication information.

====Trigger Events====
The XIS completed processing of the Retrieve medication information request message.

====Message Semantics====
Based on the query results, the XIS will either return an error or success. When the XIS needs to report an error, it SHALL use HTTP error response codes and SHOULD include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not any medication resources are found, the HTTP status code SHALL be 200.

The response message SHALL be a Bundle resource of type "searchset" containing zero or more FHIR resources as entries. If the XIS is sending warnings, the Bundle resource SHALL also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/search.html#errors Search errors]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR SHALL conform to the medication HCIMs profiles. The table below lists the medication HCIMs and their respective FHIR profiles. The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the ''meta.profile'' element in order to show compliance.

'''Note''' that the medication building blocks are grouped per 'medication treatment' conform the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0.7_Ontwerp_medicatieproces#Medicamenteuze_behandeling Medication Process specification]. Grouping SHALL be done by use of a 'medication treatment' identifier. This identifier shall be the same across different related medication resources that constitute a medication treatment. The {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Medication-MedicationTreatment|zib-Medication-MedicationTreatment extension}} is added to all medication profiles and can be used for this grouping purpose.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| #Zib Patient|Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization}}
|-
| Medicatiegebruik||MedicationUse||MedicationStatement|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse}}
|-
| Toedieningsafspraak||AdministrationAgreement||MedicationDispense|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement}}
|-
| Medicatieafspraak||MedicationAgreement||MedicationRequest|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement}}
|-
| Verstrekking||Dispense||MedicationDispense|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Dispense}}
|-
| Verstrekkingsverzoek||DispenseRequest||MedicationRequest|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DispenseRequest}}
|-
| Product||Product||Medication|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Product}}
|-
| GebruiksInstructie||InstructionsForUse||Dosage (datatype)|| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-InstructionsForUse}}
|-
|}

====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
No operations are defined or needed for this transaction.

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

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

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

The following custom search parameters are defined for this use case:

* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-category}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-medicationtreatment}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse}} *

<nowiki>*</nowiki> This SearchParameter searches on the FHIR DataType Period in the PeriodOfUse extension, which is added to profiles on MedicationRequest and MedicationDispense resources. Clients use date parameter searches as described by the [http://hl7.org/fhir/stu3/search.html#date FHIR specification]. Servers are expected to take the [http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse-Duration MedicationUse-Duration extension] into account when processing a client's search. This means that either a Period.start + Period.end or Period.start + Duration is used to determine the search results. To illustrate the expected behavior: if a Period.start and a Duration is known, but not the Period, the Duration should be added to the Period.start date to calculate the Period.end. The calculated Period.end date is then used to determine the search results.

=Use case: retrieve Dispense612ToFHIRConversion from the LSP=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This use case concerns the retrieval of medication dispenses and related medication information that is exchanged between healthcare providers on the 'Landelijk Schakelpunt' (LSP). Over the LSP, these medication dispenses are exchanged based on the information standard MedicationProces version 6.12 in HL7v3-messaging format. In this use case, the requested information by a PHR is converted to FHIR-resources by the XIS.

==Actors==
{| class="wikitable" "cellpadding="10"
! style="text-align:left;"| '''Transaction group'''
! style="text-align:left;"| '''Transaction'''
! style="text-align:left;"| '''Actor'''
! style="text-align:left;"| '''Role'''
|-
|style="background-color: white;vertical-align:top;" rowspan="2"|Retrieve Dispense612ToFHIRConversion(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve Dispense612ToFHIRConversion request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request Dispense612ToFHIRConversion from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve Dispense612ToFHIRConversion response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves Dispense612ToFHIRConversion to the PHR
|}

==Invocations==
===PHR: request message===
This message uses the HTTP GET method parameterized query to obtain medication information from a XIS.

====Trigger Events====
When the patient (PHR) wants to obtain Medication process Dispense 6.12 information matching various parameters, it issues a retrieve Dispense612ToFHIRConversion request message.

====Message Semantics====
The PHR executes an HTTP GET against the XIS's MedicationDispense FHIR endpoint. This URL is configurable by the PHR by configuring the query search parameters and search control parameters to modify the behaviour of the XIS such as response format, or pagination. The search interaction is performed by an HTTP GET compliant with the [http://hl7.org/fhir/STU3/search.html FHIR search specification] as shown:

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

=====Explicit search on MedicationDispense and AdministrationAgreement=====
To distinguish the medication-related HCIMs between each other and between general medication resources, a fixed category coding has been added to the medication-related HCIM profiles (listed below in the Message content section). The fixed category code is solely used for indexing and retrieval of the HCIM building blocks.

For this use case, HCIMs MedicationDispense and AdministrationAgreement are requested from the XIS. Both HCIMs are represented by a MedicationDispense resource, however, the PHR makes an explicit request by searching on the category code for both HCIM's.

=====Including the Patient, Organization and Medication resources in searchresults=====
The PHR requests the XIS to return resources related to the MedicationDispense resources, namely the Patient, Organization and Medication resources. The _include parameter is used for this purpose. The request URL syntax is shown here:

<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,http://snomed.info/sct|422037009&_include=MedicationDispense:medication&_include=MedicationDispense:patient&_include=MedicationDispense:performer{&[parameters]{&_format=[mime-type]}}
</pre>

This search interaction Retrieves MedicationDispense resources that represent a MedicationDispense or AdministrationAgreement and includes the related Patient, Organization and Medication resources in the result.

====Query Search Parameters====
The PHR may supply, and the XIS SHALL be capable of processing, all query parameters listed in the table below.

{| class="wikitable"
! style="font-weight: bold;text-align:left;" | MP9 search parameters
! style="font-weight: bold;text-align:left;" | Description
! style="font-weight: bold;text-align:left;" | FHIR search parameter
|-
| UsePeriod
| Search on medication use in the past, present or future within the specified time period.
| periodofuse
|-
| DispensePeriod
| Returns all medication dispenses within the specific period, based on the dispense request date.
| requestdate
|}

'''UsePeriod'''
<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,http://snomed.info/sct|422037009&periodofuse=le2011-12-31&periodofuse=ge2010-01-01&_include=MedicationRequest:medication&_include=MedicationDispense:patient&_include=MedicationDispense:performer
</pre>
Retrieves MedicationDispense resources that represent a HCIM MedicationDispense or AdministrationAgreement, were in effect within a 2 year period and includes related Medication, Patient and Organization resources in the result.

'''DispensePeriod'''
<pre>
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005,http://snomed.info/sct|422037009&requestdate=ge2010-01-01&_include=MedicationRequest:medication&_include=MedicationDispense:patient&_include=MedicationDispense:performer
</pre>
Retrieves MedicationDispense resources that represent a HCIM MedicationDispense or AdministrationAgreement, that requested after 01-01-2010 and includes related Medication, Patient and Organization resources in the result.

=====Custom Search Parameters=====
The following custom search parameters are defined for this use case:

* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-category}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse}} [[#Search_parameters_3|*]]
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/MedicationDispense-requestdate}}

===XIS: response message===
The XIS returns a HTTP Status code appropriate to the processing of the request as well as a Bundle of type searchset.

====Trigger Events====
The XIS completed processing of the retrieve medication overview request message.

====Message Semantics====
Based on the retrieve Dispense612ToFHIRConversion request processing results, the XIS will either return an error or success. When the XIS needs to report an error, it shall use HTTP error response codes and shall include a FHIR OperationOutcome resource with more details on the failure. If the request message is processed successfully, whether or not MedicationDispense resources are found or generated, the HTTP status code shall be 200.

The body of the response message shall be a Bundle resource of type "searchset". The following section will elaborate on the content included.

If the XIS is sending warnings, the Bundle resource shall also contain a FHIR OperationOutcome resource that contains those warnings. The FHIR specification describes the relevant sections:
*[http://hl7.org/fhir/STU3/http.html RESTful API framework]
*[http://hl7.org/fhir/STU3/bundle.html Bundle resource]
*[http://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR SHALL conform to the profiles listed in the table below. The resources in the response message SHALL be a valid instance of these profiles. All resources SHALL include their respective profile canonical URL in the ''meta.profile'' element to show compliance.

These profiles are derived from the HCIM profiles. This use case has a very specific and stable underlying dataset. Therefore, the profiles contain many mandatory elements. Within the Medication Process dataset, there is a difference between the concept cardinalities '1..* Required' and '1..* Mandatory'.: The first means the element is required to be present, if the system possesses the information and the latter means the element should always be present. Both are mapped to a mandatory cardinality in the FHIR profiles. If the XIS is not able to provide the required information for a mandatory element, it shall use a [http://hl7.org/fhir/STU3/extension-iso21090-nullflavor.html nullFlavor extension] to indicate that and why the information is not present. The PHR should be able to process nullFlavor extensions and values.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:Vprepub/FHIR_IG}}

{| class="wikitable" width="1400px"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|HCIM name NL||HCIM name EN||FHIR Resource||FHIR Profile url
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patient
| Patient
| Patient
| {{Simplifier| http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Patient}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Organization}}
|-
| Toedieningsafspraak
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-AdministrationAgreement}}
|-
| Verstrekking
| Dispense
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Dispense}}
|-
| Product
| Product
| Medication
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp612-DispenseToFHIRConversion-Product}}
|-
|}

====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain medication information resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve medication information transaction:
* [http://hl7.org/fhir/STU3/http.html#search Search]

===Operations===
No operations are defined or needed for this transaction.

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

Search parameter types:
* [http://hl7.org/fhir/STU3/search.html#token token]
* [http://hl7.org/fhir/STU3/search.html#date date]

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

The following custom search parameters are defined for this use case:

* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-category}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/MedicationDispense-requestdate}}
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/Medications-periodofuse}} *

<nowiki>*</nowiki> This SearchParameter searches on the FHIR DataType Period in the PeriodOfUse extension, which is added to profiles on MedicationRequest and MedicationDispense resources. Clients use date parameter searches as described by the [http://hl7.org/fhir/stu3/search.html#date FHIR specification]. Servers are expected to take the [http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse-Duration MedicationUse-Duration extension] into account when processing a client's search. This means that either a Period.start + Period.end or Period.start + Duration is used to determine the search results. To illustrate the expected behavior: if a Period.start and a Duration is known, but not the Period, the Duration should be added to the Period.start date to calculate the Period.end. The calculated Period.end date is then used to determine the search results.

=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]].

=Examples=

# Medicatieproces has a wiki page that contains [https://informatiestandaarden.nictiz.nl/wiki/mp:V9.0_Voorbeelden_doseringen examples in FHIR and CDA for dosage instructions].
# Every profile or resource on Simplifier has a reference tab. The reference tab shows all references from and to the selected resource. So the listed profiles in these use cases have a reference tab on Simplifier where examples are listed that declare conformance to the specific profile.
# Examples are accessible through the Simplifier project by going to the resources tab of the project. It is possible to filter on examples and underlying FHIR resource. This is clarified with the following URL, which lists all medication examples available in the NictizSTU3-zib2017 project: https://simplifier.net/NictizSTU3-Zib2017/~resources?category=Example&exampletype=MedicationDispense|MedicationStatement|MedicationRequest|Medication&fhirVersion=STU3&sortBy=DisplayName

=Release notes=
Release notes can be found on the [[MedMij:Vprepub/OntwerpMedicatie#Release_notes| functional design page]].

MedMij:V2020.01/FHIR PDFA

2020-07-20T15:38:44Z

Update bot: Copy of V2019.01