Uploaded image for project: 'MedMij Standaarden'
  1. MedMij Standaarden
  2. MM-369

zib Patient kardinaliteit

    Details

    • Type: Wijzigingsverzoek
    • Status: Doorontwikkeling
    • Priority: 3
    • Resolution: Unresolved
    • Fix Version/s: Nader te bepalen
    • Blokkerend:
      Nee
    • Informatiestandaard:
      Alle
    • Informatiestandaard onderdeel:
      Functioneel
    • Impact:
      Betreft fundamentele discussie, die tot tenminste mineure wijzigingen zou kunnen leiden
    • Voorgestelde oplossing:
      Hide
      Deze issue, dit wijzigingsverzoek, registreer ik als punt voor doorontwikkeling. Enkele gepubliceerde standaarden kunnen op dit gebied (dataset en scenario’s met kardinaliteiten en conformance) zeker nadere specificatie gebruiken.

      De strekking van de gepubliceerde MedMij informatiestandaarden is op dit punt echter helder. De standaarden maken inderdaad onder andere gebruik van de zib patiënt.
      Zibs kennen optionele en verplichte data-elementen. PGO dient zorggegevens conform die zibs te kunnen verwerken, en delen. Om beschikbaargestelde zorggegevens te kunnen verwerken volstaat het overigens niet om alleen verplichte data-elementen van een zib (zoals patiënt) middels PGO te ondersteunen. Nickname is geen data-element in de naamgegevens in patiënt zib. Die kan voor de gegevensuitwisseling niet gebruikt worden. Ten behoeve van uitwisseling dienen de velden conform patiënt zib ondersteund te worden.

      Bij de use case Delen (transactie Sturen) wordt ook de kardinaliteit van zib patiënt gevolgd, waarbij tenminste de verplichte data-elementen moeten worden meegestuurd. Het meesturen van identificerende informatie over de patiënt kan om ten minste twee redenen functioneel zinvol zijn. Het kan een functie hebben in het voorkomen van identiteitsverwisseling, als waarborg bovenop de authenticatie in het kader van de UC Delen of Verzamelen van het afsprakenstelsel. En het kan zinvol zijn omdat, wanneer gegevens worden doorgestuurd (eerst zijn verkregen via Raadplegen zelfmetingen, en daarna worden verstuurd via Sturen zelfmetingen), deze gegevens eerder ook zijn ontvangen en inhoudelijk verbonden zijn met de overige gegevens.

      Het kwalificatiescript is in lijn met de standaard. De standaard verplicht niet tot het vullen van (alle) patiëntadministratieve gegevens die in het script zijn opgenomen, maar voor het kwalificatiescenario zijn deze wel relevant. In de kwalificatie-addenda zijn relevante voorbeelden uitgewerkt, die optionele data-elementen kunnen bevatten. Bij de beoordeling van de kwalificatie worden die meegenomen.

      Hopelijk kunnen jullie hiermee verder met het inbouwen van de MedMij standaarden.
      Show
      Deze issue, dit wijzigingsverzoek, registreer ik als punt voor doorontwikkeling. Enkele gepubliceerde standaarden kunnen op dit gebied (dataset en scenario’s met kardinaliteiten en conformance) zeker nadere specificatie gebruiken. De strekking van de gepubliceerde MedMij informatiestandaarden is op dit punt echter helder. De standaarden maken inderdaad onder andere gebruik van de zib patiënt. Zibs kennen optionele en verplichte data-elementen. PGO dient zorggegevens conform die zibs te kunnen verwerken, en delen. Om beschikbaargestelde zorggegevens te kunnen verwerken volstaat het overigens niet om alleen verplichte data-elementen van een zib (zoals patiënt) middels PGO te ondersteunen. Nickname is geen data-element in de naamgegevens in patiënt zib. Die kan voor de gegevensuitwisseling niet gebruikt worden. Ten behoeve van uitwisseling dienen de velden conform patiënt zib ondersteund te worden. Bij de use case Delen (transactie Sturen) wordt ook de kardinaliteit van zib patiënt gevolgd, waarbij tenminste de verplichte data-elementen moeten worden meegestuurd. Het meesturen van identificerende informatie over de patiënt kan om ten minste twee redenen functioneel zinvol zijn. Het kan een functie hebben in het voorkomen van identiteitsverwisseling, als waarborg bovenop de authenticatie in het kader van de UC Delen of Verzamelen van het afsprakenstelsel. En het kan zinvol zijn omdat, wanneer gegevens worden doorgestuurd (eerst zijn verkregen via Raadplegen zelfmetingen, en daarna worden verstuurd via Sturen zelfmetingen), deze gegevens eerder ook zijn ontvangen en inhoudelijk verbonden zijn met de overige gegevens. Het kwalificatiescript is in lijn met de standaard. De standaard verplicht niet tot het vullen van (alle) patiëntadministratieve gegevens die in het script zijn opgenomen, maar voor het kwalificatiescenario zijn deze wel relevant. In de kwalificatie-addenda zijn relevante voorbeelden uitgewerkt, die optionele data-elementen kunnen bevatten. Bij de beoordeling van de kwalificatie worden die meegenomen. Hopelijk kunnen jullie hiermee verder met het inbouwen van de MedMij standaarden.

      Description

      De kardinaliteit zoals die in zib Patient wordt beschreven op zibs.nl/wiki/Patient-v3.1(2017NL) kan niet worden gevuld door het PGO.

      Tevens stuurt het PGO bij het opsturen van bijv. zelfmetingen als nameuse de waarde 'nickname' mee.

      Een gebruiker van het PGO is niet persé patient, maar kan elke willekeurige gebruiker zijn. Om toegang tot het PGO laagdrempelig te maken vragen wij alleen een profielnaam en e-mailadres aan de gebruiker. Eventueel kan dit in het profiel nog worden aangevuld met geslacht en geboortedatum.

      De profielnaam is dus vrij invulbaar en is geen gestructureerd veld, hieruit kunnen we als PGO dus ook geen achternaam afleiden omdat hier ook 'janssenjan' in kan staan of een waarde die helemaal niet lijkt op een naam. 

      Verder hebben we ook geen partnergegevens in het PGO staan.

      De zib-Patient is vanuit zorgcontext wel te begrijpen en binnen het zorgdomein dan misschien ook gemakkelijker te vullen. Vanuit persoonsdomein is gekozen kardinaliteit voor het versturen van gegevens daarmee dus niet te vullen vanuit ons PGO.

      Dit betekent niet dat we de gegevens niet kunnen ontvangen, inlezen en tonen aan de gebruiker in het geval van UseCase verzamelen. Echter bij UseCase delen kunnen we deze gegevens niet vullen. Daarnaast vindt de echte verificatie van de gebruiker/patient ook plaats in het zorgdomein en de daarbij gekoppelde patient gegevens kunnen dus ook altijd in het zorgdomein opgehaald worden.

       

      Het voorstel is dan ook om in de ontwerpen rekening te houden met dit significante verschil en bij de UseCases delen een andere kardinaliteit voor patient te kiezen. Daarnaast ook het gebruik van nameuse ruimer te accepteren. 

       

       

       

       

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              hagen@nictiz.nl Victor van Hagen
              Reporter:
              r_d@quli.nl R & D afdeling quli
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:

                  Estimations By Role

                  No roles have been estimated yet.