W3C

– DRAFT –
FHIR RDF

08 January 2026

Attendees

Present
David Booth, Detlef Grittner, Eric Jahn, Erich Bremer, EricP, Gaurav Vaidya, Ken Lord
Regrets
-
Chair
David Booth
Scribe
dbooth

Meeting minutes

IRI stems

w3c/hcls-fhir-rdf#160

gaurav: Issue 160 tracks what I plan to finish this month.
… Main update is #205 w3c/hcls-fhir-rdf#205
… Seems to be how HTML files are generated. But all CodeSystem files have been removed from THO.
… Now we only have the NamingSystem records. So there's still an issue. Should update our guidance: 1. only put the IRI stem in NamingSystems. 2. Make them more visible.
… Could put the IRI stem in the meta record file.

https://terminology.hl7.org/external_code_systems.html

gaurav: Now you're supposed to go to external code system on THO, and within this table there's an identification record, machine readable, and a metadata record file that is not machine readable.
… We have it in the machine readable file, but not worth putting it into the non-machine readable file.
… So we should change our rec to put the IRI stem into the machine readable file.

dbooth: Changing the rec in the rdf.html page appendix? gaurav: yes

gaurav: Expect to make progress next week.

Expanding the ontology

https://lists.w3.org/Archives/Public/public-semweb-lifesci/2026Jan/0001.html

ken: Background on data exchange in healthcare. Semantic layer can help improved data exchange.
… My company's view is that exchanging data between formats requires (for precision and accuracy) the ability to match semantically what that data means.
… For the moment, ignoring the problem of transforming values.
… But concepts need to match.
… For interop, the formats (eg FHIR, CDA, V2, etc.) are really data formats -- not really an easy way to get at semantics.
… They have structures that imply semantics at a high level, which makes it hard to determine semantics.
… Did some work in the OMG.
… Last principle was that this needs to be a shared ont -- not proprietary. Looking for a place where people could dev such an ont as an open resource.
… My company is implementing some of this.

dbooth: That fits within our mission. Devil is in the detail of what is practical for us to do.

eric_jahn: I'll need a person class, whether part of FHIR or not.
… We need a person class to connect healthcare data to housing data.

ericP: That's an interesting case, because whenever we take clinical data there's always a tension between a single table vs 6000 tables. Could use schema.org concept of Person, but then you might want attributes of a person.
… That's the kind of place where it would be interesting to see concrete proposals, and analyze use cases.
… Need to spend a little time modeling to see if it solves sufficient problems to be worth the time investment.

ken: Being able to make rels btwn classes is helpful. Difficult to do w data models.

dbooth: Need a concrete starting proposal.

ken: Suggestions?

dbooth: Pretty sure we won't want to invent our own Person class.

gaurav: Biolink Model has a “Case” (patient: https://biolink.github.io/biolink-model/Case/)
… It provides general classes for things like proteins and genes.
… They also have a Patient class.

dbooth: Please create an issue on our issues list, and put a concrete starting proposal in it.

dbooth: We would be starting w our existing fhir.ttl ont.

ken: There's a class called BackboneElement that we need to refine.

eric_jahn: I think we could add a person class that connect to something like schema.org

ericP: On the use of Patient, there's a bunch of places in FHIR where they flattened things. (BTW, Backbone is just a structure.)
… There's a bunch of places where the modeling isn't great.
… Could say that fhir:Patient is a subclass of something else.
… But then we might have to say it has to be unioned with the class of animals.

DICOM

erich: New version of imaging data commons scan as been generated and loaded into qlever.
… I'll send Detlef the link.

Changes from R5 to R6

w3c/hcls-fhir-rdf#214

ACTION: Dbooth to try this.

R6 testing

ericP: Tim Prudhomme is working on that

Issues list

w3c/hcls-fhir-rdf#208

w3c/hcls-fhir-rdf#201

ericP: Should we de-sync the RDF version of FHIR from the regular version of FHIR?
… That would be hard.
… Could detect every time a structure changes, but to deal w it properly, (such as going from a name to a structure) we'd have to rename it and deprecate the old one. Could do it, but would need a tie-in to the change process (i.e. the structure def spreadsheet source), and then we could run across that to see the changes.

ACTION: Ericp to propose an alternate approach

ADJOURNED

Summary of action items

  1. Dbooth to try this.
  2. Ericp to propose an alternate approach
Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).

Diagnostics

No scribenick or scribe found. Guessed: dbooth

Maybe present: dbooth, eric_jahn, erich, gaurav, ken

All speakers: dbooth, eric_jahn, erich, ericP, gaurav, ken

Active on IRC: dbooth