Stream: ontology
Topic: FHIR Meeting Report – Montreal, May 2016
Renato Iannella (May 23 2016 at 00:31):
In this report (https://onfhir.hl7.org/2016/05/20/fhir-meeting-report-montreal-may-2016/) it states that STU3 will plan to address "Introduction of RDF, tied to an ontological base".
I'm assuming the latter "ontological base" is the RIM ? (as expressed in the RIM.ttl document)
Grahame Grieve (May 23 2016 at 00:52):
more generally, i meant, there's an RDF format, and it will be supported by fhir.ttl which provides a set of definitions that allow you to reason with the turtle format and rim.ttl which provides some ontology, and that this will be base to build further ontology bindings on
Grahame Grieve (May 23 2016 at 00:53):
note, though, that actually building ontology bindings is hard work - the ontologies are very unrelated to what FHIR is trying to do. Surprisingly so, to me
Grahame Grieve (May 23 2016 at 00:53):
@Lloyd McKenzie - all that you wrote doens't address the question.
Grahame Grieve (May 23 2016 at 00:53):
take this example:
Grahame Grieve (May 23 2016 at 00:54):
fhir:Observation.code [
fhir:CodeableConcept.coding [
fhir:index 0;
fhir:concept loinc:29463-7;
fhir:Coding.system [ fhir:value "http://loinc.org" ];
fhir:Coding.code [ fhir:value "29463-7" ];
fhir:Coding.display [ fhir:value "Body Weight" ]
], [
fhir:index 1;
fhir:concept loinc:3141-9;
fhir:Coding.system [ fhir:value "http://loinc.org" ];
fhir:Coding.code [ fhir:value "3141-9" ];
fhir:Coding.display [ fhir:value "Body weight Measured" ]
], [
fhir:index 2;
fhir:concept sct:27113001;
fhir:Coding.system [ fhir:value "http://snomed.info/sct" ];
fhir:Coding.code [ fhir:value "27113001" ];
fhir:Coding.display [ fhir:value "Body weight" ]
], [
fhir:index 3;
fhir:Coding.system [ fhir:value "http://acme.org/devices/clinical-codes" ];
fhir:Coding.code [ fhir:value "body-weight" ];
fhir:Coding.display [ fhir:value "Body Weight" ]
]
];
Grahame Grieve (May 23 2016 at 00:56):
you say: "The concept absolutely *must* exist at the CodeableConcept level - because that's the semantic." - but no, the semantic is that the codings have the links to the terminologies. that they aggregate meaning on the CodeableConcept is something we derive. And so can a reasoner
Lloyd McKenzie (May 23 2016 at 01:00):
Yes, the codings have links to the terminologies. But, for a CodeableConcept, the *meaning* of the code accrues at the level of the CodeableConcept. The Observation.code is the body weight. That's where the reasoning needs to happen. And more specifically, the concept expressed by the code is the intersection of all of the concepts represented by the codings
Grahame Grieve (May 23 2016 at 01:20):
all that is true, but not addressing the point
Lloyd McKenzie (May 23 2016 at 01:29):
What's the point then? The concept shouldn't be declared on the instances because the conversion tool can't possibly know all the terminologies, and for most servers, loading all of SNOMED just to convert data from XML to RDF is too heavy anyhow. When the concept is introduced, it's going to need to be introduced as a characteristic of Observation.code - where the reasoning needs to happen.
Grahame Grieve (May 23 2016 at 01:30):
at least, we're getting to the core! yay
Grahame Grieve (May 23 2016 at 01:31):
what does it matter where it's declared if the conversion tool doesn't know the terminologies?
Grahame Grieve (May 23 2016 at 01:31):
and what does the size of snomed have to do whith where it's introduced?
Lloyd McKenzie (May 23 2016 at 01:36):
We want to make it easy to convert between XML, JSON and RDF. RDF should be "just another serialization" handled by the reference implementations. And we'd like to make generating it as low overhead as possible so that most servers will support it.
Grahame Grieve (May 23 2016 at 01:37):
yep. we do indeed. so what's your point?
Lloyd McKenzie (May 23 2016 at 01:37):
Expecting servers to include the "concept" element - which requires having copies of the (sometimes large) terminologies and intricate knowledge of how they work is not conducive to that end.
Grahame Grieve (May 23 2016 at 01:37):
... so?
Lloyd McKenzie (May 23 2016 at 01:38):
So, we shouldn't be doing it by default, nor showing it as expected practice in the examples or documentation. We can note it as an optional alternative.
Grahame Grieve (May 23 2016 at 01:39):
doing what?
Grahame Grieve (May 23 2016 at 01:50):
your argument here is curiously unfocused. The specific question is that the committee decided that fhir:concept only goes on Coding, not on CodeableConcept. You're passionately opposed to ... something.... but I'm not sure what it is you're opposed to
Lloyd McKenzie (May 23 2016 at 01:54):
I'm making several arguments:
1. fhir:concept should not appear in the examples in the spec except as a special case because it's not something any implementer can count on being in the RDF
2. fhir:concept needs to appear on the structure in the instance that corresponds to the concept. In the case of a CodeableConcept, that's at the CodeableConcept level. It's the Observation.code that's being declared to be "body weight" - that's where the reasoning needs to happen. The reasoning happens at the attribute level. The whole purpose of the root level of CodeableConcept is to represent the concept.
Grahame Grieve (May 23 2016 at 01:56):
#1 I don't see why we shouldn't add it in the examples so implementers can see where it goes.
#2. You haven't begun to make a coherent case for this. As you said, the codings have the link to the terminology, and the meaning accrues to the CodeableConcept. So that's what the RDF should say - fhir:concept on the Coding, the reasoner infers it on the CodeableConcept
Lloyd McKenzie (May 23 2016 at 02:00):
#1 - add it in one example that deals with it explicitly. But adding it everywhere is going to lead people to think they can/should expect it, but they can't.
Lloyd McKenzie (May 23 2016 at 02:01):
The reasoner needs to infer it in the first place. So why infer it somewhere other than where it needs to be?
Lloyd McKenzie (May 23 2016 at 02:02):
If we're going to go through the work of including it in the instance so it doesn't have to be inferred, why not put it where it needs to be?
Grahame Grieve (May 23 2016 at 02:08):
but see, that's what I think - put it where it makes sense. There's some ontological confusion here, perhaps. As for the example, it's really trivial, if you know the syntax transform, to put it everywhere. really, trivial. I don't see why it wouldn't be expected for the common public terminologies
Lloyd McKenzie (May 23 2016 at 02:13):
It makes sense to be where you have to reason. And when you reason, you're reasoning on Observation.code, not one of the codings. All of the concepts are in play simultaneously.
Lloyd McKenzie (May 23 2016 at 02:14):
It shouldn't be expected for the common public terminologies because that presumes that the converters are aware of the rules for all of the terminologies. Why would we require injection of extra knowledge (knowledge that will continuously be evolving) into what should be a simple wire format transformation? If we put it in the converters, that's just going to produce an ongoing maintenance issue.
Grahame Grieve (May 23 2016 at 02:14):
you keep saying that. But there's an underlying assumption: you can't reason at that level if the fhir:concept is on the Coding, not the CodeableConcept. I believe that's what the committee disagreed with. so merely hammering away on that point is not going to move the discussion along
Grahame Grieve (May 23 2016 at 02:16):
"knowledge that will continuously be evolving" - well,we have already been asked to fix the way it works for SCT and loinc.
Lloyd McKenzie (May 23 2016 at 02:22):
If you can infer from Coding to CodeableConcept, then you can reason either way. But if you need to do the reasoning at the COdeableConcept level, then why would you populate it somewhere else.
Grahame Grieve (May 23 2016 at 02:22):
so that you can reason from it at the Coding level. Cause you can infer up, but not down
Lloyd McKenzie (May 23 2016 at 02:22):
And SNOMED and LOINC are a small set of the terminologies people will want supported. Everyone will ask us to add one more. Or change to support how they do it in a new version or whatever.
Grahame Grieve (May 23 2016 at 02:23):
so, that's what interoperability means.
Lloyd McKenzie (May 23 2016 at 02:23):
You can infer it in the first place just from the data - given the code & system, you can infer it at either level. But if we're going to put it in the instance, put it where it needs to be.
Lloyd McKenzie (May 23 2016 at 02:24):
But adding supplemental data that's necessary for specific processing should be done by post-processing by those who know what they actually need, not by us (and everyone else) continuously needing to update what's supposed to be a simple wire format conversion.
Lloyd McKenzie (May 23 2016 at 02:24):
It's about separation of concerns.
Lloyd McKenzie (May 23 2016 at 02:25):
Keep things simple for those who don't care about RDF, but are willing to at least expose it if we keep it low effort. Put the complexity of managing all the differences between URIs for different code systems in the pre-processing software for those systems that actually care about it and need it.
Grahame Grieve (May 23 2016 at 02:26):
to which you tie: 'and refuse to offer those systems any standardization'
Lloyd McKenzie (May 23 2016 at 02:29):
? We have standardized the property name to use. Each terminology is responsible for standardizing the URL. (We can publish the ones we know of in either the CodeSystem or NamingSystem). Providing conversion code != standardization.
Grahame Grieve (May 23 2016 at 02:29):
you just said we shouldn't. I can't keep up with you today. You keep changing your mind
Grahame Grieve (May 23 2016 at 02:30):
"You can infer it in the first place just from the data - given the code & system, you can infer it at either level. But if we're going to put it in the instance, put it where it needs to be" - I can see we're just not going to agree. I tried. You can take it up with committee. But my opinion is that you're not making sense. and just trying to drown the actual point with too much noise.
Lloyd McKenzie (May 23 2016 at 02:35):
We *should* standardize the name of the property. We *should* include a subsection of the spec that declares that and shows where it goes. We *shouldn't* put it in the specification anywhere other than that spot or in the example instances we generate. That ensures that the conversion process between XML/JSON/RDF is simple and low-maintenance and also ensures implementers don't come to rely on something that won't necessarily be supported.
Lloyd McKenzie (May 23 2016 at 02:35):
Is that sufficiently clear?
Grahame Grieve (May 23 2016 at 02:39):
we've also been asked to say what the right representation of the fhir:concept predicate is for SCT and LOINC as well, based on their published ontologies. I don't see why we shouldn't do that
Lloyd McKenzie (May 23 2016 at 02:40):
Sure - happy to include that on the terminology page for each of those code systems
Lloyd McKenzie (May 23 2016 at 02:40):
And in general, I'd expect it to be an optional descriptive property or extension on either NamingSystem or CodeSystem.
Grahame Grieve (May 23 2016 at 02:41):
don't know that it can be computable
Lloyd McKenzie (May 23 2016 at 02:48):
It can't. That why I said "descriptive" - it'd be a textual explanation
Grahame Grieve (May 23 2016 at 02:58):
good. So the only point of contention is the original one! you can take that up with committee.
Lloyd McKenzie (May 23 2016 at 02:59):
Do you agree that reasoners will need the concept at the attribute level in all cases?
Grahame Grieve (May 23 2016 at 03:00):
nup. I don't agree. It belongs on the Coding, where it can inferred up if appropriate.
Grahame Grieve (May 23 2016 at 03:00):
you probably have to infer it up 2 levels, actually, in general, to the resource itself
Erich Schulz (May 23 2016 at 06:09):
gad
Erich Schulz (May 23 2016 at 06:16):
bit lost...
Erich Schulz (May 23 2016 at 06:17):
instance of what?
Lloyd McKenzie (May 23 2016 at 06:19):
Inferring two levels up can't work in general. In theory you can with the .code elements, but that doesn't apply to everything else. You can't say that the Observation "is a" Observation.value or "is a" Observation.site. And it's tenuous to say the Observation "is a" Observation.code. So pushing the concepts anywhere other than the attribute is generally inappropriate. While it being on the Coding as well isn't necessarily harmful, it's not helpful unless the attribute has a type of Coding. That's the only time where it makes sense to reason on a concept at the Coding level.
Erich Schulz (May 23 2016 at 06:21):
if it helps @Lloyd McKenzie I can say I am completely not following you either
Erich Schulz (May 23 2016 at 06:22):
sorry I'm a complete FHIR noob - but I get semantic networks and relational databases...
Erich Schulz (May 23 2016 at 06:24):
perhaps some examples could help?
Erich Schulz (May 23 2016 at 06:25):
this smell a bit like one of those issues that arise when then notions of "is a" and "part of" are being conflated
Erich Schulz (May 23 2016 at 06:26):
because if you have a pure taxonomy or meronomy you can infer up and down as many levels as you like...
Lloyd McKenzie (May 23 2016 at 06:30):
@Erich Schulz In this case, we definitely have a "part of" relationship, not an "is a" relationship. Specifically, Observation.code is part of Observation and Coding is part of CodeableConcept. So we can't, in general, infer that the Concept implied at one level exists at a higher level. Things are a little bit different though for Coding and CodeableConcept. You can argue that the Concept holds for the Coding as well as the CodeableConcept, but it's at the CodeableConcept level where the concept is relevant. You want to test "is the Observation.code a body weight?", not "Does the Observation.code contain any codings that are body weights".
Erich Schulz (May 23 2016 at 06:35):
mmm these are all a bit nested...
Erich Schulz (May 23 2016 at 06:38):
i'm just making screen shots of the three levels...
Erich Schulz (May 23 2016 at 06:39):
memory like seive
Erich Schulz (May 23 2016 at 06:42):
ok
Erich Schulz (May 23 2016 at 06:43):
ok so I get your comment at 4:30 now
Erich Schulz (May 23 2016 at 06:44):
so what's the issue then?
Erich Schulz (May 23 2016 at 06:45):
(picture here btw https://docs.google.com/document/d/1SJrjKq4ljfkDpNDtRxI4UHMMxRwTq6LZGMXU63Fsoc4/edit?usp=sharing)
Erich Schulz (May 23 2016 at 06:54):
it seems to me that the meaning of observation.code, observation.code.codingand (observation.code.coding.system, observation.code.coding.version and observation.code.coding.code) *should* be the same
Erich Schulz (May 23 2016 at 06:54):
(if Lloyd's earlier comments about multiple coding being synonyms is correct)
Erich Schulz (May 23 2016 at 06:55):
but the real meaning is expressed (potential in several forms) at the level of observation.code.coding
Erich Schulz (May 23 2016 at 06:59):
the existance of sobservation.codes with just atextattribute and nocoding` is a bit of speed-bump tho...
Erich Schulz (May 23 2016 at 06:59):
or existance where coding and text have divergant means (have to love users)
Renato Iannella (May 23 2016 at 07:00):
But @Lloyd McKenzie first you said that you can't infer partOf relationships, then you said you could. Now I am confused ;-)
Erich Schulz (May 23 2016 at 07:03):
sometimes you can @Renato Iannella
Erich Schulz (May 23 2016 at 07:04):
"does this person have an arm injury"?
Erich Schulz (May 23 2016 at 07:04):
finger is part of arm, therefore fracture finger is arm injury...
Erich Schulz (May 23 2016 at 07:06):
the thing about this topic is that codeableconcept defines a set of ways that should have the same meaning...
Erich Schulz (May 23 2016 at 07:06):
so in a way the parts should all equal the whole...
Erich Schulz (May 23 2016 at 07:08):
but @Lloyd McKenzie i'm just reading "The different codings may have slightly different granularity due to the differences in the definitions of the underlying codes. " from here
Renato Iannella (May 23 2016 at 07:09):
CodeableConcept is the "type-system" for FHIR Resources?
Erich Schulz (May 23 2016 at 07:10):
it is a FHIR data type used by FHIR resources
Erich Schulz (May 23 2016 at 07:12):
but i'm still not sure what Llyod and Grahame's debate was about
Renato Iannella (May 23 2016 at 07:20):
Then...*semantically* you want to infer (or express) that the *Observation* is a "body weight" ?? (not that part of the Observation is a "body weight")
Grahame Grieve (May 23 2016 at 09:57):
right. Lloyd is confusing is-a with reasoning, so far as I can tell.
Grahame Grieve (May 23 2016 at 09:58):
Observation.code is a CodeableConcept - so it can have one more codes, or just text. Obviously, it would be greatly easier to reason with if it was just a code, instead of the messy loose structure that is CodeableConcept. But we know from long hard experience that life cannot be so simple in many cases
Grahame Grieve (May 23 2016 at 09:59):
so
Observation has-defining-code Observation.code
Observation.code has-parts Observation.code.coding
where the coding is the actual link to the terminology. (I nearly wrote ontology there...)
Grahame Grieve (May 23 2016 at 09:59):
we've agreed that one of one of the RDF properties of Coding is fhir:concept, which is a URI that links to the ontological representation of the terminology - if that is defined.
Grahame Grieve (May 23 2016 at 10:02):
we debated making that relationship rdfs:type, but we say that it is not an rdfs:type relationship, at least not generically. A processor may find it useful to say that a fhir:concept relationship to a particular ontology is the same as an rdfs:type relationship, and elevate it accordingly, but we do not forcefully claim that this is so in all cases
Grahame Grieve (May 23 2016 at 10:04):
Lloyd is arguing that because you have to reason about meaning at the Observation.code level, you must therefore explicitly assert the fhir:concept links at that level, but I argue that this is wrong - you should assert them on the coding, where they are actually established, and then a reasoner must understand the relationship between the CodeableConcept and it's parts and draw it's own inferences
Grahame Grieve (May 23 2016 at 10:04):
Note that Lloyd and are switched around from our default positions - he's arguing for something that makes it easier for implementers, and I'm arguing for the harder but more correct option. In this, I do this because RDF is about correctness, not ease.
Grahame Grieve (May 23 2016 at 10:08):
Lloyd has also argued that reasoners can't pull the relationship up from the parts to the container. That doesn't make sense to me, though the only 'reasoner' I work with is sparql. It's just another statement for me. But I argue that you can't reason with just the Observation.code anyway. You have to cross-consider the status at least. And possibly category, and probably dataAbsentReason, and maybe Observation.component.code
Lloyd McKenzie (May 23 2016 at 13:24):
There's no notion of "has-defining-code" in the model, so we can't distinguish between defining codes and all of the other coded attributes. Unless and until we do that, we can't make an assertion that "Observation 'is a' Body weight". @Grahame Grieve argues for asserting the knowledge at the place in the instance where it's inferred as opposed to the place where it's needed for reasoning. I don't understand why that's "more correct". From a correctness perspective, the semantic of "Observation.code 'is a' Body weight" is absolutely true according to the semantics of how CodeableConcept is intended to work. In the past, I've expressed concern not about the ability of reasoners to pull the semantic up, but rather to pull it up only when needed and not when not needed. Sometimes the "concept" needs to live at the Coding level because there's no parent CodeableConcept. Sometimes the "concept" needs to propagate up to the parent because there is a CodeableConcept - and the concept is going to be needed on the type that actually represents the notion of "concept"
Grahame Grieve (May 23 2016 at 13:54):
woah: the solution to 'rather to pull it up only when needed and not when not needed' is ... to push it up always!
Grahame Grieve (May 23 2016 at 13:56):
but i said I wasn't going to pursue this anymore, so I won't. Argue with the committee.
Rob Hausam (May 23 2016 at 16:21):
Ultimately, I think the "concept" (in the broad sense, not necessarily fhir:concept) needs to be associated with (or "live at") the element level - the coded data type, whether it's CodeableConcept, Coding or code, is simply a means of making that association, via the binding. It's actually at the element level that the reasoning should occur, but associating the "concept" at that level can be done (at least theoretically) by reasoning from the representation in the data type instance. It will be really "interesting" when we try to do that from a CodeableConcept with multiple Codings from different terminologies, that are supposed to be representing the same "concept", but are doing it with "slightly different granularity", as the spec states and Erich noted. If the codings are actually in conflict (not sure if "the intersection of all of the concepts represented by the codings" is the correct notion here?), then ideally the reasoner would be able to detect the error (i.e. the class is unsatisfiable).
Erich Schulz (May 24 2016 at 00:28):
ok so this debate is limited to how to tie observations to RDF?
Erich Schulz (May 24 2016 at 00:29):
or probably more accurately CodeableConcept to RDF?
Erich Schulz (May 24 2016 at 00:33):
in that case I would observe that I could write all I know of RDF on back of coffee receipt :-)
Erich Schulz (May 24 2016 at 00:35):
it would seem to me that the "cleanest" way to specify a link, however, would be to do it *once* at the CodeableConcept level - eg Observation.code
Erich Schulz (May 24 2016 at 00:36):
in general health structures are complex and if any reasoner cant cope with that then perhaps they shouldn't be
Renato Iannella (May 24 2016 at 01:07):
@Erich Schulz Or even FHIR "Resource" to RDF
Renato Iannella (May 24 2016 at 01:18):
If we look at another Resource, say Specimen, it has a type property for the "kind of material" which is a CodeableConcept.
In the RDF world, you would model this using rdf:type. That is, an Specimen individual would use a terminology URI as its rdf:type. Reasoners then do not have to use an arbitrary property (in this case "type", others "code", and "category"..) to make any inferences.
Erich Schulz (May 24 2016 at 01:28):
i'm well out of experience zone here...
Erich Schulz (May 24 2016 at 01:29):
but how much is RDF used for complex JSON feeds?
Erich Schulz (May 24 2016 at 01:29):
and is it even a relevant technology here?
Erich Schulz (May 24 2016 at 01:31):
what FHIR is modelling is far more complex than booking a hotel or hiring a car...
Grahame Grieve (May 24 2016 at 01:41):
Renato, I do not think it's ever so simple as this. yes, Specimen has a property type which is of type CodeableConcept. but given the definition of rdf:type:
Grahame Grieve (May 24 2016 at 01:41):
rdf:type is an instance of rdf:Property that is used to state that a resource is an instance of a class
Grahame Grieve (May 24 2016 at 01:43):
it's wrong to state that "a specimen with a type of 'urine'" is "an instance of the class of urine". there are several respects in which I think that's not an accurate statement
Grahame Grieve (May 24 2016 at 01:48):
I think it's appropriate to make reasoners work harder to grapple with what is really going on rather than to present them with a simplified - and wrong - view of the world which is only useful given a particular set of assumptions
Renato Iannella (May 24 2016 at 01:54):
@Grahame Grieve happy to hear why you think this is not accurate: "a specimen with a type of 'urine'" is "an instance of the class of urine".
Grahame Grieve (May 24 2016 at 01:57):
first of all there's the difference between the record and the thing. The resource is the record of the specimen, not the specimen itself. Then the type might change without changing the actual specimen - a correction, say. Secondly, there's the potential gap between the definition of 'urine' and the thing that is the specimen that once was urine. Thirdly, what is the 'type' of a specimen? is it the physical type, or is it the way that it fits into the process in which it's being used? Further, with timed specimen, is it a type of time? Finally, the real question is, in your frame of reference, what are classes, and what then are instance of those classes. I don't believe that the standard terminologies for specimen type - which are classifications, actually - are the grounds on which you can make such statements with any confidence.
Grahame Grieve (May 24 2016 at 01:57):
Hence, I believe that we should leave rdf:type as an interpretation based on context and specific decisions
Renato Iannella (May 24 2016 at 04:36):
Good to add some Existentialism into the discussion 
Grahame Grieve (May 24 2016 at 05:36):
I'll take that as a lack of disagreement to my point, I think.
Renato Iannella (May 24 2016 at 07:03):
Inference correct 
Last updated: Apr 12 2022 at 19:14 UTC
