See also: IRC log
Ingeborg: Looked at bioportal and UMLS and could not find any work on OMOP, but found SALUS.
... Looks like a project for defining common data elements for post-market surveillance
... Building semantic metadata repository. Downloaded a paper on it. Anyone familiar with their work?
Eric: i know them well. They participated for a little well.
... They'ave been doing post-market surveillance. their work involved a
lot of term mapping. they were trying to figure out the right way to
write that "x is the same as y" , "and if x is the same as y, and y is
the same as z, are x and z the same? maybe optimistic".
Mike: You spoke about Salus in July 15, 2013
<Mike> http://www.w3.org/2013/07/12-hcls-minutes
<ericP> https://www.w3.org/wiki/HCLS/ClinicalObservationsInteroperability
tony: Might this have moved to ITSDU?
eric: I don't think so. They had some EU grants. I don't think their work woudl have coincided with the terminology work.
David: They reported the ICD-11 work using web protege as successful.
ingeborg: Jan 2014 paper on Salus talked about Salus common information model, and seems to have an RDF representatino.
... Not sure how to determine whether someone else's semantic work will work for my needs.
tony: curious whether there's movement toward using RDF-based EHRs. Triplestore might be a nice way to handle an EHR.
eric: There's stuff close with the FDA now. Submitting clinical trial data in RDF.
... I don't know if the backing store can be RDF yet, for triplestore performance.
tony: federated stores also.
eric: we could use MIMIC2 database from MIT and Harvard, to see what happens if you use an RDF EHR and try to do useful queries? Or only use RDF for an interface? We don't have to say to use RDF under the covers, but to use it for interchange.
tony: wondering how many ont and how the importing works. you can define an ont for the structure with some governance, and ont for the instances also. how do you manage them?
eric: Or they overlap.
tony: Tbox gives the types, both structural and semantic. Interested to see how individual data would be organized. separate ontologies?
eric: would be equiv to SPARQL endpoint for a corpus of patients. tbox axioms in the patient data?
tony: An instance of Observation related to this named
patient. Do you declare this instance to be a member of an ont, so it
has a prefix? How do you organize your prefixes, and therefore your
ontologies?
... Your instance ontologies need to import the type ontologies. THinking about the strucutres about how these ont may work.
eric: EHR for CR (Clinical Records), and EU project, is looking at using RDF for this.
... FHIR could be viewed as RDF.
david: some small-scale projects are experimenting with it. also the work that claude, neda and I are doing for the DoD is taking instance data from 30-year old MUMPS based system and representing in RDF for use in as-yet undertermined future systems.
tony: I was thinkg more of native storage of RDF.
eric: Also cecil lynch's work forthe CDC doing outbreak detection, using OWL rules.
claude: moving to the next step of FHIR ont. how to represent Modifying Extensions?
... had some discussions. An idea: currently in the OFHIR ont there are
extension points, extension super property, and then on Disease you
might have modifying and non-modifying extensions (disjoint).
... So when you want to write an extension you do it in your own
namespace, but you also make the ext a subproperty of either
ModifyingExtension or NonModifyingExtension.
... A ModifyingExtension is one that may change the semantics of its
container. E.e., saying that a medical condition is absent.
... You'd attach this and use a restriction that defines a new concept that is the set of all things that have that extension.
Mike: The ModifyingExtension would a subclass of that resource class?
claude: the set of all conditions that have a modifying extension of a particular type. e.g., Absence would have the negation indicator of True.
david: maybe the modified class coudl be RELATED to the original class.
claude: you have a concept that containsnn info about a
condition, and it can be partitioned into those that are affirmative
about it, and those that are negations of that condition.
... FHIR does not have an notion of clinical statement.
... So when you have a condition class it is a statement of a condition.
Two possibilities: 1 the patient has a condition. 2. the patient does
not have a condition. A third possibility: the patient has an unknown
probability of having that condition.
... Those three are subclasses of statemetns i can make about that patient's possible condition.
... The negative statement is the intersection of all statements of denial intersecting all statements about conditions.
... Asthma versus not-Asthma.
david: Hard to follow in the abstract, but intriguing. Bring an exmple to discuss?
claude: Negation is easier if you make clinical statements explicit, so that you can negate the statement instead of negating the disease. I can bring an example next week.
tony: interesting conflict in how FHIR develops things. Allergy and tolerance has Confirmed, Refuted or Resolved. That's another way to handle negation.
eric: Value of ModifyingExtension will be useful in a small
space, but semantic reuse will come when they become popular. E.g.,
for negation, or for a restricting date range. FHIR tries not to chase
all use cases right now, and push subtleties into SemanticExtension.
... Status Indicator is an exmplae of where they'll end up. Considering
putting it into the core. Values other than Confirmed, Refuted Unknown
(e.g., Mild) would still be extensions.
... Parties would know to look for particular extensions.
oops
damn
:)
claude: semantic cleanliness, e.g., criticality or severity
-- attribute of condition. But Refuted is not an attribute of the
condition, it is about the statement about the condition.
... This is where the benefits of RDF come into play.
... But the fact that things are not well defined semantically in many models is a problem.
tony: higher levels of what thesee different concepts are -- orthogonal? -- accuracy of the recording, etc. orthogonal different things.
claude: semantic overloading
eric: The ones that can change independently would be non-modifying extensions.
claude: I suspect that many of the modifying ext are really about the statemnts rather than about the medical condition.
eric: We'll have to manage that in RDF.
tony: Just ran across a presentation by Charlie Mead on this.
David: I'll be busy with Healthcare Datapalooza conference
Claude: I can chair that week.
Eric: I'll be busy with child care, but call in from the park.
<Mike> http://dbooth.org/2013/semtech/slides/02-Mead-RDFWorkshop-2.pdf
Claude: if we move to a world where everything is represented in RDF, could it scale to handle the job?
ADJOURNED
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) No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Default Present: Mike_Denny, DBooth, Ingeborg, Tony, Mehmet, Claude, EricP, Neda Present: Mike_Denny DBooth Ingeborg Tony Mehmet Claude EricP Neda Got date from IRC log name: 27 May 2014 People with action items:[End of scribe.perl diagnostic output]