Stream: implementers
Topic: Slicing by CodeableConcept
Lloyd McKenzie (Jul 11 2016 at 04:44):
I want to slice Practitioner.identifier by Identifier.type - which is a CodeableConcept. There's an extensible binding on it that requires codes from a specific code system, but translations are possible. To make this work, I'd need to define a discriminator of "type" and then rather than specifying a fixed value for the type, I'd instead specify a "pattern" asserting that at least one of the codings needed to include a system and code with a specific value (but that I don't care what other codings are present, what order they're in, or whether "display", various extensions or other elements are present.
Lloyd McKenzie (Jul 11 2016 at 04:46):
This is technically legal under the slicing methodology, but is presently discouraged and isn't supported in the tooling - in part because doing this on an unconstrained basis is hairy indeed to implement. On the other hand, there are certain use-cases (like the one above) where it's clearly needed and relatively straight-forward to implement. In discussing this with Grahame off-line, I proposed that we start incrementally adding specific types of patterns into tooling support, rather than trying to craft an overarching generic solution. The question is: Do others have similar needs for slicing by CodeableConcept (e.g. Observation.code) and are there other patterns we should look to cover at the same time?
Erich Schulz (Jul 11 2016 at 07:41):
I'm yet to ponder the mechanics yet, @Lloyd McKenzie but CQL is built on the assumption that the CQL engine queries resources by [type], [code], [date range] and [patient]. (given I'm currently convince that CQL is the answer for most things then I'd say this is pretty core functionality) - I'd be curious to here how far @Bryn Rhodes has gotten with this
Igor Sirkovich (Jul 11 2016 at 15:36):
Yes Lloyd, we had a similar requirement and I actualy think it's pretty common for slicing scenarios.
Chris Grenz (Jul 11 2016 at 15:37):
Absolutely. We're allowing pattern for slicing because of this scenario...there's no other reasonable way to handle this in an environment with alternate codings.
Chris Grenz (Jul 11 2016 at 15:39):
Only for CodeableConcept though...what other use of pattern makes sense? Identifier we just fix system if needed (or pattern type as you mention). Quantity same thing... CodeableConcept is the only one with the "one of the children must match" logic, correct?
Eric Haas (Jul 12 2016 at 22:17):
This the same situation i encountered when trying to profile Observation.code to allow for local code translation(s). Why doesn't the solution of binding to a valueset work? with ElementDefinition.slicing.rules = open. you can add whatever translations you want. I don't see why you need pattern.
Grahame Grieve (Jul 12 2016 at 22:30):
a value set of one for each slice?
Eric Haas (Jul 12 2016 at 23:54):
Well it cover both code and system. Also I think the pattern here is " I want at least this one Identifer.type defined and leave the translations up to the implementer. the rest are just the the rest. easier to think about obs.code where you have a LOINC wihich you require and maybe a local code
Last updated: Apr 12 2022 at 19:14 UTC
