w3c / hcls-fhir-rdf

Sketching out an RDF representation for FHIR
38 stars 15 forks source link

fhir:value is used elsewhere in FHIR. Should we use something different for FHIR extensions? #75

Closed dbooth-boston closed 1 year ago

ericprud commented 4 years ago

I'm aware of fhir:value used in e.g.

<Observation/123> obs:component [obs:component.code [CodeableConcept:coding [Coding:code [fhir:value "8462-4"]

What is the conflicting use of fhir:value?

hsolbrig commented 4 years ago

@ericprud - this is an R4 representation, no? I suspect that David is asserting that the "value" tag is used in the native FHIR JSON. In any case, I don't believe that there will be a conflict, as, last I knew we planned to eliminate the extra "value" nodes from the R5, which means that the "something different" would be nothing, correct?

dbooth-boston commented 4 years ago

Yes, "something different" would be nothing for the common case where there is no FHIR extension, but we still have not really discussed how we should handle FHIR extensions when they are present on simple attributes. This is why I wasn't sure whether our need to fhir:value would be entirely eliminated in R5.

Harold might already have some better ideas for handling FHIR extensions in R5, but one possible approach we could take in R5 is that if someone extends a boolean attribute foo, which produces attribute _foo in FHIR/JSON, we could just:

  1. Let the JSON-LD processor turn them into RDF foo and _foo properties, and
  2. Use the pre-processor or the "ontology" to add the assertion:
:foo fhir:extensionProperty :_foo 

This would enable generic processing in RDF. For example, in SPARQL one could then ask for all extension values for a given subject ?s and property ?p :

SELECT ?s ?p ?extensionValue
WHERE {
  ?p fhir:extensionProperty ?ep .
  ?s ?ep ?extensionValue .
}

If extensions like this are rare, then perhaps this approach would be adequate. It has a benefit if aligning very closely with existing FHIR/JSON.

I suspect that such a query would not be very efficient. (Because ?ep is a variable instead of a constant, it might require table scanning instead of indexing.) But I have not tested the efficiency, so I may be wrong.

But again, you might already have better ideas that we have not yet discussed.

dbooth-boston commented 1 year ago

Done. We changed it to fhir:v in R5.