FHIR Chat · hierarchical valueSet · implementers

Stream: implementers

Topic: hierarchical valueSet

natus (May 02 2017 at 16:49):

Hi,

I have a hierarchical terminology (say icd9). I want to store all the codes in a FHIR valueSet. Moreover, I d'like to store all the branches of the ICD9 hierarchy tree. Reading the documentation about valueSet and expansions:

The final "result set" is then represented in expansion. Note that the expansion structure is inherently ordered, and also provides support for a hierarchical tree of items. (https://www.hl7.org/fhir/valueset.html)

If I take this example: http://www.icd9data.com/2012/Volume1/E000-E999/E880-E888/E884/E884.0.htm, FHIR allows me to include all E000-E999, E880-E888, E884 within a nested set of abstract contains ?
Please let me know if this is right or if I am absolutely wrong and going to lost myself in that direction.

Thanks by advance

Grahame Grieve (May 02 2017 at 22:26):

ICD9 is a code system - so you should be storing it in a code system resource.

Grahame Grieve (May 02 2017 at 22:26):

btw, if you do that, I'd like to have a look at it to see how big it is, (and to load it onto tx.fhir.org)

natus (May 02 2017 at 22:55):

Reading the codeSystem documentation:

The CodeSystem resource is not intended to support the process of maintaining a code system. Instead, the focus is on publishing the properties and optionally the content of a code system for use throughout the FHIR eco-system, such as to support value set expansion and validation. Note that the important existing (large) code systems (SNOMED CT, LOINC, RxNorm, ICD family, etc) all have their own distribution formats, and there is no intent that the CodeSystem resource be used for distributing these kind of terminologies. Instead, it is intended to be used for distributing the smaller ad-hoc code systems that are ubiqutiously encountered through out the healthcare process.

That is why, I thought valueSet where the place to store code. Isn't it ?

For sure, I anderstand correctly I will implement various code system during my project, and if interesting, push them in your system.

Grahame Grieve (May 02 2017 at 22:56):

well, you're not going to actually maintain ICD itself. If you were going to do that, you'd find that code system didn't address your needs. You're just going to publish it - take the format and say 'this is ICD-X'. Yes?

natus (May 02 2017 at 23:04):

Right, I hope to publish it in a sense. This is supposed to complete the resources such condition. As you may know, I am trying to implemente FHIR as a kind of clinical datawarehouse. And then code system are the equivalent of dimension; condition as fact tables.

Grahame Grieve (May 02 2017 at 23:20):

so you should use code system then

natus (May 02 2017 at 23:34):

Thanks for the help. I hope to post here my example (http://www.icd9data.com/2012/Volume1/E000-E999/E880-E888/E884/E884.0.htm)
using the codeSystem resource.

Grahame Grieve (May 02 2017 at 23:37):

great

natus (May 03 2017 at 08:47):

Here is a first draft of http://www.icd9data.com/2012/Volume1/E000-E999/E880-E888/E884/E884.0.htm. I put 2 codes and their respective hierarchy. Main concern are :
- both codes "E884.0" and "E884.1" share the same hierarchy at some point, but it is repeated (denormalisation) .
- it is not possible to push it on simplifier.net because resource CodeSystem is not implemented (yet?) https://www.simplifier.net/test243/CodeSystem-example

Is it how it is intended to be implemented ?

Thanks

{
  "resourceType": "CodeSystem",
  "meta": {
    "versionId": "1",
    "lastUpdated": "2017-03-08T15:14:24.985-05:00"
  },
  "id": "16687",
  "version": "1",
  "name": "icd9",
  "title": "ICD-9",
  "status": "draft",
  "experimental": true,
  "publisher": "natus",
  "caseSensitive": true,
  "valueSet": "not applicable?",
  "hierarchyMeaning": "part-of",
  "content": "fragment",
  "count": 2,
  "concept": [
    {
      "code": "E884.0",
      "display": "2012 ICD-9-CM Diagnosis Code E884.0",
      "definition": "Accidental fall from playground equipment",
      "designation": [
        {
          "language": "EN",
          "value": "Short description: Fall from playgrnd equip."
        },
        {
          "language": "EN",
          "value": "E884.0 describes the circumstance causing an injury, not the nature of the injury."
        }
      ],
      "concept": [
        {
          "code": "E884",
          "display": "Other accidental falls from one level to another E884",
          "definition": "Other accidental falls from one level to another",
          "concept": [
            {
              "code": "E880-E888",
              "display": "Accidental Falls E880-E888",
              "definition": "Accidental Falls",
              "concept": [
                {
                  "code": "E000-E999",
                  "display": "Supplementary Classification Of External Causes Of Injury And Poisoning E000-E999",
                  "definition": "Supplementary Classification Of External Causes Of Injury And Poisoning"
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "code": "E884.1",
      "display": "2012 ICD-9-CM Diagnosis Code E884.1",
      "definition": "Accidental fall from cliff",
      "designation": [
        {
          "language": "EN",
          "value": "Short description: Fall from cliff."
        },
        {
          "language": "EN",
          "value": "E884.1 describes the circumstance causing an injury, not the nature of the injury."
        }
      ],
      "concept": [
        {
          "code": "E884",
          "display": "Other accidental falls from one level to another E884",
          "definition": "Other accidental falls from one level to another",
          "concept": [
            {
              "code": "E880-E888",
              "display": "Accidental Falls E880-E888",
              "definition": "Accidental Falls",
              "concept": [
                {
                  "code": "E000-E999",
                  "display": "Supplementary Classification Of External Causes Of Injury And Poisoning E000-E999",
                  "definition": "Supplementary Classification Of External Causes Of Injury And Poisoning"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Yunwei Wang (May 03 2017 at 20:09):

I think the order is wrong. For example, parent concept is E884 and child concepts are E884.0/E884.1

Rob Hausam (May 04 2017 at 00:34):

Yes - agree with Yunwei on fixing the order.

Grahame Grieve (May 04 2017 at 00:35):

I think that heirarchyMeaning should be "classified-with". And agree with Yunwei and Rob

Rob Hausam (May 04 2017 at 00:39):

Yes - didn't notice the "part-of" - agree it should be "classified-with" for ICD-9.

natus (May 04 2017 at 09:20):

Thanks for clarifications.

What about code systems having both "classified-with" and "part-of" ? I guess ICD9 is that kind. By eg: "Diseases Of The Musculoskeletal System And Connective Tissue 710-739" ; child are sometimes "Diseases Of The Musculoskeletal System" and sometimes "Diseases Of The Connective Tissue". The problem is hiearchicalMeaning is defined for all the code system, and not for each concept.

Grahame Grieve (May 04 2017 at 09:45):

I think that meets the criteria for 'classified with' - which basically means, wahtever the classification wants it to mean

Grahame Grieve (May 04 2017 at 09:45):

but if there really is a difference in heirarchy, then you can't use the heirarchy at all, and present just a flat list with properties that expresses what relatinoships there are

natus (Oct 08 2018 at 22:16):

Hi
I am wondering how to navigate in a CodeSystem hierarchy, from a client side. Other resource such Organization are quite comfortable to navigate the hierarchy with "part-of".

But CodeSystem seems to contain all the codes. There is no way to ask for root code, then childs and so -on to build some navigation tool.

Am I missing something ?

Jim Steel (Oct 08 2018 at 22:22):

You should be able to find the "roots" of a CodeSystem by expanding a ValueSet of all concepts in the CodeSystem that have no parent (property="parent", op="exists", value="false")

natus (Oct 08 2018 at 22:30):

So you suggest to use ValueSet to dig into CodeSystem. The trick would be to create a ValueSet containing all the code of the CodeSystem. The operation $expand then allows to navigate easily in the hierarchy. Is that correct ?

Grahame Grieve (Oct 08 2018 at 22:42):

I think you're looking for the $lookup operation

Jim Steel (Oct 08 2018 at 22:43):

Once you've found the root concepts, you can use $lookup to find the children

natus (Oct 09 2018 at 07:55):

@Jim Steel you suggest to both use ValueSet resource (with $expand) to get the root concept and then dig CodeSystem Resource (with $lookup) to get the children ?

@Grahame Grieve you suggest to only use CodeSystem resource (with $lookup) and use parameters such root to describe the codes hierarchy ?

Thanks

natus (Oct 10 2018 at 18:39):

@Grahame Grieve would you only focus on CodeSystem and $lookup to go through the hierachy of any code system ? Thanks

Grahame Grieve (Oct 10 2018 at 18:49):

$lookup takes a specific code as input, and returns properties on that specific code. We haven't defined a specific operation for this.

natus (Oct 10 2018 at 18:58):

Cannot $lookup take a property as input ?
From https://www.hl7.org/fhir/codesystem-operations.html#4.7.15.1
code is 0..1 so this should be possible to ask for root, leaf, parent and child with properties isnt'it ?

Yunwei Wang (Oct 10 2018 at 19:04):

You provide a code to the $lookup operation. $lookup operation will returns properties of this code. If parent is a declared property, then you can get parent code. Then you can feed the parent code to $lookup again.

natus (Oct 10 2018 at 19:05):

Guys, sorry but the documentation tells the opposite:
https://www.hl7.org/fhir/operation-codesystem-lookup.html
IN parameters can be property only or I am missing something

Yunwei Wang (Oct 10 2018 at 19:08):

"Given a code/system, or a Coding, get additional details about the concept, including definition, status, designations, and properties. "
So code/system or coding is required.

Grahame Grieve (Oct 10 2018 at 19:08):

we could be a little clearer about this

Yunwei Wang (Oct 10 2018 at 19:09):

We do have that for most valueset operations. Yeah agree. tracker?

natus (Oct 10 2018 at 19:11):

All right about that. So, in definitive, the only workaround right now to explore a hierarchy
is to use a valueset containing the whole code system with $expand ?

Grahame Grieve (Oct 10 2018 at 19:12):

yes. and we say that the value set should always exist. but then we forgot to define it.

Grahame Grieve (Oct 10 2018 at 19:12):

it might be a good idea to do this:

Grahame Grieve (Oct 10 2018 at 19:13):

http://acme.com/fhir/ValueSet/$expand?text=brain&system=http://hl7.org/fhir/sid/icd-10

Grahame Grieve (Oct 10 2018 at 19:14):

and then say that the server identifies the value set implied by the system, or fakes one up

Yunwei Wang (Oct 10 2018 at 19:14):

@Grahame Grieve wrong topic. :grinning:

Grahame Grieve (Oct 10 2018 at 19:14):

oh oops

Yunwei Wang (Oct 10 2018 at 19:18):

@natus The only way to do that is to define your own valueSet using the property that Jim Steel mentioned and use that ValueSet as input paramater for $expand operation. The question now is if the server would accept the inbound ValueSet parameter.

natus (Oct 10 2018 at 19:31):

valueSet $expand documentation is hardcore https://www.hl7.org/fhir/valueset.html#expansion
Where a simple $child, $parent in codeSystem would do the same thing easily (up and down in the codeSystem tree)

Yunwei Wang (Oct 10 2018 at 19:47):

You can do that using $lookup

/CodeSystem/$lookup?code=xxx&system=yyy&property=parent

natus (Oct 10 2018 at 19:54):

/CodeSystem/$lookup?code=xxx&system=yyy&property=parent

would return all the parent of xxx

/CodeSystem/$lookup?code=xxx&system=yyy&property=child

would return all the childs of xxx

That's too bad that

/CodeSystem/$lookup?system=yyy&property=leaf

AND

/CodeSystem/$lookup?system=yyy&property=root

are not allowed ! Any reason they are not and they won't in the future ?

Grahame Grieve (Oct 10 2018 at 19:55):

$lookup only returns the properties of a single code

Yunwei Wang (Oct 10 2018 at 19:56):

Some properties are defined by code system not FHIR.

natus (Oct 10 2018 at 20:00):

I will then focus on ValueSet + $expand only to implement the hierarchy traversal.
Hope that won't be like desert traversal, but many thanks for your support

Yunwei Wang (Oct 10 2018 at 20:01):

Just curious why you want to do that.

Grahame Grieve (Oct 10 2018 at 20:01):

desert traversal

?

natus (Oct 10 2018 at 20:04):

I am implementing a i2b2 over fhir: I provide exploring terminologies though the tool. Terminologies are huge
and cannot be loaded entirely in client memory.

@Grahame Grieve crossing desert: $expand documentation is comlicated

Grahame Grieve (Oct 10 2018 at 20:07):

yes. it's a pretty flexible thing... ideas for better doco always welcome

Rob Hausam (Oct 10 2018 at 20:20):

One thing to consider is that it's not a specific requirement that every code system have a single top-level root concept. If that's not the case in a specific instance then referencing 'root' would be either ambiguous, an error or would reference/return multiple values.

natus (Oct 10 2018 at 20:25):

would that be ok then to say every code system do have a single top-level abstract root ? icd10 abstract root would be the beginning and its child would be the first codes in the hierarchy, and the last would be leaves ?

Rob Hausam (Oct 10 2018 at 20:51):

I'm thinking that we probably wouldn't want to try to define that independently of the code system publisher (assuming that I understand what you are asking).

Rob Hausam (Oct 10 2018 at 20:53):

The set of root concept(s) would be all of the concepts for which no parent concept is defined. That's pretty straightforward, even if it doesn't always resolve to only a single concept.

natus (Oct 10 2018 at 20:56):

That makes sense. Much better definition, and I notice that this is the one Jim provided few post above.

Rob Hausam (Oct 10 2018 at 23:04):

Yes. That was a while back in the thread and I had forgotten that he said that, but it's good to confirm.

natus (Oct 11 2018 at 20:35):

Not sure the best way to implement that:

GET [base]/ValueSet/$expand?url=http://icd10.com&filter=(property="parent", op="exists", value="false")

Or

POST [base]/ValueSet/$expand --data
- parameters:
     parameter:
         ValueSet: myValueSet

The concern with the GET version is the filter is a String parameter that is not standardized
Passing the ValueSet looks more standard while this looks much more complicated to implement

Jim Steel (Oct 12 2018 at 02:05):

I don't think the first one works. When I mentioned that, I didn't mean that as a filter parameter in a GET request, I meant it as a filter block in a POSTed ValueSet resource (your second example)

Last updated: Apr 12 2022 at 19:14 UTC