Stream: committers
Topic: perceived inconsistencies
Jose Costa Teixeira (May 05 2019 at 09:50):
https://wolandscat.net/2019/05/05/a-fhir-experience-consistently-inconsistent/#more-1520
Grahame Grieve (May 05 2019 at 09:51):
it's an interesting mix of valid and invalid criticisms
Jose Costa Teixeira (May 05 2019 at 09:59):
we have been looking at trying to harmonise some of it. e.g. "Product" discussions, wondering if devices, meds should be specialisations...
and in terms of workflow where "giving / given something to a patient" is still a rather different set of resources dependng if it's a medication or a device or nutrition..
and things still in progress like one "MedicationDefinition" for catalogs.
Jose Costa Teixeira (May 05 2019 at 10:00):
I would not want to model for modeling sake.
Jose Costa Teixeira (May 05 2019 at 10:01):
however it is interesting to have this feedback and see if we should do content- or process-wise
Jose Costa Teixeira (May 05 2019 at 10:02):
*and see if we should do something content- or process-wise
Rob Hausam (May 05 2019 at 10:04):
Yes. Agree with Grahame's assessment. I expect that some of the inconsistencies may be possible (and useful) to address in R5.
Jose Costa Teixeira (May 05 2019 at 10:06):
impact of this is not only on HL7's agility and consistency, but I am interested in consistency helping implementers plan their roadmaps better, if they can grasp a full picture.
Jose Costa Teixeira (May 05 2019 at 10:08):
I am not worried because some of these have reasons to be as they are, and the resources are not normative. but it is interesting to see we are being looked at in this aspect.
Is "consistency" relevant for FMM?
Grahame Grieve (May 05 2019 at 10:16):
to some degree, yes.
Grahame Grieve (May 05 2019 at 10:16):
I can't even find one of the things he's talking about - the administration.ingredient one
Grahame Grieve (May 05 2019 at 10:17):
but the heart of the matter is this:
The general problem with failing to rationalise similar / same data structures and behaviour across a model environment is that little or no software reuse is achieved – every item of data has its own separate piece of software, each with its own private semantics. Similarly, a similar lack of re-use of data or querying can occur: software has no way of knowing that, say, Ingredient and MedicationIngredient are fundamentally the same thing, and could be queried the same way
Grahame Grieve (May 05 2019 at 10:18):
in fact, 2 data elements in different places share some degree of common semantics - somewhere between 0 and 100%. How much has to be common before the benefits of reuse kick in?
Grahame Grieve (May 05 2019 at 10:19):
or I could summarise it as this:
shorter Tom Beale: elements that I don't understand are clearly the same thing
Grahame Grieve (May 05 2019 at 10:19):
but we certainly have a problem with element names that do or don't precoordinate the type into the name
Rob Hausam (May 05 2019 at 10:20):
Agree.
Grahame Grieve (May 05 2019 at 10:20):
ServiceRequest.instantiatesCanonical and ServiceRequest.instantiatesUri is a particularly problematic example
Rob Hausam (May 05 2019 at 10:20):
yes, for sure
Jose Costa Teixeira (May 05 2019 at 10:27):
in fact, 2 data elements in different places share some degree of common semantics - somewhere between 0 and 100%. How much has to be common before the benefits of reuse kick in?
or I could summarise it as this:
shorter Tom Beale: elements that I don't understand are clearly the same thing
that would be it, for me: we should not aim at 100% consistency for the sake of consistency. My experience would be something like - as long as the meaning is clear and I know whether other contexts share the same meaning or not, we are ok. So if I don't understand the difference, it's the same to me.
In my previous projects I had to avoid too many ontology discussions and focus on definin information models so that it works and data is reusable when it needs to be reused.
This way, semantic consistency is not a prerequisite, but a process, driven by need.
Jose Costa Teixeira (May 05 2019 at 10:32):
and this is why i mentioned the device-medication boundary as example of work we are doing. Device vs Med It's an arbitrary, fuzzy and moving boundary, but we now start to see the need to harmonise - e.g. for supply, or for catalogs, these should be handled in similar way, because a) implementers need only develop functionality once (recalls, traceability, deliveries) and b) what is today a device is tomorrow a med.
Lloyd McKenzie (May 05 2019 at 10:57):
ServiceRequest.instantiatesCanonical and instantiatesUri are that way because they repeat. If we made them polymorphic, we'd have to nest them inside something. (And that parttern should actually be being followed most places for 'instantiates'.)
Lloyd McKenzie (May 05 2019 at 10:58):
That said, there are a bunch of places where the names are inconsistent for no good reason. We do, however, hear screams of anguish when we 'fix' those problems as "renaming elements for no good reason".
Lloyd McKenzie (May 05 2019 at 11:00):
What's not clear is exactly how much software re-use we would ever reasonably get in 'simple' systems - those not trying to do decision support or other complex activities. Our objective is, and always has been, to keep things as simple as possible for the 'dumb' systems, recognizing that doing so increases complexity for more sophisticated systems - e.g. those doing decision support.
Grahame Grieve (May 05 2019 at 11:10):
We do, however, hear screams of anguish when we 'fix' those problems as "renaming elements for no good reason"
Wouldn't happen if we got them consistent in the first place.
Lloyd McKenzie (May 05 2019 at 11:27):
Consistent in the first place means being model-driven rather than requirements-driven - we already know how that plays out.
Grahame Grieve (May 05 2019 at 12:32):
doesn't mean we can't try harder. at least some of those are amenable to doing something about with out ending up in absolutist insanity
Lloyd McKenzie (May 05 2019 at 12:49):
Agree. Push patterns futher into the build/QA process?
David Pyke (May 05 2019 at 13:49):
And have a document that has a list of Best Practices Names for Elements so people aren't starting from scratch.
Grahame Grieve (May 05 2019 at 14:18):
well, we already have one of those ;-)
Jose Costa Teixeira (May 05 2019 at 14:33):
model-driven or model-aware? I don't think we need to first model the universe and then go down to detail, but we don't need an excuse for having similar things modeled differently. that happens too often without any help already. we could however ensure that as part of our process (e.g. FMM) we check consistency as a criteria.
Jose Costa Teixeira (May 05 2019 at 14:37):
requirements-driven may be perceived by some as "patching things as requirements appear" - which will dlead to breaking changes. I have several examples on FHIR but also IRL, where a system supported traceability for medical devices by having a serial number, but for medication, this was on the roadmap for 3 years later.
Jose Costa Teixeira (May 05 2019 at 14:40):
@Lloyd McKenzie patterns checking in the QA processes would help.
I think it would also help that when things are about harmonisation, the decision by the committee or FMG must consider the broader scope. To avoid that a committee says "we acklowledge the pattern but we don't consider this in our current scope and we have a deviation from the pattern" - which has happened and only causes debt.
Lloyd McKenzie (May 05 2019 at 14:52):
Scope is determined by the resource proposal. If the resource scope excludes the case, that's fine. If it includes it, it has to be dealt with - though it might still be outside the 80%.
Jose Costa Teixeira (May 05 2019 at 14:58):
problem is that as we advance, the scope suddenly increases more use cases, and things become part of the 80% and we are in the same situation - patchwork.
Jose Costa Teixeira (May 05 2019 at 15:02):
just to be clear, this is not a new problem. nor am I echoing the blog article's critic view.
I am happy with our evolutive model, but I see pitfalls and we should enforce the good practices so that the quality of the work is consistent.
Lloyd McKenzie (May 05 2019 at 15:13):
We do our best to establish scope based on anticipated future needs, though agree that's not always successful.
Jose Costa Teixeira (May 05 2019 at 18:09):
We do our best to establish scope based on anticipated future needs, though agree that's not always successful.
and i don't think we can significantly change that upfront without adding considerable burden. Progressive harmonisation is ok, and should be built in the process and QA mechanisms , especially to avoid reactions like you mention "for no good reason" or "because we are told to do it this way but we don't understand or agree".
nicola (RIO/SS) (May 09 2019 at 06:20):
Good post. And good challenge for FHIR community. I disagree OOP modeling is the only sollution. It worth to take a look at semantic web/rdf approach, which from my point of view much more elegant than oop and built with open world assumption! Most of inconsistency i see in post is on attribute level, so if in FHIR we will extract elements as first class resources and make them reusable we can solve most of claims in this post. Recomendation for WGs can be - lookup element between existing before create specialized one, cross harmonize shared elements. To do this first step we do not need a lot of formalism and tooling. But at some point in time we can use descriptive logic for consistency checks, which much more better defined than oop approaches.
nicola (RIO/SS) (May 09 2019 at 06:24):
https://arxiv.org/pdf/1201.4089.pdf
nicola (RIO/SS) (May 09 2019 at 06:35):
nicola (RIO/SS) (May 09 2019 at 06:38):
As well i envision with Element approach we will be closer to first-class extensions and backward/forward compatibility for FHIR - "publishing next version of the standard as a set of extensions"!
Grahame Grieve (May 09 2019 at 10:07):
the problem is that elements do not get defined outside a specific context
Last updated: Apr 12 2022 at 19:14 UTC
