FHIR RDF and OWL Tutorial (Harold)

https://github.com/BD2KOnFHIR/BLENDINGFHIRandRDF

harold: Files with .owl extension are OWL functional syntax
... wrapper.owl names the prefixes that we use, and imports all the files that are used.
... We want the FHIR files to be static, so several of these files on github are copies of FHIR files.
... FHIR just went to STU3.
... The FHIR ontology, fhir.ttl, is about FHIR clinical records -- not about patients, tests, diagnoses, etc. It is an ont about what FHIR records about those things.
... It's generated from the FHIR build using Apache2 jena, though we want to switch to the OWL API.
... Everything in here is a transformation of things on the FHIR site.
... This ont has changed radically since it was first done about a year ago.
... It uses OWL features that are friendly to reasoners.
... Need to decide whether it needs to talk about datatypes (concrete ranges).
... The w5 ont (who what why where when) is used in generating the FHIR front page.
... If you found Patient in the fhir.ttl ont it would be a subclass of something in the w5 ont.

dbooth: what is the benefit of Patient being a subclass of a w5 class?

harold: w5 acts as a small upper ont.
... snomed_subset.ttl is a subset of SNOMED CT. Because the FHIR ont and the rules take advantage of data properties and other things, we cannot use SNOROCKET classifier, and that's the only one that can handle all of SNOMED CT.
... So we extracted a neighborhood of concepts used for this demo. There's a tool for making that extraction SNOMEDtoOWL.
... The SNOMEDtoOWL repository is actively in dev to support a formal spec for how SNOMED CT should be represented in OWL.
... There's also Kent Spackman's perl script for generating OWL, but IHTSDO never said formally what the OWL should be.
... But the perl script only works on SNOMED international, and even on that it does odd things.
... The spec being defined in this repository should be finalized in April.
... I also built a tool RF2Filter that makes a subset of OWL..
... The script snomed_subset.sh gets all the ancestors and descendants of specified classes.
... All the rules were previously used.
... In this brainct.ttl example, the status is final.
... A DiagnosticReport can be a patient or a device, but we're specifically looking for patients.
... We've included an assertion that patient f201 is a fhir:Patient.
... Also interested in the codedDiagnosis
... We've said that it is an instance of snomed class sct:188340000
... This file also declares f201.ttl to be an owl:Ontology and imports fhir.ttl to make protege happy. It also declares the version of this turtle.
... This specifies the specific version of f201.ttl
... For STU3 grahame gave this an STU3-specific URI, and we'll discuss that later.
... The final bit is a set of rules rules.owl that we have authored.
... A FinalizedReport is equivalent to any DiagnosticReport that has a status of final, amended, corrected, appended.
... And corrected and appended statuses are sub-statuses of amended, so it's a mini-ontology.
... But the folks who defined those need to decide exactly which ones should be considered final.
... Also the use of these strings in rules.owl gives trouble to a lot of reasoners.
... If these strings were URIs instead (in a mini ont, with a single superclass for final) then this would work with a lot more, simpler reasoners.
... To simplify the rules, we're defining property chains.
... And if we had URIs for the statuses, then the status would be an instance of one of the status classes.
... So then in protege if you load wrapper.owl, and open the FACT++ classifier and classify it ...
... and view individuals ...
... While that's running the reasoner, there are two catalog.xml files that protege likes to use. One is local. YOu need to use one of them.

(back to the reasoner in protege)

harold: now I can show (if it works right) all the individuals in the CancerDiagnosis class, including patient f201.
... Success! It just took a while to run.

Screenshot: https://lists.w3.org/Archives/Public/www-archive/2017Mar/att-0007/2017-03-21-120129_1600x1172_scrot.png

harold: We should consider converting the SNOMED compositional grammar to OWL, to enable things like left femur to be determined.

eric: I think we want a tool that pushes everything into snomed.

harold: This imaging study example will be in the upcoming AMIA paper.
... It includes a body site and laterality. I looked into how we would classify it, but it would require shuffling. The laterality is implied, not explicit. This makes a compelling case for the work that Lynda Byrd and Grahame are doing.
... They are working on using the finer mapping language to put this into the laterality to create the right compositional expression. As is I can't find a way to make this classify as left femur.

dbooth: Would microparsing those snomed compositional strings using ShEx make sense?

harold: It would only use the regex capability, so that would be done better at a different level.
... But shex could be an alternative to the approach that Linda and Grahame
... If you see issues with the instructions in the github, then file an issue please.

ADJOURNED