Stream: terminology
Topic: V3 vs. FHIR-defined codes
Rob Hausam (Apr 06 2017 at 19:39):
This topic came up again in OO today, and I think it would be good to get some further clarity (and probably documentation) on it. The question is, what are the rules and guidance (ideally already documented) about when and how to use V3 code systems and codes in FHIR? We have pages in the spec for the use of a number of different code systems, but there isn't a page for "Using V3 codes with FHIR" (and it's the same for V2). In the case of an otherwise fit-for-purpose V3 code system, the practical issue that arises (at least in my opinion) is that the V3 mnemonic identifiers are neither meaningless (as in Cimino's Desiderata) nor do they really fit very well with the FHIR criteria and conventions for using human-readable codes. Being uppercase short mnemonics they at best tend to be rather arcane and anachronistic, and at worst aren't really understandable at all.
My preference is to avoid using the V3 codes directly in FHIR-defined value sets. At one point I know it was discussed that we would create equivalent FHIR codes and map them to the V3 codes (assuming that the V3 code system and codes were otherwise appropriate). But opinions and practices seem to be rather variable. I actually don’t recall for sure if we ever made a decision on this in Vocab (or elsewhere), and if we did I don’t think that’s easy to find or is clear to at least many of us. So whatever our rule is (or will be) I think we need to make it clearer and reasonably easy to find in the FHIR spec.
We can discuss this here first and then create tracker(s) as needed.
Grahame Grieve (Apr 06 2017 at 21:37):
current policy is that for value sets bound to code with strength = required, the codes should be readable. Where v2 codes or v3 codes are desired, you should create FHIR specific equivalents and map to them.
For other value sets, using Coding or CodeableConcept, where the binding strength is not required, there should not be FHIR specific codes defined (though we have a few extensible ones where important concepts aren't in the alternatives). For these, v2 and v3 codes are used directly
Grahame Grieve (Apr 06 2017 at 21:41):
I think that Cimino's desiderata is wrong/too coarse in regard to this point actually. if you want a readable code, the mnemonic should capture the definition sufficiently, and then it is reasonable to use it. You should not reflect the structure of the code in the mnemonic - that's wrong. And for a few - large - code systems, there is no way to define ot test 'sufficiently' - and then you need non-human-readable codes. Perhaps that's what Jim intended, but his rules have created much needless argument for smaller code sets, and have resulted in the v3 outcome, where we achieved neither human-readability nor robustness ;-(
Rob Hausam (Apr 07 2017 at 04:33):
I agree with you on the effect of the Desiderata and the V3 outcome. I'm not quite sure about the "current policy", though - and if we've documented that policy adequately. If we wanted to leverage a particular capability in V3, then I think I would agree completely - but that might seem to be too much work. The V3 capability is the possibility of having multiple identifiers (codes) for a single V3 concept - so with that it would at least theoretically be possible to have both the standard V3 mnemonic and also a "FHIR-friendly" human readable code for concepts that are defined in a V3 code system and referenced in a FHIR value set. To do it would require going through Harmonization (either the current process or the upcoming new one based on UTG), so that might not be especially attractive. It also would tend to clutter the display in RoseTree and the V3 publication, but I don't know how much of an issue that would actually be.
The prior discussion that initiated this was in: https://chat.fhir.org/#narrow/stream/implementers/subject/FHIR.20DSTU2.20to.20STU3.20converter
and GF#13169. If we could add the FHIR-friendly codes for RESP = 'responsible-party', AUT = ‘author', and VRF = ‘verifier', then I think that would be quite nice.
Grahame Grieve (Apr 08 2017 at 21:41):
I didn't suggest adding readable codes for V3 concepts because I thought that would be unpalatable. But we could do that, and then bind to the readable codes in FHIR. Might create an interesting debate in remaining v3 spaces....
Grahame Grieve (Apr 08 2017 at 21:42):
guess this will be a subject fore vocab session about fhir tooling plans in madrid
Rob Hausam (Apr 10 2017 at 02:45):
I don't know if it will be palatable or not, but I think it could be and it's worth discussing. It may be helpful in moving toward the single HL7 terminology across all product families. The vocab tooling session seems likely to be a good place for discussing. We could initially float the idea on one of the upcoming two Vocab calls prior to Madrid (this week or in 3 weeks), if that seems to make sense.
Grahame Grieve (Apr 10 2017 at 22:37):
well, I'll be on this call - so we can at least raise the idea to get people thinking about it
Rob Hausam (Apr 11 2017 at 12:59):
sounds good - I'll see if we can add it to the agenda for this week
Eric Haas (Apr 20 2017 at 18:12):
Any resolution on this?
Rob Hausam (Apr 20 2017 at 20:22):
We began discussing it on the Vocab call last week. The general sense seemed to be somewhat favorable toward the idea, but the group felt that we need further discussion and input particulary from the terminology services implementers - and from Ted Klein since he is in China and wasn't able to be on the call. We have it on the agenda for the Tues. Q3 (joint Vocab/FHIR I) quarter in Madrid. We'll try to make remote access available if folks are interested in that and can't be there in person. The time is 8:45 AM Eastern in the US, so that should be relatively feasible (except possibly for the west coast!).
Last updated: Apr 12 2022 at 19:14 UTC
