Stream: implementers
Topic: codeSystem & valueSet (STU3)
Dave Barnet (Jun 08 2016 at 08:59):
Has anyone got a working example that I could have a look at where a valueSet selects codes and concepts from a codeSystem (probably defined on the same FHIR server). What I want is to add codeSystems with explicit concepts/codes defined to our STU3 Hapi server, then define a valueSet that selects codes from the codeSystems via the "filter" option.
Peter Jordan (Jun 08 2016 at 22:44):
@Dave Barnet. There are examples of the operations for the ValueSet and CodeSystem resources in the spec itself - including parameters and filters for specific Code Systems such as SNOMED CT, LOINC and UCUM. I've found just about everything that I've needed on there; and the Implementation-->Services-->Terminology Service page is particularly helpful with links to all the Code System specific information... http://hl7-fhir.github.io/terminology-service.html. A small caveat is that some of the CodeSystem material is a bit 'green' and the $lookup properties example on that page still needs to be corrected.
Yunwei Wang (Jun 08 2016 at 23:20):
Here is an example: http://hl7-fhir.github.io/valueset-example-intensional.xml.html
Dave Barnet (Jun 30 2016 at 13:56):
I'm trying to implement a set of codes using codeSystem & valueSet, where he codes are in a hierarchy. I noticed that in the definition of codeSystem, you appear to be able to nest concepts, so I set up a codeSystem with some nested concepts, along the lines of
<concept>
<code value="MA00"/>
<display value="Mainstream Housing"/>
<concept><code value="MA01"/><display value="Owner occupier"/></concept>
<concept><code value="MA02"/><display value="Settled mainstream housing with family/friends"/></concept>
</concept>
<concept>
<code value="HM00"/>
<display value="Homeless"/>
<concept><code value="HM01"/><display value="Rough sleeper"/></concept>
<concept><code value="HM02"/><display value="Squatting"/></concept>
</concept>
I then set up a valueSet to query (include) the codeSystem. However, when I expand the valueSet, the codes appear in a flat list, rather then in a nested list as I expected - they appeared like this
"contains": [
{
"system": "http://fhir.nhs.net/CodeSystem/AccommodationStatusCode",
"code": "MA00",
"display": "Mainstream Housing"
},
{
"system": "http://fhir.nhs.net/CodeSystem/AccommodationStatusCode",
"code": "MA01",
"display": "Owner occupier"
},
{
"system": "http://fhir.nhs.net/CodeSystem/AccommodationStatusCode",
"code": "MA02",
"display": "Settled mainstream housing with family/friends"
},
etc...
Anyone any idea what I'm doing wrong? I need to store and retrieve a list of codes that have a structure (hierarchy) within the codeSystem.
I've tested this on our (NHS) internal STU3 HAPI server, and on the public http://fhirtest.uhn.ca/ STU3 HAPI server, and get the same results (as above)
Grahame Grieve (Jun 30 2016 at 21:25):
what the spec says about this is:
Grahame Grieve (Jun 30 2016 at 21:26):
Note that the expansion structure is inherently ordered, and also provides support for a hierarchical tree of items. This specification does not fix the meaning of use of either of these, and the conceptual approach described should not be understood to prohibit any implementation approach in these regards.
Grahame Grieve (Jun 30 2016 at 21:26):
you[re not doing anything wrong, just that the servers do not generate heirarchical expansions.
Grahame Grieve (Jun 30 2016 at 21:26):
perhaps you could describe why this is important?
Chris Grenz (Jun 30 2016 at 21:27):
*may* not....
Chris Grenz (Jun 30 2016 at 21:27):
we do...
Grahame Grieve (Jun 30 2016 at 21:31):
ok, the particular servers referenced don't
Erich Schulz (Jun 30 2016 at 23:15):
is this related to my question about consistent concept representation
?
Grahame Grieve (Jun 30 2016 at 23:22):
don't know. what question is that?
Erich Schulz (Jun 30 2016 at 23:53):
Erich Schulz (Jun 30 2016 at 23:54):
ie "how to represent ideas like asthma and diabetes etc etc in a succinct, standard manner within the text of CQL logic?"
Grahame Grieve (Jun 30 2016 at 23:54):
no. I don't think it's releated
Erich Schulz (Jul 01 2016 at 00:00):
you sure? it seems related but I'm possibly confused
Grahame Grieve (Jul 01 2016 at 00:02):
distantly related - the question relates to terminology service API, which should underpin CQL terminology usage (but doesn't right now). But CQL fan bois are easily confused...
Erich Schulz (Jul 01 2016 at 00:04):
yes apparently - sorry I should have clicke 'more' on Dave's question
Dave Barnet (Jul 01 2016 at 08:42):
[Note that I've re-posted the original query to the hapi stream for a view from them, so don't get confused that there are 2 threads that look the same]
We are looking to create a value set server to support NHS applications (such as the NHS Data Dictionary). The NHS Data Dictionary contains definitions of data sets that care providers should fill out and return to the "centre" on a regular basis. The level of data captured by care providers varies, some may capture detailed information, others less detailed.
To cater for this (as one example), some of the codeSystem in the NHS Data Dictionary have a high level code, and lower level codes. You return the information at the level your operational system captures. In the example I gave above, the values come from an Accommodation Status data item used in a Young Persons Health Service data set. Some operational systems may capture the fact that a young person is Homeless, whereas other may be more detailed, and capture the fact that the young person sleeps rough. The NHS Data Dictionary codeSystem maintains the fact that sleeping rough is a sub-code of homelessness; so the codeSystem is represented as a hierarchically, generally in the format
High level code
lower level related to high level
lower level related to high level
High level code
lower level related to high level
lower level related to high level
It was my hope that nesting concepts in the codeSystem would maintain this hierarchy, and the high level/ lower level be apparent in the valueSet that includes the codeSystem when expanded.
If it is the intention of valueSets NOT to expand the hierarchy captured in a FHIR codeSystem, what's the point of being able to express a hierarchy in a codeSystem?
Grahame Grieve (Jul 01 2016 at 13:18):
heirarchy defines the meaning of the relationships between the terms.
Grahame Grieve (Jul 01 2016 at 13:18):
there are ways to use the relationships between the terms without having them be explicit in the value sets.
Grahame Grieve (Jul 01 2016 at 13:19):
and using a filter - value set - to consider the relationships between codes is inherently dangerous because concepts may be excluded, and therefore relationships are omitted
Grahame Grieve (Jul 01 2016 at 13:19):
most uses of expansions, there's no need for heirachy either.
Grahame Grieve (Jul 01 2016 at 13:20):
but since there are some, we define a heirarchical structure
Grahame Grieve (Jul 01 2016 at 13:20):
however the challenge of delivering structure correctly while filtering a DAG is considerable, so (a) we have no required this and (b) the open source servers don't do it.
Grahame Grieve (Jul 01 2016 at 13:21):
that doesn't mean you can't do it. or that you can't talk to the server maintainers (including me) about doing it
Erich Schulz (Jul 01 2016 at 13:37):
hierarchies are kinda important...
Erich Schulz (Jul 01 2016 at 13:37):
and not really that hard...
Erich Schulz (Jul 01 2016 at 13:38):
just needs an internal ancestor (aka transitive subsumption closure
) table - creating that is a 10 line operation
Michael Lawley (Jul 02 2016 at 04:22):
@Erich Schulz note that "hierarchy" != "is-a" or subsumption - it may just indicate a useful presentation structure for a pick list
Erich Schulz (Jul 02 2016 at 08:46):
not sure what you are getting at @Michael Lawley ... my understanding is that hierarchies (either tree or DAG) support both compositional meronies (part-of) and classification taxonomies (is-a) and in order to do clincial logic at scale then subsumption operations are important. From a software algorithm perspective for DAG operations, then regardless of the purity of the semantic links, an ancestor table is the simple solution... and is very simple to implement. Am I missing something?
Erich Schulz (Jul 02 2016 at 09:31):
or do you mean sometime we just need to grab immediate parents/children
Michael Lawley (Jul 02 2016 at 14:23):
hierarchy in a FHIR CodeSystem may be purely presentational and carry no semantics what so ever: "Defines children of a concept to produce a hierarchy of concepts. *The nature of the relationships is variable* (is-a/contains/categorizes) and can only be determined by examining the definitions of the concepts." You cannot assume that it necessarily conveys any informtion suitable for clinical logic, in the general case. Naturally some code systems do support this, that depends on teh code system, not the presence of hierarchy (perhaps better termed "nesting"?)
Erich Schulz (Jul 02 2016 at 23:20):
unless you are using a system that tries to use pure semantics
Erich Schulz (Jul 02 2016 at 23:22):
the point being that for clinical logic there is no choice but to rely on hierarchies specified in systems like SNOMED for clinical logic
Erich Schulz (Jul 02 2016 at 23:25):
undoubtedly there will be mortality and morbidity meetings and root-cause analyses where the problems in the ontology contributed to an adverse outcome but that is just another risk to be managed
Erich Schulz (Jul 02 2016 at 23:26):
I say that because I get a sense of this issue being ducked because of the risk
Erich Schulz (Jul 02 2016 at 23:26):
"we cant do that because its not safe"
Erich Schulz (Jul 02 2016 at 23:27):
at some point we're just going to have to suck it up and take a risk
Grahame Grieve (Jul 02 2016 at 23:28):
then you are welcome to implement a terminology server that behaves how you think it should be behave. It's not polite to lecture the professional terminology server developers about their choices - especially when you do not understand why they have made them
Erich Schulz (Jul 02 2016 at 23:32):
sorry not meaning to be impolite or lecture
Erich Schulz (Jul 02 2016 at 23:32):
I'm trying to understand what I'm missing and also seeking an answer about the standard method to do this kind of clinical logic
Erich Schulz (Jul 02 2016 at 23:33):
with particular reference tothis context
Grahame Grieve (Jul 03 2016 at 00:00):
if you are filtering and ordering, then it is unclear what a heirarchy means, either algorithmically, or to a consumer. The combination of filtering, ordering, and paging, means that most implementers have just taken it as a flat list, since the use cases for value set do not include reasoning. Code system views are for reasoning. hence we have meaning based queries on code system - lookup, subsumption, and infer.
Erich Schulz (Jul 03 2016 at 00:18):
sorry I'm so ignorant about all this - but to test my understanding of what you are saying: FHIR Codesystem resources support transitive subsumption operations, but not single step tree walk (children, parent(s)) operations?
Erich Schulz (Jul 03 2016 at 04:11):
I guess its worth noting that in both Dave's inititial request and in the clinical logic domain I'm interested in that the hierarchies are classication/is-a based
Erich Schulz (Jul 03 2016 at 04:16):
so even tho there be dragons around edge cases the solutions that are being sought are for bread and butter cases so seems like there ought to be a simple solution for each of our issues
Erich Schulz (Jul 03 2016 at 04:17):
sorry if sound like i'm attempting to teach gran to suck eggs, and if solution is right in front of me...
Grahame Grieve (Jul 03 2016 at 06:12):
I think you are largely confused about value set vs code system
Erich Schulz (Jul 03 2016 at 06:59):
ok it maybe better to come back to the requirements...
Erich Schulz (Jul 03 2016 at 07:09):
I'm going to attempt explain them in words that deliberately avoid terms that may have been given another meaning... I think @Dave Barnet is seeking to put ideas into a hierarchy
(REQ1) and then make that hierarchy accessible via some kind of FHIR resource
(REQ2). Slightly related to that is my desire to have a standard, concise syntax to express the idea of a hierarchically defined subset
(REQ3 aka the blah.blah.blah problem
) in order to use that syntax in CQL shareable knowledge artefacts
Grahame Grieve (Jul 03 2016 at 21:33):
perhaps there's a use for an operation on code system that returns a subset of it - e.g. a particular snomed heirarchy.
Peter Jordan (Jul 03 2016 at 22:21):
Would that satisfy a use case that differs from expanding an SCT implicit value set using an is-a filter?
Erich Schulz (Jul 04 2016 at 02:49):
@Peter Jordan i think a standard syntax that allowed expression of the idea of "all the is-a descendants of code X" would meet my requirements (REQ3) - I think that Dave is after a subset of the actual relationships (although that is reading between the lines)
Erich Schulz (Jul 04 2016 at 02:56):
It did occur to me that if a subset of the a full ancestor table was filtered to only include those links that didn't have a less direct alternative expression then that would meet the need of filtering the hierarchy - that wouldn't be too hard to implement in sql... (delete link A-C where there is a link "A-B" and a link "B-C") - i'm not sure if that is the DAG operation that @Grahame Grieve felt was problematic for implementers
Donna Truran (Jul 04 2016 at 03:03):
(deleted)
Dave Barnet (Jul 04 2016 at 11:12):
I'll try and restate the requirement, this time avoiding the word "hierarchy". I enter concepts into a codeSystem that are nested (codeSystem allows you to do this), I then create a valueSet which includes the codeSystem. How do I retrieve the concepts and still have the nesting maintained?
If I do a GET (something like [base]/ValueSet/150/$expand - where 150 is the value set that includes the nested codeSystem) I get back a flat list of concepts.
Naminder Soorma (Jul 04 2016 at 12:59):
Hi All, I'm working with Dave Barnet on this one. My question: is the Expansion Profile linked to this in any way? I realise that CodeSystem came after ValueSet and Expansion Profile so has the CodeSystem replaced elements of the original functionality held in ValueSet and Expansion profile. The CodeSystem concepts seem to repeat in the ValueSet profile. It would be a good idea to maybe show the deprecated values in ValueSet that are now covered in CodeSystem.
Grahame Grieve (Jul 04 2016 at 21:57):
there's no things in value set that are deprecated and covered in value set. They do have overlap but the content that appear in both has different purposes
Grahame Grieve (Jul 04 2016 at 21:58):
@Dave Barnet you still haven't said what you are actually trying to achieve. But yes, see ExpansionProfile.excludeNested
Robert McClure (Jul 04 2016 at 22:38):
Hey all. Back from family time and doing some perusing... I would expect that there would be a way of using the expand to get the identified value set concepts and then determine the hierarchy by obtaining the hierarchy structure from the code system. Is that what happens? Perhaps a special way of using expand that gets the hierarchy in addition to the value set expansion set.
Dave Barnet (Jul 05 2016 at 09:14):
See the thread on the hapi stream for more detail on what we are trying to achieve. ( https://chat.fhir.org/#narrow/stream/hapi/subject/codeSystem.20.26.20valueSet.20(STU3) )
Angus Millar (Jul 19 2016 at 00:47):
Can I validate my understanding of an implicit ValueSet.
If I have a CodeSystem and I require a ValueSet that contains all codes from the given CodeSystem. Then it is my understanding that I am not required to create a ValueSet resource instance, rather I can set the ‘valueSet’ property of my CodeSystem resource to a canonical URL that represents the CodeSystem’s implicit ValueSet. On expansion of this valueSet canonical URL, a terminology server using only the CodeSystem resource instance would construct the required ValueSet expansion.
Is this correct?
Should I creates a ValueSet instance regardless of this functionality?
If I was how would I select all code from the CodeSystem without listing them off in the ‘include’ element.
Lloyd McKenzie (Jul 19 2016 at 00:51):
I believe you still need to define the value set (though you could generate it programatically on the fly and not actually persist it). The purpose of the link is to just make it easy to find the "value set of everything"
Angus Millar (Jul 19 2016 at 01:09):
So If I was to create a ValueSet that includes all codes from the CodeSystem then how to I select all codes in a dynamic fashion. I don’t want to statically list the codes off in the ‘include’ element. How do I set a filter to capture all codes? This is a simple CodeSystem with no Parent / Child hierarchy.
Lloyd McKenzie (Jul 19 2016 at 01:17):
You don't specify a filter at all. If you define a value set referencing the system with no filter or enumeration of codes, then you get all of the codes
Angus Millar (Jul 19 2016 at 01:18):
Arh, yes! Thanks you Lloyd.
Jim Steel (Jul 19 2016 at 01:20):
in Ontoserver, if you put a uri in the CodeSystem.valueSet property, then there will be an (implicit) ValueSet with that uri
Angus Millar (Jul 19 2016 at 01:21):
Yes Jim I understood that but thought for simplicity for users that a ValueSet instance helps.
Last updated: Apr 12 2022 at 19:14 UTC