Functioneel Ontwerp BgZ

Uit informatiestandaarden
Ga naar: navigatie, zoeken



Patient Summary (BgZ)
Naar medmij.nl
AfsprakenstelselFunctioneelTechnischAfspraken-Functioneel-Technisch


1 Inleiding

1.1 Algemeen

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

De Basisgegevensset Zorg, ofwel BgZ, is de minimale set van patiëntgegevens die specialisme, ziektebeeld en beroepsgroepoverstijgend relevant is en van belang is voor de continuïteit van zorg. De BgZ is in Nederland door 'Registratie aan de Bron' gedefinieerd. Deze set aan patiëntgegevens wordt door alle zorgverleners hetzelfde vastgelegd. Hierdoor wordt uitwisseling van deze gegevens mogelijk gemaakt. De BgZ is gespiegeld aan de Europese Patient Summary.

De bekende use cases voor het uitwisselen van de BgZ zijn gericht op uitwisseling tussen zorgverleners voor spoedeisende hulp of ongeplande zorg. Deze pagina beschrijft het perspectief van de patiënt use cases raadplegen van de BgZ en een wijzigingsverzoek kunnen maken en indienen op de BgZ door de patiënt vanuit een PGO.

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: BgZ 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.

1.4.2 Specifieke informatie over deze kwalificatie

Specifieke informatie over de kwalificatie van de transacties 'Raadplegen BgZ', 'Beschikbaarstellen BgZ', “Sturen Wijzigingsverzoek BgZ” en "Ontvangen Wijzigingsverzoek BgZ" is te vinden in Toelichting Kwalificatie BgZ.

2 Use Cases

2.1 Use case 1: Raadplegen Basisgegevensset Zorg in persoonlijke gezondheidsomgeving

2.1.1 Doel en relevantie

Het voor patiënten mogelijk maken regie op hun eigen gezondheid te nemen door inzicht te geven in gegevens uit de Basisgegevensset Zorg (BgZ) die over henzelf gaan.

2.1.2 Domein

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

2.1.3 Context

Het gaat om het elektronisch en gestructureerd beschikbaar maken van de BgZ 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

De BgZ op basis van zibs release 2017 bestaat uit een selectie van 28 zibs. Deze zibs vormen samen een verzameling van patiëntgegevens die minimaal nodig is om patiënten continuïteit van zorg te kunnen bieden.

Deze use case gebruikt de structuur van 18 secties die is aangebracht in BgZ 2017. Hierin zijn de onderdelen gegroepeerd waaruit de BgZ is opgebouwd. Deze secties komen sterk overeen met de secties van CCR/CCD en maken het o.a. mogelijk om in de technische implementatie (bv FHIR) structuur aan te brengen. In de MedMij FHIR implementatie gids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit overzicht is te zien welk FHIR profiel bij welke zib hoort.

Voor het gebruik van codestelsel geldt de algemene richtlijn.

2.1.4.1 Raadplegen BgZ

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

2.1.4.2 Beschikbaarstellen BgZ

Informatie-elementen in de BgZ staan hieronder. Deze informatie is ook in een nieuw tabblad te openen. Bij het beschikbaarstellen van de BgZ worden alle beschikbare gegevens behorende bij de patiënt beschikbaargesteld.

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 (PGO) Wil de eigen BgZ raadplegen
Zorgaanbieder (XIS) Stelt de BgZ beschikbaar

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

Activiteitendiagram Raadplegen BgZ

2.1.6 Procesbeschrijving

2.1.6.1 Patient journey - Thomas van Beek

De 'patient journey' van Thomas van Beek beschrijft enkele momenten waarop je als patiënt zijnde inzicht kan of zou willen hebben in zijn/haar BgZ en hier regie op wil voeren.

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

2.1.6.2 Proces

Het stuk van het proces waar het in deze use case omgaat is:

  • Het systeem van een zorgaanbieder (XIS) stelt de BgZ van de patiënt beschikbaar aan het systeem van een patiënt (PGO).

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

2.1.6.2.1 Preconditie

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

De BgZ, of een gedeelte van de BgZ, welke de persoon wil inzien, bestaat en de zorgaanbieder (XIS) wil deze beschikbaarstellen.

Soms zijn er valide redenen om de BgZ, of gedeeltes daarvan, tijdelijk nog niet beschikbaar te stellen aan de patiënt. Bijvoorbeeld omdat de zorgverlener deze eerst zelf wil interpreteren en/of er eerst met de patiënt over wil spreken.
Een patiënt kan steeds zelf het initiatief nemen om de BgZ op te halen, maar het is ook mogelijk dat een PGO geconfigureerd is om dit 'automatisch' te doen. Dit maakt voor de scope van deze use case beschrijving geen verschil.
2.1.6.2.2 Proces stappen
Stap Omschrijving
01 Het systeem van de patiënt (PGO) raadpleegt het systeem van de zorgaanbieder (XIS) voor de BgZ van de patiënt.
02 Het systeem van de zorgaanbieder (XIS) maakt (een deel van) de BgZ beschikbaar voor de patiënt.
03 De patiënt gebruikt de persoonlijke gezondheidsomgeving (PGO) om de BgZ in te zien.
2.1.6.2.3 Post conditie

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

2.1.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 de BgZ van zorgaanbieder naar de patiënt.

Systeem Naam systeemrol Systeemrolcode Omschrijving
PGO BGZRaadplegend MM--BZR-FHIR Raadplegen BgZ bij zorgaanbieder
XIS BGZBeschikbaarstellend MM--BZB-FHIR Beschikbaarstellen BgZ aan de patiënt

Zie ook onderstaande afbeelding.

Componenten diagram

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 vraag- en antwoordbericht). Onderstaande tabel biedt een overzicht voor deze use case.

Transactiegroep Transactie Systeemrolcode Systeem Bedrijfsrol Technisch
BgZ (PULL) Raadplegen BgZ [MM--BZR-FHIR] PGO Patiënt BgZ in FHIR
Beschikbaarstellen BgZ [MM--BZB-FHIR] XIS Zorgaanbieder

2.1.9 Use case diagram

Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

Use case diagram inzien BgZ

2.2 Use case 2: Sturen Wijzigingsverzoek BgZ vanuit een PGO

2.2.1 Doel en relevantie

  • Het voor patiënten mogelijk maken om vanuit een PGO een wijzigingsverzoek te kunnen sturen naar de zorgaanbieder waar de patiënt mee bekend is, op bij deze zorgaanbieder reeds bekende BgZ instantiatie(s).

2.2.2 Domein

Basisgegevensset Zorg in het domein van zorgaanbieders en patiënten. Wijzigingsverzoeken via PGO’s zijn één van de mogelijkheden voor een patiënt om aanpassingen op het medisch dossier te kunnen indienen bij de dossiervoerder conform de:

Tevens speelt deze use case een rol binnen het subsidieprogramma VIPP5 (https://www.vipp-programma.nl/) in: Module 2: Informatie-uitwisseling met PGO en patiënt kan informatie terugzenden richting instelling vanuit PGO (tweerichtingsverkeer). (https://www.dus-i.nl/subsidies/vipp-fase-5)

Met de specificering: De instelling kan voorstellen tot aanpassingen op de aanwezige BgZ-items van de patiënt ontvangen vanuit de PGO van de patiënt. Conform BgZ 1.0 conform zibs 2017 of hoger en conform het MedMij-Afsprakenstelsel. Informatiestandaard MedMij BgZ. (https://zoek.officielebekendmakingen.nl/stcrt-2020-7935.html)

2.2.3 Context

Het gaat in deze versie van de use case om het elektronisch, via ongestructureerde tekstinvoer sturen van een door de patiënt geformuleerd wijzigingsverzoek op de reeds bij de zorgaanbieder bekende BgZ vanuit een persoonlijke gezondheidsomgeving (PGO) naar een zorgaanbiederssysteem (XIS). Alsook het op de hoogte stellen van de zorgaanbieder van het verstuurde BgZ wijzigingsverzoek en het op de hoogte stellen van de patiënt door de zorgaanbieder van statusupdates en/of afhandeling van het wijzigingsverzoek.

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

Voor deze use case wordt gebruik gemaakt van de BgZ op basis van zibs release 2020. Deze bestaat uit een selectie van 28 zibs. Deze zibs vormen samen een verzameling van patiëntgegevens die minimaal nodig zijn om patiënten continuïteit van zorg te kunnen bieden. Deze use case gebruikt een minimale hoeveelheid zibs van de BgZ 2020 die nodig zijn om het ongestructureerde wijzigingsverzoek vanuit de patiënt te kunnen sturen aan de zorgaanbieder. Er worden nadrukkelijk geen gestructureerde of anderszins op specifieke BgZ zibs gespecificeerde wijzigingsverzoeken ondersteund in deze use case, de inhoud van het wijzigingsverzoek zoals door de patiënt gemaakt is ongestructureerde tekst. In de MedMij FHIR implementatie gids staat de technische representatie van de betreffende zibs in zogenaamde FHIR profielen. In dit overzicht is te zien welk FHIR profiel bij welke zib hoort.

Voor het gebruik van codestelsel geldt de algemene richtlijn.

Bij het sturen van een BgZ Wijzigingsverzoek gaat het om de volgende informatie die uitgewisseld wordt:

  • Het door patiënt ingevulde wijzigingsverzoek op de BgZ in een specifiek daarvoor bestemd ongestructureerd tekstveld.

De informatie-elementen voor sturen en ontvangen van een wijzigingsverzoek op de BgZ staan in ART-DECOR (!!!) Invoegen:

  • Zib Patiënt (verplicht)
  • Zib Zorgverlener (indien beschikbaar, ter duiding voor de zorgaanbieder, waar het wijzigingsverzoek over gaat)
  • Zib Zorgaanbieder (verplicht)

2.2.4.1 Wijzigingsverzoek BgZ Sturen

Informatie-elementen in de BgZ staan hieronder. Deze informatie is ook in een [-----ART-DECOR linkje maken hier------------] nieuw tabblad] te openen. Bij het sturen van BgZ Wijzigingsverzoek worden alle beschikbare gegevens behorende bij de patiënt in de gespecificeerde zibs gestuurd.


ANDERE, JUISTE TABEL IN PASTEN-------------------------------------------

2.2.4.2 Toelichting

Er kunnen door implementerende partijen en zorgaanbieders afspraken gemaakt worden over verdere toelichting tonen/geven aan de patiënt bij het vullen van het BgZ wijzigingsverzoek in de PGO en voor de zorgaanbieder/zorgverlener hoe om te gaan met proces rond afhandelen van wijzigingsverzoeken via PGO en over het informeren van de patiënt over statusupdates en afhandeling hiervan.

2.2.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 Gaat BgZ Wijzigingsverzoek sturen
Zorgaanbieder Gaat BgZ Wijzigingsverzoek ontvangen

Bedrijfsrollen sturen BgZ Wijzigingsverzoek

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

Activiteitendiagram sturen Wijzigingsverzoek Basisgegevensset Zorg

Activiteitendiagram sturen BgZ Wijzigingsverzoek

2.2.6 Procesbeschrijving

2.2.6.1 Patient Journey – Thomas van Beek

Een voorbeeldsituatie die de meerwaarde van het sturen van wijzigingsverzoek op de BgZ vanuit het PGO schetst is de patiënt journey van Thomas van Beek.

beschrijft een moment waarop je als patiënt zijnde een wijzigingsverzoek zou willen indienen op de bij de zorgaanbieder vastgelegde BgZ.

Thomas is voor controle van zijn diabetes in het ziekenhuis in Groningen geweest. De verpleegkundige heeft daarbij controles gedaan en in het dossier in o.a. de BgZ vastgelegd. Twee maanden na de controle kijkt Thomas zijn BgZ in via zijn PGO en ziet dat daar zijn gewicht verkeerd staat, wellicht een typfout. Ook ziet hij dat er een oud type insulinepomp staat, hij gebruikt inmiddels alweer een tijdje een ander model hulpmiddel met andere specificaties. Thomas wil graag dat zijn dossier aangepast wordt en besluit een verzoek tot wijziging te doen.

Thomas vult in zijn PGO een wijzigingsverzoek in op de BgZ en verzendt deze naar het ziekenhuis in Groningen, zodat zij weten welke aanpassingen op zijn BgZ Thomas verzoekt. Het ziekenhuis kan hierna hun wijzigingsbeleid hanteren en Thomas op de hoogte stellen over de afhandeling van het wijzigingsverzoek.

2.2.6.2 Proces

Deze use case ondersteunt de workflow tussen zorgaanbieder en patiënt rondom het procesmatig/logistiek ontvangen van een wijzigingsverzoek en statusupdate(s)kunnen versturen naar een patiënt over de afhandeling ervan. Inhoudelijke workflow over de verwerking van het wijzigingsverzoek wordt niet ondersteund. Werkafspraken over de verwerking van wijzigingsverzoeken zijn dus geen onderdeel van deze use case en dienen buiten de informatiestandaard afgesproken te worden. Voordat het proces rond deze use case start heeft een zorgaanbieder reeds uit een behandelrelatie voortgekomen dossiervoering op (onderdelen van) de BgZ van de patiënt (gehad). Dit kan zowel een actieve behandelrelatie als ene behandelrelatie uit het verleden zijn. Ook heeft de zorgaanbieder het beschikbaar stellen van de BgZ middels MedMij gekwalificeerde PGO’s geïmplementeerd conditioneel aan het kunnen implementeren van deze use case. De patiënt heeft daartoe voorafgaand aan het maken van een BgZ wijzigingsverzoek zijn BgZ opgehaald en ingezien zoals beschreven in de use case raadplegen BgZ https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpBGZ_2017#Use_case_1:_Raadplegen_Basisgegevensset_Zorg_in_persoonlijke_gezondheidsomgeving. Patiënt heeft daarop een beeld kunnen vormen van aanpassingen op deze BgZ onderdelen die hij in een wijzigingsverzoek zou willen voorstellen richting de zorgaanbieder en kan dan een BgZ wijzigingsverzoek opstellen. Het stuk van het proces waar het in deze use case om gaat is:

  • De patiënt maakt een wijzigingsverzoek op de bij de zorgaanbieder bekende BgZ in zijn PGO en stuurt deze richting de zorgaanbieder ter verder afhandeling door de zorgverlener cq zorgaanbieder.
  • Patiënt heeft de mogelijkheid om dit verzoek in ongestructureerde tekst te beschrijven.
  • Patiënt wordt op de hoogte gesteld dat het BgZ wijzigingsverzoek succesvol is ontvangen.
  • Na het versturen van het wijzigingsverzoek wordt de zorgaanbieder op de hoogte gesteld van het wijzigingsverzoek wat gestuurd is door de patiënt.

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

2.2.6.2.1 Preconditie
  • De patiënt is in staat om de bij zorgaanbieder bekende BgZ op te halen en op te slaan in zijn PGO.

Hiervoor is de implementatie van de use case https://informatiestandaarden.nictiz.nl/wiki/MedMij:V2020.01/OntwerpBGZ_2017#Use_case_1:_Raadplegen_Basisgegevensset_Zorg_in_persoonlijke_gezondheidsomgeving raadplegen BgZ niet direct gerelateerd maar wel conditioneel.

  • Het XIS van de zorgaanbieder is in staat BgZ wijzigingsverzoeken van de patiënt te ontvangen.
  • De PGO van de patiënt is in staat BgZ wijzigingsverzoeken te kunnen versturen naar zorgaanbieder(s) waar de BgZ waar de het wijzigingsverzoek op ziet en welke reeds door de patiënt in eerder stadium is opgehaald en opgeslagen.
2.2.6.2.2 Processtappen
  • De PGO stelt de patiënt in staat een wijzigingsverzoek op de BgZ aan te maken.
  • Patiënt vult het wijzigingsverzoek op de BgZ met ongestructureerde tekst.
  • Patiënt bepaalt wanneer het invullen gereed is en naar welke zorgaanbieder het wijzigingsverzoek verstuurd moet worden.
  • PGO stuurt het wijzigingsverzoek en stelt de patiënt op de hoogte van ontvangstbevestiging.
  • XIS ontvangt wijzigingsverzoek en zorgaanbieder wordt hiervan op de hoogte gesteld hiervan.
2.2.6.2.3 Postconditie
  • De zorgaanbieder heeft het wijzigingsverzoek ontvangen en is hiervan op de hoogte gesteld.

2.2.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 BgZ Wijzigingsverzoek van de patiënt naar de zorgaanbieder.

Systeem Naam systeemrol Systeemrolcode Omschrijving
PGO BgZ wijzigingsverzoek sturend systeem MM--BZS-FHIR Sturen van BgZ wijzigingsverzoek aan zorgaanbieder
XIS BgZ wijzigingsverzoek ontvangend systeem MM--BZO-FHIR Ontvangen van BgZ wijzigingsverzoek van de patiënt

Zie ook onderstaande afbeelding. (!!!NOG FIXEN, JUISTE PLAATJE!!!)

Componenten diagram

Componenten diagram BgZ Wijzigingsverzoek sturen

2.2.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
BgZ Wijzigingsverzoek (PUSH) Stuurt BgZ Wijzigingsverzoek [MM--BZS-FHIR] PGO Patiënt BgZ Wijzigingsverzoek in FHIR
Ontvangt BgZ Wijzigingsverzoek [MM--BZO-FHIR] XIS Zorgaanbieder

2.2.9 Use case diagram

Onderstaande afbeelding toont bedrijfsrollen, activiteiten, systeemrollen, transacties en transactiegroep in samenhang.

Use case diagram Sturen Wijzigingsverzoek BgZ

Use case diagram BgZ Wijzigingsverzoek

3 Functionaliteit

3.1 Eisen en wensen

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

4 Verantwoordelijkheid voor informatie

De implementerende partijen en zorgaanbieders kunnen afspraken en/of richtlijnen maken t.b.v. afhandeling van het wijzigingsverzoek, omgang met en de verantwoordelijkheid voor (omgaan met) verkregen informatie uit dit wijzigingsverzoek.

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
- BgZ - specificatie gebaseerd op zibs release 2020 1.0 10-09-2020 BgZ - specificatie gebaseerd op zibs release 2020 Registratie aan de bron (RadB)
- Basisgegevensset Zorg - 12-08-2019 Alles over de BgZ Registratie aan de bron (RadB)
- BgZ - specificatie gebaseerd op zibs release 2017 1.1 19-04-2018 BgZ - specificatie gebaseerd op zibs release 2017 Registratie aan de bron (RadB)
Albert-Jan Spruyt & Jan A. Hazelzet Alles wat je wilt (moet) weten over CCR/CCD 1.0 13-09-2012 Alles wat je wilt (moet) weten over CCR/CCD Nictiz

8 Release notes

In onderstaande tabel staan de wijzigingen voor deze informatiestandaard. Zie de Ontwerpen landingspagina voor wijzigingen die op alle informatiestandaarden van toepassing zijn.

Release Versie BITS issue Omschrijving
2020.01 - Mei 2021 3.0.8 MM-2132 Het kwalificatiemateriaal voor BgZ 3.x bevatte een verkerde waarde voor het element medicationReference.display in de fixture medmij-bgz-medicationagreement-ts-01. Deze is gewijzigd van "20 mg" naar "10 mg".
MM-2080 Changed HTML to Markdown in the definition field for .clinicalStatus in the profile zib-Problem.
MM-2077 Fixed Markdown formatting in the AllergyIntolerance profile.
MM-2037 Fixed the broken mapping on the root of the zib ProcedureRequest profile to zib PlannedCareActivityForTransfer.
MM-2025 Het technische kwalificatiemateriaal van de BgZ gebruikte bij Scenario 1.2 - MedicationUse (PHR&XIS) & Scenario 1.3 - MedicationUse (XIS) een verkeerde URN:OID in de request. Dit is aangepast naar de juiste URN:OID.
2020.01 - April 2021 3.0.7 MM-1944 The BgZ 3.x (2020.01) FHIR IG was missing Dutch Medication HCIMs in the List of profiles, this is corrected, along with a faulty HCIM name.
MM-1881 Created a ConceptMap for the ValueSet OrderStatusCodelijst (in HCIM ProcedureRequest) to RequestStatus and added it to the HCIM ProcedureRequest FHIR profile.
2020.01 - Januari 2021 3.0.4 MM-1624 On the BgZ FHIR IG, the term "BgLZ" was used by mistake, this has been changed to the correct term "BgZ".
MM-1589 Corrected the display value for SNOMED code 79899007 in an embedded example of FHIR profile zib-MedicationUse.
2020.01 - November 2020 3.0.3 MM-1408 Added a known issue on HCIM FunctionalOrMentalStatus to the BgZ and GGZ FHIR IG's. NL-CM:4.26.6 StatusDate in the profile FunctionalOrMentalStatus is mapped on period.start, but is a date nonetheless, this will be fixed in a future release. Also see MM-1570.
MM-1382 The profile on HCIM AdvanceDirective contained a mapping to BasicElements::Author on the Consent.consentingParty element. However, the HCIM does not specify an author. Therefore, this mapping has been removed.
2020.01 - Oktober 2020 3.0.2 MM-1455 Changed the faulty HCIM name 'MedicalAid' to 'MedicalDevice' on the BgZ FHIR IG.
MM-1444 In the explanation on planning activities represented in HCIM PlannedCareActivityForTransfer mentioned both HCIM names as well as FHIR core resources which led to confusion. Because of conformance, this has been corrected, now only FHIR core resources are mentioned.
MM-1420 Added extra embedded examples to Observation.component:Amount.value[x]:valueQuantity in the HCIM AlcoholUse and HCIM TobaccoUse profiles to clarify the use of UCUM annotations in units.
2020.01 - September 2020 3.0.1 MM-1285 In the ValueSet RedenMedicatieAfspraakCodelijst, replaced the custom ART-DECOR code with SNOMED for the .designation.use element.
MM-1283 In HCIM Procedure, added mapping to the Requester (NL-CM:14.1.10) concept.
MM-1011 Replaced the term "StructureDefinitions" with the more precise term "profiles" in implementation guides.
MM-517 In zib-LaboratoryTestResult-Observation, removed the fixed value of "has-member" in related.type. Added guidance on the use of this profile in relation to other instances.
2020.01 - Zomerrelease 2020 3.0.0 MM-1204 In the zib-BloodPressure profile, the slices for diastolic and systolic pressure have been made required.
MM-972 The definition for the use of the lastn operation is unclear in the FHIR specification, therefore interpretation is added to the FHIR IG's of the information standards that use lastn.
MM-898 In zib-LaboratoryTestResult-Observation, Observation.interpretation.coding is sliced to support both the FHIR core ValueSet and the (partially overlapping) HCIM ValueSet.
MM-767 In zib-LaboratoryTestResult-Speciment(-Isolate), an extension to Speciment.collectionPeriod has been added to support the TimeInterval datatype from the pre-adopted HCIM.
MM-616 The mapping of the element RegistrationDate from HCIM AllergyIntolerance has been changed from AllergyIntolerance.reaction.onset to AllergyIntolerance.onsetDateTime. The mapping on StartDateTime has been changed from AllergyIntolerance.onset[x] to AllergyIntolerance.onsetDateTime.
MM-614 The cardinality of element AllergyIntolerance.code is now 1..1 in the zib-AllergyIntolerance profile, so it aligns with HCIM AllergyIntolerance.
MM-507 In "VitalSigns Profile NL", the cardinality of Observation.performer is relaxed from 1..* to 0..*
MM-419 The example search URL for NutritionAdvice contained a paramater for status=active, where the BgZ information standard specifies a search for all known NutritionAdvice resources. Also, status is not a concept in HCIM NutritionAdvice, which makes use of this element unnecessary. As a result, the status parameter is removed from the example search url and from the BgZ qualification material.
MM-404 In the HCIM Procedure profile, expanded the Procedure.performedPeriod element to Procedure.performed[x]. With this expansion, the profile meets the requirements of the HCIM, namely to capture a moment in time instead of a start/end date.
MM-319 In the HCIM Problem profile, the .onsetPeriod element was used to capture the HCIM concepts ProblemStartDate and ProblemEndDate, while no period is captured in the HCIM. Therefore, Condition.onsetPeriod is changed to Condition.onsetDateTime and the HCIM mapping for ProblemStartDate is corrected. The mapping for ProblemEndDate has been moved to Condition.abatementDateTime.
2019.01 - Mei 2020 2.1.14 MM-1094 Removed the retired 'zib-Appointment' profile in favor of 'eAfspraak-Appointment' in the BgZ CapabilityStatements. Added documentation about the use of the eAfspraak Appointment profile in combination with HCIM PlannedCareActivityForTransfer to the BgZ FHIR IG. Polished some HCIM terminology in the BgZ FHIR IG.
2019.01 - April 2020 2.1.13 MM-1025 Corrected the slicing logic at the discriminator path in the zib-Procedure profile.
MM-1003 In extensions zib-Payer-BankInformation and zib-TreatmentDirective-Verification, add the (required) .url element, and remove this url from the calling profile zib-Payer.
MM-939 The report element in the zib-Procedure profile used a non-existing canonical as a reference to the zib-TextResult profile. This has been fixed.
2019.01 - Maart 2020 2.1.10 MM-997 The consent-additionalSources extension for the zib-TreatmentDirective profile had a context restriction on Consent.source[x], while it actually was applied on Consent directly. This fix removes that restriction.
MM-953 Added documentation to conceptmap-ProbleemStatusCodelijst-To-Condition-Clinical-Status-Codes explaining what the relationship is between codes with equivalence type "specializes".
MM-926 In profiles zib-MedicalDeviceRequest and zib-AllergyIntolerance, add type slices on note.author[x] in order to conform to FHIR rules for extending polymorphic elements.
MM-657 Removed datatype Reference(EpisodeOfCare) and Reference(Encounter) in the .context element of the profiles zib-AlcoholUse, zib-DrugUse and zib-TobaccoUse.
2019.01 - Februari 2020 2.1.9 MM-901 The projectgroup has decided that the mapping of CanceledIndicator to .status in FHIR-profile zib-MedicationAgreement could be deleted because the information isn't necessarily anymore.
MM-900 The slices on .supportingInformation that reference zib-BodyHeight & zib-BodyWeight in FHIR-profile zib-MedicationAgreement are removed. These elements will be used as separate models.
MM-852 In HCIM MedicationUse profile: redefined slicing on MedicationStatement.derivedFrom into seperate slices to fix validator issues, also added mappings to the MedicationProcess information standard.
MM-440 Improvements have been made to the BgZ FHIR IG for the readability and findability of information. It concerns textual and style changes that have no impact on backwards compatibility of the standard.
MM-414 Ten behoeve van leesbaarheid en vindbaarheid van informatie zijn er in het functioneel ontwerp van BgZ verbeteringen doorgevoerd. Het betreft tekstuele-/stijlwijzigingen die geen impact hebben op backwards-compatibility van de standaard.
2019.01 - Januari 2020 2.1.8 MM-492 Added comment to AllergyIntolerance.comment in the HCIM Allergyintolerance FHIR profile to explain the mapping for ValueSet AllergieStatusCodelijst to AllergyIntolerance.clinicalStatus and AllergyIntolerance.verificationStatus. Added dataAbsentReason extension to AllergyIntolerance.verificationStatus.
MM-467 Added comment on MedicationRequest.reasonCode in HCIM MedicationAgreement profile to to explain mising HCIM mapping.
2019.01 - November 2.1.7 MM-806 Fixed MM430: adjusted incorrect FHIRPath constraints, moved extension to Consent.extension and moved mappings in extension from extension.value[x].reference to extension.value[x] in zib-TreatmentDirective profile.
2.1.6 MM-729 The description in MedicationStatement.informationSource of profile zib-MedicationStatement still mentioned the missing-type-reference extension, which isn't used anymore. The description has been updated to the new situation with the PractionerRole reference extension.
MM-430 The TreatmentDirective profile allowed at most 1 reference to an AdvanceDirective resource, because of restrictions in the FHIR base. There is now an extension inside the source element to allow referencing additional AdvanceDirective resources.
2019.01 - Oktober 2.1.5 MM-597 The example for NASAAL was missing urn:oid: preceding the OID value in system.
MM-594 Updated date time example in profile to include timezone as required by the FHIR specification.
2019.01 - September 2.1.4 MM-436 Aanpassen ConceptMap InterpretatieVlaggenCodelijst-to-observation-interpretation
MM-425 URL naar BGZ specificatie op FO en TO verwees naar versie 1.0, dit is aangepast naar de huidige en laatste versie 1.1.
MM-422 Aanpassen conceptnaam ResultaatVlaggen naar InterpretatieVlaggen in FHIR profiel voor LaboratoryResults.
MM-359 Nadere uitwerking van de BgZ kwalificatietoelichting voor XIS.
MM-358 Tekstcorrectie op de kwalificatie pagina ToelichtingKwalificatieBgZ.
2019.01 2.1.3 MM-348 Foutieve discrimator path voor HCIM MedicationAgreement bij MedicationStatement.derivedFrom.
MM-346 Ongeldig discriminator pad in code slicing in ZIB Verrichting.
MM-307 Aanpassen mapping van "Reden wijzigen of staken" en "Reden wijzigen of stoppen gebruik" van HCIM naar MP9.
MM-294 Naam mapping binnen div. FHIR profielen aangepast conform ZIB: HCIM LaboratoryTestResult-v4.1(2017EN).
MM-258 HCIM PharmaceuticalProduct: Added ValueSet 'IngredientCodeGTINCodeLijst' + correct reference url to ValueSet.
MM-248 Fixed typo in sliceName 'medicationTreament' --> 'medicationTreatment'.
2.1.2 MM-219 MedicationUse niet compleet na een resave in Forge.
2.1.1 MM-210 MedMij BgZ is nog gebaseerd op 1.0 i.p.v. 1.1
MM-206 Reference vanuit Observation naar Specimen Isolate onjuist.
2.1.0 MM-174 Corrected search url for PlannedCareActivityForTransfer - DeviceRequest. Added an '&'.
MM-161 CBV codes in ProcedureRequest.
MM-145 ContactPerson verwijzing informatiestandaarden vs patient zib.
MM-144 Problem zib ClinicalStatus can take on values which are not defined by the HCIM.
MM-143 Aanpassing modellering Procedure.performer in het profiel voor HCIM Verrichting.
MM-142 Onduidelijkheid in de modellering van de Aanvrager van een LaboratoriumUitslag.
MM-141 Vital Signs profielen inconsistent m.b.t. baseDefinition.
MM-134 MedicationUse StopType found values do not correspond with MedicationUseStopTypeCodeList values.
MM-127 TimeOfDay in InstructionsForUse and the Hapi Enumerators.
MM-125 Inconsistentie wiki vs simplifier.
MM-118 Profiel naam zib-Product niet passend bij Zib FarmaceutischProduct.
MM-115 Solved inconsistency in the List of StructureDefinitions. Also we will no longer check PlannedCareActivityForTransfer for MedicationAdministration in section 17 Zorgplan, because we found it was unimplementable as-is. Presumed solution will come from a future HCIM release.
MM-100 Mapping CBV naar SNOMED codes.
MM-99 Interval heeft Period maar geen PeriodUnit op simplifier.
MM-98 InstructionsForUse zib informatie model komt niet overeen met simplifier.
MM-94 Specimen microorganism en specimenSource mappen naar hetzelfde fhir element.
MM-50 Contact ondersteunt geen klinische contacten.
MM-42 medicatiegebruik - auteur - zorgverlener: kan niet alle info kwijt.
MM-41 voorschrijver/zorgverlener/zorgaanbieder past niet in medicationUse.
2018.06 2.0.1 MM-174 Corrected search url for PlannedCareActivityForTransfer - DeviceRequest. Added an '&'.
MM-128 CanceledIndicator possible values.
MM-66 Update mappings LaboratoriumUitslag in DiagnosticReport en Observation.
MM-55 Profile for HCIM TobaccoUse was missing a specification for PackYears unit - profile updated to 2.0.1.
MM-54 Wrong SNOMED code in search URL for FunctionalOrMentalStatus.
MM-23 Commentaar bij dagdeel codelijst verwijst naar dode URL.