Stream: implementers
Topic: Adding an expression datatype to Consent provisions
David Pyke (Apr 27 2021 at 16:56):
We in CBCP received a ticket (FHIR-31550) as follows:
To add a new element to the Consent.provision with the Expression data type or redefine data type for the Consent.provision.code element from CodeableConcept to choice of data type (CodeableConcept, Expression) to be able to define a restricted/allowed element by FHIRPath.
Rational: to avoid using LOINC or any other codes and define restricted/allowed element by FHIRPath, for example, instead of 76691-5 “Gender identity” use a machine readable Patient.gender.
David Pyke (Apr 27 2021 at 16:57):
The question was, is this too much to ask for implementers that they implement FHIRPath for Consent?
John Moehrke (Apr 27 2021 at 16:59):
That is the current model for Permission.. and I have similar reservations. That said, as long as you provide alternatives then IG or local decisions can choose to use those alternatives that they are willing to use.
Lloyd McKenzie (Apr 27 2021 at 17:46):
When we're talking about a choice of data types, there isn't necessarily an expectation that everyone supports all choice options. Implementation works more smoothly when 'reasonable' choices are explicit in the core spec rather than having the complexity of having the core element or an extension for the core element.
David Pyke (Apr 27 2021 at 17:48):
So if we should include the expression type, what would be a reasonable choice selection?
Lloyd McKenzie (Apr 27 2021 at 17:49):
I think so
David Pyke (Apr 27 2021 at 17:50):
Sorry, I meant should we constrain it to FHIRPath or should we allow the full selection of types?
Lloyd McKenzie (Apr 27 2021 at 17:51):
Allow full selection. CQL could also make sense. Some organizations might choose to use something organization-specific (e.g. SQL).
Last updated: Apr 12 2022 at 19:14 UTC
