W3C

– DRAFT –
FHIR RDF

03 April 2025

Attendees

Present
David Booth, Detlef Grittner, Erich Bremer, EricP, Gaurav Vaidya, Jim Balhoff
Regrets
-
Chair
David Booth
Scribe
dbooth

Meeting minutes

ITS call

ITS group approved our other two tickets https://docs.google.com/presentation/d/1Ayfwly7zeNAXgREYRi8Y_sT3cwHh6wiQKqd2K0udsnE/edit?pli=1#slide=id.g32b3cad567b_0_0

DICOM

Issue w3c/hcls-fhir-rdf#146

AGREED: to go ahead with this proposal

Looking at w3c/hcls-fhir-rdf#149

erich: I've implemented the geosparql approach, using ^^geo:wktLiteral datatype.

dbooth: The polygons would be opaque to SPARQL processors that do not implement the geosparql extension.

erich: Need to define coordinate system in the file.
… I'd have to convert those to meters to interpret them correctly.
… geosparql was designed for geo data, but there are efforts to make it work for cartesian coordinate systems.
… They're trying to push QTD coordinate systems.
… Then you could microns, and life would be good. But they're not fully compliant yet.

detlef: Would that be a problem with current data?

erich: It would parse it, but need to change it to change the coordinates to meters, and use the default geographical system.
… If the coordinate system is not specified, it defaults to meters (I believe). I need to change the numbers to comply w the default coord system.
… geosparql shows how to specify the coordinate system, but not sure what implementations support it.

eric: Do we need to preserve the lexical values?

erich: When we bring this to the DICOM group, we'll see what they say

erich: DICOM JSON allows numbers as strings to be turned into native JSON integers
… so that gives precedent.

dbooth: Would we be closing off other possible future solutions with this approach?

erich: No, because the type would still be indicated, even if it is different.

ACTION: I'll make this change (of numbers to meters), and see if I can use exponent notation in the numbers.

Round tripping of FHIR RDF examples

jim: When working on R5 changes, we identified two libs that produce Turtle from FHIR. One is for the FHIR build. It is very bespoke. Doens't use std RDF lib.
… I didn't update the parser side. It had been turned of for a long time.
… The other lib is in HAPI FHIR, based on jena.

eric: Based on 1% of jena -- interface for having a graph store. Mostly it's idiomatic to HAPI that has a parser and serializer.
… But it's very much a slave to the FHIR metamodel.
… Having a resource with attributes that contain attributes, etc.

jim: That lib saves you from having to read/write RDF formats, so you can work only at the triple level?

eric: Correct. But there's no JSON in it.
… For parsing, you pass it a jena triple store, and it will populate a POJO for it.
… Going the other way, all we did was add triples and at some point there much be calls to turn it into Turtle, which you could extend to output FHIR JSON.

eric: There are FHIR parser/serializers for XML, JSON and Turtle.
… In the HAPI code base.

fhircat/hapi-fhir

eric: This is not in R5, but it's analogous to it. https://github.com/fhircat/hapi-fhir/blob/master/hapi-fhir-structures-r4/src/test/java/ca/uhn/fhir/parser/RDFParserTest.java
… The R5 tests are identical, except s/R4/R5/

AJOURNED

Summary of action items

  1. I'll make this change (of numbers to meters), and see if I can use exponent notation in the numbers.
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

No scribenick or scribe found. Guessed: dbooth

Maybe present: AGREED, dbooth, detlef, eric, erich, jim

All speakers: AGREED, dbooth, detlef, eric, erich, jim

Active on IRC: dbooth