Introductions

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.

HL7 transitioning to Confluence

<hsolbrig> HL7 Web site is transitioning from MediaWiki to Confluence -- we need to transition our pages

Re-launch FHIR/RDF

<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.

Comments, questions, thougths

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.

Next steps

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.)