HCLS -- 08 Apr 2014

Tony Mallia's FHIR RDF

<ericP> scribenick: ericP

<dbooth_> Tony: I attend HL7 meetings, focus on FHIR. Previous specs were difficult. Ad hoc approach to forming structures in FHIR.

<scribe> scribenick: dbooth_

UNKNOWN_SPEAKER: Looking at representation of FHIR in RDF and OWL, and how to represent SNOMED-CT in RDF and OWL, coming out of ITSDU.

Tony: Info divided into resources, represented as XML or JSON. Resources can also be contained in a container.
... Defined about 50 resources so far. 100 more in the pipeline.
... There are also XML schemas that define them.
... There's an instance of a resource, then saying what it means. Approach is to separate record structure from FHIR instance data from meaning terminologies.
... The record structure is reasonably static, whereas instance data changes quickly.

Claude: Maybe add a fourth circle: Extended FHIR structure, because of extension mechanism. Could identify an ont that extends FHIR.

Tony: The danger is that everyone will define their own profile, but they need to be shared to gain interop.
... Criteria for interop has not been established. a particular concept should have a singular invariant semantic pathh through the record, but we found that every user put a particular concept in the record strcuture.
... But if they're in different parts of thte record then you have to map. Its an issue of governance of the profiles. FHIR people are expecting this to be done at the realm level -- a US presence to govern profiles.

Eric: This shows up in CCDA guidelines.

Tony: Eachpartner does it differently.
... Where is the path that gets to that semantic element? We're looking at how to process these messages when there 6 different paths to a particular data item.
... It's a background on where do we go on converging ontologies. It's a huge issues.
... Example is alergy to a bee sting, using ontograph in protege.
... The upper level are the terminology, the middle with diamonds are facts, and the bottom are FHIR record strcuture.
... I haven't shown all of the term hierarchy.
... Terms in SNOMED are classes, and therefore an instance is amember of that class.
... An instance may be a member of many classes, which differs from most modeling techniques (multiple inheritance).
... Allows you to put an instance into any class.
... Interesting thing: FHIR criticality is closed in FHIR, rather than a codable concept. But because you can see these ontologies combined when imported, FHIR imports SNOMED, and that lets me say that FHIR criticality is equivalent to SNOMED: fhir:CriticalityMedium <-> sct:Moderate

Claude: YOu imported SNOMED ont, and then related it to FHIR concepts. Record alergy is an instance?

Tony: Yes. the question: do i declare it as an axiom or should the reasoner infer it?
... Allergy to substance is a precoord term.
... Not sure whether allergy to substance was inferred or asserted.

Claude: Here you have an allergy instance, related to a bee sting substance. Because of this triple, the combination means that this is an instance of alergy substance rather than medication.

Tony: Yes. I captured this image before I started playing with inferences of this type. Allergic Disposition is in SNOMED, and its equivalent to Allergy.
... We actually got an inference working to show that.
... Because the allergy has an object property pointing to the bee sting, you can determine the causative agent and infer that it's an allergy to a substance.
... Adverse reaction on the right maps to a bee sting with anaphylaxis.

Claude: You'd have to import all the terminologies?

Tony: All within scope, yes.
... The record ont imports the FHIR record, which imports the SNOMED ont.
... I'm using hermit reasoner. Haven't got snorocket to work yet.
... Here's an XML-OWL instance example, conveying the OWL info as an extension to FHIR, so that you could pull the record and pull the OWL as well.
... I also looked at pre-coord term, allergy to substance.
... When declared it becomes a subclass of allergic disposition and not a substance.
... I'm trying to determine an endpoint: how would we like to see this in the final environment?

Claude: allergy to substance is really related to a little subgraph of something with a causative agent. You added this?

Tony: Yes, this work is ongoing in ITSDU and in the VA. Wanted to see how you would articulate it. "allergy to substance" is not a substance, but it is related to one.

Claude: Suppose SNOMED didn't do this, but you wanted to do it. And you provide an extension that defines these relationships.

Tony: There's a whole group looking at that.
... What do these things really mean?

<ericP> sct:AllergyToSubstance .

<ericP> sct:AllergicDisposition

<ericP> rdfs:subClassOf

<ericP> sct:AllergicDisposition,

<ericP> [ owl:onProperty sct:causativeAgent ;

<ericP> owl:someValuesFrom sct:Substance ] .

Tony: Convergence: how to converge good ont?
... want at least comparison of ont, with a convergence.

Josh: As far as definitions of allergy to substance, they really do say those things, like ithas a causative agent, etc.
... It's in a DL, and one of the relations says that kind of thing.
... One of the best tools is the NLM's browser.

David: Who is looking at that?

<ericP> dbooth_: what group is looking at defining these relationships?

Tony: In the VA. There's a group managing terminologies. Keith Campbell. Rafael is connected with them.
... The individ member of the pre-coord term wiill be members of the post-coord terms.
... We brought the facts into the combined ontology.
... These object property names need to be more closely examined. They're locally declared in FHIR, so they won't be the same across differentn resources.

David: Need different names if the semantics are different.

Claude: You say instance allegy_1 is an instance of a Confirmed class?

Tony: discussion is whether you treat types as properties or classes.
... I've done them as classes.
... I think that was the difference from your presentation.
... What's interesting, the sensitivity to substance is inferred to have a relationship to causative agent, slightly indirect.
... In theory, I should be able to determine that this is actually an alergy to a substance, but I'm not quite there yet.
... Yellow shows the inferred concepts.
... If you've imported this, the extended and inferred ont will contain these, and you could filter it.
... I expect you to bring the inferences into the ont.
... Returning to the profile and extension, I started by mixing them, but I realized we'd have a bad problem with the users. People would only want to see FHIR or DL but not both.
... An extension appears in almost every resource. So we'll keep the DL in a language in a way that it won't have to changed. OWL/XML could be used in the XML space -- FHIR resource could therefore carry its OWL representation that way.
... It could be attached either pre- or post exchange if the recipient has asked for a profile that requires a DL extension.
... The recipient could then view either of them.

Claude: If you used a FHIR ont then you might use many ont for each resource, right?

Tony: Yes, do you break it into multiple ont and have a separate for each?
... But you could have one. It's the object properties, since they're locally declared, that you have to keep separate.

Claude: In the approach i took I was trying to come up with a generalized ont that alilgned with Josh's work -- a set of deterministic rules to generate this ont and align with the RDF instances.
... In your case, you define a set of classes in OWL that are very geared toward the semantics of each resoruce -- not nearly as generic. It carries more local semantics for each resource. So it would be difficult to generate an ont for each resource definition. Right?

Tony: Right, I haven't assumed that this could be auto generated. I would go to the XML Schemas and gen a framework and then tweak it.

Josh: In my FHIR build process, there are spreadsheets that produces profile instances and XML Schemas. Schema expressivity is less than the profiles. I use the spreadsheets.

Claude: To know how to create these classes, wouldn't it be difficult to know what they should be?

Tony: They're right in the XML Schema, hard coded. Value sets are hard coded, so any profile changes and extensions won't change them.
... Codes are enumerations, and they become classes in teh way I model them, with the valueset being the parent class.

Claude: When I view sensitivity status value set, and a value Confirmed, I would think of an allergy as a restriction class that has a value of Confirmed.
... But you can say Confirmed is a class, and have a restriction class.

Tony: You could do that, so that when you import an instance of FHIR, a data property Confirmed could make it a member of a Confirmed class.
... Both styles could be declared, and could have relations between them.

Eric: Things in a valueset are objects of a property, but they look like individuals. But we want to give them subsumption, so we want them to be classes also. So this punning approach gives both.

Tony: You're saying that Confirmed is a state. Type or data? I think you can do both.

David: In the larger picture, both styles will inevitably occur in different ontologies, so we need to be able to relate them and map between them.

Tony: The ultimate ont is the high level ont that everything maps to.

Eric: UFO?

David: Cyc?
... +1

Eric: I'm not convinced there's much ROI in doing that. Suspicion is that the value is that you get a little bit of debugging out of it, but all of the cool stuff we'll want for CDS will be at the level you're working at right now.

Tony: Exciting is the ability to relate them together, not to require a big unified ont.

Eric: The downside of our infra is that if you run inferences and come up with conflict, people are told to throw up their hands and give up. Some say to partition it, but our specs don't yet cover that.

David: Cyc has a lot of experience with partitioning like that.

Eric: We're probably learning things redundantly. Tighter commnication would be helpful. How to work around the same table without being too claustrophobic?

Tony: Not sure I have an answer. Community of interest like this is good.

Eric: An informal morning chat helps.
... I'd like to go through Tony's instance data and draw on it. Maybe good for Tony to look at FDA stuff. Maybe wiki, google+, etc.

Tony: Just choose one. :)
... Not sure I have an answer. Community of interest like this is good.

David: Logged IRC would help, for coming in later.

Eric: How about SWIG? If we become too much of a pain we can go elsewhere.

<scribe> ACTION: Eric to install a logger for #hcls channel [recorded in http://www.w3.org/2014/04/08-hcls-minutes.html#action01]

Eric, what part of the wiki do you suggest as a starting point? http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability

Or maybe http://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability/FHIR

Decision: We'll use #hcls and Eric will add a logger. Also use the HCLS wiki.

- DRAFT -

HCLS

08 Apr 2014

Attendees

Contents

Tony Mallia's FHIR RDF

Summary of Action Items

Scribe.perl diagnostic output