FHIR Chat · How to represent multiple inheritance in a CodeSystem · terminology

Stream: terminology

Topic: How to represent multiple inheritance in a CodeSystem

Shahim Essaid (Jul 26 2019 at 17:32):

I'm still learning about FHIR and CodeSystem. I haven't been able to find a clear description or an example for how to capture multiple inheritance in a CodeSystem. One parent can be captured by nesting "concept"s. Should the additional parenthood relationships be represented with duplicate "concept" entries under the other parents, or is the "codesystem-subsumes" extension meant for capturing this?

Yunwei Wang (Jul 26 2019 at 18:06):

"Some code systems define concepts that have multiple parents. If a code system has concepts like this (typically, concepts that are subsumed by more than one other concept), the code system SHOULD NOT be represented using the hierarchy structure in the Code System resource, and the relationships between concepts should be defined using properties. If the hierarchy is used, implementers SHALL use a property to indicate additional parents that are not represented in the structural (nested concepts) hierarchy." (http://build.fhir.org/codesystem.html#hierarchy)

Robert McClure (Jul 29 2019 at 13:52):

@Shahim Essaid The best way to represent multi-parentage via the FHIR code system resource is to define a property that is used to define the parentage relationship. For example you could make a property called "has_parent" that would be type=code because this property would link the child concept to each of it's parent concepts whereby the parent code would be the value of the property attached to the child concept. BTW, "has_parent" would also be a concept in your code system. Make sense?

Shahim Essaid (Jul 30 2019 at 20:26):

@Robert McClure @Yunwei Wang thank you both for your help! I neglected to state in my post that I was working with STU3. The R4 link you provided has more details and I was able to relate it to STU3. The "parent" and "child" codes from the "concept-properties" coding system is what I was looking for.

Michael Lawley (Jul 31 2019 at 01:04):

@Robert McClure The actual property to use for this is "parent" -- it is already there as a well-known property name

Peter Robinson (Nov 23 2020 at 18:53):

Hi everybody, we would like to create a FHIR representation of the polyhierarchy (multiple parents) of the HPO. Is it best to create a flat list (i.e., no nesting of XML code elements) and represent all parents with properties? Or should we represent as much of the hierarchy as possible with XML nesting and add properties for the rest? Is there an example anywhere to learn from?

Grahame Grieve (Nov 23 2020 at 18:59):

v3 ActCode is a polyheirarchy that we represent as a heirarchy with additional properties.

Grahame Grieve (Nov 23 2020 at 19:00):

I think which is best depends on how many multiple parents there are. ActCode has only a few

Shahim Essaid (Nov 23 2020 at 19:01):

Will a FHIR server recognize the additional "parent" relationships declared through a property? Specifically, in a ValueSet filter that includes based on the "is-a" property, will this work for some specific CodeSystem property?

Shahim Essaid (Nov 23 2020 at 19:06):

For example, we (@Peter Robinson and I) have a ValueSet defined like this:

    <include>
      <system value="http://github.com/phenopackets/core-ig/CodeSystem/hpo" />
      <filter>
        <property value="concept" />
        <op value="is-a" />
        <value value="HP:0000118"></value>
      </filter>
    </include>

And it gets expanded properly based on the is-a and the concept nesting in the CodeSystem. Does the FHIR specification have a specific property that will add to this expansion if that property is used to declare HP:0000118 as a parent even if the concept is not nested under HP:0000118? Is this part of the spec or is it up to an implementation to decide if it wants to implement this behavior?

I'm trying to find the ValueSet that has a couple of properties and if I remember correctly it had a "parent" property.

Grahame Grieve (Nov 23 2020 at 19:25):

technically, it should be recognised by the property URLs http://hl7.org/fhir/concept-properties#parent and http://hl7.org/fhir/concept-properties#child

Grahame Grieve (Nov 23 2020 at 19:25):

I can't say whether existing servers do actually do this correctly

Peter Robinson (Nov 24 2020 at 14:35):

So then would it be a good strategy to represent as much as we can in the XML structure (because existing servers may not do the right thing) and add extra parents with properties (this affects about 5% of HPO terms) -- and we can hope that at least some servers will do the right thing?

Rob Hausam (Nov 24 2020 at 15:13):

@Peter Robinson When there is a polyhierarchy (multiple parents), I think the decision would depend on whether the most important consideration is to get the maximum available representation of the hierarchy on the maximum number of servers, even if in some cases that representation might not actually be complete (using a "mixed" approach with both nesting and the parent/child properties), or if it's more important to ensure that if the hierarchy is represented at all that it is a complete representation (using the parent/child properties only). I think my general inclination, when possible, would be to test my server(s) to ensure that they do handle the parent/child properties and then use that approach consistently. Mixing the two approaches seems to me a bit messy and potentially confusing and error-prone. But other practical considerations still might end up making that the preferred option in some cases.

Jim Steel (Nov 30 2020 at 00:59):

Ontoserver does polyhierarchy using parent and child. HPO is one of our biggest examples of it

Jim Steel (Nov 30 2020 at 01:00):

We (and our clients using HPO) use a different URL for HPO though. @Alejandro Metke is the guy to talk to about it.

Alejandro Metke (Nov 30 2020 at 01:30):

I agree with @Rob Hausam and think that mixing both approaches might be confusing. I would just use the parent property.

Lin Zhang (Nov 30 2020 at 04:41):

Simplicity would be good.

Robert McClure (Dec 01 2020 at 01:45):

@Peter Robinson @Shahim Essaid Please note that if you are building an HL7 FHIR IG that includes references to an external code system you MUST contact HTA (@Julie James @Carol Macumber) to register the external code system and confirm the correct canonical uri. @Jim Steel , what url do you have and did you get it from the HPO authority?

Jim Steel (Dec 01 2020 at 01:50):

I'll have to defer to @Alejandro Metke on that, I'm afraid.

Alejandro Metke (Dec 01 2020 at 01:56):

@Robert McClure, the HPO code system we use is generated with the FHIR OWL application, which by default uses the source OWL ontology IRI as the code system URL. In this case, this is http://purl.obolibrary.org/obo/hp.owl.

Michael Lawley (Dec 01 2020 at 07:05):

@Peter Robinson meet @Julie James & @Carol Macumber :-)
It would be great to have HTA & HPO confirmation that the URI from the HPO OWL http://purl.obolibrary.org/obo/hp.owl is the appropriate URI to use for the FHIR CodeSystem (this would seem non-controversial), but furthermore have agreement on the CodeSystem version (the OWL uses, AFAIK, a URI that has a varying date of the form YYYY-MM-DD). It would help implementers if the FHIR version used a simple datestamp like YYYYMMDD. Finally, we also need an agreed URI for the "all codes" ValueSet.

Ultimately, I think we'll want an HPO-specific page in the FHIR spec. and address the issue of cross-code system hierarchy (i.e., the parent properties being Coding-typed, not code-typed).

Michael Lawley (Dec 01 2020 at 07:05):

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7153051/

Julie James (Dec 01 2020 at 12:26):

We (HTA) have the HPO page https://confluence.hl7.org/display/TA/HPO+The+Human+Phenotype+Ontology but sadly no official URI (yet). The Phenopackets team for the Connectathon may be able to help here....We should reach out to @Davera Gabriel as I think she is probably the terminology link for this

Davera Gabriel (Dec 01 2020 at 15:40):

Yes: will be working with @Peter Robinson and the folks at JaxLab to update the HTA records thus. We have a meeting Thursday with Peter & his team this week and can, at a minimum, discuss plans the HPO URI then. @Michael Lawley we cannot have the HTA records indicate a URI which resolves to an .owl file. We have this issue with another terminology in the HTA records and are in discussion with them to similarly have that changed. As such @Michael Lawley I think it is safe to assume that the purl you indicate above will not be resolved URI in the HTA records. Nonetheless as HPO will be needed to support the January Connectathon, resolution will not be ongoing nor open-ended. Please stand-by as we work through the solution, and I am happy to collect information / comments on this issue and bring these to the HTA for review, or assist in any way I can.

Davera Gabriel (Dec 01 2020 at 15:43):

@Robert McClure @Shahim Essaid @Alejandro Metke please also note my comments above (I'm not sure if you will be notified by Zulip...)

Shahim Essaid (Dec 01 2020 at 17:54):

Grahame Grieve said:

technically, it should be recognised by the property URLs http://hl7.org/fhir/concept-properties#parent and http://hl7.org/fhir/concept-properties#child

Does the publisher recognize these parent/child properties? I'm unable to get this to work for the publisher itself.

For example, I have the following in a test CodeSystem and one implicitly defined ValueSet that should include the code added with the parent/child.

In the CodeSystem:

  <property>
    <code value="parent"/>
    <uri value=" http://hl7.org/fhir/concept-properties#parent"/>
    <type value="code"/>
  </property>
  <property>
    <code value="child"/>
    <uri value=" http://hl7.org/fhir/concept-properties#child"/>
    <type value="code"/>
  </property>

A child:

  <concept>
    <code value="HP:0032223" />
    <display value="Blood group" />
    <property>
      <code value="parent" />
      <valueCode value="HP:0000118"/>
    </property>
  </concept>

The parent:

    <concept>
      <code value="HP:0000118" />
      <display value="Phenotypic abnormality" />

      <property>
        <code value="child"/>
        <valueCode value="HP:0032223"/>
      </property>

Is the above the correct way to define/declare a parent/child relationship?

If it is, the publisher is not recognizing this. It doesn't' show the child as a child in the web page built for the CodeSystem (in the indented table and the "Lvl" value), and the ValueSet that is implicitly defined to include all the children of that parent is not showing this example child in the built expansions.

One basic use case that is dependent on the publisher (as opposed to servers) is for data entry apps to be able to retrieve the latest expansions of various ValueSets defined in the IG and those expansions depend on the hierarchy. Here is an example of this idea: http://phenopackets.org/core-ig/master/ValueSet-phenotypic-severity.html This ValueSet expands the concept to all the children, excluding the top parent, and it does work with nested concept declarations but it doesn't seem to work for a parent/child based hierarchy.

Michael Lawley (Dec 01 2020 at 23:29):

@Davera Gabriel can you explain further why it matters what the URI resolves to? It is a URI(dentifier), not a URL(ocation) in both the FHIR CodeSystem and the OWL Ontology identifier use cases.
If it is desired that something human-readable can be returned _if_ someone treats it as a URL, then the Accept header can be used to return HTML or something else other than OWL (XML, RDF, functional syntax, ???) as a request response.

Robert McClure (Dec 01 2020 at 23:58):

@Michael Lawley It matters because the code system is not an owl file, it happens that one representation of it is in owl, but not all representations. HTA is correct in deciding that a format-specific uri will not be allowed. And if all the url/uri loving folks really didn't care what the words meant in the canonical FHIR url, then we could have saved us all immeasurable grief by continuing to use OIDs. This ship has sailed, time to get on.

Michael Lawley (Dec 02 2020 at 05:45):

Well we can have a discussion about whether 'format' has any meaning at all in the context of a URI -- it is purely convention that .xxx is interpreted as format xxx, and further that OWL is not even a format but rather a model with many renderings (much like FHIR).
If HPO has decided that the identifier for the terminology happens to end in .owl, then who are we / HTA to argue? But HTA insisting on a URI that is different to an already established URI (as currently used in the OWL file) creates work and potential confusion for all implementers and consumers that seems entirely and otherwise unnecessary.

Robert McClure (Dec 02 2020 at 13:13):

If HPO says they want .owl to mean the code system after presenting the issue, then I suspect HTA will accept that. But honestly, this cognitive dissonance on part of the uri having meaning and part not is confusing at best.

Peter Robinson (Apr 12 2021 at 16:37):

Dear everybody, we are moving forward with the HPO code system. I was wondering if there is any advice about the easiest way to code this -- is there a class in HAPI that helps with this or should we use some general XML library? I could not find anything in the documentation. Also, where should the codesystem live? Is it sufficient for the FHIR community of the code lives as a file on the HPO site with a standard ULR (PURL)?

Alejandro Metke (Apr 13 2021 at 00:55):

Hi @Peter Robinson. I've replied with some advice directly in your GitHub repo (see https://github.com/monarch-initiative/phenol/issues/310#issuecomment-731096310). Defintively better to use HAPI instead of a general XML or JSON library. There is documentation about working with the FHIR model here: https://hapifhir.io/hapi-fhir/docs/model/working_with_resources.html. The other documentation you will need to look at is the CodeSystem resource page here: https://www.hl7.org/fhir/codesystem.html.

Peter Robinson (Apr 13 2021 at 17:48):

Thanks, Alejandro, this is working now. We want to move to making the FHIR version part of the HPO build. Is it correct that we should not add all of the data about each term (definition, comment, synomym, alt_id, etc etc) to this because it will mainly be used to check for validity?

Lin Zhang (Apr 14 2021 at 12:02):

@Peter Robinson Nice to meet you again here.:big_smile:
IMO, a more complete version would be better. A partial version might limit some potential use case(s).

Peter Robinson (Apr 17 2021 at 18:24):

Hi everybody, I have created a small app based on your feedback. https://github.com/monarch-initiative/pyrophen The app created a FHIR CodeSystem from the HPO

Last updated: Apr 12 2022 at 19:14 UTC