Stream: terminology
Topic: Concept Domain - Value Set Relationship
Clayton Daley (Jun 05 2020 at 20:44):
The documentation for v3 talks about Concept Domains as a placeholder that is made concrete using a Value Set. Is this relationship always 1:1 or can it be 1:many?
For context, we're upgrading some code that does v2 to v3 code translations. I'm trying to get it "right" on this pass to minimize the rework in the future.
- As the source of a mapping, there's no need to go beyond a Code System. This uniquely identifies a concept for the purposes of translation and it's my understanding that the meaning should be unchanged regardless of the Value Set. Thus concept X from code system Y will always translate into the same code in VS Z regadless of the context.
- The target needs to be at least a Value Set (to constraint available values), but several v3 fields are defined as being populated by a Concept Domain. If a Concept Domain is 1:1 with a Value SEt, it's not terribly important to an implementer. If a Concept Domain can be composed of many Value Sets, what does that actually mean? Is there an implicit guarantee that the Value Sets are non-overlapping? Or does a well designed, general purpose mapping system need the infrastructure to target any/all of the Value Sets within that Concept Domain?
Jean Duteau (Jun 05 2020 at 20:50):
It is 1:many. If a v3 element is bound to a Concept Domain, that means that the exact value set will be defined in a further Implementation Guide. NOTE: It's not that one Concept Domain will be composed of multiple value sets. For any given concrete implementation, it will be one value set.
Lloyd McKenzie (Jun 05 2020 at 21:24):
The typical pattern is that different value sets are selected in different countries.
Clayton Daley (Jun 06 2020 at 02:33):
What is a concrete implementation for the purposes of Jean's answer? Do you just mean a single exchange between two parties? Such that Lloyd's comment about countries is just a comment about countries tending towards the same conventions? Or does concrete implementation mean something more general/official and some country-level body is making a normative decision?
Lloyd McKenzie (Jun 06 2020 at 03:04):
In version 3, a binding (link between concept domain and value set) is established by in the context of a particular realm (typically a country). That binding essentially says "any models that use the is concept domain that are used in this country will use this value set". At least, that was the methodology.
In practice, few countries implemented v3 at all, and those that did typically declared value sets explicitly in their models rather than relying on general bindings to concept domains across models.
Question: where are you planning to make use of v3?
Clayton Daley (Jun 06 2020 at 19:55):
We built a product in ~2014 and "future proofed it" by designing it around HL7v3. It gave us a really clean, developer-friendly data structure and pushed the conformance issues for all of the v2 versions into its own box. We also assumed (incorrectly as it were) that we'd drop the (proprietary) v2-v3 converter at some point in the future and accept raw v3. In the meantime, we've gone to an effectively RIM-based architecture (which is really easy if your input is in v3).
For obvious reasons, I wouldn't start with v3 today but I'm not sure what I'd do instead. We need to preserve something like v2 message events since our real time workflow processor is (and must stay) event-based. I like the state machines in v3 so much I actually retooled our workflow engine around them. Every time I've looked, FHIR hasn't offered anything more than a normative event messaging framework (i.e. no normative events like v3).
Lloyd McKenzie (Jun 07 2020 at 14:55):
FHIR doesn't have standard event codes for a couple of reasons:
- a lot of the v2 events got subsumed by REST. No need to have a message for "update patient demographics" when you can do a simple RESTful POST
- there seems to be little appetite in the community for standardizing messaging outside of small closed communities
That said, you're already in what's essentially a proprietary v3 messaging environment, so moving to a proprietary FHIR messaging environment wouldn't be significantly different. And you might find that, at least for some events, either REST or subscriptions were viable for your real-time workflow processor. Moving to FHIR would at least give you a standard external data model as well as extensions. (With v3, the schemas are different in every country that rolled it out and extensibility is 'hard'.)
Don't feel bad about having driven your implementation solution around v3. The RIM is a very powerful and very useful data model. I still think in RIM terms when evaluating a lot of FHIR design decisions because that's helpful in understanding what's really going on. We just found that v3 didn't give us what we were hoping for in terms of standardization and broad implementability.
In terms of concept domains, if you're not working as part of a national v3 environment, then you can essentially treat your concept domains as being bound to any value set you like - or if you're expecting data from a wide variety of sources with no standards enforced, you could treat them as completely unbound. (i.e. any code from any code system is potentially legitimate.)
Clayton Daley (Jun 07 2020 at 20:36):
We use RESTful interfaces throughout our product -- even for the interface that accepts v3 messages. We've pushed for better RFC compliance in the framework we use and are actually using HATEOAS for virtually everything.
But RESTful actions are very low level -- like a messaging protocol. PUT is not equivalent to the "change/update" messages in v3. PUT is like accepting one of the many v3 message types. You must still post-process the submitted data to check for actionable data model changes. In v3, the message types actually assert the relevant changes. This is a fundamental issue with REST and not anything unique to FHIR.
What guidance does FHIR provide when it comes to post-processing? The FHIR encounter-status certainly appears to have a more direct mapping to v2. But the FHIR state machine for Events (at least as of 4.0.1 R4) feels incomplete. It lacks the path labels typical of FSMs, the explicit (but common) "revise" transition found in the v3 state machine for Acts, and more minor details like the "abort" and "complete" transition from a suspended activity. "Not Done" i.e. the v3 "Cancelled" was added somewhere between 3.0.2 and 4.0.1. It just feels like FHIR is taking the long way around on its way back to what you already learned in v3.
The key place where FHIR dominates v3 is the data model. Since it's basically implementation-first, everything starts REST- and database-friendly. Fortunately, we're not an EMR so we effectively (though not literally) carry around the raw XML. The joins it would take to traverse a properly normalized model (e.g. Patient-Participation-Encounter-Participation-Doctor-Name or Patient-Participation-Encounter-Participation-ServiceDeliveryLocation-Location-Building-Floor-Wing-Room) aren't practical so we (literally) do in-memory XPath (or indexed jsonb operations in the database). And we're not an EMR so there are very few cases where we need to make "deep" or "partial" modifications. You can figure out the complete list from the HL7v2 messages (e.g. A02 transfer, A54/A61 change attending/consulting) and we're normalized enough that these changes are clean.
I'm not saying that REST is the wrong place to be. When FHIR was a mote in Graham's eye, XML was on its way out and REST on its way in. Our product was designed in the same era based on the same (then-mature) REST technologies. As a healthcare outsider, however, RIM is the diamond of distilled and compressed expertise. v3 is the best way to understand it today. And graph databases (not to be confused with GraphQL) are the technology most ready to fully realize RIM.
Lloyd McKenzie (Jun 07 2020 at 20:56):
v3 introduced the same set of statuses everywhere - including a bunch that weren't actually used in practice. With FHIR, we try hard to only introduce those that we know systems actually use. We've also tried to drive greater consistency across statuses. With FHIR there are no defined transitions that you are bound to. Any PUT is a 'revise' - in which the status might change (and if it changes, might change from anything to anything). Tight control over what transitions are permitted, what elements are expected/permitted to change with them, and who's allowed to invoke them are all use-case-specific requirements that the core spec doesn't define. It's up to implementation guides to nail those down (because implementation guides are created in the context of a specific use case.)
In any case, glad that you have found and are making good use of HL7's diamond :)
Vassil Peytchev (Jun 08 2020 at 15:39):
In FHIR, you can take a look at the Task resource with Task.status, Task.statusReason, and Task.businessStatus - they practically enable unlimited FSM capabilities. In addition, the updated SubscriptionTopic and SubscriptionNotification may also be of interest regarding events...
Last updated: Apr 12 2022 at 19:14 UTC
