MedMij:Vissue-NICTIZ-15096/OntwerpPDFA: verschil tussen versies
(→Raadplegen medische gegevens in PDF/A: Toevoegen terminologie MM: verzamelen) |
(→Bedrijfsrollen: Toevoegen terminologie 'delen') |
||
(4 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
Regel 95: | Regel 95: | ||
=== Bedrijfsrollen === | === Bedrijfsrollen === | ||
− | Deze use case kent twee bedrijfsrollen. | + | Deze use case kent twee bedrijfsrollen. N.B. in onderstaande tabellen en figuren wordt gesproken over 'raadplegen' wat in de MedMij context ook wel 'verzamelen' wordt genoemd. |
{| class="wikitable" "cellpadding="10" width="50%" | {| class="wikitable" "cellpadding="10" width="50%" | ||
Regel 148: | Regel 148: | ||
* XIS (zorgaanbieder) | * XIS (zorgaanbieder) | ||
− | Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van zorgaanbieder naar de patiënt. | + | Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van zorgaanbieder naar de patiënt. N.B. in onderstaande tabellen en figuren wordt gesproken over 'raadplegen' wat in de MedMij context ook wel 'verzamelen' wordt genoemd. |
{| class="wikitable" "cellpadding="10" | {| class="wikitable" "cellpadding="10" | ||
Regel 248: | Regel 248: | ||
====Sturen van gezondheidsinformatie in PDF/A==== | ====Sturen van gezondheidsinformatie in PDF/A==== | ||
− | Het sturen van een gezondheidsinformatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder). | + | Het sturen, ook wel delen, van een gezondheidsinformatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder). |
Om uitwisseling van PDF/A-bestanden tot stand te brengen, neemt MedMij zoveel mogelijk over van het [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf MHD-profiel] (Mobile access to Health Documents) van [https://wiki.ihe.net/index.php/Main_Page IHE] (Integrating the Healthcare Enterprise) dat een RESTful / HTTP-interface definieert naar een XDS-omgeving met behulp van HL7 FHIR STU3-bronnen. De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf IHE MHD-profiel]. | Om uitwisseling van PDF/A-bestanden tot stand te brengen, neemt MedMij zoveel mogelijk over van het [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf MHD-profiel] (Mobile access to Health Documents) van [https://wiki.ihe.net/index.php/Main_Page IHE] (Integrating the Healthcare Enterprise) dat een RESTful / HTTP-interface definieert naar een XDS-omgeving met behulp van HL7 FHIR STU3-bronnen. De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD_Rev.2.4_TI_2018-07-24.pdf IHE MHD-profiel]. | ||
Regel 264: | Regel 264: | ||
=== Bedrijfsrollen === | === Bedrijfsrollen === | ||
− | Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel. | + | Deze use case onderscheidt twee bedrijfsrollen, namelijk de ''Patiënt'' en de ''Zorgaanbieder'' zoals te zien in onderstaande tabel. N.B. in onderstaande tabellen en figuren wordt gesproken over 'sturen' wat in de MedMij context ook wel 'delen' wordt genoemd. |
{| class="wikitable" "cellpadding="10" width="50%" | {| class="wikitable" "cellpadding="10" width="50%" | ||
Regel 321: | Regel 321: | ||
* XIS (zorgaanbieder) | * XIS (zorgaanbieder) | ||
− | Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van patiënt naar zorgaanbieder. | + | Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van patiënt naar zorgaanbieder. N.B. in onderstaande tabellen en figuren wordt gesproken over 'sturen' wat in de MedMij context ook wel 'delen' wordt genoemd. |
{| class="wikitable" "cellpadding="10" | {| class="wikitable" "cellpadding="10" |
Huidige versie van 4 jun 2024 om 10:41
Dit is een tijdelijke pagina met wijzigingen voor issue NICTIZ-15096. De gepubliceerde versie vind je hier. |
Dit is een werkpagina. De gepubliceerde versie kan hier gevonden worden: https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vcurrent_Ontwerpen |
Inhoud
- 1 Inleiding
- 2 Use Cases
- 2.1 Use case: Raadplegen gezondheidsinformatie in PDF/A door patiënt
- 2.2 Use case: Sturen gezondheidsinformatie in PDF/A door patiënt
- 3 Functionaliteit
- 4 Verantwoordelijkheid voor informatie
- 5 Afschermen van gegevens
- 6 Infrastructuur
- 7 Referenties
- 8 Release notes
- 9 Ondersteuning
1 Inleiding
1.1 Algemeen
Voor de uitwisseling van documentgebaseerde, ongestructureerde medische gegevens of gezondheidsinformatie gebruikt MedMij de PDF/A-standaard. PDF/A is een ISO-gestandaardiseerde variant van het gewone PDF-formaat. PDF/A is een van de door Forum Standaardisatie aanbevolen standaarden. Meer informatie over PDF/A vindt u hier: https://www.forumstandaardisatie.nl/standaard/pdf-nen-iso.
Het formaat is specifiek ontwikkeld voor correcte weergave van de inhoud op langere termijn. Het beoogt statische paginainhoud weer te geven en is geschikt voor het opslaan van digitale documenten waar inhoud en context niet meer van mag veranderen. Zo kunnen patiënt en zorgverlener alvast allerlei ongestructureerde gezondheidsinformatie uitwisselen zonder te hoeven wachten tot dat deze gestructureerd opgeleverd kunnen worden.
Bij implemeneteren van PDF/A dient er uit te worden gegaan van een minimale compliance aan de PDF/A-standaard. Dat wil zeggen PDF/A-1 en daarbinnen is ook PDF/A-b toegestaan. Zie voor meer informatie de wiki pagina hierover: https://en.wikipedia.org/wiki/PDF/A#Conformance_levels_and_versions
De standaard PDF/A kent de use cases Raadplegen en Sturen. Let op, 'raadplegen' en 'sturen' worden in de MedMij context respectievelijk ook wel 'verzamelen' en 'delen' genoemd. Algemene informatie betreffende use cases kan gevonden worden op de pagina Ontwerpen MedMij.
1.2 Doelgroep
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen.
1.3 Kaders en uitgangspunten
1.3.1 Richtlijn
Conform specificaties genoemd in de algemene inleiding van de MedMij functionele ontwerpen.
Toelichting op de zorginformatiebouwstenen: PDF/A versie maakt gebruik van zib publicatie 2017.
1.3.2 Infrastructuur
Geen nadere specificatie, anders dan genoemd in de algemene inleiding van de MedMij functionele ontwerpen.
1.3.3 Geografische reikwijdte
Geen nadere specificatie, anders dan genoemd in de algemene inleiding van de MedMij functionele ontwerpen.
1.4 Kwalificatie
1.4.1 Introductie
Op deze informatiestandaard is een Nictiz kwalificatie van toepassing. Kwalificatie vindt plaats per systeemrol.
Kwalificatiescripts en meer informatie over de kwalificatie is te vinden via de betreffende paragraaf op de kwalificatiepagina.
2 Use Cases
Deze sectie vervolgt met de volgende use cases:
- Raadplegen gezondheidsinformatie in PDF/A door patiënt
- Sturen gezondheidsinformatie in PDF/A door patiënt
2.1 Use case: Raadplegen gezondheidsinformatie in PDF/A door patiënt
2.1.1 Doel en relevantie
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in medische informatie die over henzelf gaan. Het is niet mogelijk om alle medische informatie direct gestructureerd te kunnen ontsluiten voor de patiënt. Dit ontwerp beschrijft het uitwisselen van ongestructureerde digitale informatie in een PDF/A format.
2.1.2 Domein
Documenten en ongestructureerde medische informatie in een PDF/A formaat in het domein van zorgaanbieders en patiënten.
2.1.3 Context
Het gaat om het elektronisch beschikbaar maken van medische gegevens in PDF/A formaat vanuit een zorgaanbiederssysteem (XIS) naar een persoonlijke gezondheidsomgeving (PGO). Deze pagina bevat (verwijzingen naar) beschrijvingen van:
- informatie
- bedrijfsrollen (actoren),
- proces,
- systemen,
- systeemrollen,
- transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.
2.1.4 Informatie
2.1.4.1 Raadplegen medische gegevens in PDF/A
Het raadplegen, ook wel verzamelen, van medische informatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder).
Informatie elementen in de vraag om PDF/A documenten staan hieronder. Dit betreft de filtermogelijkheden (query parameters) in de vraag om documentgegevens. Deze filtermogelijkheden zijn een subset de filtermogelijkheden zoals benoemd in het IHE MHD profiel.
- patient
- aanmaakdatum
- status
Het ondersteunen van DocumentManifest is optioneel voor het raadplegen van PDF/A.
2.1.4.2 Beschikbaarstellen medische gegevens in PDF/A
De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het IHE MHD profiel. Dit betreft de inhoud van de transactie waarbij het om de volgende HL7 FHIR STU3 informatie modellen en Zorginformatiebouwstenen gaat:
- HL7 FHIR
- Zorginformatiebouwstenen
Het ondersteunen van DocumentManifest is optioneel voor het beschikbaarstellen van PDF/a.
2.1.5 Bedrijfsrollen
Deze use case kent twee bedrijfsrollen. N.B. in onderstaande tabellen en figuren wordt gesproken over 'raadplegen' wat in de MedMij context ook wel 'verzamelen' wordt genoemd.
Bedrijfsrol | Activiteit |
---|---|
Patiënt | Wil medische gegevens in PDF/A formaat raadplegen |
Zorgaanbieder | Stelt medische gegevens in PDF/A formaat beschikbaar |
Bedrijfsrollen afspraak inzien
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.
Activiteitendiagram PDF/A raadplegen
2.1.6 Procesbeschrijving
2.1.6.1 'Patient journey' - Roos Dalstra
Het verhaal van de 'patient journey' van Roos vindt u hier. Hieronder een voor Roos relevante situatie waarbij het raadplegen van een PDF/A document rol speelt.
Na het ontslag komt de informatie over de opnameperiode vanuit het ziekenhuis beschikbaar in de PGO, zodat zij een goed beeld heeft van haar opname en haar medicatie. Dit kan zij ook delen met haar naasten.
Roos zou in haar PGO bijvoorbeeld de ontslagbrief van haar opname kunnen opvragen.
2.1.6.2 Proces
Het stuk van het proces waar het in deze use case om gaat is:
- Het systeem van een zorgaanbieder (XIS) stelt de PDF/A beschikbaar aan het systeem van een patiënt (PGO).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
2.1.6.2.1 Preconditie
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van medische gegevens in PDF/A tussen het betreffende XIS en de eigen persoonlijke gezondheidsomgeving.
De patiënt wil zijn medische gegevens inzien en de zorgaanbieder stelt dit ook beschikbaar.
- Een patiënt kan steeds zelf het initiatief nemen om zijn medische gegevens op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de beschrijving van deze use case geen verschil.
2.1.6.2.2 Proces stappen
- Het systeem van de patiënt (PGO) vraagt om beschikbare medische gegevens bij een XIS aan de hand van een zoekopdracht.
- Het systeem van de zorgaanbieder (XIS) levert een lijst met metadata over de gevonden PDF/A documenten op voor de patiënt.
- De Patiënt gebruikt de persoonlijke gezondheidsomgeving om de gewenste PDF/A te raadplegen of te downloaden.
- Het systeem van de zorgaanbieder (XIS) levert de PDF/A op voor de patiënt.
2.1.6.2.3 Post conditie
De patiënt heeft zijn medische gegevens geraadpleegd via de persoonlijke gezondheidsomgeving.
2.1.7 Systemen & Systeemrollen
Zowel zorgaanbieder als patiënt maken gebruik van een informatiesysteem:
- PGO (patiënt)
- XIS (zorgaanbieder)
Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van zorgaanbieder naar de patiënt. N.B. in onderstaande tabellen en figuren wordt gesproken over 'raadplegen' wat in de MedMij context ook wel 'verzamelen' wordt genoemd.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
PGO | PDFAMetadataLijstRaadplegend | MM--PLR-FHIR | Raadplegen PDF/A metadata lijst bij zorgaanbieder |
PDFARaadplegend | MM--PDR-FHIR | Raadplegen PDF/A document bij zorgaanbieder | |
XIS | PDFAMetadataLijstBeschikbaarstellend | MM--PLB-FHIR | Beschikbaarstellen PDF/A metadata lijst bij patient |
PDFABeschikbaarstellend | MM--PDB-FHIR | Beschikbaarstellen PDF/A document bij patient |
Zie ook onderstaande afbeelding.
Componenten diagram PDFA raadplegen
De kwalificatie van informatiesystemen vindt plaats op basis van systeemrollen.
2.1.8 Transacties, transactiegroepen en systeemrollen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Systeemrolcode | Systeem | Bedrijfsrol | Technisch |
---|---|---|---|---|---|
PDFA metadata lijst (PULL) | Raadplegen PDF/A metadata lijst | MM--PLR-FHIR | PGO | Patiënt | PDF/A in FHIR |
Beschikbaarstellen PDF/A metadata lijst | MM--PLB-FHIR | XIS | Zorgaanbieder | ||
PDFA (PULL) | Raadplegen PDF/A | MM--PDR-FHIR | PGO | Patiënt | |
Beschikbaarstellen PDF/A | MM--PDB-FHIR | XIS | Zorgaanbieder |
2.1.9 Use case diagram
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.
Use case diagram PDF/A Raadplegen
2.2 Use case: Sturen gezondheidsinformatie in PDF/A door patiënt
2.2.1 Doel en relevantie
Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door gezondheidsinformatie te delen met zorgverleners. Het is niet mogelijk om alle informatie direct gestructureerd te kunnen sturen. Dit ontwerp beschrijft het uitwisselen van ongestructureerde digitale informatie in PDF/A formaat.
2.2.2 Domein
Documenten en ongestructureerde gezondheidsinformatie in een PDF/A formaat in het domein van zorgaanbieders en patiënten.
2.2.3 Context
Het gaat om het elektronisch beschikbaar maken van een document of documenten in PDF/A formaat vanuit een persoonlijke gezondheidsomgeving (PGO) naar zorgaanbiederssysteem (XIS). Deze pagina bevat (verwijzingen naar) beschrijvingen van:
- informatie
- bedrijfsrollen (actoren),
- proces,
- systemen,
- systeemrollen,
- transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.
2.2.4 Informatie
De informatie-elementen die van toepassing zijn voor de standaard PDF/A Sturen, zijn gedefinieerd op het platform ART-DECOR in het project Documentuitwisseling.
2.2.4.1 Sturen van gezondheidsinformatie in PDF/A
Het sturen, ook wel delen, van een gezondheidsinformatie gaat van een specifieke patiënt naar een specifieke organisatie in de zorg (bijvoorbeeld een zorgaanbieder).
Om uitwisseling van PDF/A-bestanden tot stand te brengen, neemt MedMij zoveel mogelijk over van het MHD-profiel (Mobile access to Health Documents) van IHE (Integrating the Healthcare Enterprise) dat een RESTful / HTTP-interface definieert naar een XDS-omgeving met behulp van HL7 FHIR STU3-bronnen. De informatie-elementen voor het beschikbaarstellen van een PDF/A worden beschreven in het IHE MHD-profiel.
De inhoud van de transactie gaat om de volgende HL7 FHIR STU3 informatie modellen en Zorginformatiebouwstenen:
- HL7 FHIR
- Zorginformatiebouwstenen
2.2.5 Bedrijfsrollen
Deze use case onderscheidt twee bedrijfsrollen, namelijk de Patiënt en de Zorgaanbieder zoals te zien in onderstaande tabel. N.B. in onderstaande tabellen en figuren wordt gesproken over 'sturen' wat in de MedMij context ook wel 'delen' wordt genoemd.
Bedrijfsrol | Activiteit |
---|---|
Patiënt | Wil gezondheidsinformatie in PDF/A formaat sturen |
Zorgaanbieder | Ontvangt gezondheidsinformatie in PDF/A formaat |
Onderstaande afbeelding toont de bedrijfsrollen en de activiteiten die zij uitvoeren.
Activiteitendiagram PDF/A sturen
2.2.6 Procesbeschrijving
2.2.6.1 'Patient journey' - Roos Dalstra
Een voorbeeldsituatie die de meerwaarde schetst van het sturen van PDF/A vanuit het PGO is de 'patient journey' van Roos Daalstra. Hieronder een voor Roos relevante situatie waarbij het sturen van een PDF/A document rol kan spelen.
Roos is ’s nachts vanwege benauwdheid opgenomen op de afdeling cardiologie van het ziekenhuis. De internist in dienst die nacht wil graag weten welke medicatie Roos gebruikt. Aangezien Roos alles heeft bijgehouden in haar persoonlijke gezondheidsomgeving kan zij het ziekenhuis haar medicatiegegevens laten zien door deze te sturen naar het ziekenhuisinformatiesysteem.
Wanneer het XIS niet in staat is om het medicatieoverzicht gestructureerd te ontvangen, zou het PGO het medicatieoverzicht in een PDF/A kunnen sturen. Zo heeft de arts wel gelijk de beschikking over het medicatieoverzicht.
2.2.6.2 'Patient journey' - Jelmer Postma
Een tweede voorbeeld waarbij de meerwaarde van raadplegen en sturen van PDF/A vanuit het PGO is de 'patient journey' van Jelmer Postma. Hieronder een voor Jelmer relevante situatie waarbij het sturen van een PDF/A document rol kan spelen.
De opname in de GGZ-instelling is van korte duur. Vanaf nu wordt Jelmer ambulant behandeld door een reguliere GGZ-instelling.
Vanuit zijn zorgtraject heeft Jelmer verschillende plannen en verslagen in zijn PGO opgeslagen. Onder andere het initiële plan van de bedrijfsarts en het behandelplan van de psychiater kan Jelmer raadplegen in zijn PGO. De verslagen kan Jelmer als PDF/A sturen aan (nieuwe) begeleiders zodat alle betrokkenen de informatie rond Jelmer zijn ziekte hebben, waarmee zijn herstel zo spoedig mogelijk kan verlopen.
2.2.6.3 Proces
Het stuk van het proces waar het in deze use case om gaat is:
- Het systeem van een patiënt (PGO) stuurt de PDF/A naar het systeem van een zorgverlener (XIS).
Deze paragraaf vervolgt met een beschrijving van precondities, proces stappen, en post condities.
2.2.6.3.1 Preconditie
De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van gezondheidsinformatie in PDF/A tussen eigen persoonlijke gezondheidsomgeving en het betreffende XIS.
De patiënt wil zijn gezondheidsinformatie sturen en de zorgaanbieder ontvangt deze.
- Een patiënt kan steeds zelf het initiatief nemen om zijn gezondheidsinformatie te sturen.
2.2.6.3.2 Proces stappen
- Het systeem van de patiënt (PGO) stuurt gezondheidsinformatie in PDF/A formaat naar een XIS.
- Het systeem van de zorgaanbieder (XIS) ontvangt een PDF/A van de patiënt.
2.2.6.3.3 Post conditie
De patiënt heeft zijn gezondheidsinformatie in PDF/A formaat gestuurd via de persoonlijke gezondheidsomgeving.
2.2.7 Systemen & Systeemrollen
Zowel patiënt als zorgaanbieder maken ieder gebruik van een informatiesysteem:
- PGO (patiënt)
- XIS (zorgaanbieder)
Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om een document of documenten PDF/A van patiënt naar zorgaanbieder. N.B. in onderstaande tabellen en figuren wordt gesproken over 'sturen' wat in de MedMij context ook wel 'delen' wordt genoemd.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
PGO | DocumentcollectieSturend | MM--DCS-FHIR | Sturen PDF/A document naar zorgaanbieder |
XIS | DocumentcollectieOntvangend | MM--DCO-FHIR | Ontvangen PDF/A document van de patiënt |
Zie ook onderstaande afbeelding.
Componenten diagram PDF/A Sturen
2.2.8 Transacties en Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Systeemrolcode | Systeem | Bedrijfsrol | Technisch |
---|---|---|---|---|---|
PDFA (PUSH) | Sturen PDF/A Document(en) | MM--DCS-FHIR | PGO | Patiënt | PDF/A in FHIR |
Ontvangen PDF/A Document(en) | MM--DCO-FHIR | XIS | Zorgaanbieder |
2.2.9 Use case diagram
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.
Use case diagram PDF/A sturen
3 Functionaliteit
3.1 Raadplegen
PGO raadpleegt als eerste bij het XIS, de index met referenties naar documenten. PGO raadpleegt in zijn tweede stap de documenten via deze referenties onder dezelfde condities - met name autorisatie- als de raadpleging van de index. Het XIS is gehouden aan de controle van deze condities. De referenties in de index moeten dus leiden naar een locatie die onder controle staat van het betreffende XIS. Om deze controlemogelijkheid af te dwingen kan het nodig zijn dat het XIS de referentie naar het werkelijke document in opgehaalde indexgegevens vervangt door een alternatieve referentie die onder controle staat bij het XIS. Voor een PGO is een eventuele vervangen referentie transparant: het blijft een referentie die het systeem kan volgen onder dezelfde condities als het indexgegeven zelf.
De transactie "Raadplegen PDF/A" door de PGO volgt de (aangepaste) referentie naar het document. Het raadplegen via het XIS is om context en controle te houden.
3.2 Sturen
Bij Sturen van PDF/A door een PGO worden de PDF/A documenten direct in het bericht als een (binair) bestand meegezonden. Er wordt dus niet gewerkt met referenties zoals bij Raadplegen PDF/A het geval is.
De XIS zal het bericht ontvangen en het PDF/A afleveren bij de Ontvanger (vaak de zorgverlener) die in het bericht is opgenomen. Hoe het afleveren aan de XIS kant van de PDF/A naar een zorgverlener plaatsvindt wordt niet door de informatiestandaard bepaald.
4 Verantwoordelijkheid voor informatie
Er zijn geen specifieke toevoegingen over verantwoordelijkheden voor informatie.
5 Afschermen van gegevens
Er zijn geen afspraken over het afschermen van gegevens.
6 Infrastructuur
Er zijn geen afspraken over een specifieke infrastructuur waarop de informatie wordt uitgewisseld.
7 Referenties
Auteur(s) | Titel | Versie | Datum | Bron | Organisatie |
---|---|---|---|---|---|
- | Mobile access to Health Documents (MHD) | - | 10-05-2019 (wijzigingsdatum) | Mobile access to Health Documents (MHD) | Integrating the Healthcare Enterprise (IHE) |
- | FHIR STU3 Resource Index | FHIR STU3 | 19-04-2017 | Resource Index | Hl7 |
- | Zorginformatie bouwstenen | zib Publicatie 2017(NL) | 23-12-2018 (wijzigingsdatum) | Zorginformatie bouwstenen | Nictiz |
8 Release notes
In onderstaande tabel staan de wijzigingen voor deze informatiestandaard.
Release | Versie | BITS issue | Omschrijving |
---|---|---|---|
2020.01 - December 2024 | 3.0.43 | MM-5354 | Verduidelijking toegevoegd in de FHIR IG voor de interpretatie van mustSupport in FHIR-profielen. Definitie van mustSupport is een eis van de FHIR-standaard aan implementatiegidsen/informatiestandaarden |
MM-5395 | Er zijn enkele tekstuele aanscherpingen doorgevoerd in de uitleg over kwalificaties. | ||
MM-5415 | Vrijheidsgraden voor element 'Type' toegevoegd aan vrijheidsgradenpagina | ||
2020.01 - November 2024 | 3.0.42 | MM-5351 | Het project _Documentuitwisseling_ verwijst nu naar het overzicht van alle publicaties in plaats van naar de live omgeving. Daarnaast verwijzen de transacties nu ook naar de transacties horend bij de nieuwe 2.0.1 publicatie van _Documentuitwisseling_, in plaats van naar de transacties van de live omgeving. |
MM-5347 | De waardelijst horend bij ‘Status’ is hertaald en een nieuwe publicatie (2.0.1) van _Documentuitwisseling_ is aangemaakt. | ||
MM-5362 | Op het voorblad van het CC-formulier is een regel toegevoegd over de conformance level. | ||
MM-5326 | Vrijheidsgradenpagina gemaakt en link naar deze vrijheidsgradenpagina aan kwalificatiescript Beschikbaarstellen toegevoegd | ||
MM-5372 | Richtlijn deduplicatie toegevoegd aan FO | ||
2020.01 - Oktober 2024 | 3.0.41 | MM-5361 | Een foutieve FHIRPath-expressie in TestsScripts is gecorrigeerd. De functionaliteit blijft gelijk. |
MM-5349 | Voeg een paragraaf 'Bekende problemen' toe met betrekking tot de verschillen tussen de functionele en technische implementatie van de PDF/A-standaard. | ||
MM-5340 | Verwijder Bundle and List profielen van List of Profiles en voeg reden van verwijdering toe aan IssueBox. | ||
2020.01 - September 2024 | 3.0.40 | MM-5336 | Conformiteitscheck gegevensdiensten (CCG) formulier is hernoemd naar conformiteitscheck (CC) formulier |
2020.01 - Juli 2024 | 3.0.39 | MM-5272 | In het FO is het doel expliciet beschreven volgens het standaard format (catalogusriterium 4.1) & zijn de gegeven functies van het MedMij Afsprakenstelsel - i.e., Verzamelen of Delen - expliciet benoemd (cataloguscriterium 4.5). |
2020.01 - Maart 2024 | 3.0.38 | MM-5147 | Gebroken links naar het MedMij-afsprakenstelsel zijn hersteld. |
MM-5114 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. | ||
MM-4759 | De controle op de OperationOutcome bij een 40x-error is uit scenario 2.5 verwijderd. | ||
MM-4755 | De sectie “handling errors” in de MedMij FHIR IG is aangepast om duidelijk te maken dat een OperationOutcome ongewenst is bij een HTTP 401 error code. | ||
2020.01 - Februari 2024 | 3.0.37 | MM-5132 | Aan iedere operation binnen alle MedMij-TestScripts wordt een requestHeader met naam 'X-Correlation-ID' toegevoegd met als value een UUID. Een toelichting op de MedMij-headers is in de Touchstone-handleidingen geplaatst. |
2020.01 - Januari 2024 | 3.0.36 | MM-5061 | Op de kwalificatiewiki's van PDF/A is het fBSN toevoegd aan de tabellen inhoudelijke gegevens. |
2020.01 - December 2023 | 3.0.35 | MM-5081 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
2020.01 - November 2023 | 3.0.34 | MM-5037 | Het gebruik van een fBSN voor Patiëntgegevens wordt consequent toegepast over alle test- en kwalificatiematerialen. |
MM-5023 | De technische controle op het Coding-datatype is in al het test- en kwalificatiemateriaal aangepast, zodat 'Coding' daadwerkelijk met een hoofdletter gespeld wordt. | ||
2020.01 - Augustus 2023 | 3.0.33 | MM-4852 | De volgorde van de zib-mapping-declaraties is aangepast in de FHIR STU3 profielen, zodat de mapping naar de 2017-versie van de zib als default getoond wordt in Simplifier. |
MM-4887 | Een overbodige controle op de syntax van referenties is verwijderd uit alle technische TestScripts. | ||
2020.01 - Juni 2023 | 3.0.32 | MM-4830 | In diverse extensies en datatype-profielen stond het StructureDefinition.kind-veld niet correct ingevuld. Dit is aangepast. |
2020.01 - Mei 2023 | 3.0.31 | MM-4740 | De assert die adhv. de self-link controleert of de server alle search parameters uit de request ondersteunt, negeert afwijkende waardes van de parameters als ze lijken op een referentie, aangezien de server ze in dat geval kan herschrijven. |
MM-4772 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. | ||
2020.01 - April 2023 | 3.0.30 | MM-4741 | De term "DVZA" is vervangen door de term "DVA" op de wikipagina's en de Nictiz-website, conform de naamswijziging in het MedMij-Afsprakenstelsel. In de begrippenlijsten bij de kwalificatiepagina's is een toelichting geplaatst dat "DVZA" de verouderde term is. |
MM-4723 | De T-datums in de JSON-fixtures die voor DVA/XIS-testen worden gebruikt, weken op enkele plekken af van het functionele script en van de XML-fixtures. Dit is gecorrigeerd. | ||
MM-4698 | Op het MedMij algemene functionele ontwerp van de v2020.01 en v2020.02 standaarden is een richtlijn/advies geplaatst over het uitwisselen van niet gecodeerde informatie. Deze informatie is onder een nieuwe paragraaf geplaatst, namelijk 'Implementatie-advies'. | ||
2020.01 - Maart 2023 | 3.0.29 | MM-4683 | De FAQ-pagina (MedMij Kwalificatiepagina) is verwijderd. |
2020.01 - Februari 2023 | 3.0.28 | MM-4204 | In test- en kwalificatiefixtures zijn de .display-waarden van SNOMED- en LOINC-codes bijgewerkt. |
2020.01 - Januari 2023 | 3.0.27 | MM-4103 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
MM-3841 | De bearer tokens voor testpatiënten in de Touchstone-scripts worden voortaan vanuit één enkel configuratiebestand beheerd. | ||
MM-3496 | Uitleg toegevoegd aan het TO van PDF/A over het gebruik van en het verschil tussen de masterIdentifier- en identifier-elementen in de DocumentReference- en DocumentManifest-resources, inclusief een verwijzing vanuit het kwalificatiescript naar deze uitleg. | ||
2020.01 - December 2022 | 3.0.26 | MM-3840 | Underscores in de id van een TestScript rule zijn vervangen door streepjes. |
MM-3839 | De sectie over het meesturen van "secundaire" resources in de implementatiegidsen voor FHIR STU3 en R4 beargumenteert dat het updaten van bestaande resources ontmoedigd wordt, maar dat wordt verwoord als "PUT", wat breder inzetbaar is dan een update. Dit is aangepast naar "de update operation". | ||
2020.01 - November 2022 | 3.0.25 | MM-3792 | De tabellen met release notes per versie van de informatiestandaarden zijn opnieuw opgesteld zodat ze een completer beeld geven. De tabellen zijn daarnaast afgekapt op de laatste majorversie van de standaard. |
MM-3687 | In scenario 2.5 van PDF/A een Nictiz-interne assert aan de derde subtest toegevoegd, ervoor gezorgd dat niet-Nictiz-interne asserts worden uitgevoerd in default- en NoManifest-usecases, en OperationOutcome-gerelateerde asserts toegevoegd. | ||
MM-3686 | Tekstuele verbeteringen en consistentere beschrijvingen aangebracht in scenario's 1.3/1.4/1.5/2.2/2.3/2.4 van PDF/A. | ||
MM-3444 | Tekstuele toevoeging aan de PDF/A-kwalificatiescripts op de wiki: vermelding gebruik verschillende documenten tijdens kwalificatie. | ||
2020.01 - Oktober 2022 | 3.0.24 | MM-3700 | De uitleg over het gebruik van tokens is als sectie opgenomen in de overkoepelende handleiding van Touchstone, de losse pagina is verwijderd. |
MM-3685 | De ongebruikte Practitioner fixtures in de PDF/a-test- en kwalificatiematerialen zijn verwijderd. | ||
MM-3654 | De PDF/A-TestScripts geven nu consistent alleen een waarschuwing als de testende partij de MasterIdentifier uit de test/kwalificatiematerialen gebruikt. | ||
MM-3652 | In de test/kwalificatiematerialen zijn titels en beschrijvingen voor de DocumentReference-fixtures consistent gemaakt. | ||
MM-3607 | In het testscript van scenario 2.5 van PDF/A is de read-operatie vervangen door een get-operatie, en het dummy-resourceType verwijderd. | ||
MM-3498 | DocumentReferentie 3, die een ongeldige verwijzing bevat, is verwijderd uit de test/kwalificatiematerialen voor PDF/A beschikbaarstellen. | ||
2020.01 - September 2022 | 3.0.23 | MM-3595 | The outdated contact information in the profiles has been updated. |
MM-3586 | Enkele gedupliceerde en ongebruikte bestanden in het kwalificatiemateriaal van PDF/A zijn verwijderd. | ||
MM-3540 | In het kwalificatiescript van 'Beschikbaarstellen PDF/A' is zijn Persoonsgegevens verwijderd uit het 'Verwacht functioneel resultaat'. Daarnaast zijn enkele typo's gecorrigeerd. | ||
MM-3500 | A known issue has been added to the IG of PDF/A to indicate that the Bundle and List profiles are not used within the information standard. Moreover several typos have been corrected. | ||
MM-3357 | The test and qualification scripts that test the communication with the XIS in JSON format now also use JSON when information is sent, and not only when it is requested. | ||
2020.01 - Augustus 2022 | 3.0.22 | MM-3493 | De uitleg over het gebruik van het CCG-formulier is aangepast naar de huidige werkwijze. |
MM-3476 | De automatische assert gerelateerd aan de HTTP-code in scenario 1.3 is aangepast zodat deze alleen slaagt wanneer code 400 wordt gebruikt. Verder zijn scenario 1.3 en 1.5 meer met elkaar in lijn gebracht. | ||
MM-3475 | The incorrect HTTP status code in the error handling example related to a syntactically incorrect request has been fixed. Moreover several typos and inconsistencies have been corrected on the 'Error handling examples' page. | ||
MM-3247 | De testscripts van scenario 1.4 en 2.5 zijn in lijn gebracht met het kwalificatiescript en testen nu respectievelijk alleen oplevering via een Binary-resource en een normale HTTP-read. Daarnaast is de beschrijving van scenario 2.5 in het kwalificatiescript aangevuld met de autorisatietest die technisch uitgevoerd wordt. | ||
MM-3162 | Op Raadplegen kwalificatiescripts AllergieIntolerantie, PDF/A, eAfspraak, Zelfmetingen wordt nu toegelicht dat er in de kwalificatie geen extra raadpleging op patient wordt verwacht, wanneer in een scenario geen inhoudelijke gegevens beschikbaar zijn. | ||
2020.01 - Juli 2022 | 3.0.21 | MM-3367 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
MM-3360 | De titels van de voorbeelddocumenten zijn gecorrigeerd in het kwalificatiemateriaal en bij de documentinhoud in het kwalificatiescript. | ||
MM-3355 | Een toelichting dat het BSN niet uitgewisseld mag worden met PGO's is toegevoegd aan het algemeen functioneel ontwerp. | ||
MM-3351 | In het kwalficatiemateriaal bevatte het element DocumentManifest.author de waarde van de ontvanger van de documenten (A. Janssen). Dit is aangepast naar de naam van de patiënt (Helene XXX_Ellens). | ||
MM-3338 | De git-repository's "Nictiz-STU3-testscripts" en "Nictiz-STU3-testscripts-src" zijn samengevoegd en verhuisd naar een nieuw repository met de naam "Nictiz-testscripts". | ||
MM-3337 | De TestScript-resources voor test- en kwalificatiedoeleinden op TouchStone zijn gemigreerd naar FHIR R4. | ||
MM-3308 | In the FHIR STU3 IG, the link to "paging" the FHIR spec has been corrected. | ||
MM-3300 | In the MedMij FHIR IG, the link to "MedMij consultaties" has been corrected. | ||
2020.01 - Juni 2022 | 3.0.20 | MM-3288 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
MM-3279 | De narratives in de test- en kwalificatiefixtures worden vanaf nu bij elke wijziging opnieuw gegenereerd. | ||
MM-3254 | In the general IG an explanation has been added that our FHIR profiles don't use the mustSupport flag. | ||
MM-3245 | In het kwalificatiescript van PDF/A is de term 'non-Binary resource' als alternatief voor 'Binary-resource' vervangen door 'HTTP-verwijzing'. | ||
MM-3237 | Onder 'Uit te voeren stappen' in het kwalificatiescript van PDF/A waren ten onrechte twee uitgangspunten toegevoegd, deze zijn naar de relevante plekken van het script verhuisd. | ||
MM-3230 | Several examples of the zib2017 profiles were missing a reference to PractitionerRole. This reference has been added. | ||
MM-3213 | De DVZA-TestScripts staan het toe dat de resultaten één extra DocumentReference of DocumentManifest mogen bevatten zolang de status _current_ is. | ||
MM-3212 | In het kwalificatiescript van PDF/A waren de omschrijvingen van twee scenario's (2.4 en 2.5) onduidelijk, deze zijn verbeterd. | ||
MM-3163 | Op het functioneel ontwerp is de link naar het IHE MHD-profiel gecorrigeerd. | ||
MM-2759 | Correct and incorrect examples have been added to the common FHIR IG for referencing resources when the server doesn't support RESTful reads. | ||
2020.01 - Mei 2022 | 3.0.19 | MM-3204 | In de Touchstone-handleiding is een waarschuwing geplaatst over het verwijderen van de USER_KEY of ORG_KEY in publieke plekken. |
MM-3185 | Er is een variant van de technische testscripts gemaakt voor partijen die de DocumentManifest-resource niet ondersteunen. | ||
MM-3184 | Op de kwalificatiepagina zijn de 'Conformiteitscheck Gegevensdienst'-documenten (CCGs) verwijderd. | ||
MM-3174 | |||
MM-3054 | Reference.display is niet langer verplicht in de technische testscripts wanneer de NullFlavor- of data-absent-reason-extensie aanwezig is. | ||
MM-2916 | Incorrect comments related to data elements not allowed to be present in the PDF/A profiles (DocumentReference, DocumentManifest and List) have been removed. | ||
2020.01 - April 2022 | 3.0.18 | MM-3096 | In the error handling examples on the FHIR IG, 'OperationOutcome.code' has been replaced by 'OperationOutcome.issue.code' in accordance with the FHIR specs. |
MM-3082 | Spelfouten en andere kleine foutjes opgelost. | ||
MM-3045 | Aan alle DVZA-testen voor succesvolle search operations op Touchstone is een assert toegevoegd die controleert of de self-link de gebruikte search parameters onderkent. | ||
MM-3033 | De foutieve assert op DocumentReference is aangepast naar DocumentManifest in de technische testscripts voor scenario 2.2. | ||
MM-3032 | In de kwalificatiematerialen wordt nu gecontroleerd of FHIR Identifiers zowel een .system (of eventueel een .type) en een .value bevatten. | ||
MM-3016 | Foutieve T-datums in DocumentReference- en DocumentManifest-fixtures zijn gecorrigeerd. | ||
MM-2972 | De Identifier veranderd van URL naar urn:oid in onze technisch kwalificatie materiaal. | ||
2020.01 - Maart 2022 | 3.0.17 | MM-3035 | Op de wikipagina voor kwalificatie van PDFA Beschikbaarstellen is een hyperlink naar de Inhoudelijke gegevens gecorrigeerd, deze verwees voorheen naar een niet bestaande pagina. |
MM-3031 | Het opmerkingenveld in de CCG van PDFA is opengesteld waardoor gebruikers opmerkingen in het vrije veld kunnen vermelden. | ||
MM-2973 | De assert die testte op aanwezigheid van .display of .text in elementen van type CodeableConcept ging er ten onrechte vanuit dat .text alleen aanwezig mag zijn als de gecodeerde waarde afwezig is. Dit is aangepast. | ||
MM-2968 | The CapabilityStatements for PDF/A now support POST searchIncludes | ||
2020.01 - Februari 2022 | 3.0.16 | MM-2887 | Op de FAQ kwalificatiepagina is de term pre-kwalificatie vervangen door kwalificatie 1. Verder is het kwalificatieproces verduidelijkt. |
MM-2886 | Added a textual known issue to the ValueSet ProbleemNaamCodelijst that an urn:oid is present where an url is expected. | ||
MM-2882 | Op de kwalificatiewikipagina is explicieter aangegeven dat bij afwijkingen van het kwalificatiescript er een argumentatie noodzakelijk is dat vooraf moet worden gecommuniceerd. | ||
MM-2880 | In the profiles nl-core-address and nl-core-contactpoint, the Markdown notation for the tables has been changed to an actual table instead of a code block. | ||
MM-2872 | Er is een leesvriendelijke tekst aan 2 links toegevoegd in de introductie op het algemene functioneel ontwerp | ||
MM-2858 | De PGO-testscripts voeren geen uitgebreide checks meer uit op de FHIR-responses vanuit de testserver. | ||
MM-2846 | In een van de technische PDFA-testscripts voor XIS-systemen die test op een JSON-response werd om een XML-response gevraagd. Dit is aangepast. | ||
MM-2844 | The patch version number for nl-core-practitioner has been corrected. | ||
MM-2834 | In various CapabilityStatements, searchParams that were present, but that were not shown in their respective TOs, were removed and incorrect searchIncludes have been corrected. | ||
MM-2830 | - Het aanpassen van enkele tekstuele beschrijvingen op de addendum-wiki van de PDF/A-kwalificatie.
- Het corrigeren van enkele typo's en inconsequente bewoordingen. | ||
MM-2820 | In the package manifests for all packages, the incorrect entry "web" has been changed to "url". This change pertains the packages for zib2017, Questionnaires, BgZ, Images and eAfspraak. | ||
MM-2787 | In de technische TestScripts wordt gecontroleerd of .system én .code altijd samen aanwezig zijn en of er geen ValueSet-uri gebruikt wordt als .system. | ||
MM-2770 | Op de kwalificatiewikipagina's is additionele informatie toegevoegd dat verduidelijkt op welke systeemomgeving gekwalificeerd dient te worden. | ||
MM-2721 | De generieke uitgangspunten van de systeemrol 'Sturen' is toegevoegd en de systeemrol 'Ontvangen' is uitgebreider beschreven op de kwalificatiepagina 2020.01. | ||
MM-2691 | De technische TestScripts gebruiken nu de "Prefer: return=representation" header bij het sturen van informatie om te garanderen dat de response de aangemaakte resources bevat. | ||
MM-2663 | In de gezamenlijke basis voor de Touchstone-testen zijn de MedMij-asserts uitgesplitst van de niet-MedMij-asserts. Hierdoor is de volgorde van asserts in veel Touchstone-testscripts veranderd. | ||
MM-2659 | Een aantal overlappende testen in de technische TestScripts van verschillende standaarden zijn generaliseerd naar een algemene basis. Sommige TestScripts voeren daardoor completere controles uit. | ||
MM-2375 | De aansluitpagina voor Touchstone is veralgemeniseerd zodat deze multi-inzetbaar. Op de MedMij-wikipagina staat nu deze algemene informatie samen met MedMij-specifieke informatie. | ||
2020.01 - Januari 2022 | 3.0.15 | MM-2764 | In de meest recente beoordelingsformulieren is de volledigheidsbeoordeling uitgebreid met specifiekere technische criteria. Tevens is de achterhaalde term '(pre)' van '(pre)kwalificatie' verwijderd uit de beoordelingsformulieren en wikipagina's. |
MM-2734 | Er is nu een pagina met informatie over het toepassen van herleidbaarheid in PGO en XIS. Hiernaar wordt naar verwezen vanuit het algemeen functioneel ontwerp en alle kwalificatiescripts voor de rollen raadplegen en ontvangen. | ||
MM-2711 | De 'conformiteitscheck gegevensdienst'-documenten (CCG) zijn toegevoegd op de kwalificatiepagina voor alle gegevensdiensten waarvoor deze beschikbaar zijn. | ||
MM-2664 | Locatie van Documentreferentie 3 en Document 3 bleken onjuist, dit is gecorrigeerd. Er wordt nu terecht verwezen naar een niet bestaand document met een foutieve ID. | ||
MM-2531 | De ontbrekende uitleg over het gebruik en invoeren van de variabele T-datum is toegevoegd aan de sectie Configureren simulator op de kwalificatiepagina. | ||
MM-2515 | Aan de kwalificatie-eisen is uitleg toegevoegd in welke omstandigheden een Touchstone-uitvoer gefaalde tests mag bevatten. | ||
MM-2461 | In the zib2017 FHIR package, the missing terminology bindings in profiles zib-AllergyIntolerance and zib-BodyHeight have been restored. | ||
MM-2324 | All LoadResources scripts for the qualification materials are bundled per main folder (MedMij-20XX.0X-Test/Cert), leading to less overhead in the montly update cycle. | ||
2020.01 - November 2021 | 3.0.14 | MM-2480 | Correctie en verduidelijking PDF/A wiki-pagina's raadplegen en beschikbaarstellen: De footnote in 4.4. is verder uitgewerkt en onjuistheden in de addenda zijn aangepast. |
2020.01 - Oktober 2021 | 3.0.13 | MM-2264 | Notitie in het PDF/A DVP kwalificatiescript onder sectie 2.3 gezet die verduidelijking geeft over de PDF die niet binnen het zelfde domein opgehaald kan worden. |
MM-2310 | Edited the PDF/A qualification script for scenario 2.5 to be able to check both a Binary and a direct PDF download. Edited the PDF used in internal materials to a Nicitz document. | ||
MM-2414 | In de addenda voor beschikbaarstellen PDF/A is de juiste zorgverlener aan de DocumentReferentie2 toegevoegd. | ||
MM-2415 | Guidance has been added to the FHIR IG on working with "secondary" resources (Patient, Practitioner) which are referred from a resource that's being created by a client on a server. | ||
MM-2443 | De aanleverformats van PDF/A zijn aangepast zodat deze overeenkomen met de verwachte functionele resultaten per scenario in de PDF/A kwalificatiescripts. | ||
2020.01 - September 2021 | 3.0.12 | MM-2361 | Inhoudelijke finetuning van de PDF/A wiki-pagina's: De begrippen zijn verder uitgewerkt en onjuistheden in de addenda zijn aangepast. |
2020.01 - Augustus 2021 | 3.0.11 | MM-2168 | De kwalificatiescripts en addenda zijn naar wiki-pagina’s omgezet. Verwijder of archiveer eerder gedownloade (pdf) versies. Daarnaast is de naamgeving van de begrippen geharmoniseerd, zijn de addenda verder uitgewerkt en is uiteengezet wat er per scenario wordt getoetst. |
2020.01 - Juni 2021 | 3.0.9 | MM-2187 | In PDF/A testscripts 1.4 en 2.4 de query die gebruikt wordt om references te kunnen resolve zodanig aangepast dat deze om kan gaan met het aantreffen van meedere bundle.link elementen. |
2020.01 - Mei 2021 | 3.0.8 | MM-2075 | In het kwalificatiescript PDF/A PHR 2.1, is de description aangepast zodat deze nu correct weergeeft dat het script 2.1 betreft. |
MM-1721 | Aanpassing gedaan aan de aanleverformats voor PDFA. Op de Wiki zijn nieuwe aanleverformats gepubliceerd. | ||
2020.01 - April 2021 | 3.0.7 | MM-2014 | DocumentManifest is optioneel voor zowel DVZA's als DVP, dit is doorgevoerd in de testscripts van PDF/A 3.x (2020.01). |
MM-2013 | DocumentManifest is optioneel voor zowel DVZA's als DVP, dit is doorgevoerd in het functioneel ontwerp van PDF/A 3.x (2020.01). | ||
MM-1960 | Support for the Find DocumentManifest transaction is made optional instead of mandatory for servers, this has been changed on the PDF/A 3.x (2020.01) FHIR IG. | ||
MM-1707 | De Patient Journey van "Jelmer Postema" is aangepast, een nieuwe PDF is toegevoegd op de functionele ontwerpen van Vragenlijsten 2.x, Basisgegevens GGZ 2.x en PDF/A 3.x (publicatie 2020.01). Op het functioneel ontwerp van Vragenlijsten en Basisgegevens GGZ zijn daarnaast ook de verhaalteksten bij de use-case aangepast. | ||
2020.01 - Februari 2021 | 3.0.5 | MM-1772 | Mode value changed from "client" to "server" in the MedicationServer and PDFAServer CapabilityStatements. |
2020.01 - November 2020 | 3.0.2 | MM-1466 | Binnen het FO van PDF/A zijn de verwijzingen naar FHIR-versienummers weggehaald. |
2020.01 - September 2020 | 3.0.1 | MM-1393 | Tweaks in the qualification materials of the PDF/A standard on multiple aspects including scripts, addendum, fixtures and wiki guidance. |
MM-1328 | Clarified specifications of which transactions are needed to be supported by DVP's for PDF/A | ||
MM-1281 | Gelijktrekken van woordkeuzes in kwalificatiescripts en addenda voor PDF/A | ||
MM-1228 | Removed inline examples in TO of PDF/A and replaced them with links to simplifier examples. | ||
MM-1011 | Replaced the term "StructureDefinitions" with the more precise term "profiles" in implementation guides. | ||
2020.01 - Zomerrelease 2020 | 3.0.0 | 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-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-816 | Removed additional constraints on .author reference to allow for a Patient reference. |
9 Ondersteuning
Voor vragen en wijzigingsverzoeken met betrekking tot de informatie op deze pagina kan een ticket worden aangemaakt in Servicedesk Portaal.