FHIR Chat · Slicing on Valueset membership

Stream: australia

Topic: Slicing on Valueset membership

Brett Esler (Apr 04 2019 at 00:59):

Working on AU base there are a few spots where we would like to have slices indicating value set bindings that are useful - then downstream specs can mandate or indicate must support as desired .e.g HealthccareService.speciailty - have been referring to discussion https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/slicing.20on.20a.20value.20set - am trying to achieve the following

Grahame Grieve (Apr 04 2019 at 01:00):

why slice? why not just define the value set in the base IG?

Brett Esler (Apr 04 2019 at 01:07):

fair point - think that would be simpler... wanted to allow people to opt-in to must support / mandatory and not stop other code usage - so if they made specialty mandatory it did not require support for the binding unless they wanted that as well (that is why I sliced)

Brett Esler (Apr 04 2019 at 01:10):

can I go from preferred to required in derived IG constraints on binding? that might do

Grahame Grieve (Apr 04 2019 at 01:10):

sure

Brett Esler (Apr 04 2019 at 01:11):

@Brian Postlethwaite @Jim Steel any comments?

Brett Esler (Apr 04 2019 at 01:12):

@Richard Townley-O'Neill @Dusica Bojicic

Richard Townley-O'Neill (Apr 04 2019 at 01:31):

Slicing demonstrates several bindings, but here there is only one of interest. Using a preferred binding in AU base is simple and will allow us to easily make it required in a derived profile.

I expect that here the Agency will want something like the following:

Uncoded text is permitted
If any codes are included, a code from abc is required
Other codes are permitted

Richard Townley-O'Neill (Apr 04 2019 at 01:33):

which might want slicing of specialty.coding, but not of specialty.

Brett Esler (Apr 04 2019 at 01:38):

I think the only place where I now have issues is Medication*.code - where wanted to effectively list coding options including PBS, GTIN, MIMS, and multiple levels of AMT (as separate value sets - TP, MP, CTP, TPP, MPP, TPUU, MPUU) - want to allow them all to co-exist and specs pick up the slices with desired must support / cardinality constraints

Richard Townley-O'Neill (Apr 04 2019 at 01:44):

@Brett Esler Do you mean that you still see value in slicing Medication*.medication/Medication.code but not in slicing places like HealthcareService.specialty?

Brett Esler (Apr 04 2019 at 01:44):

guess I am back to - is a discriminator type=value, path=coding going to work? want validator to select slices based on membership of required binding of coding in slices

Brett Esler (Apr 04 2019 at 01:46):

@Richard Townley-O'Neill yes I think so - the other places than Medication have only one preferred valueset so can simplify - medications has a number of binding that make sense and do already co-exist

Brett Esler (Apr 04 2019 at 01:59):

could think about tweaking slicing for meds case to be based on coding.system - define slices for MIMS, GTIN, PBS, and SCT (AMT) - then do some invariants on the AMT slice to check extension (MEdication Type) content - this would mean other SNOMED-CT medicaiton terms (not AMT) would fail - so is a constraint

Richard Townley-O'Neill (Apr 04 2019 at 04:39):

@Brett Esler Here are a couple of slicings
value is text or from specified code system

specialty       0..*    Slice: Closed by exists:coding
specialty       0..*    coded value
    coding      1..1    Binding: myVS (required)
    text        0..1
specialty       0..*    uncoded value
    coding      0..0
    text        1..1

Richard Townley-O'Neill (Apr 04 2019 at 04:44):

value is text or coding includes a value from specified code system

specialty       0..*    Slice: Closed by exists:coding
specialty       0..*    coded value
    coding      1..*    Slice: Open by value:code, value:system
    coding      1..*    Binding: myVS (required)
        system      1..1
        code        1..1
    text        0..1
specialty       0..*    uncoded value
    coding      0..0
    text        1..1

David Hay (Apr 07 2019 at 18:23):