Stream: implementers
Topic: Why the type of the component field under Observation is Bac
Seref Arikan (Apr 28 2016 at 19:45):
Greetings,
I am currently implementing some FHIR based functionality and I realized I don't understand why the type of a component under observation resource is BackboneElement.
According to documentation of BackboneElement, the component of observation has a type (Observation.Component) which is a specialisation of BackboneElement ( https://www.hl7.org/fhir/backboneelement.html )
Why is not this type used as the type of component for the Observation resource instead of the current BackboneElement type defined in the documentation? ( https://www.hl7.org/fhir/observation.html )
All the best
Seref
ps: I tried to send this question to mail lists but for some reason failed (or so I think) apologies if this ends up as a cross-post.
Lloyd McKenzie (Apr 28 2016 at 20:45):
The documentation shows the information that's not already conveyed elsewhere. The type definition of Observation.Component is already visible. What you need to know as a reader is that Observation.Component is a subtype of BackboneElement - so that's what the documentation exposes.
Seref Arikan (Apr 29 2016 at 08:09):
Hi Llyod,
Thanks for the response. My feedback as a reader is that I'd expect to see the actual type of component in the documentation. I just checked and saw that the UML representation indeed shows that component has the type of Component. If the type definition of component is visible, than at least for me it has low visibility. I figured this out by clicking on BackboneElement and reading that page.
Another feedback from an implementation point of view is that someone with an OO view assumes that there is a reason for a base type to be used so I tried to figure out what kind of functionality BackboneElement would be providing. I was acting based on a misunderstanding of course, but jst to let you know, the way the documentation presents the component field has led to the process above and thus, this question. Whether or not that serves the purpose, that is up to maintainers of course, but at least for one developer, it is a bit misleading.
Grahame Grieve (Apr 29 2016 at 08:22):
I guess the confusion here is that in the logical table, there's no differentiation between 'is-type-of' and 'is-anonymous-specialization-of'. The confusion is thinking that the logical table is a OO statement - the UML doesn't act like this.
Seref Arikan (Apr 29 2016 at 08:24):
Hi Grahame,
Exactly as you've put it: I assumed that the logical table is an OO statement.
Grahame Grieve (Apr 29 2016 at 08:26):
I added this to the documentation of teh format table:
Note that the type of the element has one of two meanings, depending on whether the element has defined children. If the element has children, then the element has an anonymous type that specializes the given type. If the element has no children, then the element has properties and children as specified by the nominated type
Grahame Grieve (Apr 29 2016 at 08:27):
of course no one reads that documentation anyway
Grahame Grieve (Apr 29 2016 at 08:27):
but there's more than this going on. Technically, the logical table is as a heirarchy of 11179(like) element definitions. It can be converted into an OO definition, but that's definitely a conversion. (and we don't document explicitly how that works - it's an open task for me to document exactly how typing and element definitions work)
Seref Arikan (Apr 29 2016 at 14:37):
Thank you. I do like reading docs, so I'd appreciate if you could point at the document you're talking about.
Interesting point re logical table to OO conversion. Could I safely assume the Fhir UML is always a valid starting point for OO representation? If not, what would be a good method for a developer with OO tools at hand to map specifications to actual computable artefacts?
Grahame Grieve (Apr 29 2016 at 15:36):
UML is technically correct OO, but is too brief, so you can't use it alone
Grahame Grieve (Apr 29 2016 at 15:42):
there's no quick recipe for a proper method to represent FHIR in OO. The major OO reference implementations all make slightly different decisions about how to best make this work, depending on the balance of features in the OO language
Last updated: Apr 12 2022 at 19:14 UTC
