MedMij:V2020.01/OntwerpBeelden: verschil tussen versies
(MM-3792: Verwijder de opmerking dat er nog overkoepelende release notes zijn) |
(MM-3987: toevoegen Sjabloon Ondersteuning) |
||
Regel 258: | Regel 258: | ||
In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. | In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. | ||
{{#lsth:Tabellen met release notes|Beelden 2}} | {{#lsth:Tabellen met release notes|Beelden 2}} | ||
+ | |||
+ | {{#lsth:MedMij:Sjabloon_Ondersteuning}} |
Versie van 25 jan 2023 om 10:05
Inhoud
- 1 Inleiding
- 2 Use Cases
- 3 Functionaliteit
- 4 Verantwoordelijkheid voor informatie
- 5 Afschermen van gegevens
- 6 Infrastructuur
- 7 Referenties
- 8 Release notes
1 Inleiding
1.1 Algemeen
Deze pagina beschrijft het functioneel ontwerp voor de uitwisseling van beelden binnen MedMij. De algemene inleiding van de MedMij functionele ontwerpen kan hier gevonden worden.
1.2 Doelgroep
De doelgroep voor deze pagina wijkt niet af van de algemene doelgroep van de MedMij functionele ontwerpen, die hier gevonden kan worden.
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: Beelden versie 2.0.39 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
2.1 Use case 1: Sturen beelden vanuit een PGO
2.1.1 Doel en relevantie
- Het voor patiënten/ personen mogelijk maken regie op hun eigen gezondheid te nemen door beelden te sturen naar (verschillende) zorgaanbieders.
- Deze use case ondersteunt geen interactie met de patiënt middels het PGO. De zorgverlener kan niet online reageren op de gestuurde beelden. De zorgverlener dient buiten deze use case om de beelden te bespreken met de patiënt.
2.1.2 Domein
Beelden in het domein van zorgaanbieders en patiënten/ personen.
2.1.3 Context
Het gaat om het elektronisch en gestructureerd sturen van beelden vanuit een persoonlijke gezondheidsomgeving (PGO) naar een zorgaanbiederssysteem (XIS). Deze pagina bevat (verwijzingen naar) beschrijvingen van:
- informatie,
- bedrijfsrollen (actoren),
- proces,
- systemen,
- systeemrollen,
- transactiegroepen en transacties, inclusief de inhoud van deze transacties.
De beschrijving is infrastructuur-onafhankelijk.
2.1.4 Informatie
Bij het sturen van beelden gaat het om de volgende informatie die uitgewisseld wordt: de beelden, bijbehorende meta-informatie per beeld en een mogelijk toelichting/ begeleidende tekst.
De informatie-elementen voor sturen en ontvangen van een beeld of collectie beelden staan in ART-DECOR Sturen Beelden.
2.1.4.1 Beeldformaat
- De ontvangende systemen dienen de volgende gegevensformaten te ondersteunen: JPEG, PNG, GIF en JP2. De PGO bepaalt zelf in welke van deze ondersteunende beeldformaten, de beelden worden verstuurd. De genoemde beeldformaten zijn ook de gegevensformaten, bestaande uit één frame, die door DICOM standaard worden gespecificeerd voor gebruik bij DICOM web-services. Binnen deze use case zijn dit de enige gebruikte gegevensformaten voor beelden. Beeldformaat DICOM is niet in scope voor deze use case.
- Beelden mogen extra (meta)informatie bevatten in bijvoorbeeld de Exif standaard. Een voorbeeld is het opslaan van patiëntgegevens binnen het beeldformaat JPEG. Hier wordt in deze use case echter geen gebruik van gemaakt.
2.1.4.2 Frequentie sturen beeld(en)
- Met het oog op bijvoorbeeld een denial of service attack is de overweging geweest om de frequentie waarmee de patiënt beelden kan versturen te beperken. Besloten is om voorlopig geen beperkingen op te nemen in de standaard.
2.1.4.3 Grootte van beeld(en)
De maximale grootte van een beeld is 20 MB (voordat het Base64 encoded is). Een PGO kan één tot maximaal 3 beelden tegelijk sturen. De maximale grootte van een collectie beelden is 60 MB. Base64 codering maakt het resultaat 37% groter.
2.1.4.4 Toelichting
De patiënt kan per beeld en/of per collectie beelden een begeleidende tekst meegeven. Dit gaat middels de 'toelichting' meta-informatie elementen.
2.1.4.5 Meta-informatie
Het beeld dient te worden voorzien van voldoende meta-informatie om door het ontvangende systeem goed te kunnen worden geïnterpreteerd. De specificatie van de meta-informatie wordt gegeven in de dataset en transactiebeschrijving. Daarnaast kent het FHIR profiel, verwezen vanuit het technisch ontwerp, nog een aantal verplichte concepten. Deze use case houdt rekening met zelfstandige XIS-sen en met XIS-sen die zijn aangesloten op een XDS-netwerk door het bericht te voorzien van voldoende meta-informatie voor indexatie. Het correct indexeren van beelden in een XDS netwerk is de verantwoordelijkheid van het ontvangende XIS. Het technische ontwerp geeft een niet-normatieve implemenatierichtlijn middels een mapping van het FHIR bericht naar XDS concepten en het IHE MHD profiel.
2.1.5 Bedrijfsrollen
Deze use case onderscheidt twee bedrijfsrollen, namelijk de Patiënt en de Zorgaanbieder zoals te zien in onderstaande tabel.
Bedrijfsrol | Activiteit |
---|---|
Patiënt | Wil beelden sturen |
Zorgaanbieder | Wil beelden ontvangen |
Bedrijfsrollen sturen beelden
Onderstaande afbeelding toont de verschillende activiteiten uit de procesbeschrijving die door de bedrijfsrollen worden uitgevoerd.
Activiteitendiagram sturen beelden
2.1.6 Procesbeschrijving
2.1.6.1 Patient Journey – Thomas van Beek
Een voorbeeldsituatie die de meerwaarde van het sturen van beelden vanuit het PGO schetst is de patiënt journey van Thomas van Beek.
De afgelopen periode heeft Thomas wisselend last van eczeem. De vorige keer dat Thomas een dergelijke aanval had, waren de klachten al afgenomen op het moment dat de afspraak met de huisarts plaatsvond. Om de ernst van de klachten te kunnen inschatten heeft de huisarts gevraagd of Thomas in het vervolg een foto kan maken van de eczeem wanneer deze in alle ernst aanwezig zijn. Vandaag is het weer zover. Bij het maken van de afspraak met de huisarts verzoekt de assistente of Thomas direct een foto kan maken en deze de huisarts wil toesturen. Thomas maakt foto's van onder andere zijn gezicht en upload deze naar zijn PGO. Een paar dagen na het versturen van de foto heeft hij een afspraak bij de huisarts. De foto's komen tijdens het consult ter sprake en een passende behandeling wordt gekozen.
2.1.6.2 Patient Journey – Kenneth van Someren
Een tweede voorbeeld waarbij de meerwaarde van het sturen van beelden vanuit het PGO geschetst kan worden is de patiënt journey van Kenneth van Someren.
De grote antieke stoel in de woonkamer is het plekje waar Kenneth thuis graag te vinden is. De stoel begon echter de laatste tijd steeds minder lekker te zitten. De zuster adviseert regelmatig af te wisselen met de bank, maar de televisie is lang niet zo interessant als het dorpsplein aan de overkant van de straat. Het begon met enkel een klein rood plekje op zijn ruggengraat, maar inmiddels begon dit vormen aan te nemen die ook dochter Debby zorgen baarde. Na kort overleg met de thuiszorg besluit ze telefonisch contact op te nemen met de wondverpleegkundige van de organisatie. Deze vraagt om een duidelijke foto te maken en via het PGO te sturen voor beoordeling. De wondverpleegkundige ziet de foto en vind het ook zorgelijk. Daarom maak ze direct een afspraak met Kenneth om de plek zelf te beoordelen. De volgende ochtend lukt dat al en die middag komt de thuiszorg met de juiste kennis en materialen om de wond te behandelen.
2.1.6.3 Proces
Het stuk van het proces waar het in deze use case omgaat is:
- Patiënt en zorgverlener maken de afspraak dat de patient een beeld kan sturen aan de zorgverlener.
- Patiënt maakt, ontvangt of downloadt één of meerdere beelden en uploadt deze naar zijn PGO. De beelden kunnen gemaakt zijn door de patiënt, een zorgaanbieder of iemand anders.
- Patiënt heeft de mogelijkheid om een begeleidende tekst van maximaal 1 MB toe te voegen aan het beeld en/of beelden.
- Het PGO stuurt de beelden naar het systeem van de zorgaanbieder.
- Mogelijk moet of kan de patiënt metagegevens behorende bij de beelden aanvullen of invullen.
- De zorgaanbieder raadpleegt de beelden in zijn eigen dossier (XIS).
- De zorgverlener bespreekt het beeld buiten het PGO om met de patiënt. Deze use-case ondersteunt geen interactie met de patiënt middels het PGO.
Deze paragraaf vervolgt met een beschrijving van precondities, processtappen, en postcondities.
2.1.6.3.1 Preconditie
- De patiënt heeft toestemming gegeven voor het elektronisch uitwisselen van beelden tussen het eigen PGO en de betreffende XIS.
- De patiënt en zorgaanbieder hebben onderling afspraken gemaakt over het sturen van beelden.
- Het XIS van de zorgaanbieder is in staat afbeeldingen van de patient te ontvangen.
- De beelden bevinden zich in of zijn toegankelijk voor, het PGO
2.1.6.3.2 Processtappen
- Het systeem van de patiënt (PGO) stuurt de beelden naar het systeem van de zorgaanbieder (XIS).
- Het systeem van de zorgaanbieder (XIS) ontvangt de beelden van het PGO.
2.1.6.3.3 Postconditie
- Indien het systeem van de zorgaanbieder (XIS) gebruik maakt van een XDS-omgeving zal dit systeem de beelden op gepaste wijze in het netwerk registreren.
- De zorgaanbieder gebruikt het systeem (XIS) om de beelden te kunnen zien en/of beoordelen.
2.1.7 Systemen & Systeemrollen
Zowel de patiënt als de zorgaanbieder maken ieder gebruik van een informatiesysteem:
- PGO (patiënt)
- XIS (zorgaanbieder)
Deze systemen kennen ieder verschillende systeemrollen, die het uitwisselen van gegevens tussen deze systemen mogelijk maken. Hier gaat het om beelden van de patiënt naar de zorgaanbieder.
Systeem | Naam systeemrol | Systeemrolcode | Omschrijving |
---|---|---|---|
PGO | Sturen van Beelden | MM-2.0.39-BES-FHIR | Sturen van beelden naar zorgaanbieder |
XIS | Ontvangen van Beelden | MM-2.0.39-BEO-FHIR | Ontvangen van beelden vanuit het PGO |
Zie ook onderstaande afbeelding.
Componenten diagram van systemen en systeemrollen
2.1.8 Transacties & Transactiegroepen
Het uitwisselen van gegevens tussen de verschillende systeemrollen gebeurt op basis van transacties. Een transactiegroep is een verzameling van bij elkaar horende transacties (bijvoorbeeld een stuur- en ontvangstbericht). Onderstaande tabel biedt een overzicht voor deze use case.
Transactiegroep | Transactie | Systeemrolcode | Systeem | Bedrijfsrol | Technisch |
---|---|---|---|---|---|
Beelden (PUSH) | Sturen Beelden | MM-2.0.39-BES-FHIR | PGO | Patiënt | Beelden in FHIR |
Ontvangen Beelden | MM-2.0.39-BEO-FHIR | XIS | Zorgaanbieder |
2.1.9 Use case diagram
Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.
Use case diagram sturen beelden
3 Functionaliteit
3.1 Eisen en wensen
- Afstemming vooraf: Tijdens de ontwikkeling van de informatiestandaard is er nagedacht over het opnemen van een verplichte checkbox die de patiënt moet aanvinken om aan te geven dat er afstemming is geweest met de zorgverlener. Uiteindelijk is besloten om deze eis niet op te nemen in de standaard omdat in de praktijk patiënt en zorgverlener altijd een context hebben waarin het sturen van de beelden past. Daarnaast is het uitgangspunt om de patiënt zo min mogelijk te laten invullen bij het sturen van een beeld.
3.2 Niet functionele eisen en wensen
Het technisch ontwerp bevat een aantal verplichte (technische) data elementen die niet zijn opgenomen in de functionele dataset. Een aantal van deze velden zijn verplicht gesteld om compatibiliteit met XDS-netwerken te ondersteunen. Het gaat om de volgende elementen:
- Indentificatie van het beeld en collectie beelden
- Een hash van de data van het beeld
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 |
---|---|---|---|---|---|
- | Persoonlijke Gezondheidsomgeving | 06-12-2018 | https://www.patientenfederatie.nl/themas/persoonlijke-gezondheidsomgeving/ | Patiëntenfederatie Nederland | |
- | Rendered Media Types | 10-12-2018 | http://dicom.nema.org/medical/dicom/2017d/output/html/part18.html#table_6.1.1-3 | NEMA (DICOM) | |
- | Exif | 10-12-2018 | https://en.wikipedia.org/wiki/Exif | Wikipedia |
Referenties
8 Release notes
In onderstaande tabel staan de wijzigingen voor deze informatiestandaard.
Release | Versie | BITS issue | Omschrijving |
---|---|---|---|
2020.01 - Oktober 2024 | 2.0.39 | MM-5361 | Een foutieve FHIRPath-expressie in TestsScripts is gecorrigeerd. De functionaliteit blijft gelijk. |
2020.01 - September 2024 | 2.0.38 | MM-5336 | Conformiteitscheck gegevensdiensten (CCG) formulier is hernoemd naar conformiteitscheck (CC) formulier |
2020.01 - Juli 2024 | 2.0.37 | MM-5261 | In het FO is het doel expliciet beschreven volgens het standaard format (cataloguscriterium 4.1) & zijn de gegeven functies van het MedMij Afsprakenstelsel - i.e., Delen - expliciet benoemd (cataloguscriterium 4.5). |
2020.01 - Maart 2024 | 2.0.36 | MM-5147 | Gebroken links naar het MedMij-afsprakenstelsel zijn hersteld. |
MM-5114 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. | ||
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 | 2.0.35 | 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 - December 2023 | 2.0.34 | MM-5081 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
2020.01 - November 2023 | 2.0.33 | 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 | 2.0.32 | 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 | 2.0.31 | MM-4830 | In diverse extensies en datatype-profielen stond het StructureDefinition.kind-veld niet correct ingevuld. Dit is aangepast. |
2020.01 - Mei 2023 | 2.0.30 | 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 | 2.0.29 | 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-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 | 2.0.28 | MM-4683 | De FAQ-pagina (MedMij Kwalificatiepagina) is verwijderd. |
2020.01 - Januari 2022 | 2.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. | ||
2020.01 - December 2022 | 2.0.27 | 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 | 2.0.26 | 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. |
2020.01 - Oktober 2022 | 2.0.25 | MM-3700 | De uitleg over het gebruik van tokens is als sectie opgenomen in de overkoepelende handleiding van Touchstone, de losse pagina is verwijderd. |
2020.01 - September 2022 | 2.0.24 | MM-3595 | The outdated contact information in the profiles has been updated. |
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 | 2.0.23 | MM-3493 | De uitleg over het gebruik van het CCG-formulier is aangepast naar de huidige werkwijze. |
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. | ||
2020.01 - Juli 2022 | 2.0.22 | MM-3367 | Spelfouten opgelost en andere kleine aanpassingen doorgevoerd. |
MM-3355 | Een toelichting dat het BSN niet uitgewisseld mag worden met PGO's is toegevoegd aan het algemeen functioneel ontwerp. | ||
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 | 2.0.21 | 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-3230 | Several examples of the zib2017 profiles were missing a reference to PractitionerRole. This reference has been added. | ||
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 | 2.0.20 | MM-3204 | In de Touchstone-handleiding is een waarschuwing geplaatst over het verwijderen van de USER_KEY of ORG_KEY in publieke plekken. |
MM-3174 | |||
MM-3054 | Reference.display is niet langer verplicht in de technische testscripts wanneer de NullFlavor- of data-absent-reason-extensie aanwezig is. | ||
2020.01 - April 2022 | 2.0.19 | 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-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-3032 | In de kwalificatiematerialen wordt nu gecontroleerd of FHIR Identifiers zowel een .system (of eventueel een .type) en een .value bevatten. | ||
MM-2972 | De Identifier veranderd van URL naar urn:oid in onze technisch kwalificatie materiaal. | ||
2020.01 - Maart 2022 | 2.0.18 | 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. |
2020.01 - Februari 2022 | 2.0.17 | MM-2889 | De layout van het Beelden-kwalificatiescript is geüpdated met het algemene template. |
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-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 | 2.0.16 | 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-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 - Oktober 2021 | 2.0.13 | 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. |
2020.01 - Augustus 2021 | 2.0.11 | MM-2303 | De kwalificatiescripts en addenda zijn naar wiki-pagina’s omgezet. Verwijder of archiveer eerder gedownloade (pdf) versies. |
2020.01 - Zomerrelease 2020 | 2.0.0 | 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. |