FHIR Chat · codeSystem & valueSet (STU3) · hapi

Stream: hapi

Topic: codeSystem & valueSet (STU3)


view this post on Zulip Dave Barnet (Jul 01 2016 at 08:17):

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)

[*NOTE* this was originally posted on the Implementer's stream, but re-posted here for a view from the hapi folk]

view this post on Zulip Michael Lawley (Jul 01 2016 at 23:27):

@Dave Barnet You're not doing anything wrong - the $expand operation is free to return the expansion as a flat list or with nesting as it sees fit. Our terminology server always returns a flat list because the order is significant (ranked by the score from the filter matching) and this is incompatible with also returning hierarchy.
However, since the structure is in the CodeSystem, you can use $lookup to access it.

view this post on Zulip Dave Barnet (Jul 04 2016 at 11:18):

As far as I can see, $lookup acts on a single concept defined in a codeSystem.
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.

view this post on Zulip Erich Schulz (Jul 04 2016 at 12:05):

have you looked at the terribly named $closure resource @Dave Barnet ?

view this post on Zulip Erich Schulz (Jul 04 2016 at 12:10):

from what i gather (sorry I'm bit of a FHIR noob) it will do a full hierarchy walk and return all the descendant-ancestor links

view this post on Zulip Erich Schulz (Jul 04 2016 at 12:11):

ie if A is a subset of B, and B is a subset of C then it would give [A-B, A-C, B-C]

view this post on Zulip Erich Schulz (Jul 04 2016 at 12:15):

my comment on the other thread was just saying that it would be possible possible to prune back to the core links by culling A-C because there are more hi-res links available that transitively imply the A-C link (A-B and B-C)

view this post on Zulip Erich Schulz (Jul 04 2016 at 12:18):

so this involves a two step process as far as I can tell, the $lookup to get the list then $closure to get the "ancestor table"

view this post on Zulip Dave Barnet (Jul 04 2016 at 13:46):

Thanks Erich, I'll see if I can give this a go. It does seem a long-winded way round for getting out information (creating client side tables, and $lookup acts on one concept at a time etc.). What we are trying to achieve is a vocabulary server using codeSystem and valueSet, containing & maintaining our own code systems. It's really conceptually very simple, so I was trying to avoid complexity.

view this post on Zulip Grahame Grieve (Jul 04 2016 at 22:00):

it's still not clear to me what you are trying to achieve.

view this post on Zulip Erich Schulz (Jul 05 2016 at 07:51):

I'm intererested in this too @Dave Barnet and agree there should be a simpler solution. Perhaps someone needs to request a "$hierarchy" service?

view this post on Zulip Erich Schulz (Jul 05 2016 at 07:52):

Its extremely possible that I'm leading you up the garden path tho - I am a complete FHIR noob so I wouldn't believe me :-)

view this post on Zulip Dave Barnet (Jul 05 2016 at 09:11):

I'll try and expand a little on what we are trying to achieve. We are looking for a way to manage some code values for our Data Dictionary. FHIR offers many of the facilities that we would require (such as querying via an API, auditing, distinguishing between code system & value sets etc.). However, there are some challenges to overcome with the code sets we want to manage, which we are working through. Although 90% of the code sets conform to a code/value pair, which are straight forward to incorporate into a codeSystem, there are some code sets that have code/value/notes and some code sets that have structure within them, such as nesting of codes. I've put an example codeSystem of the nesting issue on the Canadian public FHIR server (http://fhirtest.uhn.ca/baseDstu3/CodeSystem/111052), and an example of a valueSet that includes this codeSystem (http://fhirtest.uhn.ca/baseDstu3/ValueSet/111111). The codeSystem has nested codes. When you expand the valueSet (do a GET on http://fhirtest.uhn.ca/baseDstu3/ValueSet/111111/$expand) all the nesting in the codeSystem is lost, and the codes appear in a flat list.
It was my hope that if you put nested codes into a codeSystem, you'd get out nested codes when you retrieved them.
Hope that makes things clearer

view this post on Zulip Grahame Grieve (Jul 05 2016 at 09:20):

well, I don't think you've thought this all the way through. This looks like a classification. When you get the expansion, I think that you don't want the root codes MA00 and HM00 to be selectable

view this post on Zulip Grahame Grieve (Jul 05 2016 at 09:23):

hmm. is that the case?

view this post on Zulip Erich Schulz (Jul 05 2016 at 09:49):

looking at http://fhirtest.uhn.ca/baseDstu3/CodeSystem/111052 - what is the gap between that and your requirements?

view this post on Zulip Erich Schulz (Jul 05 2016 at 09:51):

(I can see it wouldn't cope well with large DAG hierarchies due to duplication, but for small trees it seems to have the core information)

view this post on Zulip Dave Barnet (Jul 05 2016 at 12:10):

The Data collections in the UK are sometimes at a detailed level, or at a higher level to help those systems that don't collect detailed data. Another example of nesting is for relationships. The Data Dictionary states "Note that ORGANISATIONS may choose to collect the RELATIONSHIP TO PERSON FOR CHILDREN AND YOUNG PEOPLE codes at the high level (shown in bold) or at the more detailed level below each high-level code." The list includes
*BPX* Biological Parent
BPM Biological mother
BPF Biological father
*SPX* Step-Parent
SPM Stepmother
SPF Stepfather
*GPX* Grandparent
GPM Grandmother
GPF Grandfather
etc..
The nesting is certainly required for presentation purposes, and so needs to be maintained in the codeSystem, and served out to the presenting system as a nested list.

view this post on Zulip Erich Schulz (Jul 05 2016 at 12:12):

@Dave Barnet that makes sense to me for one, but I'm still wondering why http://fhirtest.uhn.ca/baseDstu3/CodeSystem/111052 isn't meeting your requirements?

view this post on Zulip Grahame Grieve (Jul 05 2016 at 12:31):

So the problem here isn't the spec, it's the open source terminology services.

view this post on Zulip Grahame Grieve (Jul 05 2016 at 12:31):

have you looked at the definition for ExpansionProfile.excludeNested?

view this post on Zulip Grahame Grieve (Jul 05 2016 at 12:32):

James, I could enhance the standard value set expander to maintain the heirarchy from the code system if the include statement is simple enough, and if the right flag is set. But that doesn't solve all cases, right? how do you handle merging outside the standard expander?

view this post on Zulip Dave Barnet (Jul 05 2016 at 12:35):

My colleague Naminder Soorma is having a look at the expansionProfile - I'll let you know how we get on.

view this post on Zulip Naminder Soorma (Jul 05 2016 at 12:41):

I am confused how ExpansionProfile works, here is some of the code, can you tell me how ValueSet links to the ExpansionProfile?

<ExpansionProfile xmlns="http://hl7.org/fhir">
<url value="http://fhir.nhs.net/ExpansionProfile/TestExpansion"/>
<identifier>ExpansionProfileNHS</identifier>
<version value="1.0"/>
<name value="ExpansionProfileNHS"/>
<status value="active"/>
<experimental value="false"/>
<codeSystem>
<include>
<codeSystem>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
</codeSystem>
</include>
</codeSystem>
<excludeNested value="false"/>
</ExpansionProfile>

view this post on Zulip Grahame Grieve (Jul 05 2016 at 12:43):

ExpansionProfile is a parameter on the $expand operation

view this post on Zulip Naminder Soorma (Jul 05 2016 at 12:51):

Hi, do you mean it is an IN Parameter? http://hl7.org/fhir/2016May/valueset-operations.html#expand

I couldn't find any reference to it on this page? Could you give me an example please.

view this post on Zulip Grahame Grieve (Jul 05 2016 at 12:54):

profile parameter. Guess I better update the documentation for that parameter since we now defined the ExpansionProfile

view this post on Zulip James Agnew (Jul 05 2016 at 13:49):

@Grahame Grieve Yeah, adding that capability to the ValueSetExpander probably wouldn't help here anyway. I only actually use that to do expansions on "built in" codesystems (i.e. the ones distributed with the spec itself). Anything user supplied or not-present is expanded using a Lucene query. Nonetheless, this would probably be useful at some point...

I'd love to get our term service enhanced so that you can specify a profile and get the hierarchical expansion, but that's a TBD.. If I get to it first, I'll do the ValueSetExpanderSimple too.

view this post on Zulip Grahame Grieve (Jul 05 2016 at 13:49):

ok

view this post on Zulip Grahame Grieve (Jul 05 2016 at 13:49):

I'll probably do it while doing publishing QA in the lead into the ballot publication

view this post on Zulip James Agnew (Jul 05 2016 at 13:51):

On another note, I love the HM04 code from that code system. I've sure had periods where Sofa surfing (sleeps on different friends floor each night) applied.. don't know that I thought of myself as homeless though.

I feel like if that was a SCT code it would be "Sleeps on Couch, Sofa, or Chesterfield or similar for a period not exceeding two months where the subject does not permanently reside in the same dwelling (Finding)"

view this post on Zulip Naminder Soorma (Jul 05 2016 at 13:57):

James - :) very posh if you got to sleep on a Chesterfield.... @Grahame Grieve - So are you talking about the Valueset profile, I tried some code like this:

<expansion>
<extension url="http://hl7.org/fhir/StructureDefinition/valueset-expansionSource">
<valueUri value="http://hl7.org/fhir/ValueSet/example-extensional"/>
</extension>
<identifier value="http://fhir.nhs.net/ExpansionProfile/TestExpansion"/>
<timestamp value="2016-07-07T10:00:00Z"/>
<parameter> <!-- 0..* Parameter that controlled the expansion process -->
<name value="excludeNested"/><!-- 1..1 Name as assigned by the server -->
<valueBoolean value="false"/>
</parameter>
<contains>
<abstract value="true"/>
<display value="Cholesterol codes"/>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<version value="1"/>
<code value="A01Main"/>
<display value="Main Code Header"/>
</contains>
</contains>
</expansion>

view this post on Zulip Grahame Grieve (Jul 05 2016 at 13:57):

where did you try that?

view this post on Zulip Naminder Soorma (Jul 05 2016 at 13:58):

<ValueSet xmlns="http://hl7.org/fhir">
<identifier>
<system value="http://fhir.nhs.net/valueset/TestValueSet"/>
<value value="ValueSetNHS"/>
</identifier>
<version value="1"/>
<name value="ValueSetNHS"/>
<status value="active"/>
<experimental value="false"/>
<publisher value="NHS Data Dictionary"/>
<date value="2016-07-05"/>
<description value="Test ValueSet"/>
<compose>
<include>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<version value="1"/>
</include>
</compose>
<expansion>
<extension url="http://hl7.org/fhir/StructureDefinition/valueset-expansionSource">
<valueUri value="http://hl7.org/fhir/ValueSet/example-extensional"/>
</extension>
<identifier value="http://fhir.nhs.net/ExpansionProfile/TestExpansion"/>
<timestamp value="2016-07-07T10:00:00Z"/>
<parameter> <!-- 0..* Parameter that controlled the expansion process -->
<name value="excludeNested"/><!-- 1..1 Name as assigned by the server -->
<valueBoolean value="false"/>
</parameter>
<contains>
<abstract value="true"/>
<display value="Cholesterol codes"/>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<version value="1"/>
<code value="A01Main"/>
<display value="Main Code Header"/>
</contains>
</contains>
</expansion>
</ValueSet>

view this post on Zulip Grahame Grieve (Jul 05 2016 at 13:59):

I don't know why putting it there will make any difference. What are you trying to do?

view this post on Zulip Grahame Grieve (Jul 05 2016 at 13:59):

it should be something like GET [base]/ValueSet/[id]/$expand?profile=[uri]

view this post on Zulip Naminder Soorma (Jul 05 2016 at 14:02):

I was reading up the following: ValueSet.expansion.parameter
Definition
A parameter that controlled the expansion process. These parameters may be used by users of expanded value sets to check whether the expansion is suitable for a particular purpose, or to pick the correct expansion.

Control 0..*
Comments
The server decides which parameters to include here, but at a minimum, the list SHOULD include the date, filter, and profile parameters passed to the $expand operation (if any).

so based on your code profile=[uri] = the name of the expansion profile?

view this post on Zulip Naminder Soorma (Jul 05 2016 at 14:03):

basically that returns the following:
<ValueSet xmlns="http://hl7.org/fhir">
<expansion>
<identifier value="urn:uuid:7064442e-0780-438d-999e-090d3dc9a7c1"/>
<timestamp value="2016-07-05T15:02:21+01:00"/>
<parameter>
<name value="version"/>
<valueUri value="http://fhir.nhs.net/CodeSystem/TestCodeSystem?version=1"/>
</parameter>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A01Main"/>
<display value="Main Code Header"/>
</contains>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A01Sub"/>
<display value="Sub Code 01"/>
</contains>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A02Sub"/>
<display value="Sub Code 02"/>
</contains>
</expansion>
</ValueSet>

I want it to return THIS:

<ValueSet xmlns="http://hl7.org/fhir">
<expansion>
<identifier value="urn:uuid:7064442e-0780-438d-999e-090d3dc9a7c1"/>
<timestamp value="2016-07-05T15:02:21+01:00"/>
<parameter>
<name value="version"/>
<valueUri value="http://fhir.nhs.net/CodeSystem/TestCodeSystem?version=1"/>
</parameter>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A01Main"/>
<display value="Main Code Header"/>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A01Sub"/>
<display value="Sub Code 01"/>
</contains>
<contains>
<system value="http://fhir.nhs.net/CodeSystem/TestCodeSystem"/>
<code value="A02Sub"/>
<display value="Sub Code 02"/>
</contains>
</contains>
</expansion>
</ValueSet>

view this post on Zulip Grahame Grieve (Jul 05 2016 at 14:10):

[uri] is the url in the expansion profile.

view this post on Zulip Naminder Soorma (Jul 05 2016 at 14:24):

ok, well I have tried that then on the HAPI STU3 server and it returned the result in my previous post.

view this post on Zulip James Agnew (Jul 05 2016 at 14:25):

Oh yeah, we don't support the profile parameter yet unfortunately. So you may well be doing it right, but HAPI doesn't yet support it. :)

view this post on Zulip Robert McClure (Jul 05 2016 at 14:34):

Folks, When I look at http://fhirtest.uhn.ca/baseDstu3/CodeSystem/111052 I see nesting that is undefined and simply represented as indentations. That is not how a code system should do this - use additional space as the relationship that links a child to a parent. What I see is a visual metaphore for something that should be computable. In real code systems a hierarchy is a specialized type of relationship where the code system has defined content that uses a named relationship to link concepts AND then says that relationship is hierarchical (transitive is ussually what is meant.) So I don't see that information in the link @Dave Barnet has provided so I suspect the computability of the hierarchy is missing. I am not an expert on what FHIR supports for all this but is the code system shown somehow legally defining a hierarchy in FHIR?

view this post on Zulip Dave Barnet (Jul 05 2016 at 14:57):

I was going by this definition "CodeSystem.concept.concept
Definition
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" from http://hl7.org/fhir/2016May/codesystem-definitions.html#CodeSystem.concept.concept, which implies a basic hierarchy denoted by nesting (I think??)

view this post on Zulip Robert McClure (Jul 05 2016 at 15:41):

@Grahame Grieve Is @Dave Barnet correct? It seems this is essentially a shortcut that allows the code system definition to describe a relationship of "childOf" (perhaps implicitly parentOf too?) but I wonder if that shortcut makes other computations more difficult. I assume this is for inline code systems primarily - Dave, is that what you are using this for?

view this post on Zulip Grahame Grieve (Jul 05 2016 at 19:30):

@Robert McClure you were on the call when we discussed this, and you helped draft the text Dave quoted. But you don't seem to remember that in your comments above. The heirarchy is a convenient short cut for a computable relationship, but It was you who pushed back against making it computable

view this post on Zulip Michael Lawley (Jul 06 2016 at 07:13):

Perhaps now is a good time to renew my call to revisit the proposed ExpansionProfile Resource? All those boolean parameters would be much better as optional explicit parameters to $expand

view this post on Zulip Naminder Soorma (Jul 06 2016 at 08:23):

Can I ask what the Expansion Profile is trying to achieve that the ValueSet resource does not achieve? I haven't been able to distinguish what it brings extra to the table, that couldn't already be incorporated into the ValueSet.

view this post on Zulip Grahame Grieve (Jul 06 2016 at 12:49):

the value set resource defines what codes are in the set. The expansion profile resource defines information about how expansions are done on the system

view this post on Zulip Grahame Grieve (Jul 06 2016 at 12:50):

Michael - I guess you should create a task so I can ask Vocab to talk about it. or you could send an email to the vocab list

view this post on Zulip James Agnew (Jul 06 2016 at 13:47):

It is a bit of a curious design I suppose. I'd assume that the intention is more that the server would expose a set of profiles it supports, essentially making ExpansionProfile a conformance resource, and clients would be expected to pick from those.

view this post on Zulip Grahame Grieve (Jul 06 2016 at 13:58):

well, there's some.. uncertainty.... about whether some of those flags are server profiles or client choices

view this post on Zulip James Agnew (Jul 06 2016 at 13:59):

Yeah, it would be interesting to hear what the intent is, and whether it is guided by any existing systems or implementer experience.

If the idea is that these are client choices, the current design is overcomplicated.

view this post on Zulip Naminder Soorma (Jul 06 2016 at 14:21):

I can't see why it can't be achieved using the ValueSet.expansion.parameter element as the documentation suggests.

ValueSet.expansion.parameter
Definition
A parameter that controlled the expansion process. These parameters may be used by users of expanded value sets to check whether the expansion is suitable for a particular purpose, or to pick the correct expansion.

Control 0..*
Comments
The server decides which parameters to include here, but at a minimum, the list SHOULD include the date, filter, and profile parameters passed to the $expand operation (if any).

view this post on Zulip Robert McClure (Jul 06 2016 at 16:08):

@Grahame Grieve Yep, I don't remember but you're taking liberties to say I would "push" to make it not computable - that is very unlikely. Setting revisionist history aside, I don't think it's a good idea. Here is the thing, if this dot notation is unequivocally computable and uniquivocally defines bi-directional relations (i.e: both child of and parent of) then I would assume FHIR terminology services can treat this as a special type of relation that can be reasoned over including transitive closure. IS that whaat you all are doing? @Michael Lawley How do you handle this?

view this post on Zulip Robert McClure (Jul 06 2016 at 16:18):

For those of you unclear (and this is very understandable because it has been unclear to date) as to the difference between a value set definition and a value set exapnsion, I suggest you take a look at the just published Value Set Definition STU here http://www.hl7.org/implement/standards/product_brief.cfm?product_id=437. The value set resource was orginally created (I think) to support defining what concepts/codes should be in the expansion you want to use - this is called the expansion code set. An expansion is the resulting expansion code set PLUS any addition information about the concept (or information related to the concept) you need to use. Any number of value set definitions can result in the same expansion code set. The FHIR community is STRONGLY encourage to continue to align with this - as Graham has done (with some grumbling) to date - thank you Graham. You all are the leading edge in implementing this so where changes need to done to the approach we've outlined, let us know and we'll work together.

view this post on Zulip Rob Hausam (Jul 06 2016 at 18:37):

I took the liberty to create task #10277 for this. @Michael Lawley, please go ahead and add or change what you want. We could potentially bring this up for discussion on the Vocab call tomorrow, if there is available time (can check with Ted).

view this post on Zulip Rob Hausam (Jul 06 2016 at 19:19):

thanks for adding the Zulip discussion link to the task, @James Agnew - I was just thinking that I should go back and do that

view this post on Zulip Michael Lawley (Jul 06 2016 at 21:33):

@Robert McClure We interpret nesting in the CodeSystem as transitive parent/child relationships. Hence this hierarchy will be used when computing the results for the $closure operation, and for populating the parent/child properties in a $lookup.

view this post on Zulip Michael Lawley (Jul 06 2016 at 21:34):

@Rob Hausam Thanks - I've added some detail in a comment

view this post on Zulip Michael Lawley (Jul 06 2016 at 21:38):

@Naminder Soorma ValueSet.expansion.parameter is about the server telling the client what it did during the expansion. ExpansionProfile is about letting the client tell the server what it wants - e.g., exclude inactive codes

view this post on Zulip Grahame Grieve (Jul 06 2016 at 21:45):

@Robert McClure I proposed an element to define what the heirarchy meant. As things stand snow, the heirarchy is clear and computable (and how we do things in many contexts) but the implication it carries is unstated. So "if this dot notation is unequivocally computable and uniquivocally defines bi-directional relations (i.e: both child of and parent of) then I would assume FHIR terminology services can treat this as a special type of relation that can be reasoned over" - yes. But " including transitive closure" not so much, because the definition of transitive closure is more specific.

view this post on Zulip Grahame Grieve (Jul 06 2016 at 21:46):

that was why I proposed an element on code system so you could say that this was safe, but it failed to get through vocab, and I remember that you were the prime source of resistance to the idea

view this post on Zulip Grahame Grieve (Jul 06 2016 at 21:46):

so now, we are forced to 'assume' that the heirarchy indicates subsumption.

view this post on Zulip Grahame Grieve (Jul 06 2016 at 21:48):

which is Michael says he does, as do I and Apelon as well

view this post on Zulip James Agnew (Jul 06 2016 at 21:52):

As do I. :)

view this post on Zulip Michael Lawley (Jul 07 2016 at 00:24):

and at the same time I warn people (as in my message to Erich) that the assumption may be faulty :)
Just as CodeSystem contains a flag to indicate whether it is "compositional", it would be much better to include a flag that indicates whether the hierarchy corresponds to subsumption or not (and to explicitly document that the containing concept is the subsumer).

view this post on Zulip Grahame Grieve (Jul 07 2016 at 00:53):

that's what I proposed, and vocab knocked it back.

view this post on Zulip Rob Hausam (Jul 07 2016 at 05:11):

We can revisit it again - it's probably needed.

view this post on Zulip Grahame Grieve (Jul 07 2016 at 10:18):

well, I doubt we have time to revisit it prior to ballot. So we can all ballot about it

view this post on Zulip Robert McClure (Jul 07 2016 at 15:36):

@Grahame Grieve I remember we had a discussion but I don't remember this being the focal issue. If we had captured "transivity" of the assumed relation I am definitely been in favor of identifying that. Let's not dwell on the past... However we can identify that the unstated hierarchy relation is transitive we should do that. But I'd say that we are likely VERY safe in assuming that anything you all make using such a notation will be transitive so this practice simply needs to be documented (I.E.: The FHIR default (un-named) nested hierarchy is always transitive.)

view this post on Zulip Rob Hausam (Jul 07 2016 at 16:36):

I agree, @Robert McClure

view this post on Zulip Grahame Grieve (Jul 07 2016 at 19:45):

transitivity is not the whole question. We can certainly state the transitivity is implied and can be taken for granted. but we can't say that subsumption can be taken for granted

view this post on Zulip Robert McClure (Jul 07 2016 at 20:59):

@Grahame Grieve Ok, I'm dense. How do you see them as different? Are you saying that subsumption is a more general "grouped by" operation and transitive is limited to "Is-A"? I'm assuming that is not what you mean because if subsumption = "grouped by” then subsumption means having a hierarchy. So help me understand how you separate defining a heriearchy from subsumption in a hierarchy?

view this post on Zulip Rob Hausam (Jul 07 2016 at 21:01):

@Grahame Grieve can we state that both transitivity and subsumption are the implied default - unless stated otherwise?
I'm not immediately thinking of cases where that wouldn't work - but if there are some, it would be good to bring them forward

view this post on Zulip Rob Hausam (Jul 07 2016 at 21:08):

@Robert McClure it actually would be the other way around - for example, part-of would be transitive, but it is not subsumption

view this post on Zulip Grahame Grieve (Jul 07 2016 at 21:09):

yes, the other way around. heirarchy is implicitly transitive, but a given heirarchy is not always subsumptive

view this post on Zulip Eric Haas (Jul 07 2016 at 22:36):

Great discussion too bad is 'buried' in hapi-land ( no offense to James - I'm sure everyone is already subscribed) can it be moved to conformance or implementers?

view this post on Zulip Grahame Grieve (Jul 07 2016 at 23:51):

yeah this ended up as general dsiscussion. Actually, it's really time we had a terminology track - terminology is ending up split between 4 tracks....

view this post on Zulip Erich Schulz (Jul 09 2016 at 09:34):

@Grahame Grieve how would that be different from the existing ontology track? (genuine question)

view this post on Zulip Grahame Grieve (Jul 09 2016 at 11:38):

well, within the health community we differentiate between a terminology and an ontology, though the line is blurred. A terminology - and terminology use and services - is a list of codes with definitions. An ontology is a graph of concepts that tries to assign underlying meaning to the content (blurry, as I said)

view this post on Zulip Grahame Grieve (Jul 09 2016 at 11:39):

in FHIR< terminology means code system, value set, + the service API, where as ontology usually means RDF representation + validation + reasoning against external ontologies and services

view this post on Zulip Erich Schulz (Jul 09 2016 at 11:43):

thanks @Grahame Grieve - I'd be seeing more benefit from converging these streams rather then diverging tbh

view this post on Zulip Erich Schulz (Jul 09 2016 at 11:44):

at the end of the day its all about giving ideas identifiers to support agregation and filtering, and on which knowledge and relationship can be hung...

view this post on Zulip Grahame Grieve (Jul 09 2016 at 11:44):

well, that's the grounds for the current arrangement, but that only works if everybody buys in. And multiple people have said to me that following terminology is a problem because it appears in multiple places. Remember: all models are wrong. but some are useful

view this post on Zulip Erich Schulz (Jul 09 2016 at 11:51):

i guess there is always a distinction between the abstract and concrete...

view this post on Zulip Eric Haas (Jul 09 2016 at 14:50):

+1 for separation. Is simpler that way.

view this post on Zulip Rob Hausam (Jul 10 2016 at 12:50):

+1 for adding terminology stream
I think it needs it's own place - seems that pretty much everyone agrees that it's too fragmented currently
and practically, the discussions in ontology have been, as Grahame said, more about RDF and reasoning, so I would vote for keeping that as is, at least for now

view this post on Zulip Erich Schulz (Jul 10 2016 at 13:03):

well I'm still looking for an answer to the blah.blah.blah problem so if splitting helps concentrate the collective brain on that it can only be a good thing... i guess

view this post on Zulip Robert McClure (Jul 12 2016 at 15:03):

@Rob Hausam One of us in confused. Subsumption is by definition transitive in my book. A->B, B->C, transitive says A->C

view this post on Zulip Rob Hausam (Jul 12 2016 at 20:36):

I didn't say otherwise, @Robert McClure - what I did say was that transitive does not necessarily imply subsumption. I didn't say anything either way about subsumption being transitive, but I agree with you that it is.


Last updated: Apr 12 2022 at 19:14 UTC