FHIR Chat · FHIRPath Types and Reflection

Stream: implementers

Topic: FHIRPath Types and Reflection

John Timm (Aug 28 2019 at 18:13):

@Bryn Rhodes In the FHIRPath specification, there is an example of ListInfoType:

Patient.address.type()

that produces:

{
  ListTypeInfo { elementType: 'FHIR.Address' }
}

But then in the next example:

Patient.contact.type()

which produces:

{
  TupleTypeInfo {
    element: {
      TupleTypeInfoElement { name: 'relationship', type: 'List<FHIR.CodeableConcept>', isOneBased: false },
      TupleTypeInfoElement { name: 'name', type: 'FHIR.HumanName', isOneBased: false },
      TupleTypeInfoElement { name: 'telecom', type: 'List<FHIR.ContactPoint>', isOneBased: false },
      TupleTypeInfoElement { name: 'address', type: 'FHIR.Address', isOneBased: false },
      TupleTypeInfoElement { name: 'gender', type: 'FHIR.code', isOneBased: false },
      TupleTypeInfoElement { name: 'organization', type: 'FHIR.Reference', isOneBased: false },
      TupleTypeInfoElement { name: 'period', type: 'FHIR.Period', isOneBased: false }
    }
  }
}

Since both Patient.address and Patient.contact are 0..* I'm wondering if either the first example should show the ClassInfo for FHIR.Address or if the second example should be ListTypeInfo. There seems to be a disagreement between the two examples of when ListInfoType is produced. IMO, ListInfoType isn't that useful. I'd rather get type info about the List element type.

Grahame Grieve (Aug 28 2019 at 19:35):

it's certainly not useful in FHIR, where we've deliberately restricted the use of list variants in the content model itself. Really all there is to know is whether it's a list or not. I think it might be more useful wen your doing FHIRPath with other content models that FHIR, where there is more metdata floating around

Bryn Rhodes (Sep 05 2019 at 07:48):

There is definitely an inconsistency in the example there, thank you for pointing that out @John Timm . Do you mind submitting a tracker to correct that? What we say in the spec is that the operation produces a collection with the type for each element of the input collection. So the Patient.contact.type() example is consistent with that, but the Patient.address.type() example is not.

John Timm (Sep 05 2019 at 13:31):

@Bryn Rhodes Tracker item submitted:
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23857&start=0

Bryn Rhodes (Sep 05 2019 at 15:42):

Thank you!

Last updated: Apr 12 2022 at 19:14 UTC

Main menu