See also: IRC log
<ericP> 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.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/yest/yet/ Succeeded: s|Topic: /me wonders how to tell IRC that dbooth is the same person as me|| Found ScribeNick: ericP Found ScribeNick: dbooth_ Inferring Scribes: ericP, dbooth_ Scribes: ericP, dbooth_ ScribeNicks: ericP, dbooth_ Present: Claude DBooth Josh JoshM Kerstin_Forsberg Mike_Denny Neda TallTed Tony egonw ericP joshmandel Got date from IRC log name: 08 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/08-hcls-minutes.html People with action items: eric[End of scribe.perl diagnostic output]