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

Transacties versus FHIR-requests binnen de BGZ

    Details

    • Type: Bevinding
    • Status: Gesloten
    • Priority: 3
    • Resolution: Resolved
    • Fix Version/s: Niet van toepassing
    • Blokkerend:
      Nee
    • Informatiestandaard:
      BgZ
    • Informatiestandaard onderdeel:
      Functioneel
    • Voorgestelde oplossing:
      Hide
      Het afsprakenstelsel kan niet via het informatiestandaarden ticketsysteem worden beïnvloed. Hier kunt u uw vraag het beste richten aan info@medmij.nl t.a.v. Carin Salomon

      De informatiestandaarden bewegen zich op twee lagen van het [vijflagenmodel|https://www.nictiz.nl/standaardisatie/interoperabiliteit/]. Het functionele ontwerp zit op de informatielaag en het technisch ontwerp zit op de applicatielaag.Deze lagen zijn gerelateerd, maar niet een op een aan elkaar gelijk. Het technisch ontwerp moet de functionaliteit dekken van het functionele model.

      FHIR Transaction Bundles zijn niet geschikt om mee te query-en. Deze zijn bedoeld om als transactie dingen te uploaden. We hebben bij het uitwerken van de BgZ in FHIR wel diverse mogelijkheden op tafel gehad, waaronder het opsturen van een Query Bundle en een Operation. De Query Bundle is afgevallen op verzoek van diverse leveranciers omdat dit tot onoplosbare pagineringsvraagstukken en performance-issues zou leiden. De Operation is afgevallen omdat dit tot een precedent zou leiden waarbij we bij iedere toekomstige use case met een set gegevens een nieuwe Operation nodig zouden hebben wat iedere keer een custom FHIR oplossing zou zijn voor MedMij. Ook paginering en performance hebben een rol gespeeld bij het afwijzen van een Operation.

      De huidige oplossing waarbij de losse onderdelen van een BgZ kunnen worden uitgevraagd komt tegemoet aan een breed gedeelde wens van leveranciers om fijne, granulaire uitvragingen te doen en dus niet noodzakelijk altijd de BgZ als geheel op te halen. De gekozen oplossing geeft wel autorisatie-uitdagingen, maar deze zijn overkomelijk geacht en gebleken.
      Show
      Het afsprakenstelsel kan niet via het informatiestandaarden ticketsysteem worden beïnvloed. Hier kunt u uw vraag het beste richten aan info@medmij.nl t.a.v. Carin Salomon De informatiestandaarden bewegen zich op twee lagen van het [vijflagenmodel| https://www.nictiz.nl/standaardisatie/interoperabiliteit/ ]. Het functionele ontwerp zit op de informatielaag en het technisch ontwerp zit op de applicatielaag.Deze lagen zijn gerelateerd, maar niet een op een aan elkaar gelijk. Het technisch ontwerp moet de functionaliteit dekken van het functionele model. FHIR Transaction Bundles zijn niet geschikt om mee te query-en. Deze zijn bedoeld om als transactie dingen te uploaden. We hebben bij het uitwerken van de BgZ in FHIR wel diverse mogelijkheden op tafel gehad, waaronder het opsturen van een Query Bundle en een Operation. De Query Bundle is afgevallen op verzoek van diverse leveranciers omdat dit tot onoplosbare pagineringsvraagstukken en performance-issues zou leiden. De Operation is afgevallen omdat dit tot een precedent zou leiden waarbij we bij iedere toekomstige use case met een set gegevens een nieuwe Operation nodig zouden hebben wat iedere keer een custom FHIR oplossing zou zijn voor MedMij. Ook paginering en performance hebben een rol gespeeld bij het afwijzen van een Operation. De huidige oplossing waarbij de losse onderdelen van een BgZ kunnen worden uitgevraagd komt tegemoet aan een breed gedeelde wens van leveranciers om fijne, granulaire uitvragingen te doen en dus niet noodzakelijk altijd de BgZ als geheel op te halen. De gekozen oplossing geeft wel autorisatie-uitdagingen, maar deze zijn overkomelijk geacht en gebleken.

      Description

      (Issue n.a.v. telefonisch overleg op 25 april 2019. Lilian Brouwer, ik ben zo vrij om hem aan jou toe te wijzen, omdat je me dan eventueel naar een al bestaand issue kunt verwijzen.)

      Punten 14 t/m 16 van de flow op op https://afsprakenstelsel.medmij.nl/display/PUBLIC/UCI+Verzamelen
      omschrijven de eerste FHIR-request:

      "Nu is de PGO Server gereed om het verzoek om de gezondheidsinformatie naar de Resource Server te sturen.
      (...) dan verstuurt de Resource Server deze ze in een FHIR-response naar de PGO Server.
      (...) Deze bewaart de ontvangen gezondheidsinformatie in het persoonlijke dossier."

      Ze omschrijven ook de mogelijkheid van vervolg-requests
      ALS de Gegevensdienst uit meerdere Transacties bestaat:

      "Mocht de Gegevensdienst waartoe de Zorggebruiker heeft geautoriseerd uit meerdere Transacties bestaan,
      bevraagt de PGO Server de Resource Server daarna mogelijk opnieuw voor de nog resterende Transacties,
      eventueel na nieuwe gebruikersinteractie.
      Zolang het access token geldig is, kan dat."

      Verder is gegeven:

      Conclusie:

      Er ontbreekt een pijltje in de flow op https://afsprakenstelsel.medmij.nl/display/PUBLIC/UCI+Verzamelen
      voor wanneer een Transactie uit meerdere requests bestaat, zoals in het geval van de BGZ.

      Zonder dit extra pijltje mag een client strikt genomen maar één FHIR-request doen binnen één doorloop van de flow,
      dus kan alleen een stukje van de BGZ worden opgehaald.

      Alternatieve conclusies:

      1. De BGZ moet worden opgehaald in één FHIR-request.
        FHIR ondersteunt dit d.m.v. een FHIR-transactie-request: http://hl7.org/fhir/STU3/http.html#transaction
      2. De BGZ moet uit meerdere Transacties bestaan.
        Dan passen meerdere FHIR-request binnen de huidige flow,
        maar de stap 'bewaar in dossier' staat dan wel op een ongelukkige plaats:
        in geval van een fout bij het ophalen één van de BGZ-onderdelen
        zijn de daarvóór opgehaalde BGZ-onderdelen al opgeslagen,
        maar mogen de overige BGZ-onderdelen niet meer worden opgehaald omdat de flow wordt afgebroken.

        Attachments

          Activity

            People

            • Assignee:
              toonstra Ardon Toonstra
              Reporter:
              jeroen.leeuwestein@curavista.nl Jeroen Leeuwestein
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Estimations By Role

                No roles have been estimated yet.