Closed dbooth-boston closed 1 year 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?
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:
: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.
Done. We changed it to fhir:v in R5.
I'm aware of fhir:value used in e.g.
What is the conflicting use of fhir:value?