MedMij:Vissue-MM-3540/PDFA Beschikbaarstellen - Bewerkingsoverzicht

Luud Slagter op 9 sep 2022 om 07:07

2022-09-09T07:07:20Z

Luud Slagter: /* Versiebeheer */

2022-09-09T07:03:37Z

Versiebeheer

← Oudere versie		Versie van 9 sep 2022 07:03
Regel 16:		Regel 16:
	\| 11-11-2021 \|\|[https://bits.nictiz.nl/browse/MM-2480 MM-2480]\|\| Correctie en verduidelijking script		\| 11-11-2021 \|\|[https://bits.nictiz.nl/browse/MM-2480 MM-2480]\|\| Correctie en verduidelijking script
	\|-		\|-
	\| 9-09-2021 \|\|[https://bits.nictiz.nl/browse/MM-2361 MM-2361]\|\| ~~Fine tuning~~: inhoudelijke ~~fine tuning~~ na overgang naar de wiki		\| 09-09-2021 \|\|[https://bits.nictiz.nl/browse/MM-2361 MM-2361]\|\| Finetuning: inhoudelijke finetuning 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		\| 29-07-2021 \|\|[https://bits.nictiz.nl/browse/MM-2168 MM-2168]\|\| Optimalisatie script/addenda PDF/A: Raadplegen, Beschikbaarstellen, Ontvangen en Sturen
Regel 26:		Regel 26:
	\| 29-09-2020 \|\| [https://bits.nictiz.nl/browse/MM-1393 MM-1393] \|\| Verbeteren kwalificatiematerialen PDF/A. Verwijderen duplicaten in het addendum		\| 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-1079 MM-1079] \|\| Opknippen usecases in scripts
	\|-		\|-
	\| 03-02-2020 \|\| \|\| Volgorde scenario aangepast en T-waarde in addenda toegevoegd		\| 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).		\| 23-10-2019 \|\| \|\| Verduidelijking en harmonisering van opmaak en tekst (géén inhoudelijke wijzigingen)
	\|}		\|}

Luud Slagter: /* Specifieke voorwaarden voor kwalificatie */

2022-09-09T06:55:20Z

Specifieke voorwaarden voor kwalificatie

← Oudere versie		Versie van 9 sep 2022 06:55
Regel 76:		Regel 76:
	<!-- OPTIONEEL: PLAATS HIER AANVULLENDE SPEFICIEKE VOORWAARDEN -->		<!-- OPTIONEEL: PLAATS HIER AANVULLENDE SPEFICIEKE VOORWAARDEN -->
	Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:		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.		# Kennis en begrip van het IHE MHD-profiel zoals al verwezen vanuit de MedMij-informatiestandaard PDF/A.

	== Op te leveren kwalificatiemateriaal door de leverancier ==		== Op te leveren kwalificatiemateriaal door de leverancier ==

Luud Slagter: /* Inleiding */

2022-09-09T06:48:55Z

Inleiding

Luud Slagter: /* Doelgroep */

2022-09-09T06:45:11Z

Doelgroep

← Oudere versie		Versie van 9 sep 2022 06:45
Regel 35:		Regel 35:
	= Doelgroep =		= Doelgroep =

	De doelgroep van dit document is de XIS leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen PDF/A’ binnen het MedMij afsprakenstelsel.		De doelgroep van dit document is de XIS-leverancier die wil kwalificeren op de systeemrol ‘Beschikbaarstellen PDF/A’ binnen het MedMij-afsprakenstelsel.

	= Begrippenlijst =		= Begrippenlijst =

Luud Slagter: /* Specifieke gegevens */

2022-09-09T06:36:13Z

Specifieke gegevens

← Oudere versie		Versie van 9 sep 2022 06:36
Regel 138:		Regel 138:
	== Specifieke gegevens ==		== Specifieke gegevens ==
	Deze kwalificatie is bedoeld om te controleren of het systeem (XIS) succesvol een PDF/A aan een persoon (PGO) beschikbaar kan stellen. Dit gaat door middel van twee transacties, namelijk: eerst door		Deze kwalificatie is bedoeld om te controleren of het systeem (XIS) succesvol een PDF/A aan een persoon (PGO) beschikbaar kan stellen. Dit gaat door middel van twee transacties, namelijk: eerst door
	‘beschikbaarstellen PDF/A metadata lijst’ gevolgd door ‘beschikbaarstellen PDF/A’. Oftewel ~~Het~~ systeem van de zorgaanbieder (XIS) levert een lijst met metadata over de gevonden PDF/A documenten op voor de patiënt; en		‘beschikbaarstellen PDF/A metadata lijst’ gevolgd door ‘beschikbaarstellen PDF/A’. Oftewel het systeem van de zorgaanbieder (XIS) levert een lijst met metadata over de gevonden PDF/A-documenten op voor de patiënt; en
	daarna levert het systeem van de zorgaanbieder (XIS) de PDF/A op voor de patiënt. 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		daarna levert het systeem van de zorgaanbieder (XIS) de PDF/A op voor de patiënt. 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 ervan uit dat de verbinding reeds succesvol is gemaakt. Daarnaast is het uitgangspunt dat 1 bronsysteem (XIS) bevraagd wordt.
	is gemaakt. Daarnaast is het uitgangspunt dat 1 bronsysteem (XIS) bevraagd wordt.

	=== Document PDF/A ===		=== 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.		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)		* 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)		* DocumentReferentie: onderwerp (omschrijving van document), datum (meestal aanmaakdatum van document), auteur (meestal auteur van document)
	* DocumentInhoud: ContentType		* DocumentInhoud: ContentType

	=== Gegevens PDF/A documenten ===		=== 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		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 =		= Inhoudelijke gegevens scenario’s =

Luud Slagter: /* Inhoudelijke gegevens scenario’s */

2022-09-09T06:33:31Z

Inhoudelijke gegevens scenario’s

← Oudere versie		Versie van 9 sep 2022 06:33
Regel 153:		Regel 153:

	= Inhoudelijke gegevens scenario’s =		= Inhoudelijke gegevens scenario’s =
	In dit hoofdstuk zijn de addenda van scenario 1 en 2 te vinden. Naast de addenda zijn ook documenten nodig voor de kwalificatie, deze zijn te vinden op de kwalificatiepagina onder [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/Kwalificatie#PDF.2FA_3.0 Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]. Aangezien PDF/A wordt toegepast in verschillende ~~zorg domeinen~~, is het mogelijk om naast de ~~voorbeeld documenten~~, gebruik te maken van eigen representatieve ~~test documenten~~. Welke documenten met welke metadata dient vooraf te worden overlegd. In de onderstaande sectie is uiteengezet hoe de metadata wordt ingevuld, zowel wanneer er gebruik wordt gemaakt van de documenten op de wiki als eigen documentatie.		In dit hoofdstuk zijn de addenda van scenario 1 en 2 te vinden. Naast de addenda zijn ook documenten nodig voor de kwalificatie, deze zijn te vinden op de kwalificatiepagina onder [https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/Kwalificatie#PDF.2FA_3.0 Voorbeelddocumenten PDFA voor use case Beschikbaarstellen]. Aangezien PDF/A wordt toegepast in verschillende zorgdomeinen, is het mogelijk om naast de voorbeelddocumenten, gebruik te maken van eigen representatieve testdocumenten. Welke documenten met welke metadata worden gebruikt, dient vooraf te worden overlegd. In de onderstaande sectie is uiteengezet hoe de metadata wordt ingevuld, zowel wanneer er gebruik wordt gemaakt van de documenten op de wiki als eigen documentatie.

	== Scenario 1.1-1.5: persoon 1 wil documenten ~~beschikbaarstellen~~ ==		== Scenario 1.1-1.5: persoon 1 wil documenten raadplegen ==
	Scenario 1 heeft betrekking op persoon 1. Deze persoon probeert zijn/haar PDF/A documenten, die door het bronsysteem van de zorgaanbieder beschikbaar zijn gesteld, op verschillende wijzen te raadplegen in een PGO.		Scenario 1 heeft betrekking op persoon 1. Deze persoon 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:		Om dit te toetsen zijn de volgende gegevens nodig:

	* Persoonsgegevens van persoon 1		* Persoonsgegevens van persoon 1
	* Gegevens van 3 zorgverleners		* Gegevens van 3 zorgverleners
	* Drie ~~documentReferenties~~		* Drie DocumentReferenties
	* De twee documenten zelf		* De twee documenten zelf

Regel 304:		Regel 304:
	\|}		\|}

	== Scenario 2.1-2.5: persoon 2 wil documenten in een ~~documentManifest beschikbaarstellen~~ ==		== Scenario 2.1-2.5: 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:		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 te toetsen zijn de volgende gegevens nodig:

	* Persoonsgegevens van persoon 2		* Persoonsgegevens van persoon 2
	* Drie ~~documentManifests~~		* Drie DocumentManifests
	* Gegevens van 2 zorgverleners		* Gegevens van 2 zorgverleners
	* Twee DocumentReferenties		* Twee DocumentReferenties
Regel 457:		Regel 457:
	\|Content2 \|\|Verwijzing naar DocumentReferentie 5 (zie hierboven), of DocumentReferentie van eigen document.		\|Content2 \|\|Verwijzing naar DocumentReferentie 5 (zie hierboven), of DocumentReferentie van eigen document.
	\|}		\|}
	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 DocumentManifest 1.		Note: In werkelijkheid zou dit hoogstwaarschijnlijk een historische 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 DocumentManifest 1.

	{\| class="wikitable" style="width: 50%;"		{\| class="wikitable" style="width: 50%;"
Regel 466:		Regel 466:
	\|Identifier \|\|Zelf te bepalen.		\|Identifier \|\|Zelf te bepalen.
	\|-		\|-
	\|Status \|\|~~current~~		\|Status \|\|Current
	\|-		\|-
	\|Type \|\| Radiology Consult note, of type van eigen document.		\|Type \|\| Radiology Consult note, of type van eigen document.

Luud Slagter: /* Persoonsgegevens */

2022-09-09T06:25:36Z

Persoonsgegevens

← Oudere versie		Versie van 9 sep 2022 06:25
Regel 129:		Regel 129:
	== Persoonsgegevens ==		== Persoonsgegevens ==
	Het onderdeel Persoonsgegevens bevat algemene gegevens over de persoon zoals naam, adres en woonplaats.		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.		In het MedMij-afsprakenstelsel is vastgelegd dat het BSN door de PGO niet gebruikt mag worden om het XIS 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.		Er is wel een fBSN (fictieve BSN voor testdoeleinden) in de persoonsgegevens opgenomen, aangezien het Raadplegende systeem (PGO) deze nodig kan hebben.

Luud Slagter: /* DocumentReferentie */

2022-09-09T06:20:05Z

DocumentReferentie

← Oudere versie		Versie van 9 sep 2022 06:20
Regel 351:		Regel 351:
	! colspan='2'\|DocumentReferentie 4		! colspan='2'\|DocumentReferentie 4
	\|-		\|-
	\|style="width: 15%;"\|MasterIdentifier \|\|Zelf te bepalen .		\|style="width: 15%;"\|MasterIdentifier \|\|Zelf te bepalen.
	\|-		\|-
	\|Status \|\|Current		\|Status \|\|Current

Luud Slagter: /* Uit te voeren stappen Beschikbaarstellen */

2022-09-09T06:18:56Z

Uit te voeren stappen Beschikbaarstellen

← Oudere versie		Versie van 9 sep 2022 06:18
Regel 111:		Regel 111:
	\|-		\|-
	\| 2.1 \|\| Persoon 2 haalt alle DocumentReferenties op die de status {{term\|current}} hebben en het XIS stelt deze beschikbaar. \|\| Test of een XIS op basis van parameters de juiste DocumentReferenties beschikbaar kan stellen. \|\| Aantonen dat een XIS de juiste DocumentReferenties beschikbaar kan stellen op basis van search parameters (status). \|\| DocumentReferentie 4. \|\| Persoonsgegevens van persoon 2.		\| 2.1 \|\| Persoon 2 haalt alle DocumentReferenties op die de status {{term\|current}} hebben en het XIS stelt deze beschikbaar. \|\| Test of een XIS op basis van parameters de juiste DocumentReferenties beschikbaar kan stellen. \|\| Aantonen dat een XIS de juiste DocumentReferenties beschikbaar kan stellen op basis van search parameters (status). \|\| DocumentReferentie 4. \|\| Persoonsgegevens van persoon 2.
	DocumentReferentie 4: screenshots van metadata van de DocumentReferentie. Let op: omdat filteren aan de ‘voorkant’ van het XIS niet mogelijk is, is de verwachting dat een XIS aan de voorkant DocumentReferenties 4 én 5 laat zien (niet alleen 4 zoals technisch wel verwacht wordt).		DocumentReferentie 4: screenshots van metadata van de DocumentReferentie. Let op: omdat filteren aan de ‘voorkant’ van het XIS wellicht niet mogelijk is, is de verwachting dat een XIS aan de voorkant DocumentReferenties 4 én 5 laat zien (niet alleen 4 zoals technisch wel verwacht wordt).
	\|-		\|-
	\| 2.2<sup>2</sup> \|\| Persoon 2 haalt alle DocumentManifests op die de status {{term\|current}} hebben en het XIS stelt deze beschikbaar. \|\| Test of een XIS op basis van parameters de juiste DocumentManifests beschikbaar kan stellen. \|\| Aantonen dat een XIS de juiste DocumentManifests beschikbaar kan stellen op basis van search parameters (status). \|\| DocumentManifests 1 en 3. \|\| ~~Persoonsgegevens van persoon 2.~~		\| 2.2<sup>2</sup> \|\| Persoon 2 haalt alle DocumentManifests op die de status {{term\|current}} hebben en het XIS stelt deze beschikbaar. \|\| Test of een XIS op basis van parameters de juiste DocumentManifests beschikbaar kan stellen. \|\| Aantonen dat een XIS de juiste DocumentManifests beschikbaar kan stellen op basis van search parameters (status). \|\| DocumentManifests 1 en 3. \|\| DocumentManifests 1 en 3: screenshots van metadata van de DocumentManifests. Let op: omdat filteren aan de ‘voorkant’ van het XIS wellicht niet mogelijk is, is de verwachting dat een XIS aan de voorkant alle DocumentManifests laat zien (niet alleen 1 en 3 zoals technisch wel verwacht wordt).
	DocumentManifests 1 en 3: screenshots van metadata van de DocumentManifests. Let op: omdat filteren aan de ‘voorkant’ van het XIS niet mogelijk is, is de verwachting dat een XIS aan de voorkant alle DocumentManifests laat zien (niet alleen 1 en 3 zoals technisch wel verwacht wordt).
	\|-		\|-
	\| 2.3<sup>2</sup> \|\| Persoon 2 haalt alle DocumentManifests op die de status {{term\|current}} hebben én uit de periode [T-365] t/m [T-60] komen, en het XIS stelt deze beschikbaar. \|\| Test of een XIS geen DocumentManifests, die buiten de door persoon 2 gedefinieerde periode vallen, beschikbaar stelt. \|\| Aantonen dat een XIS de juiste DocumentManifests beschikbaar kan stellen op basis van search parameters (datum en status). \|\| DocumentManifest 1. \|\| ~~Persoonsgegevens van persoon 2.~~		\| 2.3<sup>2</sup> \|\| Persoon 2 haalt alle DocumentManifests op die de status {{term\|current}} hebben én uit de periode [T-365] t/m [T-60] komen, en het XIS stelt deze beschikbaar. \|\| Test of een XIS geen DocumentManifests, die buiten de door persoon 2 gedefinieerde periode vallen, beschikbaar stelt. \|\| Aantonen dat een XIS de juiste DocumentManifests beschikbaar kan stellen op basis van search parameters (datum en status). \|\| DocumentManifest 1. \|\| DocumentManifest 1: screenshots van metadata van het DocumentManifest.
	DocumentManifest 1: screenshots van metadata van het DocumentManifest.
	\|-		\|-
	\| 2.4<sup>2</sup> \|\| Persoon 2 haalt de door het XIS beschikbaargestelde DocumentReferentie op uit het zojuist bekeken DocumentManifest. \|\| Test of een XIS een DocumentReferentie op basis van een DocumentManifest beschikbaar kan stellen. \|\| Aantonen dat een XIS kan omgaan met het beschikbaarstellen van een DocumentReferentie op basis van het technische ID. \|\| DocumentReferentie 4. \|\| ~~Persoonsgegevens van persoon 2.~~		\| 2.4<sup>2</sup> \|\| Persoon 2 haalt de door het XIS beschikbaargestelde DocumentReferentie op uit het zojuist bekeken DocumentManifest. \|\| Test of een XIS een DocumentReferentie op basis van een DocumentManifest beschikbaar kan stellen. \|\| Aantonen dat een XIS kan omgaan met het beschikbaarstellen van een DocumentReferentie op basis van het technische ID. \|\| DocumentReferentie 4. \|\| DocumentReferentie 4: screenshots van metadata van de DocumentReferentie.
	DocumentReferentie 4: screenshots van metadata van de DocumentReferentie.
	\|-		\|-
	\| 2.5<sup>1</sup> \|\| Persoon 2 raadpleegt het door het XIS beschikbaargestelde PDF/A-document uit een DocumentReferentie. \|\| Test of een XIS een PDF/A-document beschikbaar kan stellen vanuit een andere locatie dan een Binary-resource, en deze beschikbaarstelling alleen plaatsvindt als de opvrager geautoriseerd is het document in te zien. \|\| Aantonen dat een XIS PDF/A-documenten beschikbaar kan stellen vanuit een andere locatie dan de Binary-endpoint, en hierbij rekening houdt met de autorisatie van de opvrager. \|\| PDF/A-document van DocumentReferentie 4. \|\| Screenshots van de inhoud van het PDF/A-document van DocumentReferentie 4.		\| 2.5<sup>1</sup> \|\| Persoon 2 raadpleegt het door het XIS beschikbaargestelde PDF/A-document uit een DocumentReferentie. \|\| Test of een XIS een PDF/A-document beschikbaar kan stellen vanuit een andere locatie dan een Binary-resource, en deze beschikbaarstelling alleen plaatsvindt als de opvrager geautoriseerd is het document in te zien. \|\| Aantonen dat een XIS PDF/A-documenten beschikbaar kan stellen vanuit een andere locatie dan de Binary-endpoint, en hierbij rekening houdt met de autorisatie van de opvrager. \|\| PDF/A-document van DocumentReferentie 4. \|\| Screenshots van de inhoud van het PDF/A-document van DocumentReferentie 4.

← Oudere versie		Versie van 9 sep 2022 07:07
Regel 43:		Regel 43:
	! Begrip !! Toelichting		! 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		\| 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.		\| 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.		\| 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.		\| 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 (HTTP-verwijzing).		\| 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 (HTTP-verwijzing).
	\|}		\|}

Regel 229:		Regel 229:
	\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.
	\|-		\|-
	\|Location PDF/A \|\|Verwijzing naar daadwerkelijke PDF/A in een Binary resource (PDF/A ~~Document~~ 1).		\|Location PDF/A \|\|Verwijzing naar daadwerkelijke PDF/A in een Binary-resource (PDF/A-document 1).
	\|-		\|-
	\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.
Regel 257:		Regel 257:
	\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.
	\|-		\|-
	\|Location PDF/A \|\|Verwijzing naar daadwerkelijke PDF/A in een Binary resource (PDF/A ~~Document~~ 2).		\|Location PDF/A \|\|Verwijzing naar daadwerkelijke PDF/A in een Binary-resource (PDF/A-document 2).
	\|-		\|-
	\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.
Regel 285:		Regel 285:
	\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.
	\|-		\|-
	\|Location PDF/A \|\|Verwijzing naar PDF/A in een Binary resource met een foutieve ID.		\|Location PDF/A \|\|Verwijzing naar PDF/A in een Binary-resource met een foutieve ID.
	\|-		\|-
	\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.
Regel 370:		Regel 370:
	\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.
	\|-		\|-
	\|Location PDF/A \|\|Verwijzing naar een willekeurige PDF/A anders dan in een Binary resource (indien dit niet wordt ondersteund, een verwijzing naar een willekeurige PDF/A in een Binary resource).		\|Location PDF/A \|\|Verwijzing naar een willekeurige PDF/A anders dan in een Binary-resource (indien dit niet wordt ondersteund, een verwijzing naar een willekeurige PDF/A in een Binary-resource).
	\|-		\|-
	\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.
Regel 398:		Regel 398:
	\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Language \|\|Bij ondersteuning van dit concept een waarde invoeren.
	\|-		\|-
	\|Location PDF/A \|\|Verwijzing naar een willekeurige PDF/A anders dan in een Binary resource (indien dit niet wordt ondersteund, een verwijzing naar een willekeurige PDF/A in een Binary resource).		\|Location PDF/A \|\|Verwijzing naar een willekeurige PDF/A anders dan in een Binary-resource (indien dit niet wordt ondersteund, een verwijzing naar een willekeurige PDF/A in een Binary-resource).
	\|-		\|-
	\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.		\|Security label \|\|Bij ondersteuning van dit concept een waarde invoeren.

← Oudere versie		Versie van 9 sep 2022 06:48
Regel 57:		Regel 57:
	= Inleiding =		= Inleiding =
	Deze pagina bevat de te doorlopen scripts bij kwalificatie voor de systeemrollen ‘Beschikbaarstellen PDF/A		Deze pagina bevat de te doorlopen scripts bij kwalificatie voor de systeemrollen ‘Beschikbaarstellen PDF/A
	metadata lijst bij patient’ en ‘Beschikbaarstellen PDF/A document bij patient’ binnen het MedMij afsprakenstelsel. De kwalificatie wordt door de kwalificator uitgevoerd met de Nictiz kwalificatiesimulator, die is ingericht op een		metadata lijst bij patient’ en ‘Beschikbaarstellen PDF/A document bij patient’ 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.		FHIR-server. De kwalificatiesimulator kan berichten verzenden en ontvangen. Er wordt gebruik gemaakt van testpatiënten met fictieve BSN's.

	==Algemene voorwaarden voor kwalificatie==		==Algemene voorwaarden voor kwalificatie==
	Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:		Een leverancier kan starten met een kwalificatie, als hij voldoet aan onderstaande voorwaarden:
	# Kennis en begrip van MedMij afsprakenstelsel.		# 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 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 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 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 pagina		# Kennis en begrip, en het naleven van de aandachtspunten zoals beschreven op deze pagina.
	# Alle gegevens die de kwalificerende partij zelf moet invoeren zijn te vinden in de kwalificatiedocumentatie.		# 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.		# Onjuist ingevoerde gegevens (ook tijd/datum etc.) zullen leiden tot vertraging van en kunnen blokkerend zijn voor het kwalificatieproces.
Regel 76:		Regel 76:
	<!-- OPTIONEEL: PLAATS HIER AANVULLENDE SPEFICIEKE VOORWAARDEN -->		<!-- OPTIONEEL: PLAATS HIER AANVULLENDE SPEFICIEKE VOORWAARDEN -->
	Voor deze informatiestandaard gelden de volgende specifieke voorwaarden:		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.		# Kennis en begrip van het IHE MDH profiel zoals al verwezen vanuit de MedMij-informatiestandaard PDF/A.

	== Op te leveren kwalificatiemateriaal door de leverancier ==		== Op te leveren kwalificatiemateriaal door de leverancier ==
	# Schermafdrukken van de verschillende kwalificatiestappen zoals beschreven bij de "Uit te voeren stappen"		# 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 het XIS.		# De kwalificator op de FHIR-server vangt de berichten af die verstuurd zijn vanaf het XIS.

	== Uit te voeren stappen Beschikbaarstellen ==		== Uit te voeren stappen Beschikbaarstellen ==
	De volgende stappen moeten worden uitgevoerd, voor de verschillende ~~scenario’s~~:		De volgende stappen moeten 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. }}		{{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. }}