informatiestandaarden - Gebruikersbijdragen [nl]

MedMij:V2020.01/BgZ Beschikbaarstellen

2021-11-26T08:16:28Z

Vincent Goris: MM-2488, added expected count of procedures to BgZ addendum

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || Inhoud van Specifieke voorwaarden voor kwalificatie' opnieuw geordend zodat de opbouw overeenkomt met de corresponderende paragrafen in de Kwalificatiescripts voor BgLZ en BgGGZ (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer 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 andere referenties die de informatiestandaard gebruikt.
# 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:

* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* Idealiter ondersteunt de DVZA de gehele BgZ, maar om de DVZA tegemoet te komen, kan de DVZA 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 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 de DVZA alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet de DVZA slagen voor kwalificatie.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* 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 de DVZA 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].
* De DVZA 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.
* Mocht een DVZA alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan de DVZA dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert de DVZA voor die informatiestandaard, maar <u>niet</u> voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.'

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# 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.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

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

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||ALS
|-
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld moeten worden. In totaal zijn dit 6 problemen waarnaar wordt verwezen in sectie 6.1.3, 6.1.6 (deze sectie), 6.1.11, 6.1.15, 6.1.16 en 6.1.17.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat (SNOMED CT: 6012004)
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Vaste Huisarts 1
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie (SNOMED CT: 49581000146104)
|-
|TestCode ||Chloride (LOINC: 2069-3)
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

Let op: er wordt hier één verrichting specifiek beschreven, in BgZ sectie 6.1.16 wordt verwezen naar een Verrichting die ook in het testresultaat wordt verwacht.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht (SNOMED CT: 60159002)
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie (SNOMED CT: 399269003)
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit (SNOMED CT 46866001)
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:Vprepub-2020.01/BgZ Beschikbaarstellen

2021-11-26T08:16:28Z

Vincent Goris: MM-2488, added expected count of procedures to BgZ addendum

MedMij:V2020.01/BgZ Beschikbaarstellen

2021-11-26T08:08:55Z

Vincent Goris: MM-2483, provided clarity on the number of expected resources when it should be greater than 1.

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || Inhoud van Specifieke voorwaarden voor kwalificatie' opnieuw geordend zodat de opbouw overeenkomt met de corresponderende paragrafen in de Kwalificatiescripts voor BgLZ en BgGGZ (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer 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 andere referenties die de informatiestandaard gebruikt.
# 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:

* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* Idealiter ondersteunt de DVZA de gehele BgZ, maar om de DVZA tegemoet te komen, kan de DVZA 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 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 de DVZA alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet de DVZA slagen voor kwalificatie.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* 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 de DVZA 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].
* De DVZA 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.
* Mocht een DVZA alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan de DVZA dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert de DVZA voor die informatiestandaard, maar <u>niet</u> voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.'

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# 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.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

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

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||ALS
|-
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld moeten worden. In totaal zijn dit 6 problemen waarnaar wordt verwezen in sectie 6.1.3, 6.1.6 (deze sectie), 6.1.11, 6.1.15, 6.1.16 en 6.1.17.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat (SNOMED CT: 6012004)
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Vaste Huisarts 1
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie (SNOMED CT: 49581000146104)
|-
|TestCode ||Chloride (LOINC: 2069-3)
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht (SNOMED CT: 60159002)
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie (SNOMED CT: 399269003)
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit (SNOMED CT 46866001)
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:Vprepub-2020.01/BgZ Beschikbaarstellen

2021-11-26T08:08:55Z

Vincent Goris: MM-2483, provided clarity on the number of expected resources when it should be greater than 1.

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || Inhoud van Specifieke voorwaarden voor kwalificatie' opnieuw geordend zodat de opbouw overeenkomt met de corresponderende paragrafen in de Kwalificatiescripts voor BgLZ en BgGGZ (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer 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 andere referenties die de informatiestandaard gebruikt.
# 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:

* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* Idealiter ondersteunt de DVZA de gehele BgZ, maar om de DVZA tegemoet te komen, kan de DVZA 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 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 de DVZA alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet de DVZA slagen voor kwalificatie.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* 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 de DVZA 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].
* De DVZA 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.
* Mocht een DVZA alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan de DVZA dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert de DVZA voor die informatiestandaard, maar <u>niet</u> voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.'

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# 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.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

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

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||ALS
|-
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld moeten worden. In totaal zijn dit 6 problemen waarnaar wordt verwezen in sectie 6.1.3, 6.1.6 (deze sectie), 6.1.11, 6.1.15, 6.1.16 en 6.1.17.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat (SNOMED CT: 6012004)
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Vaste Huisarts 1
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie (SNOMED CT: 49581000146104)
|-
|TestCode ||Chloride (LOINC: 2069-3)
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht (SNOMED CT: 60159002)
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie (SNOMED CT: 399269003)
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit (SNOMED CT 46866001)
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:V2020.01/BgZ Beschikbaarstellen

2021-10-21T08:12:49Z

Vincent Goris: MM-2431 Aanpassing huisarts referentie bij vaccinatie naar bestaande huisarts.

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || Inhoud van Specifieke voorwaarden voor kwalificatie' opnieuw geordend zodat de opbouw overeenkomt met de corresponderende paragrafen in de Kwalificatiescripts voor BgLZ en BgGGZ (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer 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 andere referenties die de informatiestandaard gebruikt.
# 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:

* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* Idealiter ondersteunt de DVZA de gehele BgZ, maar om de DVZA tegemoet te komen, kan de DVZA 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 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 de DVZA alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet de DVZA slagen voor kwalificatie.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* 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 de DVZA 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].
* De DVZA 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.
* Mocht een DVZA alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan de DVZA dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert de DVZA voor die informatiestandaard, maar <u>niet</u> voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.'

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# 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.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

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

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|Aandoening ||ALS
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden. Bijvoorbeeld onder sectie 8. Waarschuwingen.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

Let op: er wordt hier één waarschuwing specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Vaste Huisarts 1
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie
|-
|TestCode ||Chloride
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

MedMij:Vprepub-2020.01/BgZ Beschikbaarstellen

2021-10-21T08:12:49Z

Vincent Goris: MM-2431 Aanpassing huisarts referentie bij vaccinatie naar bestaande huisarts.

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:Basisgegevensset Zorg - kwalificatie - Beschikbaarstellen Basisgegevensset Zorg {{VersieInfo|BgZ}}}}
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =


{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 31-10-2021 || [https://bits.nictiz.nl/browse/MM-2446 MM-2446] || Inhoud van Specifieke voorwaarden voor kwalificatie' opnieuw geordend zodat de opbouw overeenkomt met de corresponderende paragrafen in de Kwalificatiescripts voor BgLZ en BgGGZ (géén toevoegingen).
|-
| 31-08-2021 || [https://bits.nictiz.nl/browse/MM-2294 MM-2294] || Kwalificatiescript omgezet van PDF-formaat naar wiki
|-
| 12-03-2020 || [https://bits.nictiz.nl/browse/MM-672 MM-672] || Terminologie zib en zibs consistent gemaakt
|}

= Doelgroep =
De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel.

De basis is de BgZ op basis van de publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

= Begrippenlijst =
Er zijn geen specifieke begrippen van toepassing.

= Inleiding =
Deze bladzijde bevat de te doorlopen scripts bij kwalificatie voor de systeemrol ‘Beschikbaarstellen BgZ’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

== Algemene voorwaarden voor kwalificatie ==




Een (kandidaat-) deelnemer 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 andere referenties die de informatiestandaard gebruikt.
# 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.
# Deze kwalificatie toetst geen infrastructurele eisen.

== Specifieke voorwaarden voor kwalificatie ==
Zie voor de algemene uitgangspunten bij kwalificatie op de algemene Kwalificatie-pagina de paragraaf [[MedMij:V2020.02/Kwalificatie#Uitgangspunten_voor_kwalificatie|Uitgangspunten voor kwalificatie]]

Voor deze informatiestandaard gelden de volgende specifieke voorwaarden en uitgangspunten:

* De kwalificatie is ingericht aan de hand van BgZ secties en de onderliggende zibs. Kennis van de zibs is een voorwaarde voor kwalificatie. BgZ omvat 18 secties, en 28 onderliggende zibs.
* Idealiter ondersteunt de DVZA de gehele BgZ, maar om de DVZA tegemoet te komen, kan de DVZA 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 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 de DVZA alle ondersteunde delen laten zien. Voor alle ondersteunde delen moet de DVZA slagen voor kwalificatie.
* Voorafgaand aan kwalificatie wordt vastgesteld welke BgZ-gegevens ondersteund worden door XIS.
* BgZ gegevens die in XIS vastgelegd worden, dienen ook ontsloten te worden.
* 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 de DVZA 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].
* De DVZA 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.
* Mocht een DVZA alleen enkele losse secties van de BgZ beschikbaar willen / kunnen stellen, dan kan de DVZA dat doen als daarvoor binnen MedMij een gegevensdienst en informatiestandaard beschikbaar is. Zoals voor labuitslagen bijvoorbeeld. Dan kwalificeert de DVZA voor die informatiestandaard, maar <u>niet</u> voor BgZ. Dit komt overzichtelijkheid ten goede voor persoon en PGO.'

== Op te leveren kwalificatiemateriaal door de leverancier ==

# De berichten worden verstuurd vanuit XIS. Verstuur de inhoudelijke gegevens van de kwalificatiescenario's naar de simulator (FHIR-server).
# Schermafdrukken van de kwalificatiescenario's, zoals aangegeven onder "Uit te voeren stappen". Stuur dit materiaal op in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.]]

== Uit te voeren stappen Beschikbaarstellen ==

Voer – voor ieder scenario – de volgende stappen uit:

# Registreer in XIS de patiëntgegevens voor de testpersonen zoals beschreven in de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]]
# Maak in XIS de Basisgegevensset Zorg voor deze personen aan, gebruik hiervoor de [[MedMij:Vprepub-2020.01/BgZ_Beschikbaarstellen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario’s]].
# Maak schermafdrukken van de in XIS ingevoerde gegevens en plaats deze in het [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20210324.zip|Aanleverformat - Beschikbaarstellen BgZ.'']]
# 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.
# Basisgegevensset Zorg gegevens beschikbaarstellen conform de scenario’s.


{| class="wikitable"
|+
|-
! Doel !! Verwacht resultaat
|-
| Aantonen dat het systeem BgZ beschikbaar kan stellen met gebruik van FHIR berichten || Het systeem genereert technisch correcte berichten
|-
| Aantonen dat het systeem kan omgaan met een uitvraag voor persoon waarvoor -naast patiëntgegevens- geen BgZ gegevens bekend zijn (scenario 1.2) || Het systeem maakt op correcte wijze kenbaar dat er geen gegevens aanwezig zijn voor bewuste persoon
|}

Scenario's (vraag aan XIS van 1 specifieke Zorgaanbieder waarmee verbinding is gemaakt)''
*Scenario 1.1: BgZ van persoon 1, zoals beschreven in addendum 1.
*Scenario 1.2: BgZ van persoon 2, zoals beschreven in addendum 2 (nauwelijks BgZ gegevens aanwezig).

= Aandachtspunten voor inhoudelijke gegevens =
== Persoonsgegevens ==
De Basisgegevensset Zorg sectie Demografie en identificatie bevat algemene gegevens over de persoon zoals naam, adres en woonplaats. In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om XIS te raadplegen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN door XIS geretourneerd worden naar het persoonsdomein. Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het beschikbaar stellende systeem (XIS) deze nodig kan hebben.

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

= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1.1 en 1.2 te vinden.
== Scenario 1.1 ==
Dit betreft persoon 1 zoals hieronder beschreven.
Met scenario 1.1 wordt getoetst of XIS Basisgegevensset Zorg beschikbaar kan stellen met gebruik van FHIR berichten. Hieronder volgen de inhoudelijke gegevens conform de secties en zibs in publicatie van de [https://www.registratieaandebron.nl/pdf/BgZ_specificatie_obv_zibs_2017_v1.1.pdf specificaties BgZ zibs 2017]

===Demografie en identificatie===
{| class="wikitable" width="60%"
!
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;font-weight: bold;;"
|Patiënt.Naamgegevens ||
|-
|Voornamen ||Johan
|-
|Initialen ||J
|-
|Roepnaam ||Johan
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Helleman
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Identificatienummer ||999911120
|-
|Geboortedatum ||25-7-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||
|-
|BurgerlijkeStaat ||Gehuwd
|}

=== Financiële informatie ===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Betaler ||Inhoudelijke gegevens Persoon 1
|-
|BetalerNaam ||XXX_Helleman
|-
|BankNaam ||ING
|-
|Bankcode ||INGBNL2A
|-
|Rekeningnummer ||NL85INGB0001234567
|-
|Verzekering ||
|-
|BeginDatumTijd ||1-1-2018
|-
|EindDatumTijd ||31-1-2019
|-
|Verzekeringssoort ||Basis verzekerd
|-
|IdentificatieNummer ||3332
|-
|OrganisatieNaam ||Menzis Zorgverzekeraar N.V.
|-
|VerzekerdeNummer ||12345678
|-style="background-color: #E3E3E3;;"
|Adresgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|-style="background-color: #E3E3E3;;"
|Contactgegevens ||Zie patiënt/persoonsgegevens BgZ sectie 1
|}

===Behandelrestricties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|BehandelAanwijzing ||Inhoudelijke gegevens Persoon 1
|-
|Geverifieerd ||1
|-
|GeverifieerdBij ||Patiënt
|-
|VerificatieDatum ||9-4-2018
|-
|Behandeling ||Kunstmatige beademing
|-
|BehandelingToegestaan ||Ja, maar met beperkingen
|-
|Beperkingen ||Eerst overleg met echtgenote
|-
|BeginDatum ||9-4-2018
|-
|EindDatum ||
|-
|Toelichting ||
|-
|Wilsverklaring ||
|-
|WilsverklaringType ||Niet reanimeren verklaring
|-
|WilsverklaringDatum ||9-4-2018
|-
|Aandoening ||ALS
|-
|WilsverklaringDocument ||
|-
|Toelichting ||Niet-reanimerenpenning
|-style="background-color: #E3E3E3;;"
|Vertegenwoordiger ||
|-
|Contactpersoon ||Zie contactgegevens contactpersoon BgZ sectie 4
|}

===Contactpersonen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contactpersoon ||Inhoudelijke gegevens Persoon 1
|-
|Voornamen ||Jannie
|-
|Initialen ||J.P.M.
|-
|Roepnaam ||-
|-
|Naamgebruik ||Eigen geslachtsnaam gevolgd door geslachtsnaam partner
|-
|Voorvoegsels ||van
|-
|Achternaam ||Putten
|-
|VoorvoegselsPartner ||-
|-
|AchternaamPartner ||XXX_Helleman
|-
|Straat ||Knolweg
|-
|Huisnummer ||1000
|-
|Huisnummerletter ||-
|-
|Huisnummertoevoeging ||-
|-
|AanduidingBijNummer ||-
|-
|Postcode ||9999XA
|-
|Woonplaats ||Stitswerd
|-
|Gemeente ||-
|-
|Land ||Nederland
|-
|AdditioneleInformatie ||-
|-
|AdresSoort ||Woon-/verblijfadres
|-
|Telefoonnummer ||06-12345678
|-
|TelecomType ||Mobiel telefoonnummer
|-
|EmailAdres ||XXX_Helleman@hotmail.com
|-
|Rol ||Eerste relatie/contactpersoon
|-
|Relatie ||Echtgenote
|}

===Functionele status===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|FunctioneleOfMentaleStatus ||Inhoudelijke gegevens Persoon 1
|-
|StatusNaam ||Zich wassen
|-
|StatusWaarde ||Moeite met wassen
|-
|StatusDatum ||2001
|-
|Toelichting ||-
|-
|MedischHulpmiddel ||-
|}

===Klachten en diagnoses===

Let op: er wordt hier één probleem specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden. Bijvoorbeeld onder sectie 8. Waarschuwingen.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Probleem ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemAnatomischeLocatie ||Pols
|-
|ProbleemLateraliteit ||Rechts
|-
|ProbleemType ||Diagnose
|-
|ProbleemNaam ||Polsfractuur
|-
|ProbleemBeginDatum ||2001
|-
|ProbleemEindDatum ||
|-
|ProbleemStatus ||Niet actueel
|-
|VerificatieStatus ||Onbekend
|-
|Toelichting ||Gevallen op kunstijsbaan.
|}

===Sociale anamnese===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Woonsituatie || Inhoudelijke gegevens Persoon 1
|-
|WoningType ||Eengezinswoning
|-
|Datum ||30-06-2016
|-style="background-color: #FFFF00;font-weight: bold;;"
|DrugsGebruik ||Inhoudelijke gegevens Persoon 1
|-
|StartDatum ||1981
|-
|StopDatum ||1983
|-
|Hoeveelheid ||3x per jaar
|-
|Toelichting ||Op feestjes en in uitgaanscircuit.
|-
|DrugsOfGeneesmiddelSoort ||Amfetamine, speed
|-
|DrugsGebruikStatus ||heeft in het verleden drugs gebruikt
|-
|Toedieningsweg ||nasaal (snuiven)
|-style="background-color: #FFFF00;font-weight: bold;;"
|AlcoholGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|AlcoholGebruikStatus ||Drinkt alcohol
|-
|StartDatum ||1980
|-
|StopDatum ||
|-
|Hoeveelheid ||4 glazen per week
|-style="background-color: #FFFF00;font-weight: bold;;"
|TabakGebruik ||Inhoudelijke gegevens Persoon 1
|-
|Toelichting ||
|-
|SoortTabakGebruik ||Rookt sigaretten
|-
|TabakGebruikStatus ||Ex-roker
|-
|StartDatum ||1980
|-
|StopDatum ||1983
|-
|Hoeveelheid ||2 pakjes per week
|-
|PackYears ||1
|-style="background-color: #FFFF00;font-weight: bold;;"
|Voedingsadvies ||Inhoudelijke gegevens Persoon 1
|-
|DieetType ||Energie verrijkt
|-
|Consistentie ||Dikvloeibaar
|-
|Toelichting ||-
|}

===Waarschuwingen===

Let op: er wordt hier één waarschuwing specifiek beschreven, maar in andere BgZ secties zijn meerdere verwijzingen opgenomen die als ‘FHIR condition resources’ beschikbaar gesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Alert ||Inhoudelijke gegevens Persoon 1
|-
|ProbleemNaam ||-
|-
|AlertNaam ||Drager MRSA
|-
|BeginDatumTijd ||1-6-2010
|-
|AlertType ||Waarschuwing
|}

===Allergieën===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|AllergieIntolerantie ||Inhoudelijke gegevens Persoon 1
|-
|VeroorzakendeStof ||Bijengif
|-
|AllergieCategorie ||Stof of product
|-
|AllergieStatus ||Actief
|-
|BeginDatumTijd ||8-11-2008
|-
|MateVanKritiekZijn ||Ernstig
|-
|LaatsteReactieDatumTijd ||15-11-2009
|-
|Toelichting ||
|-style="background-color: #E3E3E3;;"
|Reactie ||
|-
|Symptoom ||Misselijk en braken
|-
|SpecifiekeStof ||
|-
|ReactieBeschrijving ||
|-
|Ernst ||Ernstig
|-
|WijzeVanBlootstelling ||
|-
|ReactieTijdstip ||
|}

===Medicatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieAfspraak ||Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||875452574
|-
|Afspraakdatum ||14-8-2016, om 16:30
|-
|RedenMedicatieafspraak ||Starten medicamenteuze behandeling
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||15-8-2016
|-
|Duur ||30 dagen
|-
|FarmaceutischProduct ||Metoclopramide zetpil 10mg, PRK 6920
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|Toedieningsweg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold
|Toedieningsafspraak || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||13610554
|-
|ToedieningsafspraakDatumTijd ||1-6-2018, om 12:25
|-
|RedenAfspraak ||
|-
|Geneesmiddel ||PRIMPERAN ZETPIL 20MG, HPK 229709
|-
|Verstrekker ||Apotheek de Gulle Gaper
|-style="background-color: #E3E3E3;;"
|GebruiksInstructie ||
|-
|Omschrijving ||Vanaf 1-6-2018, gedurende 30 dagen, zo nodig 1 maal per dag 1 stuk, rectaal
|-
|ToedieningsWeg ||Rectaal (code 12)
|-
|Doseerinstructie ||Zo nodig 1 maal per dag 1 stuk
|}

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedicatieGebruik2 || Inhoudelijke gegevens Persoon 1
|-
|Identificatie ||123457000000
|-
|Registratiedatum ||16-8-2018
|-
|GebruikIndicator ||Ja
|-
|VolgensAfspraakIndicator ||Ja
|-style="background-color: #E3E3E3;;"
|Gebruiksperiode ||
|-
|Ingangsdatum ||28-6-2018
|-
|Einddatum ||
|-
|GebruiksDuur ||3 weken
|-
|Gebruiksproduct ||Zestril tablet 10mg, HPK 615560
|-
|Voorschrijver ||Huisarts Peter van Pulver, Huisartsenpraktijk Pulver & Partners
|-style="background-color: #E3E3E3;;"
|Gebruiksinstructie ||
|-
|Omschrijving ||1 maal per dag 1 tablet, oraal
|-
|ToedieningsWeg ||Oraal
|-
|Doseerinstructie ||1 maal per dag 1 tablet
|-
|Informatiebron ||Patiënt
|}

===Medische hulpmiddelen===

Let op: er wordt hier één medisch hulpmiddel specifiek beschreven, maar in andere BgZ secties, zoals sectie 15 Verrichtingen, kunnen verwijzingen opgenomen zijn die als ‘FHIR device resources’ beschikbaargesteld worden.

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|MedischeHulpmiddel || Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;;"
|Product ||
|-
|ProductID ||-
|-
|ProductType ||Gehoorapparaat
|-
|ProductOmschrijving ||-
|-
|BeginDatum ||2007
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Presbyacusis
|-
|Toelichting ||Apparaat niet zichtbaar (diep in de gehooringang)
|-
|AnatomischeLocatie ||Oor
|-
|Lateraliteit ||Rechts
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|Zorgaanbieder.Organisatienaam ||Test Medisch Centrum
|}

===Vaccinaties===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Vaccinatie ||Inhoudelijke gegevens Persoon 1
|-
|ProductCode ||Hepatitis A vaccin
|-
|Dosis ||-
|-
|VaccinatieDatum ||5-3-1999
|-
|GewensteDatumHervaccinatie ||-
|-style="background-color: #E3E3E3;;"
|Toediener ||
|-
|Zorgverlener.Achternaam ||Vaste Huisarts 1
|-
|Toelichting ||Bezoek aan Guatemala.
|}

===Vitale functies===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Bloeddruk ||Inhoudelijke gegevens Persoon 1
|-
|Meetmethode ||Niet-invasief
|-
|ManchetType ||Groot
|-
|MeetLocatie ||Linker bovenarm
|-
|DiastolischEindpunt ||-
|-
|SystolischeBloeddruk ||108 mmHg
|-
|DiastolischeBloeddruk ||56 mmHg
|-
|GemiddeldeBloeddruk ||-
|-
|BloeddrukDatumTijd ||7-2-2013 08:53
|-
|Toelichting ||-
|-
|Houding ||Zittende positie
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamsgewicht ||Inhoudelijke gegevens Persoon 1
|-
|GewichtWaarde ||72 kg
|-
|Toelichting ||-
|-
|GewichtDatumTijd ||8-2-2013
|-
|Kleding ||Lichte kleding/ondergoed
|-
|Uitvoerder ||G.Z.M. de Wit
|-style="background-color: #FFFF00;font-weight: bold;;"
|Lichaamslengte ||Inhoudelijke gegevens Persoon 1
|-
|LengteWaarde ||183 cm
|-
|LengteDatumTijd ||8-2-2013 06:43
|-
|Toelichting ||Met schoenen aan
|-
|Positie ||Staande positie
|-
|Uitvoerder ||G.Z.M. de Wit
|}

===Uitslagen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;font-weight: bold;;"
|LaboratoriumUitslag ||Inhoudelijke gegevens Persoon 1
|-
|ResultaatType ||Klinische chemie
|-
|TestCode ||Chloride
|-
|TestDatumTijd ||23-5-2012 12:00
|-
|TestUitslag ||109 mmol/l
|-
|TestUitslagStatus ||Definitief
|-
|ReferentieBovengrens ||108 mmol/l
|-
|ReferentieOndergrens ||99 mmol/l
|-
|InterpretatieVlaggen ||Boven referentie-waarde
|-style="background-color: #E3E3E3;;"
|Monster ||
|-
|Monstermateriaal ||Bloed
|-
|AfnameDatumTijd ||23-5-2012 08:08
|}

===Verrichtingen===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Verrichting ||Inhoudelijke gegevens Persoon 1
|-
|VerrichtingStartDatum ||5-6-2012
|-
|VerrichtingEindDatum ||
|-
|VerrichtingAnatomischeLocatie ||Knie
|-
|VerrichtingLateraliteit ||Links
|-
|VerrichtingType ||Knie - prothese implantatie gewricht
|-
|VerrichtingMethode ||
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Artropathie
|-
|Toelichting ||Beperking bij het bewegen van het gewricht, drukpijn door slijtage van twee compartimenten van de linker knie.
|-style="background-color: #E3E3E3;;"
|MedischHulpmiddel ||
|-
|ProductType ||Orthopedic surgical implants
|-
|ProductID ||(01)05050474530799
(17)160131
(21)1148130801
|-
|Toelichting ||Implantant, Gen 2 Tibia Insert 5/6-9mm
|-
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-style="background-color: #E3E3E3;;"
|Uitvoerder ||
|-
|Specialisme ||Orthopedie
|-style="background-color: #E3E3E3;;"
|Aanvrager ||
|-
|Zorgverlener ||
|}

===Contacten===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Contact ||Inhoudelijke gegevens Persoon 1
|-
|ContactType ||Klinisch
|-
|BeginDatumTijd ||16-8-2012
|-
|EindDatumTijd ||19-8-2012
|-style="background-color: #E3E3E3;;"
|ContactMet ||
|-
|ZorgverlenerNaam ||G.Z.M. de Wit
|-
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||UMCG
|-
|-style="background-color: #E3E3E3;;"
|RedenContact ||
|-
|ProbleemNaam ||Fractuur van onderste extremiteit
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Chirurgische reductie van fractuur
|}

===Zorgplan===
Van de betreffende zib OverdrachtGeplandeZorgActiviteit, volgen hieronder instantiaties met verschillend OrderType.

Bij deze zib moet gebruik gemaakt worden van een opvraging van het geplande type zorg. Zo zal VaccinationRecommendation een opvraging moeten doen van de Vaccination (of meerdere Vaccinations). Dit staat verder toegelicht op het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/FHIR_BGZ_2017 Technisch Ontwerp.]

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|OverdrachtGeplandeZorgActiviteit ||Inhoudelijke gegevens Persoon 1
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Verrichting ||
|-
|OrderStatus ||Order geplaatst
|-
|BeginDatum ||12-3-2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Verrichting ||
|-
|VerrichtingType ||Biopt huid
|-style="background-color: #E3E3E3;;"
|Indicatie ||
|-
|ProbleemNaam ||Naevus wang
|-style="background-color: #E3E3E3;;"
|Locatie ||
|-
|OrganisatieNaam ||Test Medisch Centrum
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Vaccinatie ||
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Vaccinatie ||
|-
|ProductCode ||Hepatitis A vaccin
|-
|Toelichting ||Bezoek aan Guatemala.
|}

{| class="wikitable" width="60%"
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Afspraak ||
|-
|OrderStatus ||In afwachting van uitvoering
|-
|BeginDatum ||12 juli 2022 11:30 uur
|-
|EindDatum ||12 juli 2022 11:40 uur
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Afspraak ||
|-
|ContactType ||Poliklinisch
|-
|ContactOnderwerp ||Fysiotherapie Controle afspraak
|-
|OrganisatieNaam ||Test Medisch Centrum
|-
|OrganisatieLocatie ||West vleugel
|}

{| class="wikitable" width="60%"
!Medisch hulpmiddel !!
|-
|OrderStatus ||Aangevraagd
|-
|BeginDatum ||2022
|-
|EindDatum ||
|-
|OrderOverige ||
|-style="background-color: #E3E3E3;;"
|Medisch hulpmiddel ||
|-
|ProductID
||(01)05050474530799
(17)220131
(21)0123456789
|-
|ProductType
||Gehoorapparaat
|-
|ProductOmschrijving
||-
|-
|BeginDatum ||2022
|}

===Zorgverleners===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Zorgverlener ||Inhoudelijke gegevens Persoon 1
|-
|Achternaam ||Vaste Huisarts 1
|-
|Specialisme ||0100
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Adresgegevens ||
|-
|Straat ||Valkendael
|-
|Huisnummer ||45
|-
|Postcode ||6245HK
|-
|Woonplaats ||Maastricht
|-
|Land ||Nederland
|-
|AdresSoort ||Werkadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Contactgegevens ||
|-
|Telefoonnummer ||+31434073576
|-
|TelecomType ||Vast telefoonnummer
|-
|NummerSoort ||Zakelijk telefoonnummer
|-
|EmailAdres ||huisarts@huisarts.nl
|-
|EmailSoort ||Zakelijk e-mailadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Zorgverlener.Zorgaanbieder ||
|-
|OrganisatieNaam ||Maatschap Vaste Huisarts
|-
|OrganisatieType ||Huisartspraktijk (zelfstandig of groepspraktijk)
|}

== Scenario 1.2 ==
Bij scenario 1.2 gaat het om persoon 2, zoals hieronder beschreven, die in XIS slechts bekend is met personalia.
Met scenario 1.2 wordt getoetst of XIS op correcte wijze kenbaar maakt dat er geen gegevens aanwezig zijn. Er zijn geen nadere inhoudelijke BgZ-gegevens die ingevoerd zijn en beschikbaargesteld kunnen worden.

===Demografie en identificatie===

{| class="wikitable" width="60%"
|-style="background-color: #FFFF00;; font-weight: bold;"
|Patiënt ||Inhoudelijke gegevens Persoon 2
|-
|Voornamen ||Paul
|-
|Initialen ||P
|-
|Roepnaam ||Paul
|-
|Naamgebruik ||Eigen geslachtsnaam
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Geslachtsnaam ||
|-
|Achternaam ||XXX_Mesker
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Adresgegevens ||
|-
|Straat ||Knolweg
|-
|Huisnummer ||1002
|-
|Postcode ||9999ZZ
|-
|Woonplaats ||Stitswerd
|-
|Land ||Nederland
|-
|AdresSoort ||Woon-/verblijfadres
|-style="background-color: #E3E3E3;font-weight: bold;;"
|Patiënt.Contactgegevens ||
|-
|Telefoonnummer ||06-23456789
|-
|TelecomType ||Mobiel telefoonnummer
|-
|Identificatienummer ||999911284
|-
|Geboortedatum ||1-8-1964
|-
|Geslacht ||Man
|-
|MeerlingIndicator ||0
|-
|OverlijdensIndicator ||0
|-style="background-color: #FFFF00;font-weight: bold;;"
|BurgerlijkeStaat ||Inhoudelijke gegevens Persoon 2
|-
|BurgerlijkeStaat ||Geregistreerd partnerschap
|}

FHIR:V1.0 FHIR IG STU3

2021-10-21T08:12:01Z

Vincent Goris: MM-2392 improved section 'use of reference datatype' to include .reference when available.

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. To aid receiving systems that cannot handle the extension, the sending system SHOULD give as much information as possible in the main element. In the case of the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/practitionerrole-reference|nictiz.fhir.nl.stu3.zib2017|title=PractitionerRole reference extension}}, this means that the sending system SHOULD populate the main element with the reference to the Practitioner resource. In most other cases, the sender SHOULD repeat the {{fhir|.display}} used in the extension in the main element.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. A profile is a statement about the rules that this resource was created against. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.
* A receiving system MAY use the stated value of {{fhir|meta.profile}} for validation, documentation or other purposes.
* A receiving system MAY use other profiles than stated in {{fhir|meta.profile}}, e.g. when it has derived, more constrained profiles based on the stated meta.profile. Reasons for additional validation may include protecting the integrity of the receiving system or determination of internal process flow.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHOULD provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}}, {{fhir|.identifier}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

=== When is {{fhir|.identifier}} expected? ===
Systems that use an (internal) stable identifier to track information are encouraged to assign it to the {{fhir|.identifier}} element of FHIR instances when sending the resource, using a custom identifier {{fhir|.system}} (e.g. an URL or OID that is under control of the sending organization). Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir|.system}} should preferably be an OID to accommodate compatibility in transformations from FHIR. Especially for resources that are used in information standards that have a HL7v3 (CDA) component, such as the BgZ, GP data and Medication process.

The presence of this element helps receiving systems with re-identification and deduplication of resources, especially when the sender system does not natively support logical ids.

Specific requirements for the usage of {{fhir|.identifier}} will be dictated on a use case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===
As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in the table below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 401 Unauthorized - authorization is required for the interaction that was attempted (usually emitted by the authorization server)
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure (usually emitted by the resource server)
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=3 |All
| Not authorized, absent or expired access token
|
* HTTP 401 Unauthorized
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
|-
| Invalid authorization, scope of the access token is not sufficient for the request
|
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect, invalid or unsupported
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

==CapabilityStatements==
Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.

==Referring other resources when sending information==
When the client creates/updates a resource on a server, it often needs to reference "secondary" resources which are not the primary focus of the interaction -- e.g. an Observation must indicate its subject using a reference to a Patient resource. The client may refer to existing resources on the server for this, but this is not always possible (for example, the client doesn't know about the existing resource or the server doesn't support the {{fhir|read}} operation for it). In this case, the client needs to send the secondary resources along with the primary resource in a Bundle, and the server should align these new resources with the ones it already has.

A data conflict may arise if these secondary resources carry details that are not of interest within the particular context of the information standard. For example, the client posts an Observation and sends along a Patient resource containing a different telephone number than the one that is on record at the server side. This change in telephone number is not relevant in this particular context, since the interaction is about creating the Observation.

Unless more specific guidance is given by the information standard, the following guidance applies:
* Sending secondary resources SHALL only be done when the information standard specifies that a {{fhir|batch}} or {{fhir|transaction}} operation is to be used.
* If so, the client MAY send a bare-bones instance as the secondary resource containing just minimal information, but this SHOULD include the information necessary for the server to match its own copy. The information standard MAY specify which information is minimally needed for such a secondary resource and MAY also restrict the information that is sent in the secondary resource.
* The client MUST include a {{fhir|Bundle.entry.request}} for each of the resources in the Bundle, including the secondary resources that are only there for referencing purposes<ref>Although {{fhir|Bundle.entry.request}} is not formally required in FHIR STU3, it is made clear in FHIR R4 that the expected behavior actually is to include it.</ref>. {{fhir|.request}} SHOULD be a <code>POST</code> to the appropriate endpoint. As an alternative, <code>PUT</code> MAY be used, but is strongly discouraged; if the client has knowledge on the id of the resource on the server, an absolute URL is strongly preferred.
* If the server can unequivocally de-duplicate this secondary resource (for example, because the patient is already known from the security context or the healthcare provider is recognized by the UZI number), it MAY choose to ignore the differences of this resource or it MAY incorporate them (see the [https://www.hl7.org/fhir/stu3/http.html#transactional-integrity the section on transactional integity] in the FHIR specification). Please note that absence of information should not result in deletion of information on the server, as the client could send a bare-bones instance.
** If a {{fhir|transaction}} operation is used and the server chooses to ignore the differences, it SHOULD do so silently by responding with a 200 OK status code for the corresponding {{fhir|Bundle.entry.response.status}} in the response Bundle.
** If a {{fhir|batch}} operation is used and the server chooses to ignore the differences, it SHOULD do so either silently using the mechanism described above, or explicitly by responding with a 422 Unprocessable Entity status code {{fhir|Bundle.entry.response.status}} to indicate that a business rule prevented the resource from being created (in combination with an OperationOutcome resource).
* The server SHALL rewrite the references in the primary resource to the resource it already has.

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

FHIR:Vprepub-1.0 FHIR IG STU3

2021-10-21T08:12:01Z

Vincent Goris: MM-2392 improved section 'use of reference datatype' to include .reference when available.

MedMij:V2020.01/PDFA Raadplegen

2021-10-21T08:10:00Z

Vincent Goris: MM-2264 Verduidelijking toegevoegd betreffende script 2.3 voor de DVP kwalificatie

__NOINDEX__
{{MedMij:Vprepub-2020.01/Issuebox}}

{{DISPLAYTITLE:PDF/A - kwalificatie - Raadplegen PDF/A {{VersieInfo|PDFA}}}}
__NUMBEREDHEADINGS__
<span class="toclimit-3">__TOC__</span>

= Versiebeheer =

{| class="wikitable"
|+ Versiebeheer
|-
! Datum !! BITS issue !! Omschrijving
|-
| 9-09-2021 ||[https://bits.nictiz.nl/browse/MM-2361 MM-2361]|| Fine tuning: inhoudelijke fine tuning na overgang naar de wiki
|-
| 29-07-2021 ||[https://bits.nictiz.nl/browse/MM-2168 MM-2168]|| Optimalisatie script/addenda PDF/A: Raadplegen, Beschikbaarstellen, Ontvangen en Sturen
|-
| 15-04-2021 || [https://bits.nictiz.nl/browse/MM-2014 MM-2014] || DocumentManifest verder toelichten
|-
| 29-09-2020 || [https://bits.nictiz.nl/browse/MM-1393 MM-1393] || Verbeteren kwalificatiematerialen PDF/A. Verwijderen duplicaten in het addendum
|-
| 01-08-2020 || [https://bits.nictiz.nl/browse/MM-1079 MM-1079] || Opknippen use cases in scripts
|-
| 01-08-2020 || [https://bits.nictiz.nl/browse/MM-1119 MM-1119] || Herleidbaarheid gegevens
|-
| 03-02-2020 || || Volgorde scenario aangepast en T-waarde in addenda toegevoegd
|-
| 23-10-2019 || || Verduidelijking en harmonisering van opmaak en tekst (géén inhoudelijke wijzigingen).
|}

= Doelgroep =
De doelgroep van dit document is de PGO leverancier, die wil kwalificeren op de systeemrol 'Raadplegen PDF/A' binnen het MedMij afsprakenstelsel.

= Begrippenlijst =

{| class="wikitable"
|+
|-
! Begrip !! Toelichting
|-
| PDF/A Document || Het daadwerkelijke PDF/A document dat wordt beschikbaargesteld door de DVZA, opgehaald (‘retrieved’) door de PGO en geraadpleegd door de patiënt. Bijvoorbeeld: een verwijsbrief
|-
| DocumentReferentie (Metadata) || De metadata van het PDF/A document, hierin is informatie te vinden over bijvoorbeeld de auteur, de datum en type van het PDF/A document.
|-
| DocumentManifest (Metadata) || Dit kan beschouwd worden als een overkoepelende map met metadata om de DocumentReferentie(s) heen en kan worden gebruikt om de samenhang aan te geven.

|-
| Binary Resource || Manier 1 waarop een PDF/A document kan worden beschikbaargesteld/geraadpleegd: het PDF/A document is opgeslagen in het bronsysteem van de zorgaanbieder als één lange code, en deze code wordt bij het raadplegen door de patiënt omgezet in een PDF/A document.
|-
| Andere locatie || Manier 2 waarop een PDF/A document kan worden beschikbaargesteld/geraadpleegd: het PDF/A document wordt van een andere locatie dan een binary resource gehaald. Bijvoorbeeld: een link naar het internet
|}

= Inleiding =
Dit document bevat de te doorlopen scripts bij kwalificatie voor de systeemrollen ‘Raadplegen PDF/A metadata lijst bij zorgaanbieder’ en ‘Raadplegen PDF/A document bij zorgaanbieder’ binnen het MedMij afsprakenstelsel.
De kwalificatie wordt door de kwalificator getoetst met behulp van de Nictiz kwalificatiesimulator, die is ingericht op een FHIR server. De kwalificatiesimulator kan berichten verzenden en ontvangen.

Deze kwalificatiescripts zijn opgesteld ten behoeve van MedMij. Bij het opstellen van de scripts is uitgegaan van
het Functioneel Ontwerp PDF/A waarvan de actuele versie via de Ontwerpen MedMij [[MedMij:V2020.01/Ontwerpen|Ontwerpen MedMij]] te bereiken is. De op te
vragen onderdelen die in het functioneel ontwerp besloten liggen zijn waar mogelijk gekoppeld aan
zorginformatiebouwstenen.

== 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 MedMij informatiestandaard PDF/A, zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardelijsten en andere referenties die de informatiestandaard gebruikt.
# Kennis en begrip, en het naleven van de aandachtspunten zoals beschreven op deze bladzijde.
# 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 gemaakt worden voor de eindgebruiker. De leverancier levert voor deze informatie schermafdrukken op ten behoeve van controle.
# Het testen van infrastructurele eisen maakt geen onderdeel uit van deze kwalificatie.

== Specifieke voorwaarden voor kwalificatie ==
Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:
# Kennis en begrip van het IHE MDH profiel zoals al verwezen vanuit de MedMij informatiestandaard PDF/A.

== Op te leveren kwalificatiemateriaal door de leverancier ==
# Schermafdrukken van de verschillende kwalificatiestappen zoals beschreven bij de "Uit te voeren stappen"
# De kwalificator op de FHIR-server vangt de berichten af die verstuurd zijn vanaf de PGO.

== Uit te voeren stappen Raadplegen ==
De volgende stappen dienen te worden uitgevoerd, voor de verschillende scenario’s:

{{NoteBox|LET OP: Het is aan te raden om de scenario’s in volgorde af te handelen, dus eerst raadplegen en dan pas sturen. Op deze manier zorg je ervoor dat testdata niet vervuild raakt.}}

# Registreer in de PGO de patiëntgegevens voor de testpersonen zoals opgenomen in de [[MedMij:Vprepub-2020.01/PDFA_Raadplegen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario's]]
# Raadpleeg de PDF/A Documentoverzicht gegevens door middel van verschillende parameters (bijvoorbeeld voor een bepaalde persoon voor een bepaalde periode), zoals beschreven in de scenario’s 1.1, 1.2, 2.1 & 2.2(waarbij 2.1& 2.2 optioneel zijn).
# Raadpleeg het PDF/A document door middel van de verkregen referentie in het PDF/A metadata gegevens retourbericht, zoals beschreven in de scenario’s 1.3 & 2.3 (waarbij 2.3 optioneel is).
# De kwalificatiesimulator (FHIR server) zal de PDF/A documentoverzicht gegevens en het PDF/A document beschikbaarstellen. Deze gegevens komen overeen met de [[MedMij:Vprepub-2020.01/PDFA_Raadplegen#Inhoudelijke_gegevens_scenario.E2.80.99s|Inhoudelijke gegevens scenario's]]
# Ontvang en verwerk de PDF/A Documentoverzicht gegevens en het PDF/A document in het systeem.
# Maak schermafdrukken van de wijze waarop de PGO het PDF/A documentoverzicht gegevens toont aan de PGO gebruiker, en leg deze vast in [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/Kwalificatie#PDF.2FA_3.0 Aanleverformat PDF/A raadplegen]. De PGO dient de PDF/A metadata gegevens te tonen die de gebruiker in staat stelt het onderliggende document te beoordelen op relevantie. Denk hierbij aan de belangrijkste metadata velden, zoals: naam, categorie en type van het PDF/A document. Daarnaast zal de PGOgebruiker een link naar het betreffende PDF/A document moeten zien.
# Maak schermafdrukken van de wijze waarop de PGO het PDF/A document toont aan de PGO gebruiker, en leg deze vast in het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/Kwalificatie#PDF.2FA_3.0 Aanleverformat PDF/A raadplegen].
# De PGO kan zich kwalificeren door ondersteuning van het raadplegen van DocumentReference (scenario 1.1, 1.2) en daarnaast optioneel DocumentManifest (scenario 2.1 & 2.2) resources te ondersteunen.

{| class="wikitable"
|+
|-
! Nr. !! Scenario !! testbeschrijving !! Doel !! Verwacht technisch resultaat !! Verwacht functioneel resultaat
|-
| 1.1 || Persoon 1 haalt alle DocumentReferenties op die de status ‘current’ hebben en raadpleegt deze || Test of alle metadata van DocumentReferenties van persoon 1 met een ‘current’ status kunnen worden opgevraagd || Aantonen dat een PGO DocumentReferenties kan ophalen en tonen || DocumentReferentie 1, 2 en 3 || Persoonsgegevens van persoon 1 DocumentReferentie 1, 2 en 3: schermprints van metadata van de DocumentReferenties
|-
| 1.2|| Persoon 1 haalt alle DocumentReferenties op die de status ‘current’ hebben én uit de volgende periode komen: [T-730] t/m [T-365], en raadpleegt ze || Test of er geen metadata van DocumentReferenties, die buiten de gedefinieerde periode van persoon 1 vallen, worden getoond|| Aantonen dat een PGO kan omgaan met een bericht waarin geen DocumentReferentie is opgenomen|| Geen DocumentReferenties || Geen DocumentReferenties, maar een melding die aangeeft dat er geen gegevens beschikbaar zijn
|-
| 1.3|| Persoon 1 klikt op de twee PDF/A documenten uit de zojuist opgehaalde DocumentReferenties van scenario 1.1 en raadpleegt ze || Test of een PGO een binary document kan tonen || 1. Aantonen dat een PGO een PDF/A document, opgehaald via een DocumentReferentie, kan tonen.
2. Aantonen dat een PGO kan omgaan met een bericht waarin een PDF/A document wordt opgehaald via een binary resource.
||PDF/A documenten van DocumentReferentie 1 en 2 || PDF/A documenten van DocumentReferentie 1 en 2: schermprints van inhoud van de documenten
|-
| 1.4|| Persoon 1 klikt op het PDF/A document in DocumentReferentie 3 (uit scenario 1.1), echter is raadplegen niet mogelijk vanwege een foutieve link naar de locatie van het document || Test of een PGO een document op basis van een link kan tonen|| Aantonen dat een PGO kan omgaan met een foutieve link naar het PDF/A document|| Geen PDF/A document || Geen PDF/A document, maar een melding die aangeeft dat er geen gegevens beschikbaar zijn
|-
| 1.5<sup>1</sup>|| Persoon 1 controleert wat de bron is van DocumentReferentie 1 ||Test of de bron waarvan de documenten zijn opgehaald kunnen worden getoond || Aantonen dat een PGO de herleidbaarheid van documenten kan aantonen || || Een overzicht met de herleidbaarheid
|-
| 2.1<sup>2</sup> || Persoon 2 zoekt alle DocumentManifests op die de status ‘current’ hebben en raadpleegt ze ||Test of er geen metadata van Documentmanifest resources, die buiten door de gedefinieerde status van persoon 2 vallen, worden getoond || Aantonen dat een PGO DocumentManifests kan ophalen en tonen || DocumentManifest 1 en 3 || Persoonsgegevens van persoon 2 DocumentManifest 1 en 3: schermprint van metadata van de DocumentManifests
|-
| 2.2<sup>2</sup> || Persoon 2 klikt op de DocumentReferentie uit het zojuist opgehaalde DocumentManifest (1) en raadpleegt deze || Test of alle metadata van een DocumentReferentie van persoon 2 kunnen worden opgevraagd||Aantonen dat een PGO een DocumentReferentie, opgehaald via een DocumentManifest, kan tonen.|| DocumentReferentie 4|| DocumentReferentie 4: schermprints van metadata van de DocumentReferentie
|-
| 2.3<sup>1</sup>&<sup>3</sup>&<sup>4</sup>|| Persoon 2 klikt op het PDF/A document uit de zojuist bekeken DocumentReferentie (4) en raadpleegt deze.|| Test of een PGO een document op basis van een link kan tonen||1. Aantonen dat een PGO een PDF/A document, opgehaald via een DocumentReferentie, kan tonen.
2. Aantonen dat een PGO kan omgaan met een bericht waarin een PDF/A document wordt opgehaald via een andere locatie.
|| PDF/A document van DocumentReferentie 4 || PDF/A document van DocumentReferentie 4: schermprint van inhoud van het document
|}
<sup>1</sup> Dit scenario gaat buiten touchstone om.<br/>
<sup>2</sup> Dit scenario is optioneel, voor zowel de standaard als kwalificatie.<br/>
<sup>3</sup> Dit scenario is optioneel om te kwalificeren, maar niet voor de informatiestandaard. Een PGO dient beide manieren om een PDF/A document te ontsluiten te ondersteunen.<br/>
<sup>4</sup> In dit scenario dient DocumentReferentie 4 te worden gebruikt voor het ophalen van een willekeurige PDF/A op een andere locatie dan van een Binary endpoint. De verwijzing gaat momenteel naar een PDF/A-document buiten het oorspronkelijke domein en is daarmee niet conform de MedMij-eisen. Door technische beperkingen van Touchstone is het niet mogelijk om deze functionaliteit op een andere manier te testen.

= Aandachtspunten voor inhoudelijke gegevens =
Deze kwalificatie is bedoeld om te controleren of het systeem (PGO) succesvol een PDF/A bij een zorgaanbieder (XIS) kan raadplegen en tonen. Dit gaat door middel van twee transacties, namelijk: eerst
door ‘raadplegen PDF/A Documentoverzicht’ gevolgd door ‘raadplegen PDF/A’. Oftewel Het systeem van de patiënt (PGO) vraagt om beschikbare medische gegevens bij een XIS aan de hand van een zoekopdracht; en daarna gebruikt de patiënt de persoonlijke gezondheidsomgeving om de gewenste PDF/A te raadplegen of te downloaden. In deze volgorde zijn er voor twee testpersonen scenario’s beschreven ten behoeve van kwalificatie. De persoon is ingelogd in de PGO en wil gegevens raadplegen. Daarvoor moet de PGO eerst verbinding maken met een zorginformatiesysteem (XIS). In dit kwalificatiescript gaan we ervanuit dat de verbinding reeds succesvol
is gemaakt. Daarnaast is het uitgangspunt dat 1 bronsysteem (XIS) bevraagd wordt.

== Persoonsgegevens ==
Het onderdeel Persoonsgegevens bevat algemene gegevens over de persoon zoals naam, adres en woonplaats.
In het MedMij afsprakenstelsel is vastgelegd dat de BSN door de PGO niet gebruikt mag worden om te PGO te bevragen, aangezien de PGO in het persoonsdomein valt en buiten het zorgaanbiedersdomein. Evenmin mag een BSN geretourneerd worden naar het persoonsdomein.

Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het Raadplegende systeem (PGO) deze nodig kan hebben.

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

== Specifieke gegevens ==
=== Document PDF/A ===


Het sturen van PDF/A documenten vanuit een XIS naar een PGO bestaat uit drie onderdelen die als Bundle worden aangeboden. Deze onderdelen zijn Documentmanifest, DocumentReferentie en DocumentInhoud. Elk van deze onderdelen kent de volgende specifieke metadata.
* DocumentManifest: onderwerp (omschrijving van inhoud set), datum (aanmaakdatum van de set), auteur (auteur van set, meestal PGO-gebruiker), ontvanger (zorgverlener of zorgaanbieder, gebruiker van PGO)
* Documentoverzicht Referentie: onderwerp (omschrijving van document), datum (meestal aanmaakdatum van document), auteur (meestal auteur van document)
* DocumentInhoud: ContentType

=== Gegevens PDF/A documenten ===
Het onderdeel PDF/A gegevens bevat de gegevens van de PDF/A, zoals datum, auteur, ontvanger. Deze betreffen het verwachte resultaat van de opvraag
= Inhoudelijke gegevens scenario’s =
In dit hoofdstuk zijn de addenda van scenario 1 en 2 te vinden.

== Scenario 1.1-1.5: persoon 1 wil documenten raadplegen ==
Scenario 1 heeft betrekking op persoon 1. Deze patiënt probeert zijn/haar PDF/A documenten, die door het bronsysteem van de zorgaanbieder beschikbaar zijn gesteld, op verschillende wijzen te raadplegen in een PGO.
Om dit de toetsen zijn de volgende gegevens nodig:
* Persoonsgegevens van persoon 1
* Gegevens van drie zorgverleners
* Drie documentReferenties
* De drie documenten zelf

=== Persoongegevens ===
{| class="wikitable" style="width: 30%;"
! colspan='2'|Persoon 1
|-
|style="width: 50%;"|Achternaam ||XXX_Baltus
|-
|Voornaam ||Ellen
|-
|Voorletter(s) ||E
|-
|Geslacht ||Vrouw
|-
|Adresgegevens ||Piet Heinkade 1001, 9999XA, Stitswerd
|-
|Geboortedatum ||02-08-1974
|}

=== Zorgverleners ===
{| class="wikitable" style="width: 30%;"
! colspan='2'|Zorgverlener 1
|-
|style="width: 50%;"|Achternaam ||Snijder
|-
|Voorletter(s) ||A.F.
|}

{| class="wikitable" style="width: 30%;"
! colspan='2'|Zorgverlener 2
|-
|style="width: 50%;"|Achternaam ||Kneder
|-
|Voorletter(s) ||B.
|}

{| class="wikitable" style="width: 30%;"
! colspan='2'|Zorgverlener 3
|-
|style="width: 50%;"|Achternaam ||Kiek
|-
|Voorletter(s) ||F.
|}

=== Documentreferentie ===
{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentReferentie 1
|-
|style="width: 15%;"|MasterIdentifier ||
|-
|Status ||Current
|-
|Type ||Neurological surgery Discharge summary
|-
|Class ||Discharge summary
|-
|Subject ||XXX_ Baltus
|-
|Indexed/Created ||T – 355
|-
|Author ||Zorgverlener 1, zie tabel zorgverlener.
|-
|Title ||Anterior Cervical Discectomy Fusion - Discharge Summary
|-
|ContentType ||Application/pdf
|-
|Language ||English
|-
|Location PDFA ||Verwijzing naar daadwerkelijke PDFA in een Binary resource (PDF/A Document 1)
|-
|Security label || very restricted.
|}

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentReferentie 2
|-
|style="width: 15%;"|Masteridentifier ||
|-
|Status ||Current
|-
|Type ||Infectious disease Consult note
|-
|Class ||Example PDF - Infectious disease Consult
|-
|Subject ||XXX_ Baltus
|-
|Indexed/Created ||T – 60
|-
|Author ||Zorgverlener 1, zie tabel zorgverlener.
|-
|Title ||Consult Note
|-
|ContentType ||Application/pdf
|-
|Language ||English
|-
|Location PDFA ||Verwijzing naar daadwerkelijke PDFA in een Binary resource (PDF/A Document 2)
|-
|Security label ||Very restricted
|}

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentReferentie 3
|-
|style="width: 15%;"|Masteridentifier ||
|-
|Status ||Current
|-
|Type ||Neurology Consult note
|-
|Class ||Consult Note
|-
|Subject ||XXX_ Baltus
|-
|Indexed/Created ||T – 355
|-
|Author ||Zorgverlener 3, zie tabel zorgverlener.
|-
|Title ||Example PDF - Neurology Consult note
|-
|ContentType ||Application/pdf
|-
|Language || English
|-
|Location PDFA ||Verwijzing naar daadwerkelijke PDFA in een Binary resource (PDF/A Document 2)
|-
|Security label ||Very restriced
|}

=== Documenten ===
{| class="wikitable" style="width: 30%;"
! colspan='2'|Document 1
|-
|style="width: 30%;"|Document/inhoud ||Document 1 - Infectious disease Consult note.pdf
|}

{| class="wikitable" style="width: 30%;"
! colspan='2'|Document 2
|-
|style="width: 30%;"|Document/inhoud ||Document 2 - Neurology Consult note.pdf
|}

{| class="wikitable" style="width: 30%;"
! colspan='2'|Document 3
|-
|style="width: 30%;"|Document/inhoud ||Document 3 - Document 3 – Verwijsbrief Arts.pdf
|}

== Scenario 2.1-2.3: persoon 2 wil documenten in een documentManifest raadplegen ==
Scenario 2 heeft betrekking op persoon 2. Deze persoon probeert zijn/haar PDF/A documenten, die door het bronsysteem van de zorgaanbieder beschikbaar zijn gesteld, te raadplegen in een PGO. Deze documenten zijn opgeslagen in een documentManifest. Om dit de toetsen zijn de volgende gegevens nodig:
* Persoonsgegevens van persoon 2
* Drie documentManifests
* Gegevens van twee zorgverleners
* Twee DocumentReferenties
* De documenten zelf

=== Persoongegevens ===
{| class="wikitable" style="width: 30%;"
! colspan='2'|Persoon 2
|-
|style="width: 50%;"|Achternaam ||XXX_Schulte
|-
|Voornaam ||Eva
|-
|Voorletter(s) ||E
|-
|Geslacht ||Vrouw
|-
|Adresgegevens ||Knolweg 1001, 9999XA, Stitswerd
|-
|Geboortedatum ||02-08-1964
|}

=== Zorgverleners ===
{| class="wikitable" style="width: 30%;"
! colspan='2'|Zorgverlener 1
|-
|style="width: 50%;"|Achternaam ||Snijder
|-
|Voorletter(s) ||A.F.
|}

{| class="wikitable" style="width: 30%;"
! colspan='2'|Zorgverlener 2
|-
|style="width: 50%;"|Achternaam ||Kneder
|-
|Voorletter(s) ||B.
|}

=== Documentreferentie ===

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentReferentie 4
|-
|style="width: 15%;"|Masteridentifier ||
|-
|Status ||Current
|-
|Type ||Allergy and immunology Discharge summary
|-
|Class ||Discharge summary
|-
|Subject ||XXX_Schulte
|-
|Indexed/Created ||T – 320
|-
|Author ||Zorgverlener 1, zie tabel zorgverlener.
|-
|Title ||Example PDF not in Binary
|-
|ContentType ||Application/pdf
|-
|Language ||English
|-
|Location ||Verwijzing naar een willekeurige PDFA anders dan in een Binary resource
|-
|Security label || Very restricted
|}

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentReferentie 5
|-
|style="width: 15%;"|Masteridentifier ||
|-
|Status || Entered-in-error
|-
|Type ||Allergy and immunology Discharge summary
|-
|Class ||Discharge summary
|-
|Subject ||XXX_Schulte
|-
|Indexed/Created ||T – 320
|-
|Author ||Zorgverlener 1, zie tabel zorgverlener.

|-
|ContentType ||Application/pdf
|-
|Language ||English
|-
|Location PDFA ||Verwijzing naar een willekeurige PDFA anders dan in een Binary resource
|-
|Title ||Example PDF not in Binary.
|-
|Security label || Very restricted
|}

=== Documenten ===

=== DocumentManifests ===
{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentManifest 1
|-
|style="width: 15%;"|MasterIdentifier ||
|-
|Status || Current
|-
|Type || Discharge summary
|-
| Subject || XXX_Schulte
|-
| Created || T – 360
|-
| Author || Zorgverlener 2, zie tabel zorgverlener.
|-
| Source || <nowiki>http://example-pgo.org/example </nowiki>
|-
| Content1 || Verwijzing naar DocumentReferentie 4 (zie hierboven)
|}

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentManifest 2
|-
|style="width: 15%;"|MasterIdentifier ||
|-
|Status || Entered in Error
|-
|Type || Discharge summary
|-
| Subject || XXX_Schulte
|-
| Created || T – 360
|-
| Author || Zorgverlener 2, zie tabel zorgverlener.
|-
| Source || <nowiki>http://example-pgo.org/example </nowiki>
|-
| Content1 || Verwijzing naar DocumentReferentie 4 (zie hierboven)
|-
| Content2 || Verwijzing naar DocumentReferentie 5 (zie hierboven)
|}

Note: In werkelijkheid zou dit hoogstwaarschijnlijk een history versie zijn van DocumentManifest 1 met dezelfde identifiers en id. Voor testdoeleinden wordt dit ingevoerd als losstaande resource instantie, die grofweg dezelfde informatie bevat als DocumentSet 1.

{| class="wikitable" style="width: 50%;"
! colspan='2'|DocumentManifest 3
|-
|style="width: 15%;"|MasterIdentifier ||
|-
|Status || Current
|-
|Type || Radiology Consult note
|-
| Subject || XXX_Schulte
|-
| Created || T – 30
|-
| Author || Zorgverlener 2, zie tabel zorgverlener.
|-
| Source || <nowiki>http://example-pgo.org/example </nowiki>
|-
| Content1 || Verwijzing naar een willekeurige DocumentReferentie. Geen voorbeeld beschikbaar.
|-
| Content2 || Verwijzing naar een willekeurige DocumentReferentie. Geen voorbeeld beschikbaar.
|}

MedMij:Vprepub-2020.01/PDFA Raadplegen

2021-10-21T08:10:00Z

Vincent Goris: MM-2264 Verduidelijking toegevoegd betreffende script 2.3 voor de DVP kwalificatie

MedMij:V2020.01/FHIR VitalSigns

2021-06-24T11:41:07Z

Vincent Goris: MM-1621, added notebox for explanation on MustSupport flags

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|Zelfmetingen}}}}
{{MedMij:Vprepub-2020.01/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-2020.01/OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/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.

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

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-2020.01/FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:Vprepub-2020.01/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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=CapabilityStatement: Server}}
| Vital Signs server requirements
|}

=Use case: Retrieve Vital Signs=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{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 RESTful] 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{/$lastn}{?[parameters]}
</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="4" style="font-weight: bold; text-align:left;" | Observation
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
| style="font-weight: bold;" | Example
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>category</code>]
| token
| The classification of the type of observation.

Within this context this will be {{term|vital-signs}} (from code system <code><nowiki>http://hl7.org/fhir/observation-category</nowiki></code>)
|
Retrieve all Observation resources that are considered a vital sign observation:
<pre>GET [base]/Observation?category=vital-signs</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>code</code>]
| token
| The code of the observation type.

The different types of measurements are specified using the following LOINC codes:
* BloodPressure: 85354-9
* BodyWeight: 29463-7
* BodyHeight: 8302-2
* BodyTemperature: 8310-5
* Oxygenation, saturation, SpO2: 59408-5
* HeartRate: 8867-4
* PulseRate: 8889-8
* BloodGlucose
** fasting: 14770-2
** general: 14743-9
** post-meal: 14760-3
|
Retrieve all Observation resources that are a blood pressure observation:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9</pre>
Retrieve the most recent body height and the most recent body weight observation:
<pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2&code=http://loinc.org|29463-7</pre>
|-
| [https://www.hl7.org/fhir/stu3/observation.html#search <code>date</code>]
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period
|
Retrieve all Observation resources that are a blood pressure observation and have an effective date between 01-01-2010 and 31-12-2010:
<pre>GET [base]/Observation?code=http://loinc.org|85354-9&date=ge2010-01-01&date=le2011-01-01</pre>
Retrieve at most four temperature observations that have an effective date greater than 01-06-2012:
<pre>GET [base]/Observation/$lastn?max=4&code=http://loinc.org|8310-5&date=ge2012-06-01</pre>
|}

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

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure [[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}

<span id="MustSupportFlag"></span>{{NoteBox|The Vital Signs FHIR profiles contain "Must Support" flags for various elements. The "Must Support" flags are inherited from FHIR core, but no particular meaning has been specified for the interpretation of these flags. Therefore, the "Must Support" flags also have no particular meaning within this context and can be ignored.}}

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

===The <code>lastn</code> operation===
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 <code>lastn</code> 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.

The [http://hl7.org/fhir/STU3/observation-operations.html#lastn FHIR STU3] specification is vague regarding the sorting mechanism of lastn. In [http://hl7.org/fhir/R4/observation-operation-lastn.html FHIR R4] however, this has been clarified and can be read as follows: when using lastn, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

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

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| class="wikitable"
|-style="background-color: #1F497D; color: white; font-weight: bold; "
|style="width:150px;"|Zib NL||style="width:150px;"|HCIM EN||style="width:150px;"|FHIR Resource||style="width:450px;"|FHIR Profile
|-style="vertical-align:top; background-color: #E3E3E3;
|-
| Patiënt||Patient||Patient||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener||HealthProfessional||Practitioner||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Bloeddruk||BloodPressure[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht||BodyWeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte||BodyHeight[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| Lichaamstemperatuur||BodyTemperature[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyTemperature|nictiz.fhir.nl.stu3.zib2017}}
|-
| O2Saturatie||oxygenation, saturation, SpO2[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-OxygenSaturation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Hartfrequentie||HeartRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-HeartRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| Polsfrequentie||PulseRate[[#MustSupportFlag|*]]||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-PulseRate|nictiz.fhir.nl.stu3.zib2017}}
|-
| LaboratoriumUitslag (based on)||LaboratoryTestResult (based on)||Observation||{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose|nictiz.fhir.nl.stu3.zib2017}}
|}
=====Expected Actions=====
On receipt of the submission, the XIS shall validate the resources and respond with an appropriate HTTP code.

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

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.

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

MedMij:Vprepub-2020.01/FHIR VitalSigns

2021-06-24T11:41:07Z

Vincent Goris: MM-1621, added notebox for explanation on MustSupport flags

FHIR:V1.0 FHIR IG STU3

2021-05-28T08:38:05Z

Vincent Goris: MM-2074, removed notebox concerning use of conceptmaps that had become obsolete

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. Because some receiving systems may not be able to handle this extension, the {{fhir|.display}} on both the element itself and the extension SHOULD be populated with the same value.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHOULD provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

This section is about the {{fhir|.id}} field and more general about the concept of a logical/technical id to identify instances on a server. The usage of the {{fhir|.identifier}} field, i.e. the business identifier, cannot be described in general terms and will be dictated one a use-case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in table [xxx] below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 401 Unauthorized - authorization is required for the interaction that was attempted (usually emitted by the authorization server)
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure (usually emitted by the resource server)
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=3 |All
| Not authorized, absent or expired access token
|
* HTTP 401 Unauthorized
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
|-
| Invalid authorization, scope of the access token is not sufficient for the request
|
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect or invalid
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

==CapabilityStatements==
Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

FHIR:Vprepub-1.0 FHIR IG STU3

2021-05-28T08:38:05Z

Vincent Goris: MM-2074, removed notebox concerning use of conceptmaps that had become obsolete

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. Because some receiving systems may not be able to handle this extension, the {{fhir|.display}} on both the element itself and the extension SHOULD be populated with the same value.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHOULD provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

This section is about the {{fhir|.id}} field and more general about the concept of a logical/technical id to identify instances on a server. The usage of the {{fhir|.identifier}} field, i.e. the business identifier, cannot be described in general terms and will be dictated one a use-case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in table [xxx] below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 401 Unauthorized - authorization is required for the interaction that was attempted (usually emitted by the authorization server)
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure (usually emitted by the resource server)
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=3 |All
| Not authorized, absent or expired access token
|
* HTTP 401 Unauthorized
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
|-
| Invalid authorization, scope of the access token is not sufficient for the request
|
* HTTP 403 Forbidden
* OperationOutcome with {{fhir|.code}} set to {{term|security}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect or invalid
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

==CapabilityStatements==
Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

MedMij:V2020.01/FHIR PDFA

2021-04-26T08:25:22Z

Vincent Goris: MM-1960, Support for the Find DocumentManifest transaction is made optional instead of mandatory for servers.

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|PDFA}}}}
{{MedMij:Vprepub-2020.01/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-2020.01/OntwerpPDFA|Functioneel]]
circle 1787 230 212 [[MedMij:Vprepub-2020.01/FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

=Introduction=
[[Bestand:Functioneel-02.png|link=MedMij:Vprepub-2020.01/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

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub-2020.01/FHIR_IG#Use case overarching principles|use case overarching principles]].

===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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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)=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

==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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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
! style="font-weight: bold; text-align:left;" | Optionallity
|-
| rowspan="5" | Patient
|-
| rowspan="4" | PHR
|-
| rowspan="3" | Document Consumer
| Find Document Manifest
| Optional
|-
| Find Document Reference
| Required
|-
| Retrieve Document
| Required
|-
| rowspan="5" | Healthcare provider
|-
| rowspan="4" | XIS
|-
| rowspan="3" | Document Responder
| Find Document Manifest
| Optional
|-
| Find Document Reference
| Required
|-
| Retrieve Document
| Required
|}
<font size = "1">'''Table 2. MHD actors and transactions in perspective of systems in a MedMij context''' </font>

Implementation of the 'Find Document Reference' and 'Retrieve Document' transactions are required. The 'Find Document Manifest' transaction is optional for both the Document Consumer and Document Responder.

==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 RESTful] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.

<pre>
GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}
</pre>

An example query to search for DocumentReferences which have status "''current''" and which are indexed/created after 01-01-2010:
<pre>GET [base]/DocumentReference?status=current&indexed=ge2010-01-01</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 search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

{| 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
|-
| <code>indexed</code>
| date
| When this document reference was created
| <code>created</code>
| date
| When this document manifest created
|-
| <code>status</code>
| token
| current / superseded
| <code>status</code>
| token
| current / superseded
|}

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

* 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'.

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

==List of profiles==
IHE has defined profiles 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 conformance resources.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

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

{{IssueBox|The IHE profiles 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.}}

The complete set of used profiles for the response message is listed in the table below.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017|v1Min=2.0.0}}

{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentManifest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|}

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

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

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

==List of profiles==

IHE has defined profiles 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 in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

{{MedMij:Vprepub-2020.01/NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|}

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

MedMij:Vprepub-2020.01/FHIR PDFA

2021-04-26T08:25:22Z

Vincent Goris: MM-1960, Support for the Find DocumentManifest transaction is made optional instead of mandatory for servers.

FHIR:V1.0 FHIR IG STU3

2021-02-22T14:15:46Z

Vincent Goris: MM-1787, adding more guidance on the use of code.specification extension.

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

'''Please note''': Unfortunately, FHIR doesn't have a core structured way for indicating which ConceptMaps to use. Instead, mappings are documented in the description of the element in the profile and/or specifically on the mapping description contained in the element.

To retrieve the indicated ConceptMap on Simplifier, the canonical url from the description needs to be used as search term. We are still examining ways to make this more user friendly, for example by using the [https://hl7.org/fhir/STU3/extension-11179-permitted-value-conceptmap.html extension for ConceptMaps], but that does not work unless various third party tooling is updated.

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. Because some receiving systems may not be able to handle this extension, the {{fhir|.display}} on both the element itself and the extension SHOULD be populated with the same value.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHALL provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

This section is about the {{fhir|.id}} field and more general about the concept of a logical/technical id to identify instances on a server. The usage of the {{fhir|.identifier}} field, i.e. the business identifier, cannot be described in general terms and will be dictated one a use-case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in table [xxx] below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=2 |All
| Invalid authorization
|
* HTTP 403 Forbidden
* OperationOutcome with <code>code</code> set to "''security''"
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization Example|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect or invalid
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

FHIR:Vprepub-1.0 FHIR IG STU3

2021-02-22T14:15:46Z

Vincent Goris: MM-1787, adding more guidance on the use of code.specification extension.

__NOINDEX__
__NUMBEREDHEADINGS__
{{DISPLAYTITLE:FHIR Implementation Guide}}

__TOC__

=Introduction=
This implementation guide describes the considerations for using '''HL7® FHIR®''' in context of information standards that are maintained by Nictiz. It applies specifically to HL7® FHIR® version 3 (STU3).

This implementation guide is aimed at software vendors and developers that need to implement FHIR based information standards maintained by Nictiz. Users of this guide are expected to be familiar with the [https://hl7.org/fhir/STU3 FHIR STU3 specification] and resource processing. Where relevant, links to the FHIR specification are provided. This implementation guide is not intended to be a tutorial on that subject.

<section begin=OverarchingPrinciples />
=Use case overarching principles=
==Content Types and encodings==
Unless stated otherwise, the information standards use the [https://hl7.org/fhir/http.html#mime-type FHIR RESTful framework]. This framework defines at least three content-types to send/retrieve information:
* XML: application/fhir+xml
* JSON: application/fhir+json
* RDF: text/turtle - Not supported in this context

Servers SHALL support both XML and JSON, while clients MAY use either format for the request and the response. For the response, servers SHALL support server-driven content negotiation as described in [https://www.hl7.org/fhir/stu3/http.html#mime-type the FHIR specification]. This means that clients can indicate the desired response format using the optional <code>_format=[mimetype]</code> URL parameter, or the acceptable response format(s) using the <code>Accept</code> header. The URL parameter takes precedence over the header. If a client does not request a specific content-type, then it is server discretion to respond using XML or JSON.

FHIR uses UTF-8 for all request and response bodies. Since the [https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1 HTTP specification (section 3.7.1)] defines a default character encoding of ISO-8859-1, requests and responses SHALL explicitly set the character encoding to UTF-8 using the <code>charset</code> parameter of the MIME-type in the <code>Content-Type</code> header. Requests MAY also specify this <code>charset</code> parameter in the <code>Accept</code> header and/or use the <code>Accept-Charset</code> header.

==Use of coded concepts==
===Textual description of coded concepts===
Coded information is extremely important for interoperability between systems. It enables systems to act on information rather than have humans read everything for interpretation - it enables medication related alerts, exercise encouragements because of weight increase, and many more things. In the HCIMs and profiles, we therefore strive for complete coverage of all possible situations.

However it is likely that unknown codes present themselves in the communication, for example because the sending system has updated its medication codes to a newer version than the receiving system, or because an older record item is coded in a way that now has been deprecated. It is therefore vital that, in addition to the code itself, the sender includes the semantics of the code. Therefore, systems SHOULD include [https://hl7.org/fhir/STU3/datatypes.html#coding {{fhir|(CodeableConcept).coding.display}}] and/or [https://hl7.org/fhir/STU3/datatypes.html#codeableconcept {{fhir|CodeableConcept.text}}] for coded data in FHIR instances. These fields may only be absent in rare circumstances, for example when dealing with historic data, or in data acquired without such info from a third party.

===Code system URIs===
A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that is defined in the FHIR conformance resource. This canonical URI can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile.<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>

'''Please note''': it is an error to assume that the OID assigned to a code system can be used to construct its canonical URI. The canonical URI for use in a FHIR context will always be assigned through the conformance resources<ref>There are exceptions to this, in which case other rules apply, see [https://www.hl7.org/fhir/stu3/terminologies.html#system the FHIR specifications]. However, this situation is not expected to occur in the use cases that this IG covers.</ref>. It ''can'' align with this OID (as a (<code><nowiki>urn:oid:[oid]</nowiki></code> URI), but this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code>.

===Mapping of coded concepts===
Terminology from HCIMs or UCSDs (use case specific datasets) needs to be faithfully applied to the FHIR profiles, but this is not directly possible when the base FHIR resource defines required terminology that bears no direct relationship with the HCIM or UCSD. These cases include, but are not limited to, the FHIR resource elements of datatype {{datatype|code}} ({{fhir|Patient.gender}}, {{fhir|status}} elements, structural type elements, etc.). This datatype always describes FHIR specific terminology, which usually doesn't align with the HCIM/UCSD terminology.

In these cases, a mapping will be provided to explain the relationship between de HCIM/UCSD terminology and the FHIR terminology. This is normally done through a FHIR [https://hl7.org/fhir/STU3/conceptmap.html ConceptMap], which can translate between the terminology used in the HCIM/UCSD, and the terminology that FHIR instances need to adhere to. When the ConceptMap {{fhir|.equivalence}} is not {{term|equal}} or {{term|equivalent}}, the original terminology from the HCIM/UCSD SHALL be communicated as well using the extension [https://simplifier.net/resolve?target=simplifier&canonical=http://nictiz.nl/fhir/StructureDefinition/code-specification code-specification] on the same element. It is recommended to use this extension in other situations as well. This allows unambiguous interpretation on the receiver end.

Example snippet from an {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|title=AllergyIntolerance}} where both the FHIR terminology {{term|high}} and the SNOMED CT {{term|24484000}} terminology are communicated. The FHIR terminology is obtained from the HCIM terminology using ConceptMap {{Simplifier|http://nictiz.nl/fhir/ConceptMap/MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality|title=MateVanKritiekZijnCodelijst-to-allergy-intolerance-criticality}}:

<syntaxhighlight lang="xml">
<criticality value="high">
<extension url="http://nictiz.nl/fhir/StructureDefinition/code-specification">
<valueCodeableConcept>
<coding>
<system value="http://snomed.info/sct"/>
<code value="24484000"/>
<display value="Severe"/>
</coding>
</valueCodeableConcept>
</extension>
</criticality>
</syntaxhighlight>

'''Please note''': Unfortunately, FHIR doesn't have a core structured way for indicating which ConceptMaps to use. Instead, mappings are documented in the description of the element in the profile and/or specifically on the mapping description contained in the element.

To retrieve the indicated ConceptMap on Simplifier, the canonical url from the description needs to be used as search term. We are still examining ways to make this more user friendly, for example by using the [https://hl7.org/fhir/STU3/extension-11179-permitted-value-conceptmap.html extension for ConceptMaps], but that does not work unless various third party tooling is updated.

==Use of the reference datatype==
A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/STU3/references.html#Reference {{datatype|Reference}} datatype]. This datatype supports two modes of referencing:
; [https://hl7.org/fhir/STU3/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
; [https://hl7.org/fhir/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.

The resource/profile will usually constrain which resources may be targeted from a given element. For example, {{fhir|Patient.generalPractitioner}} may point only to an Organization or Practitioner resource, and the nl-core-patient profile further restricts this to the nl-core-organization and nl-core-practitioner profiles{{ref|weakness-target-unavailable}}.

The basic requirements for using references in this context are:
* Either a literal or logical reference SHALL be specified, unless specified otherwise.
** Literal references are preferred over logical references when multiple target resource types/profiles may be used{{ref|weakness-unknown-type}}.
* Literal references SHALL be resolvable.
** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
** Relative references are preferred over absolute references.
* A short description of the target resource SHALL be included using the {{fhir|.display}} element.

''Note 1'': {{note|weakness-target-unavailable}}In some circumstances, the constraints om the target are too strict for the use case and the appropriate resource can't be referenced (examples are {{fhir|Encounter.participant}}, which cannot reference a PractitionerRole resource to provide context of the attending physician, and {{fhir|Media.operator}}, which cannot target Patient resources and thus doesn't recognize patient-generated Media). In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. Because some receiving systems may not be able to handle this extension, the {{fhir|.display}} on both the element itself and the extension SHOULD be populated with the same value.

''Note 2'': {{note|weakness-unknown-type}}There is a known weakness in the Reference datatype for FHIR STU3 which is fixed in FHIR R4: if the reference might have more than one type of resource as target, a receiving system cannot know what type is meant when only an identifier is provided.

==Relating FHIR profiles with their functional definitions==
All profiles have a traceable relationship with their functional counterpart(s) based on the element mapping mechanism in FHIR. This allows to:
# define one or more references from a FHIR profile to an external URL where the functional definition can be found
# define for each FHIR profile element to which concept ''within'' a functional definition it corresponds

The functional definition(s) underlying the profile can thus be resolved using the [https://hl7.org/fhir/STU3/structuredefinition-definitions.html#StructureDefinition.mapping {{fhir|StructureDefinition.mapping}}] metadata field of a profile. To relate a FHIR profile field to a concept from the functional description, the concept ID defined in the [https://hl7.org/fhir/STU3/dataelement-definitions.html#DataElement.mapping {{fhir|DataElement.mapping}}] can be used to look up the concept in the functional definition. It is possible that a single profile element refers concepts from multiple functional descriptions. Simplifier will show an overview of all the mappings for a FHIR profile on the dedicated 'mappings' tab, together with a clickable URL to the functional definition. In addition, on the 'overview' tab for each field the relevant mapping can be found.

For example, the profile nl-core-address defines a relationship with [https://simplifier.net/NictizSTU3-Zib2017/nl-core-address/~mappings with four functional definitions], one of which is [https://zibs.nl/wiki/AddressInformation-v1.0(2017EN) AddressInformation-v1.0(2017EN)]. This mapping is identified within the profile using 'hcim-addressinformation-v1.0-2017EN'. Looking at the {{fhir|Address.city}} element in this profile, one of the mappings is defined as 'hcim-addressinformation-v1.0-2017EN:NL-CM:20.5.3'. This reveals that this element implements (amongst others) the concept from the HCIM AddressInformation-v1.0(2017EN) described using ID 'NL-CM:20.5.3'.

==Profile use and declaration==
The implementation guides for the various information standards list the profiles to use for the FHIR resources. In the interest of interoperability it is important that, when using said information standard:
* Each resource SHALL be a valid instance of the applicable profile. Note that this applies not only to profiles listed directly in the IG, but also to profiles referred from/used by listed profiles.
* Each resource SHALL include the canonical URL of this profile in the {{fhir|meta.profile}} element. The canonical of compatible base or derived profiles MAY be included as well.

=={{fhir|Resource.text}} or "the narrative"==
The FHIR STU3 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with datatype [https://hl7.org/fhir/STU3/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".

This implementation guide has the following expectations regarding the use of narratives:
* Senders SHALL provide a "clinically safe" ([[#"Clinically safe" narratives|see below]]) narrative of status {{term|extensions}} (preferred) or {{term|generated}} ([[#Narrative status|see below]]), unless:
** The resource does not support narratives. This is the case for resources that do not derive from DomainResource, like Binary.
** The resource is contained in another resource.
** It is explicitly documented in the information standard to do otherwise.
* Receiver SHALL support the narrative. Ignoring the narrative is considered passive support. Support for the narrative SHALL be in accordance with the status and explicitly documented use in the relevant information standard.
* Receiver SHALL NOT generically depend on presence of a clinically safe narrative as their only means to present data to users when an explicitly documented use case for status empty or additional exists. Also, using just the narrative you would not expect to produce graphs, support for medication alerts and other functionality.

==="Clinically safe" narratives===
Regarding the contents of the narrative, the [https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text FHIR STU3 spec states] that:
<blockquote>The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative.</blockquote>
And for the Narrative datatype:
<blockquote>Structured data SHOULD NOT generally contain information of importance to human readers that is omitted from the narrative. Creators of FHIR resources should not assume that systems will render (or that humans will see) data that is not in the narrative.</blockquote>

The decision to what entails "clinically safe" information, is somewhat arbitrary. Guidelines for "clinically safe" inspired by the [https://hl7.org/fhir/STU3/w5.html FHIR W5 report]:
* If you only had the narrative: the intention and context should be clear to you.
* Who. Patient/subject, performer, author and/or other primary actors. Is this about family history or the actual patient.
* What. The topic for the resource is clear.
* When. Is this past, present, or future information.
* Why. What led up to the event. E.g. Condition, Referral that caused Encounter or Procedure.
* Where. Location of the event/action in the resource.
* Context. Relevant context as present as presented in the resource. status, Encounter, EpisodeOfCare, Diagnosis, Condition, BodySite.
* Rendering every identifier and/or code detail may not be necessary. {{fhir|Resource.text}} is for human assessment of the situation so emphasis should be on display text, representing identifier/code/system as relevant in the context.

Informal note: Producing a "clinically safe" narrative can be cumbersome. Various reference frameworks like [https://hapifhir.io/hapi-fhir/docs/model/narrative_generation.html HAPI] include a Narrative Generator of some sort.

===Narrative status===

Datatype {{datatype|Narrative}} [https://hl7.org/fhir/STU3/valueset-narrative-status.html defines different status codes] to indicate the origin of the narrative text. This implementation guide expects the most common use case to be the status {{term|extensions}}, which means that the narrative is generated entirely from the structured data and the extensions used. The reason for this is that most resources can have extension content defined on them. This status can still be used if a particular instance doesn't contain any extensions.

Alternatively, status {{term|generated}} may be used if the sender did not anticipate inclusion of regular extension content in the narrative.

'''Note''': for both status {{term|extensions}} and {{term|generated}}, all modifier extensions SHOULD be included in the narrative as they always affect the semantics.

Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.

==Search==

===Search URLs and search parameters===
Each use case of the various information standards lists the search parameters to use for a client to query the relevant information on a server. Usually, this is done in the form of (a number of) search URL(s), although individual use cases may use some other form if necessary (for example, listing optional parameters). Regarding the search parameters, the following guidelines apply:

* Unless explicitly marked as optional, the listed search parameters are considered the minimum for a request, meaning that:
** All stated parameters and modifiers SHALL be supported both by clients and servers.
** All stated parameters and modifiers SHALL be used for searching as specified in the information standard.
* A client MAY use additional search parameters in the search (such as date-range) not defined in the information standard. These may serve to further constrain the result set.
* <span id="unknown_search_parameter_handling">A server MAY ignore and MAY support additional search parameters. A server SHALL report the applied parameters [https://www.hl7.org/fhir/stu3/search.html#conformance in the self link] of the response and SHOULD provide additional information about the search process using an OperationOutcome in the search result Bundle (as an entry with {{fhir|search.mode}} set to {{term|outcome}}). A client MAY use the self link and/or OperationOutcome to inform the user, independently apply these filters to the result set, or take some other action.</span>
* A server SHALL reject any search request that contains parameters suffixed by a modifier that the server does '''not''' support for that parameter. For example, if the server supports the name search parameter, but not the :exact modifier on the name, it should reject a search with the parameter {{fhir|1=name:exact=Bill}}, using an HTTP 400 error with an OperationOutcome with a clear error message.
* A server SHALL NOT return information that is out of scope for the defined use case or authorization, even if the request by the client is wider than the use case.
* Repeating search parameters constitute a logical AND. Repeating search parameter values constitute a logical OR. Where applicable, this will be described further in the implementation guide.
* The order of the search parameters is always irrelevant.

General guidance on the use of search parameters can be found [https://www.hl7.org/fhir/stu3/search.html in the FHIR specification].

====Search on date, number or quantity====
When a search parameter has a type of date, number or quantity, the request [https://www.hl7.org/fhir/stu3/search.html#prefix uses prefixes] to control the search behavior. Unless explicitly stated otherwise, the minimum set of supported prefixes for these types is {{fhir|eq}}, {{fhir|gt}}, {{fhir|lt}}, {{fhir|ge}} and {{fhir|le}}. For example:
GET [base]/Observation?date=ge2019-01-01&date=le2020-01-01
Searches on all Observation resources that have an {{fhir|.effective[x]}} between January 1, 2019 and January 1, 2020.

====The {{fhir|_lastUpdated}} search parameter====
Retrieving information that was added, changed, deleted relative to a date may be done using the search parameter {{fhir|_lastUpdated}}, which is available for any resource. Using the parameter {{fhir|_lastUpdated}}, a system may query for data that is ''new'' since a specified date. Any FHIR server is expected to support this parameter. More information can be found in [https://hl7.org/fhir/STU3/search.html#lastUpdated the section on {{fhir|_lastUpdated}}] in the FHIR specification.

An example search request is shown below.

<pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105&_lastUpdated=gt2018-10-01</pre>

This search finds all Consent resources with a category SNOMED code 11291000146105 that have been modified since Oct 1, 2018.

===Search results===
====Including referenced resources====
Servers may not support read interactions, but all references from search results need to be resolvable (see [[#Use of the reference datatype]]). Therefore servers MAY choose to include the referenced resources in the ''searchset'' Bundle, even if the client didn't use any <code>_include</code> parameters. These resources SHALL have <code>Bundle.entry.mode</code> set to "''include''". Servers SHOULD NOT use contained resources for this purpose.

====Paging====
Servers MAY use [https://www.hl7.org/fhir/stu3/search.html#count paging] for performance reasons. Client SHALL support this mechanism to prevent loss of information.

== Usage of the {{fhir|.id}} and {{fhir|.fullUrl}} elements in FHIR instances ==

=== {{fhir|.id}} versus {{fhir|.identifier}} ===
FHIR recognizes two fields that are used as identifier for instances: {{fhir|.id}} and {{fhir|.identifier}}. Although these are both identifiers, they are unrelated and serve a completely different purpose:
* {{fhir|.id}} is the logical identifier, or technical identifier, akin to the id-field in a database. It is used as a unique handle for every instance on a particular server, and is needed to construct the URL to the instance. As such, it is used for referring between resources. The {{fhir|.id}} has no further meaning outside of the server.
* {{fhir|.identifier}} is a business identifier, which usually has a meaning ''outside'' of the server. Examples are a registration number of a healthcare provider, a BSN or social security number for citizens, ISBNs for books, etc. Any instance may have multiple kinds of identifiers.

This section is about the {{fhir|.id}} field and more general about the concept of a logical/technical id to identify instances on a server. The usage of the {{fhir|.identifier}} field, i.e. the business identifier, cannot be described in general terms and will be dictated one a use-case basis by the particular profiles.

=== When is {{fhir|.id}} expected? ===

As stated above, the logical id is meant to uniquely identify instances on a particular server; it is a vital component when using FHIR within a RESTful context. So as a rule of thumb, the {{fhir|.id}} element should always be present when dealing with instances that have a logical id, thus with instances on a server. This means:
* When a client reads, updates or otherwise addresses an existing resource on a server, the {{fhir|.id}} element SHALL be populated in the request and response, and it SHALL match the id in the request URL.
* When a client sends a ''new'' instance to a server using a create operation, the <code>id</code> element is ''not'' expected to be present -- these new instances don't exist yet on the server, so a logical id has no meaning. However, the server SHALL assign a logical id and populate the {{fhir|.id}} element in the response.<br/>''Note'': It is not strictly prohibited to populate the {{fhir|.id}} field when sending a new instance, but the server SHOULD ignore it.
* When a client performs a search on a server, all instances in the returned searchset Bundle SHOULD have the {{fhir|.id}} field populated.<br/>''Note'': A server SHOULD try its best to create stable ids for the resources it serves. Omitting {{fhir|.id}} elements is strongly discouraged as it breaks the assumptions about RESTful behavior. However, a server that omits {{fhir|.id}}s is still considered conformant when the conditions below are met:
*# The server does not natively support logical ids, for example when it is a stateless middleware server that gets its input from a non-FHIR XIS backend.
*# ''And'' the use case doesn't require read / update / delete / patch support for any of the returned of referenced resources, as stated by the CapabilityStatement for the information standard.
*# ''And'' the server includes all referenced resources in the searchset Bundle (regardless of whether the client asked to do so). These resources refer to each other based on the fullUrl mechanism as described below.

=== Logical ids, {{fhir|.fullUrl}}s and references in Bundles ===

There are several FHIR operations, like searching or batch create operations, where multiple instances are placed together in a Bundle. These instances will usually contain references to each other. These internal references cannot be resolved simply by inspecting the {{fhir|.id}} element of every instance; it is not guaranteed that all instances have a logical id. Instead, Bundles allow an {{fhir|entry.fullUrl}} element for each instance which may be used for references. This is an additional mechanism to the logical id, not a replacement:
* The [[#When_is_id_expected.3F|guidelines above]] for populating the {{fhir|.id}} field still apply.
* If {{fhir|.id}} is present, {{fhir|.fullUrl}} SHALL correspond with it (see below).

{{fhir|.fullUrl}}s may be RESTful URLs, UUIDs or even OIDs, based on the situation (which may be mixed within the same Bundle):
; Instances with a logical id: If an instance can be accessed on the server using RESTful operations, the {{fhir|.id}} of that instance in the Bundle will be populated. The corresponding {{fhir|.fullUrl}} in this case SHALL be the absolute URL to the instance on the server.<p>Instances within the Bundle may use relative references to each other, like they are on the same server. The FHIR machinery specifies how to find the matching instance based on the {{fhir|.fullUrl}}.</p>
; Instances without a logical id: When instances are to be created on a server or when the server doesn't support reading individual instances, they don't have a logical id. When these id-less instances need to be referenced from within a Bundle, there are two alternatives:
:* <span id="uuid-as-logical-id"></span>UUIDs can be used as single-use ids that will change each time the Bundle is generated. The {{fhir|.fullUrl}} for the instance will be the UUID prefixed with <code><nowiki>urn:uuid:</nowiki></code>. <ref name="id-ambiguous">Some implementations may choose to populate the {{fhir|.id}} element with the unprefixed UUID or OID in cases when the {{fhir|.id}} field is expected, for example in searchset Bundles. The FHIR specification is ambiguous on the requirements to do so. For a long discussion on the topic, see [https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Confused.20about.20URN.20fullUrl's.20and.20resource.2Eid's chat.fhir.org].</ref>
:* <span id="oid-as-logical-id"></span>OIDs can be used if the instance has an OID-based ''business'' identifier (i.e. the {{fhir|.identifier}} field), like the UZI number of a healthcare provider. The {{fhir|.fullUrl}} will be the OID prefixed with <code><nowiki>urn:oid:</nowiki></code><ref name="id-ambiguous"/><ref>The use of OIDs as id has some limitations:
* The {{fhir|.id}} has a maximum length of 64 characters, so only OIDs that contain less than 64 characters can be used.
* OID based ids are expected to be stable, just like RESTful ids. Different Bundle instances SHALL always use the same OID based ids.
* Some ''objects'' may have multiple OID based identifiers, like AGB and UZI for practitioners. Which one do you choose? And what happens when the UZI number becomes available after you've already used the AGB as {{fhir|.id}}?
* Specifically for HL7 V3 based backends: an HL7 V3 II datatype normally consists of a <code>@root</code> (OID) and an <code>@extension</code> (string). Concatenation of <code>@root</code> and <code>@extension</code> only yields a new OID if <code>@extension</code> is numeric. Other combinations of <code>@root.@extension</code>, may yield a valid {{fhir|.id}} (pattern <code>[A-Za-z0-9\-\.]{1,64}</code>), but may not be a valid OID. In this case it is no longer possible to create a {{fhir|.fullUrl}} consistent with the {{fhir|.id}} based the <nowiki>urn:oid:</nowiki> scheme.</ref>.
: Instances within the Bundle should use the prefixed version of the UUID/OID for referencing.

==== Example ====
Consider a client that wants to send a new Observation instance to a server and simultaneously link it to an existing Task instance. This can be done using a transaction Bundle:
<syntaxhighlight lang="xml" highlight="7-8,11,23-24,27-28,33-34,41-42" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">

<type value="transaction"/>


<entry>

<fullUrl value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
<resource>
<Observation>

...
</Observation>
</resource>
</entry>
<request>
<method value="POST"/>
<url value="Observation"/>
</request>


<entry>

<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>

<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="urn:uuid:0e855422-b8ef-4247-9443-f3747e78747e"/>
</valueReference>
</output>
</Task>
</resource>
<request>
<method value="PUT"/>

<url value="Task/1234"/>
</request>
</entry>
</Bundle>
</syntaxhighlight>

The server response should then look like:
<syntaxhighlight lang="xml" highlight="5-6,9-10,28-29" style="max-height:400px; overflow: auto;">
<Bundle xmlns="http://hl7.org/fhir">
<type value="transaction-response"/>

<entry>

<fullUrl value="http://example-xis.com/QuestionnaireResponse/5678"/>
<resource>
<Observation>

<id value="5678"/>
...
</Observation>
</resource>
</entry>
<response>
....
</request>

<entry>
<fullUrl value="http://example-xis.com/Task/1234"/>
<resource>
<Task>
<id value="1234"/>
...
<output>
...
<valueReference>

<reference value="Observation/5678"/>
</valueReference>
</output>
</Task>
</resource>
<response>
....
</response>
</entry>
</Bundle>
</syntaxhighlight>

== Handling errors==
Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/STU3/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.detail}} element). Although these latter elements are not required, their usage is strongly encouraged.

For the most common errors, the expected handling is listed in table [xxx] below. This should be interpreted as a guideline, as the nature of an error is not always unambiguous and various FHIR reference implementations will make different choices. The FHIR specification provides more detail [https://www.hl7.org/fhir/stu3/http.html on error handling in general], [https://www.hl7.org/fhir/stu3/security.html#AccessDenied access denied responses] and [https://www.hl7.org/fhir/stu3/search.html#errors for search operations specifically].

In general, most FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues) will result in one of these HTTP status codes:
* 400 Bad Request - resource could not be parsed, search could not be processed or basic FHIR validation rules failed
* 403 Forbidden - the server was unable to execute the search, due to an authorization failure
* 404 Not Found - resource type not supported, or not an FHIR endpoint
* 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules

{| class="wikitable"
|-
! Interaction
! Error
! Expected action
! Example
|-
| rowspan=2 |All
| Invalid authorization
|
* HTTP 403 Forbidden
* OperationOutcome with <code>code</code> set to "''security''"
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization Example|Example]]
|-
| Resource is not supported
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
|-
| rowspan=4 |search
| No match for the given search parameters
| colspan="2" |''This is not considered an error, but a normal search without results.''
|-
| Unknown search parameter
| colspan="2" | ''This is not considered an error. See the [[#unknown_search_parameter_handling|guidance in the section on searching]].''
|-
| Syntactically incorrect parameter
|
* HTTP 400 Bad Request
* OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
|-
| Known but unsupported value. This situation applies to non-supported HCIM profiles when the Resource endpoint itself is supported.
|
* HTTP 200 OK
* Empty Bundle of {{fhir|.type}} {{term|searchset}}
* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} of {{term|outcome}}.
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
|-
| read
| Read request with unknown id
|
* HTTP 404 Not Found
* OperationOutcome with {{fhir|.code}} set to {{term|not-found}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
|-
| update
| No or incorrect Resource id
|
* HTTP 400 Bad Request
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}}
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
|-
| create/update
| Resource syntax or data is incorrect or invalid
|
* HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
* OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
|}
<section end=OverarchingPrinciples />
<section begin=FHIRPackages />

=FHIR Packages=
The information standards maintained by Nictiz adopt the FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

Please note that every effort has been made to ensure that the examples contained in the packages are correct and useful, but they are not a normative part of any information standard.

For even more background information:
* [https://confluence.hl7.org/display/FHIR/NPM+Package+Specification The HL7 base specification for FHIR pacakges]
* [https://blog.fire.ly/2017/11/28/versioning-and-canonical-urls/ What is the problem that packaging could address]
* [https://simplifier.net/organization/firely/news/55 Introducing the Simplifier FHIR Package Server] (includes what problem packaging addresses)
* [https://simplifier.net/organization/firely/news/56 Firely Torinox introduction] (this is one of the tools that's useful for working with FHIR packages)

{{NoteBox|It is '''not''' required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.}}
<section end=FHIRPackages />

Bestand:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ V2020.01 20201702.pdf

2021-02-17T14:49:22Z

Vincent Goris:

MedMij:Vissue-MM-1697/Kwalificatie

2021-02-17T14:47:56Z

Vincent Goris: New version of GGZ beschikbaarstellen addenda.

{{IssuePaginaWaarschuwing|MM-1697|MedMij:V2020.01/Kwalificatie}}
__NOINDEX__
{{MedMij:Vprepub-V2020.01/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder. Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub-V2020.01/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [[MedMij:Vprepub-V2020.01/Kwalificatie_FAQ|FAQ]] tref je de veelgestelde vragen tijdens het kwalificatietraject.

Het kwalificatiecentrum biedt ook aanvullende dienstverlening voor Stichting MedMij. Wijzigingen bij DVZA’s of DVP’s die een hoog risico vormen voor de interoperabiliteit en kwaliteit van de gegevensuitwisseling kunnen vrijblijvend worden geherkwalificeerd. Herkwalificatie kan noodzakelijk zijn indien:
* Eén van de bronsystemen wordt vervangen door een andere applicatie;
* Een versie-update aan de kant van het het bronsysteem en/of overige betrokken partijen van toepassing is;
* Er een grote update plaatsvindt aan de kant van de DVZA of DVP.

Voor het inplannen van een herkwalificatie kan contact opgenomen worden met [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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:Vprepub-V2020.01/Ontwerpen|MedMij informatiestandaard]], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub-V2020.01/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub-V2020.01/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_V2020.01.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_V2020.01.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01-20210125.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_V2020.01.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub-V2020.01/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub-V2020.01/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_V2020.01.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

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

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01_20210127.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01_20210126.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_V2020.01_20210126.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_V2020.01.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_V2020.01.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_V2020.01.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01_20201702.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

==Beelden 2.0==
* [[Media:1. Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:Aanleverformat - Ontvangen Beelden_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen Beelden.zip]]
* [[Media:Aanleverformat - Sturen Beelden_V2020.01.zip|3. Aanleverformat - Sturen Beelden.zip]]

==Basisgegevens Langdurige Zorg 2.0==
{{NoteBox|1= Meld je bij het Nictiz kwalificatiecentrum (via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]) wanneer je voor de Basisgegevens Langdurige Zorg wilt kwalificeren.}}
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.1|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.1]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.2|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.2]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.4|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.4]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
* [[Media:3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.zip]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01_20201124.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_V2020.01.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

Bestand:Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ V2020.01 20201702.pdf

2021-02-17T14:46:53Z

Vincent Goris:

MedMij:Vissue-MM-1697/Kwalificatie

2021-02-17T14:42:47Z

Vincent Goris: Clone of V2020.01 production page for issue MM-1697

{{IssuePaginaWaarschuwing|MM-1697|MedMij:V2020.01/Kwalificatie}}
__NOINDEX__
{{MedMij:Vprepub-V2020.01/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder. Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub-V2020.01/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [[MedMij:Vprepub-V2020.01/Kwalificatie_FAQ|FAQ]] tref je de veelgestelde vragen tijdens het kwalificatietraject.

Het kwalificatiecentrum biedt ook aanvullende dienstverlening voor Stichting MedMij. Wijzigingen bij DVZA’s of DVP’s die een hoog risico vormen voor de interoperabiliteit en kwaliteit van de gegevensuitwisseling kunnen vrijblijvend worden geherkwalificeerd. Herkwalificatie kan noodzakelijk zijn indien:
* Eén van de bronsystemen wordt vervangen door een andere applicatie;
* Een versie-update aan de kant van het het bronsysteem en/of overige betrokken partijen van toepassing is;
* Er een grote update plaatsvindt aan de kant van de DVZA of DVP.

Voor het inplannen van een herkwalificatie kan contact opgenomen worden met [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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:Vprepub-V2020.01/Ontwerpen|MedMij informatiestandaard]], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub-V2020.01/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub-V2020.01/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_V2020.01.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_V2020.01.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01-20210125.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_V2020.01.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub-V2020.01/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub-V2020.01/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_V2020.01.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

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

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01_20210127.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01_20210126.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_V2020.01_20210126.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_V2020.01.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_V2020.01.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_V2020.01.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01_20201124.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

==Beelden 2.0==
* [[Media:1. Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen beelden.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen beelden_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen beelden.pdf]]
* [[Media:Aanleverformat - Ontvangen Beelden_V2020.01_20201124.zip|3. Aanleverformat - Ontvangen Beelden.zip]]
* [[Media:Aanleverformat - Sturen Beelden_V2020.01.zip|3. Aanleverformat - Sturen Beelden.zip]]

==Basisgegevens Langdurige Zorg 2.0==
{{NoteBox|1= Meld je bij het Nictiz kwalificatiecentrum (via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]) wanneer je voor de Basisgegevens Langdurige Zorg wilt kwalificeren.}}
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.1|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.1]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.2|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.2]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
* [[MedMij:Vprepub-V2020.01/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.4|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.4]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
* [[Media:3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.zip]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01_20201124.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_V2020.01_20201124.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_V2020.01.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

MedMij:V2020.01/Kwalificatie

2020-11-23T15:59:08Z

Vincent Goris: MM-1467 merged to include new versions of assesment forms (with timestamp 20201124), resolved merging conflicts where names of Media have been changed from Vprepub to V2020.01.

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder. Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Kwalificatie_FAQ FAQ] tref je de veelgestelde vragen tijdens het kwalificatietraject.

Het kwalificatiecentrum biedt ook aanvullende dienstverlening voor Stichting MedMij. Wijzigingen bij DVZA’s of DVP’s die een hoog risico vormen voor de interoperabiliteit en kwaliteit van de gegevensuitwisseling kunnen vrijblijvend worden geherkwalificeerd. Herkwalificatie kan noodzakelijk zijn indien:
* Eén van de bronsystemen wordt vervangen door een andere applicatie;
* Een versie-update aan de kant van het het bronsysteem en/of overige betrokken partijen van toepassing is;
* Er een grote update plaatsvindt aan de kant van de DVZA of DVP.

Voor het inplannen van een herkwalificatie kan contact opgenomen worden met [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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 [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Ontwerpen MedMij informatiestandaard], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van gegevensdiensten, met een verwijzing naar kwalificatie-informatie per systeemrol, raadpleeg de [https://afsprakenstelsel.medmij.nl/display/MMCatalogus/Actuele+gegevensdiensten MedMij Catalogus].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_V2020.01.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_V2020.01.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_V2020.01.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_V2020.01.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_V2020.01.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

===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_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_V2020.01.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantieVertaling Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_V2020.01.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_V2020.01.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_V2020.01.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_V2020.01.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen_20201124.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_V2020.01.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

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

==Basisgegevens Langdurige Zorg 2.0==
{{NoteBox|1= Meld je bij het Nictiz kwalificatiecentrum (via [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]) wanneer je voor de Basisgegevens Langdurige Zorg wilt kwalificeren.}}
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]
* [[MedMij:Vprepub/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.1|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.1]]
* [[MedMij:Vprepub/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.2|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.2]]
* [[MedMij:Vprepub/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.3|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.3]]
* [[MedMij:Vprepub/V1.0_BgLZ1.0.0-KwalificatieAddendumScenario1.4|2. Addenda voor inhoudelijke gegevens Beschikbaarstellen/Raadplegen Basisgegevens Langdurige Zorg - scenario 1.4]]
* [[Media:3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens Langdurige Zorg.zip]]
* [[Media:3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg_V2020.01.zip|3. Aanleverformat - Raadplegen Basisgegevens Langdurige Zorg.zip]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Beschikbaarstellen_20201124.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens Langdurige Zorg.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensLangdurigeZorg Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens Langdurige Zorg.pdf]]

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_V2020.01.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_V2020.01.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_V2020.01.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

MedMij:Vprepub-2020.01/Kwalificatie

2020-11-23T15:59:08Z

Vincent Goris: MM-1467 merged to include new versions of assesment forms (with timestamp 20201124), resolved merging conflicts where names of Media have been changed from Vprepub to V2020.01.

MedMij:V2020.01/Kwalificatie

2020-10-28T12:55:58Z

Vincent Goris: /* PDF/A 3.0 */

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Register_van_informatiestandaarden Register van Informatiestandaarden] met daarin de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder van het register van Informatiestandaarden.

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel112/Catalogus catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Kwalificatie_FAQ FAQ] tref je de veelgestelde vragen tijdens het kwalificatietraject.

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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 [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Ontwerpen MedMij informatiestandaard], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van de binnen MedMij toegelaten informatiestandaarden raadpleeg het [[MedMij:Register_van_informatiestandaarden| Register van informatiestandaarden]].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_Vprepub.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

===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_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_Vprepub.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantieVertaling Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_Vprepub.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_Vprepub.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_Vprepub.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

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

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

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_Vprepub.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

MedMij:Vprepub-2020.01/Kwalificatie

2020-10-28T12:55:58Z

Vincent Goris: /* PDF/A 3.0 */

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Register_van_informatiestandaarden Register van Informatiestandaarden] met daarin de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder van het register van Informatiestandaarden.

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel112/Catalogus catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Kwalificatie_FAQ FAQ] tref je de veelgestelde vragen tijdens het kwalificatietraject.

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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 [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Ontwerpen MedMij informatiestandaard], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van de binnen MedMij toegelaten informatiestandaarden raadpleeg het [[MedMij:Register_van_informatiestandaarden| Register van informatiestandaarden]].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_Vprepub.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_V2020.01_20201027.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

===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_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_Vprepub.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantieVertaling Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_Vprepub.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_Vprepub.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_Vprepub.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zip|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

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

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

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_Vprepub.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

MedMij:V2020.01/FHIR BGZ 2017

2020-10-20T07:32:36Z

Vincent Goris: MM-1444: Textual changes on the FHIR implementation of HCIM PlannedCareActivityForTransfer, FHIR core resources are now correctly mentioned.

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: BgZ {{VersieInfo|BgZ}}}}
{{MedMij:Vprepub/Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:BGZ_icoon.png |link=|links|90px|Use case BgZ 2017|Patient Summary (BgZ)]]
<imagemap>Bestand:Leeswijzer-technisch-banner 03 white.png|center|400px|alt=Afspraken-Functioneel-Technisch
circle 241 216 211 [https://www.medmij.nl/afsprakenstelsel Afsprakenstelsel]
circle 1013 224 212 [[MedMij:Vprepub/OntwerpBGZ_2017|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]]

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

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

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

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub/FHIR_IG#Use case overarching principles|use case overarching principles]].

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

==Boundaries and Relationships==
The BgZ 2017 v1.1 use case follows the BgZ v1.0 use case. The difference between the two is the underlying HCIMs, which have been upgraded from release 2015 to release 2017. The changes are documented in a [https://github.com/Nictiz/Nictiz-STU3-Zib2017/raw/master/ReleaseNotes%20FHIR%20profielen%20ZIB2017.pdf release notes] document.

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

==Use Case: Retrieve BGZ information==
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to MedMij Afsprakenstelsel]]

{{FHIR-IG-Afsprakenstelsel-Note}}

===PHR: request message===
The PHR system requests the BgZ using individual [https://www.hl7.org/fhir/stu3/search.html search] interactions. The BgZ consists of multiple FHIR resources with certain constraints. To obtain the patient's BgLZ, the client can use multiple individual search operations based on specified search queries. The interactions are performed by an HTTP GET as shown:

<code>GET [base]/[type]{?[parameters]}</code>

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

{| class="wikitable collapsible" width="100%" style="horizontal-align: right"
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | #
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | BgZ Section
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | HCIM EN
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Content
!style="background-color: #4AB8A7; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Search URL<ref>See [[MedMij:Vprepub/FHIR_IG#Search_URLs_and_search_parameters|Search URLs and search parameters]] for the interpretation of these search URLs</ref>
|-
| 1
| Patient information
| Patient
| Identification, birth date, gender, deceased indicator, contact details, last known marital status, and general practitioner (practitioner or organization)
| <pre>GET [base]/Patient?_include=Patient:general-practitioner</pre>
|-
| 2
| Payment details
| Payer
| Insurance information
| <pre>GET [base]/Coverage?_include=Coverage:payor:Patient&_include=Coverage:payor:Organization</pre>
|-
| rowspan="2" | 3
| rowspan="2" | Treatment directives
| TreatmentDirective
| Known treatment directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11291000146105</pre>
|-
| AdvanceDirective
| Known advance directives
| <pre>GET [base]/Consent?category=http://snomed.info/sct|11341000146107</pre>
|-
| 4
| Contact persons
| ContactPerson
| First relation/contact
| <pre style="font-style: italic;">see Patient</pre>
|-
| 5
| Functional status
| FunctionalOrMentalStatus
| Last known functional / mental status
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|118228005,http://snomed.info/sct|384821006</pre>
|-
| 6
| Problems
| Concern
| All known problems
| <pre>GET [base]/Condition</pre>
|-
| rowspan="5" | 7
| rowspan="5" | Social history
| LivingSituation
| Current living situation
| <pre>GET [base]/Observation/$lastn?code=http://snomed.info/sct|365508006</pre>
|-
| DrugUse
| All known drug use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228366006</pre>
|-
| AlcoholUse
| All known alcohol use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|228273003</pre>
|-
| TobaccoUse
| All known tobacco use
| <pre>GET [base]/Observation?code=http://snomed.info/sct|365980008</pre>
|-
| NutritionAdvice
| All known current dietary recommendations
| <pre>GET [base]/NutritionOrder</pre>
|-
| 8
| Alerts
| Alert
| All known alerts
| <pre>GET [base]/Flag</pre>
|-
| 9
| Allergies
| AllergyIntolerance
| All known information regarding allergies
| <pre>GET [base]/AllergyIntolerance</pre>
|-
| rowspan="3" | 10
| rowspan="3" | Medication
| MedicationUse
| Known medication use
| <pre>GET [base]/MedicationStatement?category=urn:oid:2.16.840.1.113883.2.4.3.11.60.20.77.5.3|6&_include=MedicationStatement:medication</pre>
|-
| MedicationAgreement
| Known medication agreements
| <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication</pre>
|-
| AdministrationAgreement
| Known administration agreements
| <pre>GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication</pre>
|-
| 11
| Medical aids
| MedicalAid
| Known medical aids
| <pre>GET [base]/DeviceUseStatement?_include=DeviceUseStatement:device</pre>
|-
| 12
| Vaccinations
| Vaccination
| Known vaccinations
| <pre>GET [base]/Immunization?status=completed</pre>
|-
| rowspan="3" | 13
| rowspan="3" | Vital signs
| BloodPressure
| Last known blood pressure
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|85354-9</pre>
|-
| BodyWeight
| Last known body weight
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|29463-7</pre>
|-
| BodyHeight
| Last known body height
| <pre>GET [base]/Observation/$lastn?code=http://loinc.org|8302-2,http://loinc.org|8306-3,http://loinc.org|8308-9</pre>
|-
| 14
| Results
| LaboratoryTestResult
| Last known laboratory results per type
| <pre>GET [base]/Observation/$lastn?category=http://snomed.info/sct|275711006&_include=Observation:related-target&_include=Observation:specimen</pre>
|-
| 15
| Procedures
| Procedure
| Known surgical procedures
| <pre>GET [base]/Procedure?category=http://snomed.info/sct|387713003</pre>
|-
| 16
| Encounters
| Contact
| Known hospital admissions (no outpatient contacts)
| <pre>GET [base]/Encounter?class=http://hl7.org/fhir/v3/ActCode|IMP,http://hl7.org/fhir/v3/ActCode|ACUTE,http://hl7.org/fhir/v3/ActCode|NONAC</pre>
|-
| 17
| Planned care
| PlannedCareActivityForTransfer
| Known planned care activities
| <span id="PlannedCareRemark"></span>{{NoteBox|The HCIM PlannedCareActivityForTransfer represents a planned activity as a (reference to) the HCIM for that activity in the 'planned' status. However, FHIR doesn't recognize this status; instead it uses dedicated resources for planning. Therefore, the FHIR implementation of this HCIM uses these dedicated resources instead of a distinct profile::

*Planning an Encounter is done by using an Appointment
*Planning a Procedure is done by using a ProcedureRequest
*Planning an Immunization is done by using an ImmunizationRecommendation
*Planning a MedicalDevice is done by using a DeviceRequest
}}
<pre>GET [base]/ProcedureRequest?status=active</pre>
<pre>GET [base]/ImmunizationRecommendation</pre>
<pre style="text-decoration: line-through;">GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&status=in-progress,preparation&_include=MedicationDispense:medication</pre>
<span id="MM115Remark"></span>{{NoteBox|PlannedCareActivityForTransfer for MedicationAdministration was found unimplementable as-is. Presumed solution will come from a future HCIM release. See [https://bits.nictiz.nl/browse/MM-115 MM-115] for more information.}}
<pre>GET [base]/DeviceRequest?status=active&_include=DeviceRequest:device</pre>
<pre>GET [base]/Appointment?status=booked,pending,proposed</pre>
|-
| 18
| General practitioner
| HealthProfessional
| General Practitioner of the patient
| <pre style="font-style: italic;">see Patient</pre>
|}
<references/>
{{Sjabloon:Voorbeelden}}

===XIS: response message===
The returned data to the PHR should conform to the profiles listed in [[#List_of_profiles]].

===The <code>lastn</code> operation===
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 <code>lastn</code> 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.

The FHIR STU3 specification is vague regarding the sorting mechanism of <code>lastn</code>. In FHIR R4 however, this has been clarified and can be read as follows: when using <code>lastn</code>, the <code>effective[x]</code> element is used for sorting of Observations, sorted from most recent to the oldest.

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

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.bgz|p2=nictiz.fhir.nl.stu3.zib2017|p3=nictiz.fhir.nl.stu3.eafspraak}}

{| class="wikitable" style="horizontal-align: right"
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:10px" | Section
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | Zib NL
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | HCIM EN
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:100px" | FHIR Resource
!style="background-color: #1F497D; color: white; font-weight: bold; text-align:left; background-color: #E3E3E3 width:400px" | FHIR Profile
|-
| 1
| Patient
| #Zib Patient|Patient
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" |2
| rowspan="3" | Betaler
| rowspan="3" | Payer
| Coverage
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Payer|nictiz.fhir.nl.stu3.zib2017}}
|-
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| Patient
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" |3
| BehandelAanwijzing
| TreatmentDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TreatmentDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
| Wilsverklaring
| AdvanceDirective
| Consent
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdvanceDirective|nictiz.fhir.nl.stu3.zib2017}}
|-
| 4
| Contactpersoon
| ContactPerson
| Patient.contact
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-patient|nictiz.fhir.nl.stu3.zib2017}}
|-
| 5
| Funct. OfMentaleStatus
| FunctionalOrMentalStatus
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-FunctionalOrMentalStatus|nictiz.fhir.nl.stu3.zib2017}}
|-
| 6
| Probleem
| Problem
| Condition
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Problem|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="5" | 7
| Woonsituatie
| LivingSituation
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LivingSituation|nictiz.fhir.nl.stu3.zib2017}}
|-
| DrugsGebruik
| DrugUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-DrugUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| AlcoholGebruik
| AlcoholUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AlcoholUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| TabakGebruik
| TobaccoUse
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-TobaccoUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| Voedingsadvies
| NutritionAdvice
| NutritionOrder
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-NutritionAdvice|nictiz.fhir.nl.stu3.zib2017}}
|-
| 8
| Alert
| Alert
| Flag
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Alert|nictiz.fhir.nl.stu3.zib2017}}
|-
| 9
| AllergieIntolerantie
| AllergyIntolerance
| AllergyIntolerance
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AllergyIntolerance|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" | 10
| rowspan="3" | MedicatieGebruik
| MedicationUse
| MedicationStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationUse|nictiz.fhir.nl.stu3.zib2017}}
|-
| MedicationAgreement
| MedicationRequest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicationAgreement|nictiz.fhir.nl.stu3.zib2017}}
|-
| AdministrationAgreement
| MedicationDispense
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 11
| rowspan="2" | MedischHulpmiddel
| rowspan="2" | MedicalDevice
| Device
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceProduct|nictiz.fhir.nl.stu3.zib2017}}
|-
| DeviceUseStatement
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDevice|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 12
| rowspan="2" | Vaccinatie
| rowspan="2" | Vaccination
| Immunization
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Vaccination|nictiz.fhir.nl.stu3.zib2017}}
|-
| ImmunizationRecommendation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="3" | 13
| Bloeddruk
| BloodPressure
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BloodPressure|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsGewicht
| BodyWeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyWeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| LichaamsLengte
| BodyHeight
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-BodyHeight|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="2" | 14
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation|nictiz.fhir.nl.stu3.zib2017}}
|-
| Specimen
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Specimen|nictiz.fhir.nl.stu3.zib2017}}
|-
| 15
| Verrichting
| Procedure
| Procedure
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Procedure|nictiz.fhir.nl.stu3.zib2017}}
|-
| 16
| Contact
| Encounter
| Encounter
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-Encounter|nictiz.fhir.nl.stu3.zib2017}}
|-
| rowspan="5" | 17
| rowspan="5" | OverdrachtGeplandeZorgActiviteit
| rowspan="5" | PlannedCareActivityForTransfer
| ProcedureRequest [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest|nictiz.fhir.nl.stu3.zib2017}}
|-
| <span style="text-decoration: line-through;">MedicationDispense</span> [[#MM115Remark|**]]
| <span style="text-decoration: line-through;">{{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-AdministrationAgreement|nictiz.fhir.nl.stu3.zib2017}}</span>
|-
| ImmunizationRecommendation [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-VaccinationRecommendation|nictiz.fhir.nl.stu3.zib2017}}
|-
| DeviceRequest [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-MedicalDeviceRequest|nictiz.fhir.nl.stu3.zib2017}}
|-
| Appointment [[#PlannedCareRemark|*]]
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/eAfspraak-Appointment|nictiz.fhir.nl.stu3.eafspraak}}
|-
| rowspan="3" | 18
| rowspan="2" | Zorgverlener
| rowspan="2" | HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| PractitionerRole
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|}

==Terminology, NamingSystems, Mappings==

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

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

===Mappings===
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/OntwerpBGZ_2017#Release_notes|functional design page]].

MedMij:Vprepub-2020.01/FHIR BGZ 2017

2020-10-20T07:32:36Z

Vincent Goris: MM-1444: Textual changes on the FHIR implementation of HCIM PlannedCareActivityForTransfer, FHIR core resources are now correctly mentioned.

Bestand:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA V2020.01.pdf

2020-09-29T13:18:25Z

Vincent Goris: Vincent Goris heeft een nieuwe versie van Bestand:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA V2020.01.pdf geüpload

Bestand:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA V2020.01.pdf

2020-09-29T13:14:58Z

Vincent Goris: Vincent Goris heeft een nieuwe versie van Bestand:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA V2020.01.pdf geüpload

Bestand:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA V2020.01.pdf

2020-09-29T13:14:26Z

Vincent Goris: Vincent Goris heeft een nieuwe versie van Bestand:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA V2020.01.pdf geüpload

Sjabloon:BITS-issue

2020-09-29T09:16:35Z

Vincent Goris:

| [https://bits.nictiz.nl/browse/{{{1}}} {{{1}}}]
| {{#switch: {{{1}}}

|MM-1459 = Onterechte paragraafnummering 1.1 veranderd naar 1.3 in addendum scenario 1.3 van BgLZ.
|MM-1456 = Verwijder de onterecht geïncludeerde paragrafen 1.2 en 1.3 in addendum 1.1 van de BgLZ.
|MM-1406 = Tekstuele verbetering Toelichting kwalificatie (/Kwalificatie) paragraaf 4.2 om duidelijker te maken dat de leverancier de foutcode moet inbouwen
|MM-1393 = Tweaks in the qualification materials of the PDF/A standard on multiple aspects including scripts, addendum, fixtures and wiki guidance.
|MM-1383 = Verwijderen van niet te gebruiken eAfspraak-scenario's afspraak maken, wijzigen en verwijderen.
|MM-1379 = Remove the defunct Simplifier based rendering of operations from TO's of eAfspraak and MedicationProcess.
|MM-1374 = In the HCIM Procedure profile, corrected naming in the mappings from the old to the new HCIM.
|MM-1358 = Replaced <div> by <span> in narratives of examples.
|MM-1353 = Notebox opgenomen in FO voor Vragenlijsten om duidelijk te maken dat de uitwisseling op dit moment niet via het MedMij Afsprakenstelsel kan plaatsvinden.
|MM-1345 = Notebox opgenomen in het functioneel ontwerp van Vragenlijsten, welke toelicht dat de uitwisseling voor de use case 'Raadplegen vragenlijst' op dit moment niet via het MedMij Afsprakenstelsel kan plaatsvinden.
|MM-1343 = The references to the IHE MHD StructureDefinitions used for mapping purposes in the Images technical design have been replaced by references that resolve.
|MM-1328 = Clarified specifications of which transactions are needed to be supported by DVP's for PDF/A
|MM-1319 = Guidance has been added to the zib-LaboratoryTestResult-Observation profile on the use to of multiple LabortoryTests within one LaboratoryTestResult.
|MM-1285 = In the ValueSet RedenMedicatieAfspraakCodelijst, replaced the custom ART-DECOR code with SNOMED for the .designation.use element.
|MM-1284 = Correctie op volgorde van benoemde processtappen use case raadplegen binnen de informatiestandaard Zelfmetingen, proces stond verkeerd om beschreven.
|MM-1283 = In HCIM Procedure, added mapping to the Requester (NL-CM:14.1.10) concept.
|MM-1281 = Gelijktrekken van woordkeuzes in kwalificatiescripts en addenda voor PDF/A
|MM-1261 = In the narratives of example files, removed the HTML link from references to other resources.
|MM-1260 = In het FO van de BgLZ is de verwijzing naar de toelichting kwalificatie duidelijker gemaakt.
|MM-1259 = Toelichting Kwalificatie Langdurige Zorg aangepast: voor 3 specifieke zibs vermeld dat de vulling optioneel is. Toegepast op zowel 2019.01 als 2020.01
|MM-1256 = Various tweaks to example materials to fix minor bugs.
|MM-1228 = Removed inline examples in TO of PDF/A and replaced them with links to simplifier examples.
|MM-1220 = De leesbaarheid van de kwalificatiepagina is vergroot. Hierbij zijn de procedurele eisen opgeschreven en is de FAQ toegevoegd.
|MM-1207 = Added syntax highlighting to XML code on wiki pages.
|MM-1204 = In the zib-BloodPressure profile, the slices for diastolic and systolic pressure have been made required.
|MM-1177 = The information standard specific artifacts for MedicationProcess, eAfspraak, Images and BgZ have been split out from the main project/package and put into separate projects/packages.
|MM-1175 = Added a comment in the nl-core-address profile at Address.use.extension:AD_use to signal a known issue.
|MM-1169 = Gezien BITS reeds goede naslag biedt voor wijzigingen in de MedMij-informatiestandaarden, is er voor gekozen om de sectie "Paginahistorie" (in functionele ontwerpen) en "History" (in FHIR IG's) te verwijderen.
|MM-1168 = In the profiles on DocumentManifest, removed the profile references to three deleted profiles in the pReference slice.
|MM-1167 = Add a binding strength of "extensible" to maritalStatus in nl-core-patient.
|MM-1165 = To aid in a simpler HCIM mapping, the code-specification extensions on the .system and .use element in the nl-core-contactpoint profile where removed and replaced by one new extension: TelecomType. The usage of this extension and the corresponding mapping are added to the profile definition. Also changed the obsolete HCIM term 'TelecomSoort' in the profile and ConceptMaps to the now used 'TelecomType'.
|MM-1155 = In nl-core-address, changed the slicing logic to enable support for both GBA and ISO land codes.
|MM-1121 = Change the profile requirement for the PDF retrieve use case from the IHE profiles to the profiles adapted by Nictiz to fix slicing issues.
|MM-1119 = De herleidbaarheid van gegevens (data-elementen) wordt expliciet benoemd en een expliciet onderdeel van kwalificatie.
|MM-1118 = All information standards contained sections about error handling without added value to the FHIR specification. This has been replaced with a reference to the Overarching Principles on the main FHIR IG page. The given information here has been deduplicated from the FHIR specification. Examples are given to provide added value by putting error handling in perspective to the use in the information standards.
|MM-1117 = In the gp-JournalEntry profile, adjusted the discriminator for Observation.component (type to pattern, path to code and fixedCodeableConcepts to patternCodeableConcepts). Changed fixedCodeableConcepts to fixed values on coding.system in component.valueCodeableConcept.
|MM-1116 = Removed FHITR patch level version from file names and descriptions of qualification materials.
|MM-1115 = The HCIM MedicationAdministration was incorrectly mentioned on the IG of Medication process, therefore, the FHIR profile and resource endpoint for MedicationAdmistration are removed.
|MM-1097 = Not all requirements for the custom search parameter 'periodofuse' were technically described for servers. Technical implementation notes were added to the IG for for Medication and to the SearchParameter.
|MM-1095 = Add guidance about the use of FHIR id's and Bundle fullUrl's in the different circumstances to the 'overarching principles' section of the MedMij IG.
|MM-1094 = Removed the retired 'zib-Appointment' profile in favor of 'eAfspraak-Appointment' in the BgZ CapabilityStatements. Added documentation about the use of the eAfspraak Appointment profile in combination with HCIM PlannedCareActivityForTransfer to the BgZ FHIR IG. Polished some HCIM terminology in the BgZ FHIR IG.
|MM-1092 = An extra scenario is added for SelfMeasurements MedMij qualification. This scenario adds PHR and XIS testscripts with a search on Observation resources with category 'vital signs'.
|MM-1090 = The AD_use extension was incorrectly used on the .use element instead of the root of the profile. The extension was replaced by a custom extension named AddressType, for a simpler and more complete mapping mechanism for HCIM AddressInformation.
|MM-1085 = To aim for a more general approach in the Questionnaires information standard, textual changes were made in the Questionnaires profiles, README and the Simplifier project so that they no longer state 'MedMij' and 'Nictiz situation'.
|MM-1084 = The profiles for zib-Payer and zib-MedicalDevice have been added to the list of profils in the IG for Questionnaires.
|MM-1083 = Added mapping for zib FamilySituation concept MaritialStatus to the profile for nl-core-patient
|MM-1082 = Voor de PDF/A-standaard was het niet duidelijk welk PDF/A-niveau minimaal ondersteund dient te worden. Op het FO en TO is nu toegevoegd dat het om PDF/A-1 gaat.
|MM-1081 = Added meta.profile declaration to some examples where it was missing.
|MM-1080 = Het kwalificatiemateriaal voor Zelfmetingen wordt per use case gepubliceerd. Een (kandidaat-)deelnemer is niet verplicht te kwalificeren op meerdere use cases. Met het opknippen van het kwalificatiescript wordt dit verduidelijkt.
|MM-1079 = Het kwalificatiemateriaal voor PDF/A wordt per use case gepubliceerd. Een (kandidaat-)deelnemer is niet verplicht te kwalificeren op meerdere use cases. Met het opknippen van het kwalificatiescript wordt dit verduidelijkt.
|MM-1069 = The IHE MHD list of search parameters was deemed to pose a disproportionate implementation burden for servers. A selection of the most appropriate and likely used search parameters has been made.
|MM-1054 = Changed the package dependency of the information standards from the patch level to the minor level, as all patch level packages are interchangable.
|MM-1059 = Fixed a typo in the BgLZ FHIR IG: changed 'Patient.general-pracitioner' to 'Patient.generalPractitioner'
|MM-1053 = Changed mapping name in nl-core-organization profile from 'HCIM Patient-v3.1.1(2017EN)' to the correct 'HealthcareProvider-v3.1.1(2017EN)' as it was incorrect and could lead to misunderstanding.
|MM-1050 = The FHIR specification on Resource.text is not completely clear and found multi interpretable. Therefore, additional explanation and guidance on this subject is added to the MedMij FHIR IG.
|MM-1036 = The code-specification extension was not used on all the required elements where it is required in the qualification material, this has been corrected.
|MM-1034 = It was not possible to distinguish a version-specific identifier among identifiers in the instance of a Media resource. This is solved by adding a mandatory fixed value at identifier.use in the identifier.
|MM-1032 = Removed the explicit slice "masterIdentifier" from the images-Media profile, as it was impossible to define a discriminator. The masterIdentifier concept is now defined directly on Media.identifier.
|MM-1025 = Corrected the slicing logic at the discriminator path in the zib-Procedure profile.
|MM-1017 = The SelfMeasurements IG incorrectly didn't mention the PulseRate profile. This has been added.
|MM-1015 = Added a generated narrative to all example instances.
|MM-1011 = Replaced the term "StructureDefinitions" with the more precise term "profiles" in implementation guides.
|MM-1007 = The IG for the Images information standard included broken links to example instances on Simplifier. These have been removed and replaced with a general link to example instances on Simplifier.
|MM-1006 = Sub-measurements in the zib-GeneralMeasurement have been changed from Observation.component's to a set of related zib-GeneralMeasurement instances. Additionally, the ResultStatusCodelist is added to Observation.status.
|MM-1003 = In extensions zib-Payer-BankInformation and zib-TreatmentDirective-Verification, add the (required) .url element, and remove this url from the calling profile zib-Payer.
|MM-1002 = In extension patient-nationality of the nl-core-patient profile, the binding on NationaleCodelijst has been moved from the root to the code slice.
|MM-997 = The consent-additionalSources extension for the zib-TreatmentDirective profile had a context restriction on Consent.source[x], while it actually was applied on Consent directly. This fix removes that restriction.
|MM-979 = The IG for eAfspraak incorrectly labeled the "$prefetch" operation as "$find", while the OperationDefinition filename and .id also incorrectly used "find" rather than "prefetch". This has been corrected.
|MM-975 = Update CapabilityStatements of PDF/A information standard to include recovered IHE profiles.
|MM-972 = The definition for the use of the lastn operation is unclear in the FHIR specification, therefore interpretation is added to the FHIR IG's of the information standards that use lastn.
|MM-969 = Updated irrelevant value of address.city & address.district in all examples.
|MM-958 = The profile zib-InstructionsForUse profile used capitalized names for the DoseRange and DoseQuantity slices. Since type slices should start lowercased in FHIR, this has been changed to doseRange and doseQuantity.
|MM-954 = Removed several stand-alone examples for the Images standard which were already present in an example Bundle, as they only have meaning within a Bundle context and Removed an illegal extension from one of the Images examples.
|MM-953 = Added documentation to conceptmap-ProbleemStatusCodelijst-To-Condition-Clinical-Status-Codes explaining what the relationship is between codes with equivalence type "specializes".
|MM-949 = The ExtraOxygenAdministration concept in the zib-OxygenSaturation profile was illegally bound on a CodeSystem. This binding has been changed to the corresponding ValueSet.
|MM-947 = Extension code-specification is in use under Address.country, but this context was not yet declared as valid in this extension.
|MM-945 = Added IHE.FormatCode.vs ValueSet to the package, which is referenced in the IHE MHD STU3 profile (which was already included).
|MM-943 = Updated coding.display names in extension-comment extension and in example instance (zib-Stoma-01) to match the display name in LOINC.
|MM-942 = References to XML Schematron have been removed from example instances. These do not serve any implementation purpose and are not permitted by the Java validator.
|MM-941 = In the profile zib-LaboratoryTestResult-DiagnosticReport, corrected the reference to the Specimen Isolate profile, which makes it implementable.
|MM-940 = In an embedded example in profile zib-MedicationUse, an incorrect oid based SNOMED reference was used. This has been corrected.
|MM-939 = The report element in the zib-Procedure profile used a non-existing canonical as a reference to the zib-TextResult profile. This has been fixed.
|MM-938 = For a number of profiles, the StructureDefinition.id in now matches the final part of StructureDefinition.url. This improves predictability of handling the profile set in various reference frameworks.
|MM-931 = Updated example zib-NursingIntervention-01 to conform to its stated profile.
|MM-930 = .description and .id were absent in all ConceptMap recources. These two values have been added, with .id containing the final part of the canonical url.
|MM-929 = Added the code-specification extension to all examples where a ConceptMap is involved to clarify its use.
|MM-926 = In profiles zib-MedicalDeviceRequest and zib-AllergyIntolerance, add type slices on note.author[x] in order to conform to FHIR rules for extending polymorphic elements.
|MM-913 = Verschillende functionele-ontwerppagina's verwezen nog naar een oude versie van het MedMij-afsprakenstel. Deze links zijn aangepast naar de huidige versie.
|MM-901 = The projectgroup has decided that the mapping of CanceledIndicator to .status in FHIR-profile zib-MedicationAgreement could be deleted because the information isn't necessarily anymore.
|MM-900 = The slices on .supportingInformation that reference zib-BodyHeight & zib-BodyWeight in FHIR-profile zib-MedicationAgreement are removed. These elements will be used as separate models.
|MM-899 = Added mapping to MP9 dataset to the timing-exact extension in FHIR profile zib-AdministrationSchedule.
|MM-898 = In zib-LaboratoryTestResult-Observation, Observation.interpretation.coding is sliced to support both the FHIR core ValueSet and the (partially overlapping) HCIM ValueSet.
|MM-894 = In zib-FamilySituation, zib-FamilySituationChild and zib-BodyHeight profiles, remove additional reference types from subject element.
|MM-888 = Een hoofdstuk toegevoegd aan de kwalificatiepagina met uitgangspunten voor kwalificatie.
|MM-870 = The IHE MHD STU3 profiles on which the PDF/A standard is based, were deleted by IHE. Nictiz has copied the two missing profiles to this project.
|MM-857 = Some FHIR example instances don't contain a narrative. Removed the unnecessary text.status values at these examples.
|MM-854 = Add the requirement to the overarching IG that FHIR resources should adhere to the profiles listed in the IG's of the information standard.
|MM-852 = In HCIM MedicationUse profile: redefined slicing on MedicationStatement.derivedFrom into seperate slices to fix validator issues, also added mappings to the MedicationProcess information standard.
|MM-831 = Add documentation on the BSN format in the Patient.identifier:BSN slice of the nl-core-patient profile.
|MM-827 = We have added a small text about the published examples on Simplifier at the IG-pages from every information standards (except Medication).
|MM-816 = Removed additional constraints on .author reference to allow for a Patient reference.
|MM-815 = Tekstuele harmonisatie en verduidelijking rondom het concept "systeemrolcodes" doorgevoerd en bijbehorende tabellen aangevuld en gecorrigeerd in de MedMij standaarden in paragraaf/paragrafen Systeem & Systeemrollen.
|MM-806 = Fixed MM430: 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.
|MM-770 = Updated example materials of nl-core-contactpoint profile to include relevant extensions as required by the zib and fixed mistakes in mapping.
|MM-767 = In zib-LaboratoryTestResult-Speciment(-Isolate), an extension to Speciment.collectionPeriod has been added to support the TimeInterval datatype from the pre-adopted HCIM.
|MM-751 = Upped fhirVersion in FHIR profiles from "3.0.1" to "3.0.2.", changed Simplifier package dependency from "Simplifier.Core.STU3 3.0.3" to "hl7.fhir.r3.core 3.0.2".
|MM-737 = Added a notebox to the Example Searches section in MedicationProcess FHIR IG, for explanation of a known issue regarding the MedicationTreatment search parameter.
|MM-733 = Scenario's voor AllergieIntolerantie in ART-DECOR ontwikkeld, zodat deze in lijn zijn met de zib. Dit geeft meer duiding.
|MM-729 = The description in MedicationStatement.informationSource of profile zib-MedicationStatement still mentioned the missing-type-reference extension, which isn't used anymore. The description has been updated to the new situation with the PractionerRole reference extension.
|MM-722 = De leesbaarheid van het Functioneel Ontwerp van AllergieIntolerantie verbeterd op basis van de zib. Tevens verwijzingen naar de dataset en de scenario's opgenomen.
|MM-717 = De kwalificatiescripts uitgebreid met meer data, datum T geïmplementeerd en dit ontsloten via ADA. Dit komt de kwaliteit en de leesbaarheid van het kwalificatiemateriaal ten goede.
|MM-672 = Er werden verouderde en verschillende schrijfwijzen gehanteerd van de term zib en zibs (afkorting van zorginformatiebouwstenen), dit is gecorrigeerd in de MedMij standaarden
|MM-657 = Removed datatype Reference(EpisodeOfCare) and Reference(Encounter) in the .context element of the profiles zib-AlcoholUse, zib-DrugUse and zib-TobaccoUse.
|MM-616 = The mapping of the element RegistrationDate from HCIM AllergyIntolerance has been changed from AllergyIntolerance.reaction.onset to AllergyIntolerance.onsetDateTime. The mapping on StartDateTime has been changed from AllergyIntolerance.onset[x] to AllergyIntolerance.onsetDateTime.
|MM-614 = The cardinality of element AllergyIntolerance.code is now 1..1 in the zib-AllergyIntolerance profile, so it aligns with HCIM AllergyIntolerance.
|MM-597 = The example for NASAAL was missing <nowiki>urn:oid:</nowiki> preceding the OID value in system.
|MM-594 = Updated date time example in profile to include timezone as required by the FHIR specification.
|MM-593 = Remove space in master Value Set definition for RedenWijzigenStakenMedicatiegebruikCodelijst from Medicatieproces, and apply that to the exported FHIR Value Set in the package.
|MM-529 = In the IG for GP Data, added a missing pipe symbol to the search URL for lab results so that the search is to be interpreted as the code system rather than the code.
|MM-517 = In zib-LaboratoryTestResult-Observation, removed the fixed value of "has-member" in related.type. Added guidance on the use of this profile in relation to other instances.
|MM-513 = In the nl-core-organization examples, added Organization.partOf for the aid of interpreting what an organization with multiple locations looks like.
|MM-511 = In profile zib-LaboratoryTestResult-DiagnosticReport, make the "resultType" slice in DiagnosticReport.category.coding optional in accordance to the zib.
|MM-507 = In "VitalSigns Profile NL", the cardinality of Observation.performer is relaxed from 1..* to 0..*
|MM-492 = 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.
|MM-476 = The unit of the LOINC code used for fasting blood glucose differed from the unit used in the other blood glucose LOINC codes. To rectify this, code 41604-0 was changed to 14770-2 in the valueset 'GlucoseMeetmomentenLOINCCodelijst' and on the SelfMeasurements FHIR IG. This has also been changed in the qualification material.
|MM-467 = Added comment on MedicationRequest.reasonCode in HCIM MedicationAgreement profile to to explain mising HCIM mapping.
|MM-456 = Added clarification for CanceledIndicator in mapping comments of HCIM MedicationAgreement and HCIM AdministrationAgreement profile.
|MM-451 = In het Addenda en in FHIR/ART-DECOR wordt de incomplete code: SoortInterventieCodelijst SNOMED CT 2921100014610 (gedwongen medicatie) vervangen door de juiste: SNOMED CT 29211000146105
|MM-440 = Improvements have been made to the BgZ FHIR IG for the readability and findability of information. It concerns textual and style changes that have no impact on backwards compatibility of the standard.
|MM-437 = Updated search parameter related information on wiki pages for each standard and added chapter on search parameters to overarching principles.
|MM-436 = Aanpassen ConceptMap InterpretatieVlaggenCodelijst-to-observation-interpretation
|MM-433 = Many slicing definitions were incorrect or not working properly, especially slice definitions that are differentiated by bound ValueSets. These slice definitions are now fixed and improved, allowing validators to correctly validate instances.
|MM-430 = The TreatmentDirective profile allowed at most 1 reference to an AdvanceDirective resource, because of restrictions in the FHIR base. There is now an extension inside the source element to allow referencing additional AdvanceDirective resources.
|MM-425 = URL naar BGZ specificatie op FO en TO verwees naar versie 1.0, dit is aangepast naar de huidige en laatste versie 1.1.
|MM-422 = Aanpassen conceptnaam ResultaatVlaggen naar InterpretatieVlaggen in FHIR profiel voor LaboratoryResults.
|MM-421 = To aid in better interoperability between systems, several improvements have been made to the GP Data information standard, in functional design, FHIR IG, FHIR profiles and qualification material. Enumerated this means: Added Encounter (Contactmoment) and added explanation for parted contacts (Deelcontacten); Removed query on Flag, because it was already included in EpisodeOfCare; Queries on general practitioner and patient have been made optional, because they are referenced and/or included in every other resource; Added use-case relevant examples; Aligned CapabilityStatements and qualification material in accordance with the above changes.
|MM-419 = The example search URL for NutritionAdvice contained a paramater for status=active, where the BgZ information standard specifies a search for all known NutritionAdvice resources. Also, status is not a concept in HCIM NutritionAdvice, which makes use of this element unnecessary. As a result, the status parameter is removed from the example search url and from the BgZ qualification material.
|MM-414 = Ten behoeve van leesbaarheid en vindbaarheid van informatie zijn er in het functioneel ontwerp van BgZ verbeteringen doorgevoerd. Het betreft tekstuele-/stijlwijzigingen die geen impact hebben op backwards-compatibility van de standaard.
|MM-404 = In the HCIM Procedure profile, expanded the Procedure.performedPeriod element to Procedure.performed[x]. With this expansion, the profile meets the requirements of the HCIM, namely to capture a moment in time instead of a start/end date.
|MM-359 = Nadere uitwerking van de BgZ kwalificatietoelichting voor XIS.
|MM-358 = Tekstcorrectie op de kwalificatie pagina ToelichtingKwalificatieBgZ.
|MM-348 = Foutieve discrimator path voor HCIM MedicationAgreement bij MedicationStatement.derivedFrom.
|MM-347 = Fix for FHIRpath expression in SearchParameter MedicationDispense-whendispensed.
|MM-346 = Ongeldig discriminator pad in code slicing in ZIB Verrichting.
|MM-322 = Link from mp612dispensetofhirconversiondispense to prescription in profile wrong.
|MM-319 = In the HCIM Problem profile, the .onsetPeriod element was used to capture the HCIM concepts ProblemStartDate and ProblemEndDate, while no period is captured in the HCIM. Therefore, Condition.onsetPeriod is changed to Condition.onsetDateTime and the HCIM mapping for ProblemStartDate is corrected. The mapping for ProblemEndDate has been moved to Condition.abatementDateTime.
|MM-307 = Aanpassen mapping van "Reden wijzigen of staken" en "Reden wijzigen of stoppen gebruik" van HCIM naar MP9.
|MM-295 = Verstrekkingenvertaling: specificaties voor search parameters.
|MM-294 = Naam mapping binnen div. FHIR profielen aangepast conform ZIB: HCIM LaboratoryTestResult-v4.1(2017EN).
|MM-267 = Toevoegen notebox aan FO's om te verduidelijken dat de term "PGO" ook als ander soort eindgebruiker geïnterpreteerd kan worden.
|MM-258 = HCIM PharmaceuticalProduct: Added ValueSet 'IngredientCodeGTINCodeLijst' + correct reference url to ValueSet.
|MM-248 = Fixed typo in sliceName 'medicationTreament' --> 'medicationTreatment'.
|MM-221 = In Observation based profiles, where fixed values are used in .code slices and a value is expected to be present, changed the cardinality to 1..1.
|MM-219 = MedicationUse niet compleet na een resave in Forge.
|MM-210 = MedMij BgZ is nog gebaseerd op 1.0 i.p.v. 1.1
|MM-206 = Reference vanuit Observation naar Specimen Isolate onjuist.
|MM-174 = Corrected search url for PlannedCareActivityForTransfer - DeviceRequest. Added an '&'.
|MM-174 = URL voor PlannedCareActivity- DeviceRequest mist een '&'.
|MM-164 = Medicatietoediening - toegediende hoeveelheid - cardinality mismatch
|MM-162 = Update naar medicatieproces versie 9.0.7.
|MM-161 = CBV codes in ProcedureRequest.
|MM-145 = ContactPerson verwijzing informatiestandaarden vs patient zib.
|MM-144 = Problem zib ClinicalStatus can take on values which are not defined by the HCIM.
|MM-143 = Aanpassing modellering Procedure.performer in het profiel voor HCIM Verrichting.
|MM-142 = Onduidelijkheid in de modellering van de Aanvrager van een LaboratoriumUitslag.
|MM-141 = Vital Signs profielen inconsistent m.b.t. baseDefinition.
|MM-134 = MedicationUse StopType found values do not correspond with MedicationUseStopTypeCodeList values.
|MM-128 = CanceledIndicator possible values.
|MM-127 = TimeOfDay in InstructionsForUse and the Hapi Enumerators.
|MM-125 = Inconsistentie wiki vs simplifier.
|MM-118 = Profiel naam zib-Product niet passend bij Zib FarmaceutischProduct.
|MM-115 = Solved inconsistency in the List of StructureDefinitions. Also we will no longer check PlannedCareActivityForTransfer for MedicationAdministration in section 17 Zorgplan, because we found it was unimplementable as-is. Presumed solution will come from a future HCIM release.
|MM-106 = Het Bundle-MedicationOverview profiel en de technische wiki pagina beschrijven nu hoe de bundle.total bepaald wordt in de MedicationOverview response.
|MM-105 = Raadplegen 6.12 medicatieverstrekkingen (bij apothekers).
|MM-102 = Bundle type 'collection' is vervangen door 'searchset' in de use case voor het raadplegen van het medicatieoverzicht.
|MM-100 = Mapping CBV naar SNOMED codes.
|MM-99 = Interval heeft Period maar geen PeriodUnit op simplifier.
|MM-98 = InstructionsForUse zib informatie model komt niet overeen met simplifier.
|MM-94 = Specimen microorganism en specimenSource mappen naar hetzelfde fhir element.
|MM-71 = reden wijzigen/stoppen gebruik onterecht gemapt op reasonNotTaken.
|MM-66 = Update mappings LaboratoriumUitslag in DiagnosticReport en Observation.
|MM-55 = Profile for HCIM TobaccoUse was missing a specification for PackYears unit - profile updated to 2.0.1.
|MM-54 = Wrong SNOMED code in search URL for FunctionalOrMentalStatus.
|MM-50 = Contact ondersteunt geen klinische contacten.
|MM-48 = Medicatiegebruik/informant is zorgverlener: moet ook practitionerrole mogelijk maken.
|MM-42 = medicatiegebruik - auteur - zorgverlener: kan niet alle info kwijt.
|MM-41 = voorschrijver/zorgverlener/zorgaanbieder past niet in medicationUse.
|MM-23 = Commentaar bij dagdeel codelijst verwijst naar dode URL.
}}<noinclude>
== Doel ==

Bij elke release worden de release notes van het desbetreffende issue in een tabel op de wiki geplaatst. Dit sjabloon is bedoeld om de release notes per issue op een centrale plek te beheren, en om ze te vertalen naar een geformatteerde tabel-rij.

== Gebruik ==

Het sjabloon kan op pagina's ingezet worden met:
<pre>{{BITS-issue|<issue-nummer>}}</pre>

Dit wordt vertaald naar een tabelrij met twee cellen, waarbij de eerste de link naar het issue bevat en de tweede de release note.

=== Onderhoud release notes ===

Het sjabloon haalt de release notes niet zelf op uit BITS, ze moeten handmatig in de switch toegevoegd worden. Deze is te zien bij het bewerken van de pagina. Voor het toevoegen van een nieuw issue, moet een regel worden toegevoegd:
<pre>| <issue-nummer> = <release notes></pre>
</noinclude>

MedMij:V2020.01/FHIR PDFA

2020-09-25T12:43:36Z

Vincent Goris: MM-1228: Removed inline examples in TO of PDF/A and replaced them with links to simplifier examples.

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|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

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub/FHIR_IG#Use case overarching principles|use case overarching principles]].

===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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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)=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

==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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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 'Find Document References' and 'Retrieve Document', implementing 'Find Document Manifest' is optional for Document Consumer. 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 RESTful] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.

<pre>
GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}
</pre>

An example query to search for DocumentReferences which have status "''current''" and which are indexed/created after 01-01-2010:
<pre>GET [base]/DocumentReference?status=current&indexed=ge2010-01-01</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 search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

{| 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
|-
| <code>indexed</code>
| date
| When this document reference was created
| <code>created</code>
| date
| When this document manifest created
|-
| <code>status</code>
| token
| current / superseded
| <code>status</code>
| token
| current / superseded
|}

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

* 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'.

{{Sjabloon:Voorbeelden}}

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

{{Sjabloon:Voorbeelden}}

==List of profiles==
IHE has defined profiles 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 conformance resources.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

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

{{IssueBox|The IHE profiles 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.}}

The complete set of used profiles for the response message is listed in the table below.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentManifest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|}
{{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]
</pre>

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

{{Sjabloon:Voorbeelden}}

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

==List of profiles==

IHE has defined profiles 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 in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|}

{{Sjabloon:Voorbeelden}}

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

MedMij:Vprepub-2020.01/FHIR PDFA

2020-09-25T12:43:36Z

Vincent Goris: MM-1228: Removed inline examples in TO of PDF/A and replaced them with links to simplifier examples.

MedMij:V2020.01/FHIR PDFA

2020-09-25T12:41:37Z

Vincent Goris: MM-1328: Changed specifications of which transactions are needed to be supported by DVP

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|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

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub/FHIR_IG#Use case overarching principles|use case overarching principles]].

===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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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)=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

==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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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 'Find Document References' and 'Retrieve Document', implementing 'Find Document Manifest' is optional for Document Consumer. 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 RESTful] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.

<pre>
GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}
</pre>

An example query to search for DocumentReferences which have status "''current''" and which are indexed/created after 01-01-2010:
<pre>GET [base]/DocumentReference?status=current&indexed=ge2010-01-01</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 search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

{| 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
|-
| <code>indexed</code>
| date
| When this document reference was created
| <code>created</code>
| date
| When this document manifest created
|-
| <code>status</code>
| token
| current / superseded
| <code>status</code>
| token
| current / superseded
|}

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

* 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://nictiz.nl/fhir/StructureDefinition/IHE.MHD.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]

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

==List of profiles==
IHE has defined profiles 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 conformance resources.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

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

{{IssueBox|The IHE profiles 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.}}

The complete set of used profiles for the response message is listed in the table below.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentManifest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|}
{{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]
</pre>

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

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

==List of profiles==

IHE has defined profiles 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 in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|}

{{Sjabloon:Voorbeelden}}

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

MedMij:Vprepub-2020.01/FHIR PDFA

2020-09-25T12:41:37Z

Vincent Goris: MM-1328: Changed specifications of which transactions are needed to be supported by DVP

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|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

'''Note''': This implementation guide builds on the general guidelines described in the [[MedMij:Vprepub/FHIR_IG#Use case overarching principles|use case overarching principles]].

===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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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)=
[[Bestand:Afsprakenstelsel-01.png|link=https://www.medmij.nl/afsprakenstelsel/|rechts |100px|Go to Afsprakenstelsel]]
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
This section summarizes the IHE MHD profile to find and retrieve PDF/A documents in a MedMij context.

==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|nictiz.fhir.nl.stu3.zib2017|title=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|nictiz.fhir.nl.stu3.zib2017|title=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 'Find Document References' and 'Retrieve Document', implementing 'Find Document Manifest' is optional for Document Consumer. 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 RESTful] and [http://hl7.org/fhir/search.html search] specification. A search query would have the following format.

<pre>
GET [base]/DocumentReference?status=[status]{&[parameters]}
GET [base]/DocumentManifest?status=[status]{&[parameters]}
</pre>

An example query to search for DocumentReferences which have status "''current''" and which are indexed/created after 01-01-2010:
<pre>GET [base]/DocumentReference?status=current&indexed=ge2010-01-01</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 search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

{| 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
|-
| <code>indexed</code>
| date
| When this document reference was created
| <code>created</code>
| date
| When this document manifest created
|-
| <code>status</code>
| token
| current / superseded
| <code>status</code>
| token
| current / superseded
|}

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

* 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://nictiz.nl/fhir/StructureDefinition/IHE.MHD.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]

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

==List of profiles==
IHE has defined profiles 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 conformance resources.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

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

{{IssueBox|The IHE profiles 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.}}

The complete set of used profiles for the response message is listed in the table below.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}

{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgverlener
| HealthProfessional
| Practitioner
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner|nictiz.fhir.nl.stu3.zib2017}}
|-
| Zorgaanbieder
| HealthcareProvider
| Organization
| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-organization|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentManifest
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest|nictiz.fhir.nl.stu3.zib2017}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|}
{{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]
</pre>

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

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

==List of profiles==

IHE has defined profiles 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 in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

{{MedMij:NoteBoxPackage|p1=nictiz.fhir.nl.stu3.zib2017}}
{| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| style="background-color: white;"| PractitionerRole
| style="background-color: white;"| {{Simplifier|http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.ProvideDocumentBundle|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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.Minimal.DocumentReference|nictiz.fhir.nl.stu3.zib2017}}
|-
| 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|nictiz.fhir.nl.stu3.zib2017}}
|}

{{Sjabloon:Voorbeelden}}

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

MedMij:V2020.01/Kwalificatie

2020-09-25T12:36:34Z

Vincent Goris: MM-1393, toevoegen voorbeeldbestanden kwalificatie PDF/A

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Register_van_informatiestandaarden Register van Informatiestandaarden] met daarin de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder van het register van Informatiestandaarden.

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel112/Catalogus catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Kwalificatie_FAQ FAQ] tref je de veelgestelde vragen tijdens het kwalificatietraject.

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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 [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Ontwerpen MedMij informatiestandaard], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van de binnen MedMij toegelaten informatiestandaarden raadpleeg het [[MedMij:Register_van_informatiestandaarden| Register van informatiestandaarden]].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_Vprepub.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

===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_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_Vprepub.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantieVertaling Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_Vprepub.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_Vprepub.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_Vprepub.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zib|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

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

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

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_Vprepub.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

MedMij:Vprepub-2020.01/Kwalificatie

2020-09-25T12:36:34Z

Vincent Goris: MM-1393, toevoegen voorbeeldbestanden kwalificatie PDF/A

{{MedMij:Vprepub/Issuebox}}
__NUMBEREDHEADINGS__





=Introductie=
Nictiz beheert voor Stichting MedMij het [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Register_van_informatiestandaarden Register van Informatiestandaarden] met daarin de informatiestandaarden die binnen MedMij gebruikt worden. Om de informatiestandaarden te kunnen toepassen binnen MedMij, zijn gegevensdiensten gedefinieerd die bestaan uit één of meerdere systeemrollen vanuit een informatiestandaard. Stichting MedMij omschrijft de gegevensdiensten en bepaalt vanaf wanneer en tot hoelang de gegevensdienst op het MedMij-netwerk gebruikt kan worden. Dit doet Stichting MedMij in samenspraak met Nictiz als beheerder van het register van Informatiestandaarden.

Voor het implementeren van informatiestandaarden en daaruit de gedefinieerde gegevensdiensten voor MedMij, is een Nictiz kwalificatie van toepassing. De kwalificaties worden uitgevoerd door het kwalificatiecentrum van Nictiz en vinden plaats per systeemrolcode. De systeemrolcode vormt de koppeling van een (MedMij) informatiestandaard aan een, in de [https://afsprakenstelsel.medmij.nl/display/MedMijAfsprakenstelsel112/Catalogus catalogus] vermelde, gegevensdienst van het MedMij-netwerk.

Kwalificatiescripts en meer informatie over een kwalificatie zijn te vinden via de betreffende paragrafen onder [[MedMij:Vprepub/Kwalificatie#Kwalificatiebenodigdheden|kwalificatiebenodigdheden]].<section end=medmij_kwalificatie_introductie />

Voor een optimaal verloop van de kwalificatie is het belangrijk dat via de juiste kanalen wordt gecommuniceerd. Raadpleeg hiervoor het onderstaand communicatiekanalenoverzicht:
* Procedure en planninggerelateerde vragen: [mailto:kwalificatie@medmij.nl kwalificatie@medmij.nl]
* Inhoudelijke vragen of opmerkingen over de implementatie van informatiestandaarden en gegevensdiensten: [https://bits.nictiz.nl/projects/MM BITS]
* Algemene vragen MedMij: [mailto:info@medmij.nl info@medmij.nl]

In onze [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Kwalificatie_FAQ FAQ] tref je de veelgestelde vragen tijdens het kwalificatietraject.

== Kwalificatie gebruik van terminologie ==
Op de kwalificatiepagina wordt gesproken over DVP en PGO of DVZA en XIS. <br>
Een DVP dient altijd te kwalificeren met een PGO en een DVZA dient altijd te kwalificeren met achterliggend bronsysteem of bronsystemen (XIS).

{| class="wikitable"
|-
| '''DVP''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert een Persoonlijke gezondheidsomgeving, een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''DVZA''' || Dit betreft een rol in het MedMij Afsprakenstelsel. <br>
Levert Diensten aan de Zorgaanbieder gerelateerd aan de uitwisseling tussen Persoon en Zorgaanbieder en committeert zich hiervoor aan de naleving van de afspraken van het MedMij Afsprakenstelsel.
|-
| '''Persoonsdomein''' || Alle Personen en alle Dienstverleners personen vormen samen het Persoonsdomein.
|-
| '''PGO''' || Een Persoonlijke gezondheidsomgeving is een dienst aan de Persoon voor de regie op zijn gezondheid die minimaal gegevensuitwisseling met de Zorgaanbieder mogelijk maakt middels het MedMij Afsprakenstelsel.
|-
| '''XIS''' || Het systeem of geheel van de systemen waarin de zorgaanbieder het medisch dossier van de persoon bijhoudt.
|-
| '''Zorgaanbiedersdomein''' || Alle Zorgaanbieders en alle Dienstverleners zorgaanbieder vormen samen het Zorgaanbiedersdomein.
|}

=Algemene voorwaarden voor kwalificatie=
Een (kandidaat-) deelnemer kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
# Kennis en begrip van [https://www.medmij.nl/afsprakenstelsel/ 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 [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub/Ontwerpen MedMij informatiestandaard], zoals beschreven op de informatiestandaarden wiki van Nictiz.
# Kennis en begrip en het kunnen toepassen van de verschillende tabellen, waardenlijsten 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 van 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 (kandidaat-) deelnemer levert voor deze informatie schermafdrukken op voor controle.'''
# Deze kwalificatie toetst geen infrastructurele eisen.

=Procedurele eisen voor kwalificatie=
Naast de bovengenoemde algemene voorwaarden voor kwalificatie dient een kwalificerende (kandidaat-) deelnemer ook te voldoen aan de procedurele eisen voor kwalificatie. Om het kwalificatietraject niet onnodig te vertragen wordt van een (kandidaat-) deelnemer verwacht dat deze de onderstaande procedurele eisen in acht neemt.

* Indien niet kan worden voldaan aan de functionele en/of technische eisen van een gegevensdienst, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Indien gebruik gemaakt wordt van de vrijheidsgraden die de gegevensdiensten BgGGZ, BgLZ, BgZ en PDF/a bieden, dient dit minimaal 2 weken '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* De testexecutie dient 100% succesvol geslaagd te zijn voordat gestart kan worden met de kwalificatie. Indien dit niet het geval is dient dit '''voorafgaand aan de kwalificatie''' aangegeven te worden.
* Het uitgevoerde certificering-testscript dient niet ouder te zijn dan één week voor de aanlevering van het (pre)kwalificatiemateriaal. Nictiz staat in zijn recht om te bepalen of een test executie is verouderd en daarom af te wijzen.
* Bij het instellen van een variabele T datum door een DVZA, dient de datum gelijk te zijn aan de datum waarop de Touchstone testexecutie is uitgevoerd.
* Voor zowel DVP als DVZA geldt dat de schermafdrukken overeen dienen te komen met de uitgevoerde Touchstone testexecutie die is bijgevoegd in het aanleverformat. Wanneer hier niet aan wordt voldaan leidt dit tot een afwijzing.
* Het kwalificatiemateriaal dient in het juiste formaat aangeleverd te worden. Gebruik voor het aanleveren van het kwalificatiemateriaal altijd het aanleverformat behorende bij de gegevensdienst. In het aanleverformat staat per dia beschreven welke schermafdruk wordt verwacht.
** Voor een DVP geldt dat er schermafdrukken gemaakt dienen te worden van de interface van een PGO.
** Voor een DVZA geldt dat er schermafdrukken gemaakt dienen te worden (van de combinatie) van de achterliggende bronsystemen waarmee men kwalificeert. '''Let op''': Wanneer men voor een nieuwe combinatie van bronsystemen acht te kwalificeren wordt dit behandeld als een nieuwe kwalificatie waarbij ook van die nieuwe combinatie schermafdrukken dienen te worden gemaakt. Schermafdrukken van andere interfaces zoals van een XDS worden afgekeurd.

=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 functioneel ontwerp van de informatiestandaard.

==Systeemrol 'Raadplegen' (Persoonsdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Raadplegen':
<section begin=Uitgangspunten_Systeemrol_Raadplegen />
* De set van de gegevensdienst is bewust als één geheel vastgesteld. Daarvoor kwalificeer je wel/niet binnen de MedMij context.
* Een PGO dient alle functionele data-elementen conform de dataset van de informatiestandaard te tonen aan de gebruiker. De uitzonderingen per gegevensdienst zijn beschreven in de bijbehorende functionele ontwerpen.
* 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.
* Een PGO biedt de persoon inzicht in herkomst van de verzamelde gegevens, en wanneer deze gegevens verzameld zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door de PGO bij ontvangst van de geraadpleegde gegevens.<section end=Uitgangspunten_Systeemrol_Raadplegen />

==Systeemrol 'Beschikbaarstellen' (Zorgaanbiedersdomein)==
Hieronder volgen de generieke uitgangspunten voor de kwalificatie van de systeemrol 'Beschikbaarstellen':
<section begin=Uitgangspunten_Systeemrol_Beschikbaarstellen />
* Een DVZA dient de gehele gegevensdienst te ondersteunen. Uitzonderingen worden toegelicht in de bijbehorende functionele ontwerpen en kwalificatiescripts.
* Een DVZA 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 de DVZA 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 foutcode moet ingebouwd worden door het XIS. Hierop wordt de DVZA ook gekwalificeerd.<section end=Uitgangspunten_Systeemrol_Beschikbaarstellen />

==Systeemrol 'Ontvangen' (Zorgaanbiedersdomein)==
Hieronder volgt een generiek uitgangspunt voor de kwalificatie van de systeemrol 'Ontvangen':
* Een XIS biedt inzicht in herkomst van de ontvangen gegevens, en wanneer deze gegevens ontvangen zijn. Dit betreft concepten die meer technisch van aard zijn, maar voor de eenduidigheid en herleidbaarheid van de gegevens noodzakelijk zijn. Dit betreffen de metagegevens zoals gelogd door het XIS bij ontvangst van de gestuurde gegevens.

=Kwalificatie aansluiten op Touchstone=
Nictiz stelt het testsysteem Touchstone beschikbaar voor het testen van systeemrollen met bijbehorende MedMij gegevensdiensten als voorbereiding op het kwalificatieproces.
<br>MedMij (kandidaat-) deelnemers kunnen Touchstone eveneens gebruiken in de ontwikkel- en testfase voor het vroegtijdig testen en/of valideren van de FHIR berichten.
* Documentatie over het aansluiten op Touchstone is te vinden op de pagina Kwalificatie aansluiten in de sectie [[MedMij:Vprepub/Kwalificatie_aansluiten#Configureren_simulator|configureren simulator]].
* Voor uitleg over gebruik van de simulator en tokens, zie [[MedMij:Vprepub/Qualification | gebruik tokens]]
<section end=medmij_kwalificatie_introductie />
<span id="Kwalificatiescripts"></span><section begin=medmij_kwalificatiescripts />

=Kwalificatiebenodigdheden=
Het kwalificatiemateriaal voor de meest recente versies van de verschillende systeemrollen met bijbehorende MedMij gegevensdiensten is in dit hoofdstuk te vinden.
<br> Voor een actueel overzicht van de binnen MedMij toegelaten informatiestandaarden raadpleeg het [[MedMij:Register_van_informatiestandaarden| Register van informatiestandaarden]].

=Kwalificatiescripts=
==Basisgegevensset Zorg 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen BgZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen_BgZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen_BgZ.zip]]
* [[Media: Aanleverformat - Raadplegen BgZ_Vprepub.zip|3. Aanleverformat - Raadplegen BgZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevenssetZorg Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen BgZ.pdf]]
* [[Media: Beoordelingsformulier_BasisgegevenssetZorg_Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen BgZ.pdf]]

===Uitgebreide gegevensset===
Nota bene: onderstaande kwalificatiescripts bevatten een uitgebreidere gegevens set voor de BgZ. Deze worden '''niet''' gebruikt voor kwalificatie.

* [[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 2.0==
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Raadplegen Laboratoriumresultaten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten_Vprepub.pdf|2. Addenda - Kwalificatiescript – MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Laboratoriumresultaten.zip]]
* [[Media: Aanleverformat - Raadplegen Laboratoriumresultaten_Vprepub.zip|3. Aanleverformat - Raadplegen Laboratoriumresultaten.zip]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Laboratoriumresultaten.pdf]]
* [[Media: Beoordelingsformulier Laboratoriumresultaten Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Laboratoriumresultaten.pdf]]

==AllergieIntolerantie 2.0==

===AllergieIntolerantie===
* [[MedMij:Vprepub/kw-MM-AIB-FHIR|1. Kwalificatiescript - MedMij Beschikbaarstellen AllergieIntolerantie gegevens]]
* [[MedMij:Vprepub/kw-MM-AIR-FHIR|1. Kwalificatiescript - MedMij Raadplegen AllergieIntolerantie gegevens]]
* [[Media: Aanleverformat - Beschikbaarstellen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen AllergieIntolerantie.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantie_Vprepub.zip|3. Aanleverformat - Raadplegen AllergieIntolerantie.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantie Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen AllergieIntolerantie.pdf]]

===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_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Aanleverformat - Raadplegen AllergieIntolerantieVertaling_Vprepub.zip|3. Aanleverformat - Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.zip]]
* [[Media: Beoordelingsformulier AllergieIntolerantieVertaling Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen medicatiegerelateerde allergie- en intolerantiegegevensvertaling.pdf]]

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

==Zelfmetingen 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen Zelfmetingen.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Ontvangen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Ontvangen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Raadplegen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Raadplegen Zelfmetingen.zip]]
* [[Media: Aanleverformat - Sturen Zelfmetingen_Vprepub.zip|3. Aanleverformat - Sturen Zelfmetingen.zip]]
* [[Media: Beoordelingsformulier Meetwaardenvitalefuncties Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Zelfmetingen.pdf]]
* [[Media: Beoordelingsformulier_zelfmetingenvanvitalefuncties_Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen Zelfmetingen.pdf]]

==PDF/A 3.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|1. Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Ontvangen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen PDFA.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Sturen PDFA_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Sturen PDFA.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen PDFA_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen PDFA.zip]]
* [[Media: Aanleverformat - Ontvangen PDFA_Vprepub.zip|3. Aanleverformat - Ontvangen PDFA.zip]]
* [[Media: Aanleverformat - Raadplegen PDFA_Vprepub.zip|3. Aanleverformat - Raadplegen PDFA.zip]]
* [[Media: Aanleverformat - Sturen PDFA_Vprepub.zip|3. Aanleverformat - Sturen PDFA.zip]]
* [[Media: Beoordelingsformulier PDFA Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Sturen.pdf|4. Beoordelingsformulier - MedMij Sturen PDFA.pdf]]
* [[Media: Beoordelingsformulier PDFA Ontvangen.pdf|4. Beoordelingsformulier - MedMij Ontvangen PDFA.pdf]]
* [[Media: PDFA Example Documents.zib|5. Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]]

==Huisartsgegevens 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Huisartsgegevens.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Huisartsgegevens.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen huisartsgegevens.zip]]
* [[Media: Aanleverformat - Raadplegen huisartsgegevens_Vprepub.zip|3. Aanleverformat - Raadplegen huisartsgegevens.zip]]
* [[Media: Beoordelingsformulier Huisartsgegevens Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Huisartsgegevens .pdf]]
* [[Media: Beoordelingsformulier Huisartsgegevens Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Huisartsgegevens .pdf]]

==Basisgegevens GGZ 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen Basisgegevens GGZ.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen Basisgegevens GGZ.zip]]
* [[Media: Aanleverformat - Raadplegen Basisgegevens GGZ_Vprepub.zip|3. Aanleverformat - Raadplegen Basisgegevens GGZ.zip]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Beschikbaarstellen.pdf|4. Beoordelingsformulier - MedMij Beschikbaarstellen Basisgegevens GGZ.pdf]]
* [[Media: Beoordelingsformulier BasisgegevensGGZ Raadplegen.pdf|4. Beoordelingsformulier - MedMij Raadplegen Basisgegevens GGZ.pdf]]

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

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

==Vragenlijsten 2.0==
* [[Media:1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|1. Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Beschikbaarstellen en Ontvangen Vragenlijsten.pdf]]
* [[Media:2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten_Vprepub.pdf|2. Addenda - Kwalificatiescript - MedMij Raadplegen en Sturen Vragenlijsten.pdf]]
* [[Media: Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten_Vprepub.zip|3. Aanleverformat - Beschikbaarstellen en Ontvangen vragenlijsten.zip]]
* [[Media: Aanleverformat - Raadplegen en sturen vragenlijsten_Vprepub.zip|3. Aanleverformat - Raadplegen en sturen vragenlijsten.zip]]

<section end=medmij_kwalificatiescripts />
[[Categorie:Kwalificatie]]

Bestand:PDFA Example Documents.zip

2020-09-16T08:38:57Z

Vincent Goris: Voorbeelddocumenten ten behoeve van DVZA kwalificatie voor PDF/A

== Beschrijving ==
Voorbeelddocumenten ten behoeve van DVZA kwalificatie voor PDF/A

MedMij:V2020.01/FHIR PDFA

2020-07-24T14:18:39Z

Vincent Goris: MM-1121, Merge Nictiz IHE and IHE profiles on DocumentManifest & DocumentReference

__NUMBEREDHEADINGS__
{{DISPLAYTITLE:MedMij FHIR Implementation Guide: PDF/A {{VersieInfo|Vprepub|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 search parameters listed below. These search parameters are a selection of the defined search parameters by the IHE MHD profile. The IHE MHD profile contains more search parameters that were deemed to pose a disproportionate implemenation burden for Document Responders. The following subselection still allow Document Consumers with server-side filter capabilities while making this use case more implementable for Document Responders.

{| 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
|-
| status
| token
| current / superseded
| status
| token
| current / superseded
|}

====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://nictiz.nl/fhir/StructureDefinition/IHE.MHD.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.

Due to errors encountered when creating the send use case, that IHE did not intend to fix in STU3, Nictiz has fixed the errors and re-published the IHE.MHD profiles in the Nictiz namespace. Note that IHE originally created two profiles, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

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

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

The complete set of used StructureDefinitions for the response message is listed in the table below.

{{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://nictiz.nl/fhir/StructureDefinition/IHE.MHD.DocumentManifest}}
|-
| -
| -
| DocumentReference
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/IHE.MHD.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]

====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 in the Nictiz namespace. The table below shows the IHE MHD profiles used for the Providing Document Bundle transaction and the relevant HCIM profiles. Note that IHE originally created two profiles on DocumentReference, one for Query DocumentReference and one for Provide DocumentReference which are identical to eachother. For usability purposes, these two profiles have been merged.

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

{{Sjabloon:Voorbeelden}}

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

MedMij:Vprepub-2020.01/FHIR PDFA

2020-07-24T14:18:39Z

Vincent Goris: MM-1121, Merge Nictiz IHE and IHE profiles on DocumentManifest & DocumentReference

MedMij:V2019.01 FHIR LaboratoryResults

2020-06-24T13:28:08Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:Vprepub-2019.01 FHIR LaboratoryResults

2020-06-24T13:28:08Z

Vincent Goris:

MedMij:V2019.01 FHIR LaboratoryResults

2020-06-24T13:27:54Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:Vprepub-2019.01 FHIR LaboratoryResults

2020-06-24T13:27:54Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:V2019.01 FHIR LaboratoryResults

2020-06-24T13:27:10Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs to be supported for this transaction. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

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

Search result parameters:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:Vprepub-2019.01 FHIR LaboratoryResults

2020-06-24T13:27:10Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs to be supported for this transaction. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

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

Search result parameters:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:V2019.01 FHIR LaboratoryResults

2020-06-24T13:26:36Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:Vprepub-2019.01 FHIR LaboratoryResults

2020-06-24T13:26:36Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide LaboratoryResults {{VersieInfo|V2019.01|Laboratoriumresultaten}}}}
{{MedMij:V2019.01_Issuebox_FHIR_IG}}

[[Bestand:MedMij2.png |link=https://www.medmij.nl/|rechts|Naar medmij.nl]]
[[Bestand:LabResults@2x.png|87px|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:V2019.01_OntwerpLabresult|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

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

This page describes patient's use cases for the retrieval of laboratory results, in a personal health environment (PHR) context. Functional specifications are described at the [[MedMij:V2019.01_Ontwerpen| functional design wiki page]]. The technical specification is described here. HL7 FHIR STU3 is used for this purpose.

Many laboratory result observations have important relationships to other observations and need to be grouped together. [http://hl7.org/fhir/observation.html#10.1.4.1 The FHIR specification] defines three structures to do this: DiagnosticReport and DiagnosticReport.result, Observation and Observation.component, and Observation and Observation.related. For the transactions of laboratory results retrieval, the following two grouping structures are relevant.

====Observation====
Individual laboratory results are represented by Observation resources, such as one blood glucose value. The Observation resource can also be used as a structure for a panel or battery observation. Observation.related is used for any supporting result that can be interpreted and used on its own and has one or more different values for method, observation, performer, device, time, and/or error conditions. The top-level observation specifies the grouping code in Observation.code, but typically does not have its own Observation.value, and the set of member observations are listed in the Observation.related element.

====DiagnosticReport====
In contrast to the Observation resource, the DiagnosticReport resource typically includes additional clinical context and some mix of atomic results, images, imaging reports, textual and coded interpretation, and formatted representations. Report conclusions can be expressed as a simple text blob, structured coded data or as an attached fully formatted report such as a PDF. The DiagnosticReport.code names the panel and serves as the grouping element, which is traditionally referred to as a "panel" or "battery" by laboratories. The DiagnosticReport.result element references the individual observations.

Both structures may exist in a XIS. Therefore, two transactions are defined to retrieve a patient's laboratory results. The transaction content either consists of a single and related laboratory results structure or a complete diagnostic report that adds more clinical meaning to the single and related laboratory results. The transactions:

* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results| Retrieve laboratory results]]
* [[MedMij:V2019.01_FHIR_LaboratoryResults#Use_case:_retrieve_laboratory_results_DiagnosticReport| Retrieve laboratory results DiagnosticReport]]

=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/labresults-clientcapabilities|CapabilityStatement: Client}}
| LaboratoryResults process client requirements
|-
| Healthcare professional
| The user of a XIS
| XIS
| Healthcare information system
|[[Bestand: Verwijzing.png| 20px]] {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/labresults-servercapabilities|CapabilityStatement: Server}}
| LaboratoryResults server requirements
|}

=Use case: retrieve laboratory results=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory results transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory results from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory results response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory results 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 laboratory results, it issues a retrieve laboratory results request message.

====Message Semantics====
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]. See [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vprepub_FHIR_IG#Use_of_search_parameters| here] for general rules on search parameters.

{| 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
|-
| date
| date
| Obtained date/time. If the obtained element is a period, a date that falls in the period.
|-
|category
|token
|The classification of the type of observation.
|}

=====Search on fixed category code=====
To distinguish the zib LaboratoryTestResults Observations from other Observation resources, such as zib DrugUse observations, a fixed category code has been added to the zib LaboratoryTestResults profile. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult Observations this category code is SNOMED code '49581000146104' - Laboratory test finding (finding).

=====Including other resources in search results=====
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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or Specimen resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Search URLs=====

<pre>
1. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104
2. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/Observation?category=http://snomed.info/sct|49581000146104&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/Observation?_include=Observation:specimen&category=http://snomed.info/sct|49581000146104date=ge2010-01-01&date=le2011-12-31</pre>

# Retrieves all zib LaboratoryTestResults Observation resources
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResults Observation resources that have an effective date within a 2 year period and includes Specimen information in the search results.

=====Expected Actions=====
The XIS shall process the query to discover Observation resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching observation information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory results 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 observation 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| LaboratoriumUitslag
| LaboratoryTestResult
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain observation and specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 type needs 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/observation.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || Obtained date/time. If the obtained element is a period, a date that falls in the period
|}

==Examples==

=Use case: retrieve laboratory results DiagnosticReport=
{{FHIR-IG-Afsprakenstelsel-Note}}

==Introduction==
The retrieve laboratory diagnostic report transaction is used by the PHR to retrieve laboratory results from a 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="3"|Retrieve Laboratory Results(PULL)
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report request
|style="background-color: white;vertical-align:top;"|Patient (using a PHR)
|style="background-color: white;vertical-align:top;"|Request laboratory diagnostic report from the XIS
|-
|style="background-color: white;vertical-align:top;"|Retrieve laboratory diagnostic report response
|style="background-color: white;vertical-align:top;"|Healthcare professional (using a XIS)
|style="background-color: white;vertical-align:top;"|Serves laboratory diagnostic report 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 laboratory diagnostic report, it issues a retrieve laboratory diagnostic report request message.

====Message Semantics====
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 DiagnosticReport endpoint. This search query URL is configurable by the PHR and has the following format.

<pre>
GET [base]/DiagnosticReport?[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/diagnosticreport.html#search DiagnosticReport].

{| class="wikitable"
! colspan="3" style="font-weight: bold; text-align:left;" | DiagnosticReport
|-
| style="font-weight: bold;" | Name
| style="font-weight: bold;" | Type
| style="font-weight: bold;" | Description
|-
| date
| date
| The clinically relevant time of the report.
|-
| category
| token
| Which diagnostic discipline/department created the report.
|}

=====Search on zib LaboratoryTestResult DiagnosticReport=====
A fixed category code has been added to the zib LaboratoryTestResults profile to distinguish the zib LaboratoryTestResult DiagnosticReports between other DiagnosticReport resources. This fixed category code is solely used for indexing and retrieval of the zib building blocks. For LaboratoryTestResult DiagnosticReport this category is SNOMED code '4241000179101' - Laboratory report (record artifact).

=====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 for example the subject (Patient resource) or performer (Organization / Practitioner resource) or the Observation resource that the clinical resource refers to. The client can use the _include parameter to indicate that the subject resources be included in the results. An example is shown below.

=====Example search URLs=====
<pre>
1. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101
2. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01
3. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&date=ge2010-01-01&date=le2011-12-31
4. GET https://vonk.test-nictiz.nl/DiagnosticReport?category=http://snomed.info/sct|4241000179101&include=DiagnosticReport:result&date=ge2010-01-01&date=le2011-12-31 </pre>

# Retrieves all zib LaboratoryTestResult DiagnosticReport resources
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date greater than 01-01-2010.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period.
# Retrieves all zib LaboratoryTestResult DiagnosticReport resources that have an effective date within a 2 year period and include the referenced Observation resources in the search results.

=====Expected Actions=====
The XIS shall process the query to discover DiagnosticReport resources that match the search parameters given.

===XIS: response message===
The XIS returns an HTTP Status code appropriate to the processing as well as a FHIR Bundle including the matching laboratory diagnostic report information.

====Trigger Events====
The XIS completed processing of the retrieve laboratory diagnostic report 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 DiagnosticReport 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/operationoutcome.html OperationOutcome resource]

=====Message resource content=====
The returned data to the PHR should conform to the profiles listed in the table below. This table shows the relevant zibs and their related 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.

{{NoteBoxPackage|https://simplifier.net/NictizSTU3-Zib2017/~packages|1.3.x|MedMij:V2019.01_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}}
|-
| rowspan="2" | LaboratoriumUitslag
| rowspan="2" | LaboratoryTestResult
| DiagnosticReport
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport}}
|-
| Observation
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation}}
|}
{{Sjabloon:Voorbeelden}}
====Expected Actions====
The PHR shall process the results according to application-defined rules. The PHR should be robust as the response may contain DiagnosticReport, Observation and Specimen resources that match the query parameters.

==Interactions, operations, search parameters==
===Interactions===
The following logical interactions are needed for the retrieve laboratory results 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 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:
{| class=wikitable
! Parameter !! Type !! Description
|-
| [http://hl7.org/fhir/STU3/search.html#include _include] || || To request inclusion of indicated resources, referenced from the Laboratory Results
|-
| [http://hl7.org/fhir/STU3/diagnosticreport.html#search date] || [http://hl7.org/fhir/STU3/search.html#date date] || The clinically relevant time of the report
|}

=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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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

MedMij:V2019.01 FHIR VitalSigns

2020-06-24T13:23:29Z

Vincent Goris:

__NUMBEREDHEADINGS__
{{#customtitle:MedMij FHIR Implementation Guide Vital Signs {{VersieInfo|V2019.01|Zelfmetingen}}}}
{{MedMij:V2019.01_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:V2019.01_OntwerpZelfmetingen|Functioneel]]
circle 1787 230 212 [[MedMij:V2019.01_FHIR_IG|Technisch]]
desc none
</imagemap>

__TOC__

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

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:V2019.01_FHIR_VitalSigns#Use_case:_Retrieve_Vital_Signs|Retrieve vital signs]]
* [[MedMij:V2019.01_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:V2019.01_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:V2019.01_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:V2019.01_FHIR_IG#Mapping_of_coded_concepts|Mapping of coded concepts]].

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