FHIR Chat · ValueSet Service · implementers

Stream: implementers

Topic: ValueSet Service

Tim Dunnington (Jun 20 2017 at 20:00):

Hey All! We're about to embark on creating a ValueSet service that will allow our FHIR consumers to expand value sets. We have many facilities, and each facility could potentially have a different set of values for a given concept. To represent this, we've added the facility identifier to the end of our System URLs, so for example https://fhir/System/Code/12345 would be the System for an arbitrary concept callled "Code" at our facility with id 12345.

I'm having a hard time figuring out what this means for ValueSet. Does this mean I have one ValueSet, and in it I import each facility's separate System, like this?

    <ValueSet xmlns="http://hl7.org/fhir">
        <url value="https://fhir/ValueSet/Code"/>
        <compose>
            <include>
                <system value="https://fhir/System/Code/12345"/>
            </include>
            <include>
                <system value="https://fhir/System/Code/23456"/>
            </include>
            ...
        </compose>
    </ValueSet>

Or do I have multiple ValueSets, one per facility, and then in that case, how do I tie multiple ValueSets to a single field?

I'm leaning towards the former, such that our ValueSet would import each facility's System, and then use the "filter" query parameter of the $expand action to expand the ValueSet for a given facility. So using the sample above, the codes for facility 12345 would be expanded like this:

    .../ValueSet/$expand?identifier=https://fhir/ValueSet/Code&filter=12345

Has anyone dealt with a similar issue?

Grahame Grieve (Jun 20 2017 at 21:23):

so firstly, is there an underlying single set of codes across all of them?

Grahame Grieve (Jun 20 2017 at 21:24):

I would want to see
- a single code system
- a value set for each of the facilities
- combination value sets for combinations of the facilities
- a single value set for the whole code system

Grahame Grieve (Jun 20 2017 at 21:25):

but if each of the facilities can define their own codes, and the codes aren't unique across them all, then you'll need instead:
- a code system for each facility (with distinct URLs)
- a value set for each facility
- combination value sets that include the facility specific value set

Tim Dunnington (Jun 20 2017 at 21:44):

Unfortunately we can't count on the codes being the same. The system allows for differences, and while some code sets have been standardized by our organization, other codesets are not and we need to prepare for it.

Good news is that I've already got code systems for each facility with a unique url, so good there, and I can create the ValueSets any way I need to as we're just now implementing this service.

Tim Dunnington (Jun 20 2017 at 21:44):

Thanks for your help!

Robert McClure (Jun 21 2017 at 16:55):

@Tim Dunnington While Graham is correct (IMHO ;-), you do have one complication in the approach you've chosen. You note that "some code sets have been standardized by our organization" which I assume means your system expects any use of said "organizationally defined" to have the same code for the shared idea, right? If so then the common organizational code system needs to identified and used with the same code system identifier in all places. Does that make sense? I would NOT suggest you try to make aech facility code system create the same "common" code in each facility-specific code system.

Yunwei Wang (Jun 23 2017 at 13:54):

@Tim Dunnington when you say "how do I tie multiple ValueSets to a single field", do you mean mapping codes from difference facilities? or put codes from different facilities into an organization code list?

Tim Dunnington (Jun 23 2017 at 18:22):

Hey @Robert McClure , you are correct, if I know for certain that a code set is standard, then we will define only one System for it. The most annoying problem we face, though, is that our EMRs allow users to change chodes and there is no way to prevent that, so while some codes are standardized, they can also be altered and so we cannot always count on them being identical at all facilities.

Because many/most of our codesets can change at each facility, we download the codesets to our data warehouse nightly. So when we implement our ValueSet service, it will actually be querying the database on-the-fly to find the current codeset for the facility. The EMR prevents the user from removing codes that have been used in the past, so we won't have the problem of a particular code just "disappearing" from under our nose.

The other services in our FHIR infrastructure are presenting data from these same EMRs, so the codesets will match up to the data presented by that facility's EMR. For example, our Encounter service serves up encounter data from the EMR. Any code sets used in that Encounter will match up to the codes in our warehouse for that facility.

Tim Dunnington (Jun 23 2017 at 18:28):

@Yunwei Wang , I meant the latter. Mapping codes will be handled with a ConceptMap service that we are planning to build, but is also dependent on how we handle the ValueSet service so we are tackling ValueSet first. I was simply remarking that in our case we have almost 200 distinct Systems in a single ValueSet, so any field that is using that ValueSet will accept any value from any of those systems. But, in practice the System must match up to the facility in question, so while the ValueSet says "hey, you can use any one of these 200 Systems" in fact you can only use one for your Encounter (or Patient or whatever), that being the System that matches your facility. I will be enforcing that business logic in the service itself, but from a Conformance document point of view I was at a loss as to how to handle it.

Last updated: Apr 12 2022 at 19:14 UTC