– DRAFT –
FHIR RDF

HAPI

eric: Still working on the jena shex for it. No ETA yet. Need to get semantic actions back in. Very fast validation now, but harder to figure out how it knows what to execute a semantic action. Also need to add extends support, needed for FHIR shex.

Questions from U Michigan

allen: Avanti starting to look at FHIR RDF Playground work

https://lists.w3.org/Archives/Public/public-semweb-lifesci/2023May/0005.html

allen: Working with 3 kinds of data. We were working w the FHIR ServiceRequest, but also interested in Prov ont.
… Want to take inputs, compute a resutlt and log that result as a FHIR object.
… Adeel is building a pipeline for it, producing FHIR as output.
… We'll be producing a JSON-LD @context object. want to make endpoint URLs in our results that point directly to where terms are defined.
… Therefore we need several URIs in our @context.
… How should we deal with this?

dbooth: Why are you using JSON-LD?

allen: JSON-LD data objects are loaded

dbooth: how are the JSON-LD objects being created by your functions?

eric: Sounds like you are trying to do JSON?

allen: Trying to do both JSON and JSON-LD.
… Python write statements are used to generate the JSON-LD.

eric: When you try to make JSON-LD represent arbitrary RDF, then you have @graph at the root and a bunch of triples, and it would not be friendly to JSON users.
… But it sounds like you want something appealing to JSON users.

allen: yes.

eric: Perfectly reasonable to write everything out in JSON-LD. You'll have to decide how to reference things. JSON-LD works well for tree, but when you reference something in a non-tree structure, you'll need full URI for it.
… I'd expect to have extra prefixes in the @context, or full URLs in the data.
… But if you're pointing to HTML, and look at the ServiceRequest page and look at Turtle examples...
… How is fhir:SRD: being used in your URLs?

{
  "@context": {
    "fhir": "http://hl7.org/fhir/",
    "fhirSRD":"http://hl7.org/fhir/servicerequest-definitions.html#",
    "fhirDTP" : "http://hl7.org/fhir/datatypes.html#",
    "fhirPROV": "https://hl7.org/fhir/r4/provenance.html#",
    "xmlSM" : "http://www.w3.org/2001/XMLSchema#"
  },

https://bluebrainnexus.io/

"fhir:relevantHistory":{
             "@type": "fhirSRD:ServiceRequest.relevantHistory",
              "fhir:provenance": {
              "@type": "fhirPROV:Provenance",
              "fhir:entity":[{
               "@type": "fhirPROV:Provenance.entity",
              "fhir:role":{
              "@type": "fhirDTP:code",
              "fhir:v": "source"

eric: you're looking at ServiceRequest.relevantHistory?

allen: yes

eric: In R5, relevanHistory has become a property.
… The type is Provenance

https://build.fhir.org/servicerequest

https://build.fhir.org/provenance.html

https://build.fhir.org/provenance-example.ttl.html

eric: i think that's what you want.

allen: In the data model for the provenance (our second question), in the Prov spec https://build.fhir.org/provenance.html
… We've looked at ProvO, and want to bring in Activity, Entity and Agent. Trying to declare entities assoc w the computational processs we're doing.

eric: The FHIR model has entities have a role and an agent attribute, as well as a "what" attribute.

allen: ProvO target is the thing that the provenance is for or about. We're trying to figure out the target entity.

allen; Looking at this example: https://build.fhir.org/provenance-example.ttl.html

https://build.fhir.org/provenance.html#bnc

allen: When we use RDF for health data, we were directly using ProvO -- not FHIR Provenance. If there's already an established RDF vocab, would we expect it to inform FHIR resources? Or would we expect FHIR to point to ProvO?

eric: You'll face pain either way.
… If you follow ProvO, ProvO people will understand it, but you won't be able to automatically dump it into FHIR.
… If you go the other way, you need to map the FHIR idioms onto ProvO.

allen: So we'll need to map to/from FHIR.

dbooth: I think that's inescapable.

allen: once we produce these JSON-LD resource and put them into bluebrain, we want to do sparql queries on them, so might not need to go into FHIR.

eric: And need to look down the road to ask "will we want to dump the data as FHIR"?

dbooth: important arch question to consider: what do you want your native data representation to be? FHIR or general RDF?

allen: We're taking FHIR resources, unpacking them, using them as input parameters to a function, produces a computed result. Wondering: what if it were FHIR all around?

eric: if you want FHIR all around, you might want to work natively in FHIR.
… Wondering why you were considering doing it all in FHIR?

allen: Our stakeholders are building FHIR expertise. Wondering about leveraging that.
… The center does treatment, but also research.

dbooth: Should consider what kinds of questions you want to ask of the data, and how you want to ask them.

allen: We can look at some of the questions they've previously asked.

dbooth: What other data or ont do you want to pull into the mix?

allen: ProvO and function ont.
… Want a flexible way to add functions.

dbooth: Should look at what clinically relevant data or ont you might want to add.

allen: Comparative effectiveness.

eric: Guessing that the Prov stuff will be important to researchers, in terms of FHIR provenance.

allen: Version is important.

dbooth: If you only care about FHIR data, then you might as well stay in the FHIR world. But if you want clinically relevant data or ont from other sources, that changes the calculus of whether to use general RDF.

ADJOURNED