W3C

– DRAFT –
FHIR RDF

28 October 2021

Attendees

Present
Brad Simons, David Booth, EricP, Gaurav Vaidya, Gopi, James Champion, Jim Balhoff
Regrets
-
Chair
David Booth
Scribe
dbooth

Meeting minutes

Issues 77 and 93

https://github.com/w3c/hcls-fhir-rdf/issues/93

eric: On 93, option 2c, we currently have: fhir:origValueBoolean true
… Propose adding origValueBoolean also to #77 for regular extensions.
… Or just fhir:value
… In RDF we typically put the datatype in the value itself, instead of making a separate property name for each datatype.
… e.g., in RDF 'fhir:valueDecimal 0.75' is redundant, because 0.75 is already xsd:decimal

eric: could call it "extendedValue"

david: Or "originalValue"

eric: We cannot call it fhir:value because that's already used.

Action: Eric to write up proposed resolution for #93 and #77

Issue 76: How should list ordering be preserved in R5?

https://github.com/w3c/hcls-fhir-rdf/issues/76

jim: On the last call, people seemed inclined to stay with the R4 approach

eric: I'm slightly inclined to change to RDF lists now.

jim: Difficult to use the ordering in SPARQL

eric: True. But rarely care about the order. Only care when validating slicing.
… e.g., first entry in an address is a home address.

david: Do we have more usage data, on the impact this has on SPARQL queries?

eric: None of our NHS queries have cared about the order.

brad: I've never had to care about the order either.

james: Patient name, and patient telecon has the order preserved.
… But I haven't had experience needing to care about the order.
… I'm more working on generating the FHIR data.

brad: If a patient has multiple names, we only care about all the possibilities, we don't care about the order.

james: Might be important with labs or medications.

brad: Everything comes through with a datetime on labs, so we use that.
… People care about trending ... "give me the 5 most recent".

eric: People care in a slicing example, but shex takes care of that.
… JSON-LD 1.1 supports RDF collections now, so that would allow more of the conversion processing to be done using JSON-LD 1.1 rather than doing it in the preprocessing.

jim: RDF list is nice and concise. Leaning toward that.

Action: David to write up option 4, and new option 3 to be a regular RDF list

Eric: suggest using as example, a series of codings in a codeableConcept, or a series of addresses.

Action: David to change to a better example also.

david: Is there enough benefit to make this change to R5?

eric: We can make this change in our code. Now is the time to do it.

Issue 69: Shorten FHIR property names or use superproperties?

https://github.com/w3c/hcls-fhir-rdf/issues/69

eric: Want to remove the datatype from the property name: instead of fhir:valueBoolean it would be fhir:value .
… Instead of fhir:valueCodeableConcept it would be fhir:value [ a fihr:CodeableConcept ; ... ] for complex types.

jim: https://www.hl7.org/fhir/observation.html#resource

eric: OWL DL won't allow classification based on a property value that is a literal.

ADJOURNED

Summary of action items

  1. Eric to write up proposed resolution for #93 and #77
  2. David to write up option 4, and new option 3 to be a regular RDF list
  3. David to change to a better example also.
Minutes manually created (not a transcript), formatted by scribe.perl version 136 (Thu May 27 13:50:24 2021 UTC).

Diagnostics

Succeeded: s|jim: https://github.com/w3c/hcls-fhir-rdf/issues/69||

No scribenick or scribe found. Guessed: dbooth

Maybe present: brad, david, eric, james, jim