Meeting minutes
R6 testing
tim: Created R5 examples using R6 encoding, and Shex using changes to R6 encoding.
w3c/
tim: For the parsing of the R6 turtle with HAPI. Does HAPI just support R6 now?
… R6 didn't previously support R6 structure defs.
ericp: We won't have a final R6 tests, and we won't until balloting is done about a year from now.
tim: So this is still useful?
ericp: Yes, very much. Even if HAPI has some version of the resource defs it will not necessarily be in sync w the examples.
ericp: Therefore even if HAPI has some R6 structure defs, it won't help us much now.
tim: Possible to set up a turtle parser in the core lib?
… There's both using the core lib for parsing turtle, and we could potentially use that in HAPI, to make them consistent.
ericp: The core lib has purpose-built parsers to handle the examples.
ericp: We'll be validating the examples from the shex. And we'll gen the shex from the resources as of R5, and we can do that without HAPIU.
tim: But for round-tripping, we can only do that w HAPI?
… You parse the JSON and Turtle versions into HAPI, then compare them for equivalence.
(Postponing discussion for a few minutes)
Extending the ont
dbooth: Use case looks reasonable. Can you fill it out more?
ken: Yes
… There are three existing artifacts of people who have worked on individual parts of this use case.
… Use case will integrate them.
ACTION: Ken to post the documents into the issue
EricJahn: How is this different from an upper level ont, different from other bio ontologies?
ken: Yes, it's an upper ont. To achieve that, there are classes that may exist in the HUD ont. Need to be able to create an equivalence or add classes to FHIR ont. New classes may need to be added in many directions.
EricJahn: I've invited HUD's tech representatives to these calls. They're very int in FHIR.
dbooth: We'll be incrementally adding to our existing ont, not creating a new upper level ont.
EricJahn: Maybe another piece is to take human concepts and map to FHIR. Could be outside of this group, but using the product of this group.
tim: This will be relevant for mapping to the Gravity project IGs w3c/
tim: w3c/
ken: There are 3-4 groups around this work, but calling it a FHIR ont may cause some concern.
… Can we call it a Care ont? FHIR tends to be clinically oriented. Gravity is very int in social determinants, and very active in workflow issues.
… A more encompassing Care ont might bring a larger audience and not raise concerns.
dbooth: Suggest first looking at what we need, and then deciding how to categorize it.
tim: I think the naming is the least of your worries. Sounds like you're talking about making mappings to FHIR ont.
… FHIR has a lot of admin, clerical and financial resources. Gravity has an impl guide in FHIR. RIght now we don't have a way to represent FHIR profiles in the ont, but we know how to do it.
… Could take the Gravity impl guide and represent them as OWL classes, and then you can map to those.
ken: There are profiles in the DaVinci project where having a graph would be very helpful.
… There may be some things that don't fit well in FHIR, e.g., personal relationship between entities.
tim: We do have "related person" in FHIR.
ken: But that has a 1:1 rel w a patient.
tim: How do you see these mapping being encoded?
ken: Good question. Let's get the use case there first, then discuss.
tim: Excited about this, esp if you can use OWL reasoning to test it. But can also be very challenging. FHIR has a lot of mixing of info elements w other things that are not info, such as BackboneElement. But there are ways to get them mapped correctly.
… An instance of a Patient is not a BackboneElement.
jim: Do you think the ont should be revised, to make BackboneElement more of a meta represetnation?
tim: No, more a question of mapping.
… E.g., mapping to BFO, Backbone would be into, and Patient would be a material object.
… But because we have structure defs in FHIR, I think we can make it all make sense.
… Info about things vs the things themselves.
ken: I think of that as implementation, how FHIR handles structure defs. Maybe a little out of scope for this, but we'll see.
tim: For scope, are you doing all elements from source ont, or all from target ont? Don't have to map everything in FHIR.
tim: I've also seen work from Renci (where Jim works) mapping a lot of onts together.
jim: Gaurav implements that.
gaurav: I map identifiers, not the whole ont. E.g., figuring out all the identifiers for water, across wikidata, and other onts.
tim: Hoping to focus this year: Now FHIR has ways to connect to terminologies like SNOMED, ICD, etc. Mostly used for data validation.
… They're doing that now using healthcare terminology framework that could be done in better ways using ont and reasoners.
… Hoping to strengthen some of those connections. That's another way to connect FHIR to other onts.
ken: Have you looked at PIQI in HL7?
piqi hl7
https://
tim: Checking a SNOMED code for cancer, you can use a terminology service to do that using code expansion, e.g., specific cancer code is related to more general code.
… I want to do that using OWL, in a service.
ken: My company is focused on data concept level.
tim: Problem w OWL is the OWA, but we can use shex for validation.
… But doing term expansions, that currently requires a custom terminology service, but could be done we OWL.
… Want to do that in a clear interoperable way using OWL and shex.
ken: What kind of document?
EricJahn: Suggest we start w a google doc. dbooth: Sounds good.
IRI stems
gaurav: At yesterday's ITS call we approved https://
… The LOINC IRI stem was incorrect. This proposal would fix that.
gaurav: Also continuing on my other issues w3c/
ADJOURNED