See also: IRC log
<inserted> harold: Need to sync with Rob Hausam about pushing this into the FHIR build.
harold: Someone enquired about
FHIR RDF being at risk. Grahame said no, but lack of
uptake.
... Spoke to James Agnew about HAPI server, about getting RDF
into it. Need to either convince HAPI folks that RDF folks that
they should do it, or we have to do it ourselves.
... Maybe we can get some guidance from them.
dbooth: Any funding available for doing it?
harold: Some possibility of Mayo
funds -- shoe-horn under some of grant funding.
... We have a grant proposal in. No idea how it will be
received. Proposal is to clean up loose ends in FHIR and then
use it in a clinical environment.
... Got endorsement from timbl too. :)
... Yosemite webinar that I did has sparked a lot of
interest.
... But still have more work to do for production demos.
harold: That has some real
potential. Folks are starting to get that pretty fast. Spoke to
Jim Cambell about loading big ontologies into I2B2.
... We came up with a plan for pulling FHIR valuesets in a
usable way.
dbooth: That I2B2 work sounds like it could be another really good webinar topic.
harold: Yes, we're getting
close.
... Loading a bundle of resources into I2B2 and perform some
queries. (Now need to write papers on that work.) But what we
haven't done: datatype is complex data type in I2B2, and I2B2
fact table kind of allows complex data type as a single
row.
... This is most useful to the FHIR community, for search and
query.
harold: This is also an
interesting, promising direction.
... The idea that I can mark up a foreign document, and the
notion of using fhir.ttl as a catalog, has a lot of
promise.
dbooth: Rafael Richards (from VA) met with schema.org folks at google in London last week. Might want to get his report.
harold: Spoke to Marc T, and
since then we now have compelling case for both
healthcare.schema.org and fhir.schema.org to co-exist.
... healthcare.schema.org serves the same role as SNOMED CT. It
gives vocab.
... Both are needed.
... And healthcare.schema.org has maps to SNOMED CT and other
vocabs also.
ken: How do you see healthcare.schema.org and fhir.schema.org being linked?
harold: When grahame was on one
of these calls, he said he had three goals. His third goal was
defining the semantics of the healthcare record.
... That was his goal for the near future.
... If you look, SNOMED CT codes have been assigned to a lot of
the FHIR components.
... LOINC codes have been absorbed. At the SNOMED business mtg
last week they indicated that they were going to re-open the
decision that if you were using LOINC you had to use LOINC
codes. You can use SNOMED codes instead.
... But assigning the semantics to FHIR is a daunting task. The
FHIR and SNOMED community have taken it on. It's also
validating the semantics ,that's needed.
... And need to show that it has value also.
... And that brings us back to the FHIR RDF work.
... RDF eliminates a daunting barrier, between models in one
format.
... E.g., the query shown in the Yosemite webinar last week. WE
could validate that code met the semantics of the links that
Grahame and Linda are putting in.
eric: It reduces the problem to
the terminfo problem: two separate models and puts them into
the same model.
... Then I have an observation with a code with a laterality,
and an observation.laterality. I should be able to infer one
way or another between them.
harold: Right now there's s lot
of tacit info used to make this work.
... We as humans know these things, but they need to be
explicit in the data, for machines to make the proper
inferences.
... I suspect that when we make those things explicit, we'll
turn up all sorts of inconsistencies in the models, in SNOMED
and elsewhere.
... In I2B2 a daunting task has been to translate local codes
into SNOMED CT. The fact that they're in FHIR right out of the
box is very powerful.
dbooth: What other things still need to be done in FHIR RDF?
harold: See the end of my webinar
(last week).
... One of them: Protege still cannot retrieve a FHIR resource
unless it knows its actual name.
... I cannot ask for patient 12345, because the FHIR server
takes text/turtle, but protege asks for
application/RDF+XML.
... If we're going to get the OWL rep of the FHIR code systems
in there also, then we'll hit this problem in spades.
... Because we'll have two reps: the RDF turtle rep of the code
system resource, and the OWL rep.
... We need a general conneg session with EricP on best
practices, and document it to get the FHIR tools to do what
they need.
dbooth: Sounds to me like protege
should ask first for turtle, rather than RDF/XML.
... And it isn't only protege. It is also classifiers.
harold: Should schedule a
separate session to work this out.
... Need to do a little prep work first, to see what other
tools do also.
<ericP> is this the Accept header? "application/rdf+xml, application/xml; q=0.5, text/xml; q=0.3, */*; q=0.2"
harold: IDK
... Need to make a definitive statement about how one talks
with a FHIR RDF server.
... Also, at the moment the FHIR community uses "turtle" and
"RDF" synonymously. Need to generalize, so that other formats
can be used.
... We also have the non-RDF OWL syntaxes.
... SNOMED in OWL will be distributed using OWL syntax: using
OWL refset, where each row in the table will be an OWL
functional statement.
... Let's plan for Nov 7 call to work this out. Need to know
what other tools might used to point at FHIR servers.
harold: Need to describe exactly how to request FHIR in RDF and specify preferences for syntaxes.
harold: FHIR paths will either be
an extension or part of FHIR vocab. I used property chains to
represent paths.
... Also in I2B2 I have to record the path to the element as
1-2 URIs.
... So if we construct URIs that are not in the FHIR spec, we
should put them in the FHIR spec to be consistent.
... I could put together a proposal on how to do that, using
property chains.
ken: We've done work to create those paths also.
harold: Everybody needs those paths. If we can publish them in the FHIR spec, then everyone will use the same ones.
harold: We can fold this issue in
to the conneg issue.
... If I ask for patients 12345, if the server does a redirect,
then it loses the format requested.
... Eric can advise on what it should do.
... That problem exists not only with the URI format, but also
in the conneg section, I think.
eric: Browser should not lose the conneg stuff..
harold: I think at the moment it redirects to more specific type.
harold: They cause OWL reasoners to become ill. At the moment i have to edit xsd:date, xsd:time etc into xsd:datetime in FACT++ to make them work.
eric: Support for datatype reasoning sucks in OWL reasoners.
harold: I have a switch in the code to allow two versions to be generated if desired.
dbooth: I'll record these as issues on our list, to track them.
ADJOURNED
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: i/Topic: Status of FHIR RDF/harold: Need to sync with Rob Hausam about pushing this into the FHIR build. Succeeded: i/What other things still need to be done in FHIR RDF/Topic: Conneg for FHIR RDF resources Succeeded: i|Need to describe exactly how to request FHIR in RDF|Also https://github.com/owlcs/owlapi/blob/49b00d97887cae334c36ae2a33cc3e0509e02713/api/src/main/java/org/semanticweb/owlapi/io/DocumentSources.java#L52 Present: David_Booth Ken_Lord EricP Harold_Solbrig No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth Found Date: 24 Oct 2017 Guessing minutes URL: http://www.w3.org/2017/10/24-hcls-minutes.html People with action items:[End of scribe.perl diagnostic output]