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

Hoe om te gaan met DomainResource.text

    Details

    • Type: Vraag
    • Status: Gesloten
    • Priority: 3
    • Resolution: Resolved
    • Fix Version/s: None
    • Blokkerend:
      Nee
    • Informatiestandaard:
      Alle
    • Informatiestandaard onderdeel:
      FHIR
    • Beproeving:
      POC
    • Voorgestelde oplossing:
      Hide
      DomainResource.text. We zeggen daar in MedMij niets speciaals over. Dan geldt de FHIR standaard zelf. Deze zegt daarover (https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text):

      “A human-readable narrative that contains a summary of the resource, and may be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.

      Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative."

      Dus samengevat:

      1. Systemen die FHIR resources opleveren zouden Resource.text moeten (SHOULD: niet SHALL) hebben op een niveau die de menselijke lezer een redelijk beeld geeft van de informatie. Uitzondering is Resource.contained.Resource. Deze mag geen text bevatten. Het is mij niet geheel duidelijk in de FHIR standaard hoe je “summary of the resource” rijmt op de Narrative.status codes “empty” en “additional” (https://hl7.org/fhir/STU3/valueset-narrative-status.html). Beide zijn namelijk voorbeelden waarin de text geen samenvatting is.

      — Aanbeveling: zorg voor Resource.text van type extensions of generated. Extensions heeft voorkeur omdat dan de verwachting is dat zib-specifieke extensies ook worden meegenomen.

      In bijvoorbeeld HAPI zit ook een NarrativeGenerator. Ik weet niet wat deze kan (bijvoorbeeld Nederlandse labels genereren). Alternatief is mogelijk de NarrativeGenerator die wij in XSL (2.0) in voorbereiding hebben ten behoeve van de HL7v3 naar FHIR mappings. Deze staat nog in de develop branch van de mappings (https://github.com/Nictiz/HL7-mappings/tree/develop/ada_2_fhir/fhir)

      2. Systemen die FHIR resources consumeren, mogen de Resource.text gebruiken voor weergave. Aangezien deze ook status “empty” of “additional” kan hebben kun je als systeem daar niet van afhankelijk van zijn. We besteden daar bij kwalificatie in groeiende mate aandacht aan. Er geldt nu een regime waarin “alle informatie in de addenda getoond moet kunnen worden”.

      — Aanbeveling: maak jezelf niet afhankelijk van Resource.text, tenzij wellicht om een snel dingen te tonen om er een indruk van te krijgen zonder de directe ambitie deze weg te schrijven in je systeem. Je zou met alleen Resource.text bijvoorbeeld geen grafieken kunnen plotten, geen informatie aan elkaar kunnen verbinden, slecht overzichten over meerdere metingen kunnen creëren etc.
      Show
      DomainResource.text. We zeggen daar in MedMij niets speciaals over. Dan geldt de FHIR standaard zelf. Deze zegt daarover ( https://hl7.org/fhir/STU3/domainresource-definitions.html#DomainResource.text): “A human-readable narrative that contains a summary of the resource, and may be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety. Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative." Dus samengevat: 1. Systemen die FHIR resources opleveren zouden Resource.text moeten (SHOULD: niet SHALL) hebben op een niveau die de menselijke lezer een redelijk beeld geeft van de informatie. Uitzondering is Resource.contained.Resource. Deze mag geen text bevatten. Het is mij niet geheel duidelijk in de FHIR standaard hoe je “summary of the resource” rijmt op de Narrative.status codes “empty” en “additional” ( https://hl7.org/fhir/STU3/valueset-narrative-status.html ). Beide zijn namelijk voorbeelden waarin de text geen samenvatting is. — Aanbeveling: zorg voor Resource.text van type extensions of generated. Extensions heeft voorkeur omdat dan de verwachting is dat zib-specifieke extensies ook worden meegenomen. In bijvoorbeeld HAPI zit ook een NarrativeGenerator. Ik weet niet wat deze kan (bijvoorbeeld Nederlandse labels genereren). Alternatief is mogelijk de NarrativeGenerator die wij in XSL (2.0) in voorbereiding hebben ten behoeve van de HL7v3 naar FHIR mappings. Deze staat nog in de develop branch van de mappings ( https://github.com/Nictiz/HL7-mappings/tree/develop/ada_2_fhir/fhir ) 2. Systemen die FHIR resources consumeren, mogen de Resource.text gebruiken voor weergave. Aangezien deze ook status “empty” of “additional” kan hebben kun je als systeem daar niet van afhankelijk van zijn. We besteden daar bij kwalificatie in groeiende mate aandacht aan. Er geldt nu een regime waarin “alle informatie in de addenda getoond moet kunnen worden”. — Aanbeveling: maak jezelf niet afhankelijk van Resource.text, tenzij wellicht om een snel dingen te tonen om er een indruk van te krijgen zonder de directe ambitie deze weg te schrijven in je systeem. Je zou met alleen Resource.text bijvoorbeeld geen grafieken kunnen plotten, geen informatie aan elkaar kunnen verbinden, slecht overzichten over meerdere metingen kunnen creëren etc.

      Description

      Wij zijn een DVZA. Tot op heden vullen wij in de resources niet de text component, waarin in html min of meer dezelfde waarden zouden moeten staan als in de rest van de resource. Dit omdat we in het verleden begrepen hadden dat dit niet verplicht zou zijn. Bepaalde partijen die bij ons  gegevens opvragen gebruiken nu juist wel deze text component binnen de composition. 

      Wat zijn de verwachtingen aan DomainResource.text?

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              henket Alexander Henket
              Reporter:
              henket Alexander Henket
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Estimations By Role

                  No roles have been estimated yet.