Stream: conformance
Topic: terminology stream
Grahame Grieve (Jul 10 2016 at 20:57):
I have created a new terminology stream for discussions about CodeSystem, ValueSet, ConceptMap, and the terminology service
Grahame Grieve (Jul 10 2016 at 20:58):
this stream remains for discussions about the other terminology resources and conformance testing
Alexander Henket (Jul 14 2016 at 11:26):
This is probably relevant here:
GF#10345: Change ALL Required ValueSet bindings in ALL non-conformance and non-infrastructural resources to Extensible
Michel Rutten (Jul 14 2016 at 11:33):
GF#10345 seems a great suggestion. I often get questions about this during my HL7 profiling tutorials. Seems peculiar that most resource elements are defined as optional by default, while many bindings are defined as Required by default.
Grahame Grieve (Jul 14 2016 at 11:42):
I would never support that. Not at all
Alexander Henket (Jul 14 2016 at 11:42):
Not even if 80% of the use cases would say otherwise? :-)
Grahame Grieve (Jul 14 2016 at 11:43):
not globally, not generally, never
Grahame Grieve (Jul 14 2016 at 11:43):
and not for status no
Alexander Henket (Jul 14 2016 at 11:43):
The current situation basically says to our analists that FHIR decided that their analysis is wrong
Grahame Grieve (Jul 14 2016 at 11:44):
then we need to talk about it
Grahame Grieve (Jul 14 2016 at 11:44):
your analysts should remember DSTU
Alexander Henket (Jul 14 2016 at 11:45):
Yes we should. We started by filing our problems on a per binding basis, but it is just too much to ask in the timeframe we have.
Our analysts do not live under a FHIR regime I'm afraid. They have their own dynamics.
Alexander Henket (Jul 14 2016 at 11:46):
By the time they hand work to us for profiling, that's when we are faced with the rigidity of those bindings
Grahame Grieve (Jul 14 2016 at 11:46):
sounds like you have a process problem.
Grahame Grieve (Jul 14 2016 at 11:47):
there would be 2 things - you want a finer granularity - there is a right status, but you want more status codes
Grahame Grieve (Jul 14 2016 at 11:47):
that's an extension
Alexander Henket (Jul 14 2016 at 11:47):
Only from the perspective of FHIR. We have a very regular process
Grahame Grieve (Jul 14 2016 at 11:47):
of there's no status code - that's a dsicussion with the committee
Alexander Henket (Jul 14 2016 at 11:47):
It is not just status. It just one of the multiple examples we found.
Grahame Grieve (Jul 14 2016 at 11:48):
you can't have a process that is independent of the community, and then say, the way to sovle this is to impose extensibility on everything everywhere on everyone in the community
Grahame Grieve (Jul 14 2016 at 11:48):
no, not going to happen
Alexander Henket (Jul 14 2016 at 11:51):
OK then we have a deadlock. We cannot use FHIR as-is in these cases. So either we ignore the bindings and go with our own valuesets regardless or we need special instructions for implementers along the lines of "ignore these these and these elements and read extensions instead"
Grahame Grieve (Jul 14 2016 at 11:52):
perhaps you could illustrate with an example
Alexander Henket (Jul 14 2016 at 11:52):
Sure. Observation.status has a value Corrected according to our analysts. V2 agrees with us. FHIR does not
Alexander Henket (Jul 14 2016 at 11:53):
Allergy.reaction.certainty has values Low/Medium/High/Fatal according to our analysts and according to FHIR Low/High/Unable to determine
Grahame Grieve (Jul 14 2016 at 11:54):
amended = corrected
Grahame Grieve (Jul 14 2016 at 11:54):
Allergy reacton.certainy - a very long argument. you can use the 3 codes, and add your own additional extension with your 4 codes as well
Alexander Henket (Jul 14 2016 at 11:54):
Amended maps to our Appended already. Cannot be both
Grahame Grieve (Jul 14 2016 at 11:55):
what's the difference?
Alexander Henket (Jul 14 2016 at 11:55):
AllergyIntolerance.status: FHIR Required VS binding: active / unconfirmed / confirmed / inactive / resolved / refuted / entered-in-error. Our analysts insist on: active/completed/obsolete/nullified
Grahame Grieve (Jul 14 2016 at 11:55):
stupid v3 codes. I don't think that you're going to have any luck with them till they give you good definitions
Alexander Henket (Jul 14 2016 at 11:55):
Corrected says I changed what I previously sent. Appended says I added info but left existing as-is
Grahame Grieve (Jul 14 2016 at 11:56):
in an *observation*?
Grahame Grieve (Jul 14 2016 at 11:56):
both are amended.
Grahame Grieve (Jul 14 2016 at 11:56):
if you want to differentiate between the two - if you really think that makes sense - you can have an extension
Alexander Henket (Jul 14 2016 at 11:57):
Yes in an observation. You could probably argue that they logically come down to the same thing in Observation, but in DiagnosticReport they made a distinction so I guess the modelling was not consistent there then
Grahame Grieve (Jul 14 2016 at 11:57):
no they are different beasts
Alexander Henket (Jul 14 2016 at 11:58):
How so?
Grahame Grieve (Jul 14 2016 at 11:59):
I'm used to differentiating between amended and corrected with diagnostic reports. I've implemented the editing restrictions.
Grahame Grieve (Jul 14 2016 at 11:59):
but I don't know what that would mean for an observation.
Alexander Henket (Jul 14 2016 at 11:59):
Suppose I send Length 1.92m without interpretation. Correction means I update 1.92m to e.g. 1.90m. Amending would mean that I add an interpretation code
Grahame Grieve (Jul 14 2016 at 12:00):
really? I've never heard of that
Grahame Grieve (Jul 14 2016 at 12:01):
but, well, this is something I've seen elsewhere - experienced doing v2 and CDA work - you have analysts that sit in their own circle, decide how things are for themselves, freeze their requriements, and then look all shocked when they're out of step with the rest of the world.
Alexander Henket (Jul 14 2016 at 12:01):
Actually in my day to day speak I would use the term Appending instead of Amending. Amending makes me think of politics
Grahame Grieve (Jul 14 2016 at 12:01):
we'll be sympathetid to the problems that causes, but we won't simply give up.
Alexander Henket (Jul 14 2016 at 12:02):
I don't hand down any disjunct between what they think and what I can do in FHIR. Just the things where I feel FHIR is being too rigid or limited. In other cases I push back. So it is not as simple as you put it
Grahame Grieve (Jul 14 2016 at 12:05):
we can always talk about the places where you think we don't have the codes you need. And it might be that the allergyintolerance one shouldn't be a required binding. I agree it's not simple. But neither is it as simple s 'no required bindings anywhere'
Alexander Henket (Jul 14 2016 at 12:05):
If a valid use case comes along where FHIR doesn't let me, I file a tracker item. But here the problem is that by design the FHIR Resources give me Required bindings in certain places. That means that I can only go through committee level agreeing before I can move on. I can shall and will do that, but the time and effort involved with that process may or may not fly well with day-to-day deadlines on the project I'm payed to do.
What we ask is to lower the bar to make our use cases possible. Obviously we still need that sit down.
Grahame Grieve (Jul 14 2016 at 12:07):
well, I could well believe that committees are being too restrictive without necessarily counting the cost of that for implementers. Perhaps I've been guilty of that myself - this is DSTU, so lets try and see if it's a problem..
Alexander Henket (Jul 14 2016 at 12:08):
I just posed this thing as a problem. To give you an idea: beginning of September we need to have implementable stuff as first draft ready.
Grahame Grieve (Jul 14 2016 at 12:08):
I know we said 'fast', but that's.... faster
Alexander Henket (Jul 14 2016 at 12:09):
I cannot currently create a profile that conforms to both the analysts and FHIR. It currently is either/or
Alexander Henket (Jul 14 2016 at 12:09):
You know Nictiz had a long run to get here but hey: here we are :-)
Grahame Grieve (Jul 14 2016 at 12:09):
you haven't nominated cases where you can't - just where it isn't 'nice'
Grahame Grieve (Jul 14 2016 at 12:11):
but it's good you're here. even if maybe I don't since like it right now
Alexander Henket (Jul 14 2016 at 12:11):
? Observation.status, Allergy.reaction.certainty, AllergyIntolerance.criticality, AllergyIntolerance.status all qualify as troublemakers to us.
Alexander Henket (Jul 14 2016 at 12:11):
And we have 4/5 more profiles to go
Alexander Henket (Jul 14 2016 at 12:12):
I'm glad you appreciate our presence :-) :-)
Chris Grenz (Jul 14 2016 at 18:38):
What's the stance on using additional codings when the granularity of a code isn't sufficient? In other words, use the FHIR defined coding and add a second, userSelected, more granular code from another system?
Chris Grenz (Jul 14 2016 at 18:38):
Seems to me that if the meaning is wider/narrower this is OK - it's only the disjoint that would require an extension. Or is that not good practice?
Eric Haas (Jul 14 2016 at 18:49):
If you mean translations for codings and codeableconcepts- that is appropriate. It would be nice to have a ConceptMap too. For example Observation.code = LOINC for 'height' with a translation local code = 'height while hanging by ankles'.
Chris Grenz (Jul 14 2016 at 19:30):
So is using a more granular local code and translating to the (less granular) standard code in an alternate coding expected?
Grahame Grieve (Jul 14 2016 at 19:54):
we expect that if you have a more granular code, that you'll use the more granular code in an extension. There's an example somewhere. hang on...
Grahame Grieve (Jul 14 2016 at 19:58):
http://hl7-fhir.github.io/message-request-link.xml.html - gender on the second patient
Chris Grenz (Jul 14 2016 at 20:00):
Makes sense for code or Coding. For CodeableConcept could these be alternate codings?
Chris Grenz (Jul 14 2016 at 20:01):
Or maybe that's all you're talking about...sorry if I missed that!
Grahame Grieve (Jul 14 2016 at 20:01):
yes it would be
Alexander Henket (Jul 18 2016 at 12:31):
Your question is mine. When the datatype is code and the binding is Required, you cannot but choose from the given set. If your use case mismatches with that given set you are now stuck. You can:
1. File a change request on the valueset
2. Add an isModifier extension with the code you really wanted
3. Go for foul play and just override the valueset with your own
Note that the code datatype does not have a system so it is as vulnerable as ID and IS in HL7 version 2 for overlapping codes from other parties with foul play.
We think that filing a change request is the preferred way, but also time consuming which may or not fly well with the project timeline. We also think that adding an isModifier extension puts a much bigger strain on patient safety and implementers than converting the datatype to Coding and the binding to extensible.
Grahame Grieve (Jul 18 2016 at 12:55):
the correct course of action depends on whether the code you wanted is for a finer grained status or for a status that doesn't exist.
Grahame Grieve (Jul 18 2016 at 12:55):
if you can populate the correct status, then you don't need a modifier extension, you can use a normal extension
Grahame Grieve (Jul 18 2016 at 12:56):
the idea of using code is that it makes sense to haev an enumerated set of values
Lloyd McKenzie (Jul 18 2016 at 15:52):
Where we have "code" it's because we believe it's reasonable to have a base degree of interoperability across all systems. Further nuance, if needed, can be conveyed by extensions. However, it is important that if we use "code" as the data type that the bound value set does provide complete coverage for all possible use-cases - even if only at a large-grained level. (And that we expect pretty much all systems to be able to map to that granularity.)
Alexander Henket (Jul 18 2016 at 19:36):
Gotcha. In addition to tracker item we filed for changing all code/Required to Coding/Extensible we have also filed tracker items for the individual ValueSets that fail to meet that complete coverage criterium according to what our analysts deemed necessary and what we feel are reasonable use cases. Either way we will get where we need to be.
Grahame Grieve (Jul 18 2016 at 21:02):
note that you need to take the terminology stuff seriously. You can't simply propose new codes without dealing with terminology qa rules, and providing good solid definitions that the committee can use.
Grahame Grieve (Jul 18 2016 at 21:03):
proposing 'add medium' to AllergyIntolerance.criticality doesn't give the committee anything to work from, and they'll almost inevitably have to fail the proposal because they can't come up with a definition that is obviously different
Grahame Grieve (Jul 18 2016 at 21:03):
that'll be a problem for you, from listening to the clinicians argue about what they think each other means on this subject
Alexander Henket (Jul 19 2016 at 08:28):
We have filed that exact question with them too. We do take our stuff seriously. You might be right that we should have filed that tracker item after they came back to us with answers.
Grahame Grieve (Jul 19 2016 at 10:36):
so they have come back with answers?
Alexander Henket (Jul 19 2016 at 16:07):
I'm afraid your track record in response times is much better than theirs. Bear/bare(?) in mind that the logical definitions were finished last year too so parts of the responsible groups have gone on to other things or on holiday this part of the year. :-) But rest assured I'm rattling cages.
Last updated: Apr 12 2022 at 19:14 UTC
