Harold: With Johns-Hopkins, healthcare modeling, SNOMED in OWL, lately in FHIR/RDF work
<hsolbrig> Johan Vansoest
Johan Vansoest: working with Michel Dumontier, distributed machine learning, need stadnardaization of data, HL7 FHIR, smemantic web, images derived from image data, combine data using RDF.
Subhashish: Post doc, doing EU project using FHIR, Carma tools from USC.
<hsolbrig> Dazhi Jiao, Software engineer at Johns Hopkins. Working on HOT (Health Open Terminologies) and RDF/OWL ontologies
Dazhi: Software eng working w Harold at Johns-Hopkins on FHIR terminology, Health Open Terminologies. Also working on RDF and OWL ontologies for representing terminiologies. New to this field.
Ananya: PhD working w FHIR, tried to model, research aim is to use distributed data, using RDF, having FHIR/RDF would be very useful, bridge gap research/clinical. Last name: Choudhury
Giorgio Cangeli(sp?): consultant, EU project through HL7. Intl patient summary. last name: Cangioli
Maethijs Sloet: PhD student, working with Michel Dumontier, med ont. Maethijs Sloet.
<hsolbrig> HL7 Web site is transitioning from MediaWiki to Confluence -- we need to transition our pages
<hsolbrig> dbooth: We now have some experience under our belt wrt. FHIR RDF
<hsolbrig> ... we get to take a new look at it based on experience ...
<hsolbrig> ... JSON LD 1.1 specification is not in the final stages. FHIR is currently in JSON/XML and we added third, RDF Turtle format.
<hsolbrig> ... We looked at JSON-LD when doing the initial RDF, hoping to use JSON + context as official RDF spec...
<hsolbrig> ... turned out to not be possible, due to technical limitations ...
<hsolbrig> ... looking at JSON LD 1.1 as new approach to RDF
harold: json-ld 1.0 did not allow context-sensitive URIs to be generated.
<hsolbrig> ericp: I have not tried machine generating the JSON-LD from profiles, but rolled it up by hand and it worked
EricP introduction: Worked on FHIR/RDF for years, ShEx, and Solid. W3C.
johan: Goal to get more FHIR developers to acknowledge this as FHIR?
eric: My motivation was to convert it to RDF. Lots of people like the dual-use aspect of JSOn-LD -- both JSON and RDF.
harold: Also like the crispness
of the spec. One goal is to get the def of FHIR/RDF more
precise.
... If the spec can be in a JSON-LD @context it would
help.
... if this is accepted, we'll need common FHIR servers to
provide the RDF. We've been working on the FHIR HAPI
server.
... The task would be miuchj easier if we could use an
@context.
Harold;s slides: https://lists.w3.org/Archives/Public/www-archive/2019Nov/att-0000/FHIRRdf.pdf
slide 3
slide 4
harold: everything in FHIR is
extensible -- even boolean!
... Extension provides a value + URL, to uniquely identify
it.
... Lots of FHIR models that are outside the 80% use extension.
You need to decide up front whether somehting will be an
extension or a part of the main FHIR model. Not possible to
smoothly change an extension to a first-class element.
eric: Popular extension that becomes first-class will orphan data that used the extension.
harold: In XML and JSON, the datatype is built into the name, e.g., valueMoney
slide 6
slide 7
harold: In FHIR/XML when you extend "active", you provide a nested extension inside the element, with extension URL and value.
slide 8
harold: In FHIR/JSON, they have a different approach. The extension tag starts with an underscore, such as "_active".
slide 9
harold: In FHIR/RDF 1.0, to
handle the possibility of extensions, we made every value a
bnode, with some nested triples.
... And fhir:index we added to retain list ordering.
... And even the fhir:Extension.url is extensible!!!
slide 10
harold: so when you code against
this model in XML, it's not too bad. Testing for an extension
is okay.
... And FHIR/JSON is similar for accessing the value. And to
access the extension, you need to add an underscore to the tag
name to look for it.
slide 11
harold: The way we did this in
FHIR/RDF 1.0, a bnode is used for each value. Turtle hides the
bnode, but you can see it below in the actual triples.
... all that work!
slide 12
harold: and accessing these from SPARQL or code is more dificult.
slide 13
harold: And it gets worse in
creating FHIR/RDF data, because the bnode has to be added
also.
... fhir.schema.org is based on doing RDFa transformation into
triples, but we cannot do this with the intervening bnode.
slide 14
harold: furthermore, to look for patient 12345, I need to go through all those intermediat bnodes. More difficult than it should be. Primary goal of FHIR/JSOn was to make it easy as JSON.
slide 15
harold: we should have made the routine things easy, but (mistakenly) made the routine things possible, but not easy.
slide 16
harold: FHIR/RDF as "Trial Use" status at HL7, so we can fix this bnode problem.
slide 17
harold: Proposing to fix this.
Need to revisit the FHIR extension language. Need to get rid of
tag/value speed bump in the RDF. Many FHIR tools have ways to
make extensions look like standard model elements.
... We need to re-look at this, at how extension URLs are used,
to avoid two sets of code.
... Also proposing to make the normal case easy -- accessing
the patient.active flag easily. But make the extension use case
possible.
... Want raise FHIR/RDF maturity level from 2 to 3; make
FHIR/RDF on all open-source major implementations.
... Also ShEx provides a direct way to validate RDF, but also a
way to take a bunch of related FHIR data, and assemble them
into cohesive resources into FHIR.
Ananya: In designing new model of FHIR, possible to incorporate new profiles. Similar in JSON-LD?
harold: If you go through FHIR,
there are 6 different modeling languages: structure def,
extensions, FHIRPath, slicing language, valueSet construction
language, vocabulary group tag/value modeling.
... Hoping with ShEx to take all these rules and represent them
in a single RDF idiom. Profiles are on the radar. Nothing
prevents the use of profiles inRDF, but might need to validate
them.
eric: ShEx extension feature was designed to make profiles in FHIR pretty similar in ShEx.
harold: could point people to examples of FHIR/RDF
david: Who is working with RDF?
ananya: Yes RDF, but not FHIR/RDF.
matthijs: building RDF knowledge graph.
harold: Mayo Clinic also using FHIR/RDF.
<scribe> ACTION: Harold to prepare FHIR/RDf background for next week.
harold: Also need to finish the
@context. Use one huge @context? Or lots of little ones?
... For python, rdflib needs to be updated to JSON-LD 1.1. Now
looking at pyld to integrate that with rdflib. Help is
desired.
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 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: s/Maethijs Sloet: PhD student/Maethijs Sloet: PhD student, working with Michel Dumontier/ Succeeded: i/With Johns-Hopkins/Topic: Introductions Succeeded: i/HL7 Web site is transitioning/Topic: HL7 transitioning to Confluence Succeeded: s/Present+ Johan Vansoest// Succeeded: s/Maethijs Sloet/Maethijs_Sloet/ Succeeded: s/Subhashis Das/Subhashis_Das/ Present: David_Booth Harold_Solbrig hsolbrig Dazhi_Jiao Johan_Vansoest Giorgio_Cangioli Eric_Prud'hommeaux_(a/k/a_EricP) Ananya_Choudhury Maethijs_Sloet Subhashis_Das No ScribeNick specified. Guessing ScribeNick: dbooth Inferring Scribes: dbooth WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: harold WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]