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

kardinaliteit business identifiers in profielen voor medicatiebouwstenen

    Details

    • Type: Wijzigingsverzoek
    • Status: Analyse
    • Priority: 3
    • Resolution: Unresolved
    • Fix Version/s: Nader te bepalen
    • Blokkerend:
      Nee
    • Informatiestandaard:
      Medicatieproces
    • Informatiestandaard onderdeel:
      FHIR
    • FHIR Category:
      Profiles
    • Voorgestelde oplossing:
      Hide
      De zibs zijn niet limitatief. Ook niet voor identifier 1..1. Als ik 2 identifiers heb, dan is de eerste zib-conform, en de tweede niet gedefinieerd. Die kan echter valide zijn in een use case die zib niet kent: zibs kennen tenslotte _by design_ geen context/use case. Zoals de zib bijvoorbeeld ook geen medicamenteuze behandelings-id (MBH-id) kent terwijl het profiel hiervoor wel een extensie definieert.
      Dus: de MBH-id en de tweede identifier zijn weliswaar niet gedefinieerd in de zib, maar wel conform de mogelijkheden van de zib om te worden aangepast aan de context waarin de zib wordt toegepast.

      Dat het profiel voor identificatienummer 0..* heeft in plaats van 1..* lijkt minder handig gekozen. Het stelt een implementer in staat om zonder identificatie een medicatieafspraak op te leveren, terwijl er -ook historisch- gezien geen reden is om dat te doen. Het is zelfs onwenselijk omdat het zonder identificatienummer niet mogelijk is om verwijzingen tussen medicatieafspraken en andere dingen te laten lopen.

      Voorstel is dan ook in het profiel voor medicatieafspraak de identifier op 1..* te brengen. Van toedieningsafspraak / toediening / verstrekkingsverzoek / verstrekking / medicatiegebruik / medicatieverbruik zou dat ook kunnen, maar daar zou dan van moeten worden vastgesteld of dat nodig is/kan.
      Show
      De zibs zijn niet limitatief. Ook niet voor identifier 1..1. Als ik 2 identifiers heb, dan is de eerste zib-conform, en de tweede niet gedefinieerd. Die kan echter valide zijn in een use case die zib niet kent: zibs kennen tenslotte _by design_ geen context/use case. Zoals de zib bijvoorbeeld ook geen medicamenteuze behandelings-id (MBH-id) kent terwijl het profiel hiervoor wel een extensie definieert. Dus: de MBH-id en de tweede identifier zijn weliswaar niet gedefinieerd in de zib, maar wel conform de mogelijkheden van de zib om te worden aangepast aan de context waarin de zib wordt toegepast. Dat het profiel voor identificatienummer 0..* heeft in plaats van 1..* lijkt minder handig gekozen. Het stelt een implementer in staat om zonder identificatie een medicatieafspraak op te leveren, terwijl er -ook historisch- gezien geen reden is om dat te doen. Het is zelfs onwenselijk omdat het zonder identificatienummer niet mogelijk is om verwijzingen tussen medicatieafspraken en andere dingen te laten lopen. Voorstel is dan ook in het profiel voor medicatieafspraak de identifier op 1..* te brengen. Van toedieningsafspraak / toediening / verstrekkingsverzoek / verstrekking / medicatiegebruik / medicatieverbruik zou dat ook kunnen, maar daar zou dan van moeten worden vastgesteld of dat nodig is/kan.

      Description

      Bij de medicatiebouwstenen is de business identifier altijd 1..1, in de profielen op Simplifier vinden we 0..*, zie bijvoorbeeld: https://simplifier.net/nictizstu3-zib2017/zib-medicationagreement 

      Het is niet de bedoeling dat er meer dan 1 business identifier uitgewisseld wordt voor medicatiebouwstenen, implementerende partijen moeten er van uit kunnen gaan dat er precies één is.

      Het profiel moet in lijn gebracht worden met de informatiestandaard.

        Attachments

          Activity

            People

            Assignee:
            wetering Arianne van de Wetering
            Reporter:
            wetering Arianne van de Wetering
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated:

                Estimations By Role

                No roles have been estimated yet.