Meeting minutes
IRI stems
gaurav: Working on github action, scheduled, clones the UTG github repo, looks for every IRI stem, generates markdown, compares it with our repo, and generates a PR if there were any changes.
12
gaurav: Want reviewers on it
ACTION: DBooth to review Gaurav's github code
FHIR Ontology
ken: Requirements based on practical applications. Working with Eric Jahn.
Ken's slides: https://
(Goes through slides)
tim: Davinci project integrates financial data w clinical data w FHIR. But the financial data models have been translated into FHIR.
… Could you just do everthing in FHIR, instead of trying to keep something outside of FHIR?
ken: There's a lot of functionality that is a black box, e.g., "enrollment" in the insurance space.
… That is not a FHIR concept.
… It's the API approach.
EricJahn: Our discussion has evolved in recent months.
… A year ago I would have said FHIR needs to add a Person resource (not only Patient).
… We need something that we can connect to, from FHIR, and not a resource and not clinical.
… Person concept that allows mapping between human services and FHIR.
… Cannot bring it all into FHIR because we don't have the structures in FHIR that we need. FHIR assumes that we have Patients, but we don't. We have clients/persons.
(Michel presents his slides)
michel: I run multiple projects that try to integrate clinical or device data.
… Harmonization projects
… Problem w SNOMED and other ont is that they are very domain-specific.
… That causes complexity for users, and makes it not interoperable between domains.
… Can we use upper level ont to harmonize?
… Use it to map across different standards?
… Want an upper ont for domain-indendence
… Use a restricted vocab of relations in OWL, to get more interop.
… SPHN is an RDF vocab.
… hasAdmissionDateTime was created, but later they refactored their schema.
… Arbitrary change
… In RDBMS we have third normal form. But in this ont work, we don't have standard represenation.
… If you just make up relations, you are susceptible to refactoring later.
… SULO is an upper ont to describe how to make ont, and make sense of existing terminologies.
… Did some work w EricP at hackathon in August
… If we map from one standard to another, we would use SULO using ShExMap.
michel: I'd love to provide conceptual support for FHIR ont dev.
… And want to be able to convert between standards. Want to formalize the meaning of them to facilitate translation.
tim: Worked on mapping PROV ont to BFO.
… There are other ways to map ont, eg SSSOM.
Here’s another ontology mapping approach I worked on BFO-Mappings/
https://
michel: But you need more powerful ont transformations. That's why ShExMap.
tim: Issue I had w SSSOM was it was too simple. Tried SWRL.
michel: Want bidirectional also: Write one pattern, and the engine transforms either way.
… SUMO is much easier to use than BFO.
tim: You might also want some mapping between BFO and SULO.
michel: I think we can represent all upper level onts. But more int in healthcare.
ken: We're more focused on the data concepts that are exchanged.
michel: We use ont for knowledge verification.
… We found errors in the annotation process, and we found bastardization of those files.
… Formalizatoin of the intended semantics ensures that they are correct.
tim: I would probably start with an example of something specific in FHIR that we want translated to some ontology, and vice versa. Then use those as the first “unit test” for the mapping.
tim: Might be preaching to the choir. Difficult part is engineering the tooling: How to code these mappings? How to test them?
… Can we point to a specific example of something we actually want to map? Use those as starting point for testing the mappings?
jim: SULO covers most useful things.
EricJahn: @Tim Prudhomme HUD is mapping to FHIR using skos: comparison properties currently. We could start there?
ADJOURNED
michel: Unable to join next week, due to travel