FHIR Chat · Limitations of 'definition' for population/extraction · questionnaire

Stream: questionnaire

Topic: Limitations of 'definition' for population/extraction

Lloyd McKenzie (Feb 13 2020 at 23:13):

Gabriella Brown raised FHIR#25251 which asks whether we truly intend to limit item.definition references to element ids actually defined in the referenced profile or whether it's legitimate to reach 'deeper' into the structure than the snapshot actually exposes. (E.g. pointing to Patient.name.given in the base Patient resource profile). We've come up with 3 possible different answers, each having different pros and cons in terms of complexity, expressivity, etc. and who gets to feel the pain. We're seeking wider community feedback. @Grahame Grieve @Brian Postlethwaite please take a look at the comments on the issue and provide thoughts either here or there.

Grahame Grieve (Feb 13 2020 at 23:14):

looks like the wrong task to me

Lloyd McKenzie (Feb 13 2020 at 23:15):

Fixed. (Had copied the filter number rather than the issue number)

Grahame Grieve (Feb 13 2020 at 23:22):

some comments:

• it should definitely be id not path
• it's not useful to talk out of a profile into implied content - you are referring to an element definition, and the definition doesn't depend on the context through which you find it.
• not is it useful to alias the element. e.g [core]#HumanName.text isn't different to [us-core]#/Patient.name.text, and so shouldn't be given an alias

Given that, I think that (a) we should be clear that it's id. and (b) you should have to refer to the id directly.

Lloyd McKenzie (Feb 13 2020 at 23:26):

Meaning that if you want to refer specifically to Patient.name.given, you'd have to define a specific profile that exposed that - because pointing to HumanName.given doesn't have the same semantic.

Lloyd McKenzie (Feb 13 2020 at 23:26):

(context is different)

Gabriela Brown (Feb 14 2020 at 00:42):

Thanks for bringing this up for discussion! What do you mean by exposing Patient.name.given in a profile? Is it generally intended that a Profile should be created to be able to use a Questionnaire?

Generally, what is the way to create a questionnaire for an arbitrary structure definition? (https://www.hl7.org/fhir/operation-structuredefinition-questionnaire.html) Would you have to make a profile with elements iterating every possible path into the resource that goes through a complex type?

How would you write a Questionnaire that just has three questions: first name, last name, birthdate, that get extracted to Patient.name.given, Patient.name.family, and Patient.birthdate, with given and family on the same HumanName object in the Patient.name list?

I think the context of the element definition does matter for extraction. If you create a Questionnaire, ignore its tree structure, and get a response with two HumanName.given items and two HumanName.family items, where would you put them? All four on the same HumanName object in Patient.name? Each on its own HumanName object in Patient.name? (how would you even know that Patient.name is the right place, as opposed to a contained Patient resource?) I think the questionnaire should be able to express this in itself without needing to reference a profile (some sort of path context to an element in a resource, and some way to group nested elements onto particular containing elements).

Also it is my impression that population is based entirely on fhirpath initialExpression extensions, and the definitions are only used for extraction.

Grahame Grieve (Feb 14 2020 at 02:05):

if you want to refer specifically to Patient.name.given you'd have to define a specific profile that exposed that

Yes, pretty much, because referring to Patient.name.given as an inferred idea doesn't say what you mean

Grahame Grieve (Feb 14 2020 at 02:06):

Is it generally intended that a Profile should be created to be able to use a Questionnaire

No. you can always have a questionnaire without a profile. But is intended that you can delegate the semantics of the questions to re-useable element definitions in StructureDefinitions

Grahame Grieve (Feb 14 2020 at 02:07):

that get extracted to

Extracted is not the same is is-defined-by

Grahame Grieve (Feb 14 2020 at 02:08):

at least, i think that's the core question

Brian Postlethwaite (Feb 14 2020 at 02:43):

Isn't the issue here that we're referring to a potential id value that is in no snapshot, but that it could be.
Just as in the Patient.name.given example.
As the snapshot doesn't have to walk into every property of every element (otherwise types like identifier would explode)

Brian Postlethwaite (Feb 14 2020 at 02:44):

And from my understanding, the definition property was prefixed with the profile canonical URL to start from, then a # then the element ID that could be walked to in that profile (even if it walks into the datatype that isn't fully expanded in the snapshot)

Brian Postlethwaite (Feb 14 2020 at 02:45):

(At least that's how I've implemented it at present)

Grahame Grieve (Feb 14 2020 at 03:47):

but what's the point? it's not a meaningful definition

Miriam (Feb 14 2020 at 05:42):

The definition itself is not meaningful, but I guess it is the structure implied by the path (Patient.name.given) that is meaningful for extraction. Although, you can derive same meaning from the group hierarchy, which I think is what @Grahame Grieve is getting at? Ex:

  "item": [
    {
      "linkId": "name",
      "definition": "http://hl7.org/fhir/StructureDefinition/Person#Person.name",
      "type": "group",
      "repeats": true
      "item": [
        {
          "linkId": "name-given",
          "definition": "http://hl7.org/fhir/StructureDefinition/HumanName#HumanName.given",
          "type": "string",
          "repeats": true
        },
        {
          "linkId": "name-family",
          "definition": "http://hl7.org/fhir/StructureDefinition/HumanName#HumanName.family",
          "type": "string"
        }
      ]
    }
  ]

^this approach makes sense to me. It's the same example Gabriela provided on the thread https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Representing.20Complex.20DataTypes.20in.20defintion-based.20extraction/near/181574410 but I don't think there was a consensus there on how it should look.

Brian Postlethwaite (Feb 14 2020 at 05:49):

My example was very simple, but more likely will have a profiled name element in the profile, and then just walk the 1 step further into the family element.

Brian Postlethwaite (Feb 14 2020 at 05:52):

2 examples I did for a practitioner qualifications form....
https://sqlonfhir-r4.azurewebsites.net/fhir/Questionnaire/prac-demo
This second one includes definitions through extensions and slices (defined in a profile)
https://sqlonfhir-r4.azurewebsites.net/fhir/Questionnaire/prac-ext-demo
(referenced profile is here https://sqlonfhir-r4.azurewebsites.net/fhir/StructureDefinition/hcxdir-practitioner)

Miriam (Feb 14 2020 at 17:50):

Thanks for sharing the examples @Brian Postlethwaite. Looking at the Practitioner.name.text item I guess you would have two options for extractability: (1) use definition HumanName.text but nest it in a group with definition Practitioner.name, (2) profile Practitioner.name.text and use that as the definition.

I think it's worth clarifying the Extraction Guide on this point, because it is only sort of implied: in order to perform Extraction without profiling, the structure of the Questionnaire must match exactly the structure of the Resource(s) to extract. It makes sense, but because groups are described as meant to "organize content of the questionnaire into sections, sub-sections, etc." we're sort of stuck with visual groupings that match the FHIR resource shape exactly (e.g. I can't collect first name, last name, and birthDate in a single "section").

I don't have any other suggestion :slight_smile: just want to clarify my understanding on this point. Seems like Profile is really the way to go for anything more complex.

Last updated: Apr 12 2022 at 19:14 UTC