FHIR Chat · Profiling with several slices · implementers

Stream: implementers

Topic: Profiling with several slices


view this post on Zulip Mareike Przysucha (Sep 05 2019 at 11:56):

Dear community.
I have a problem with slicing. We made a profile on observations for woundsize with several components (length, width, depth and area). These components we want to code with loinc and e.g. snomed ct. Therefore we did not only slice the component, but also the coding in the components (see https://simplifier.net/posithera/positherawoundsize).
For the slices we need a discriminator. We chose "code.coding.code" for components, which is now not applicable due to the slice on coding.
Now we are unsure how to solve this problem. Has anyone an idea to cope with such a situation? Thanks in advance!

view this post on Zulip Chris Moesel (Sep 05 2019 at 13:03):

Hi @Mareike Przysucha -- I think the recommended way forward now would be to use pattern[x] to fix the codes within the component slices. Then you only have one level of slicing. There was actually some recent discussion regarding how best to fix codes (slice+fixed[x] vs. pattern[x]) here: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Fixed.20Code.20vs.20Pattern (note, it went off-topic toward the end, so read from the top).

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 13:04):

Hi @Chris Moesel . thanks for your reply, I will read the recommended topic.

view this post on Zulip Michel Rutten (Sep 05 2019 at 13:07):

Note that discriminator paths are relative to the sliced element:
http://hl7.org/fhir/profiling.html#discriminator
In this case, you would probably like to discriminate on system, not on code.

view this post on Zulip Chris Moesel (Sep 05 2019 at 13:08):

There's a bit of back and forth in the topic -- so it's a kind of bumpy ride -- but the end result is to use pattern[x] to fix Coding and CodeableConcept types.

view this post on Zulip Chris Moesel (Sep 05 2019 at 13:10):

@Michel Rutten -- if they're trying to discriminate components based on the fixed code in the component, then I think they'd actually want to discriminate on code.coding.code and code.coding.system, wouldn't they?

view this post on Zulip Michel Rutten (Sep 05 2019 at 13:12):

Correct. Nested slices would use a short(er) discriminator path. Apologies if I understood incorrectly.

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 14:26):

That drives me to the next Part. I've never worked with patterns before. So I am unsure how it can solve my problem... I am sorry that I don't know. Probably I am just too stupid to use Forge in this context.

I also don't know if the composition of "code" and "system" will do the job as we have 8 pairs (4 component slices x 2 code systems [LOINC and SNOMED]), and two of them identifying the same component. Probably a fixed "text" with minimum cardinality "1"?

view this post on Zulip Rob Hausam (Sep 05 2019 at 15:27):

@Mareike Przysucha I'm not sure what you mean by "two of them identifying the same component"? I looked at the Simplifier link, but maybe you can point out specific examples? I agree with Chris and Michel that likely pattern is going to be the best approach to take, but if you do have requirements that you know or think that it can't meet, that would be good to know and further explore.

view this post on Zulip Lloyd McKenzie (Sep 05 2019 at 15:28):

With pattern, if you wanted to, you could define a pattern that included two codings - one from LOINC and one from SNOMED if that's what you really wanted (though be aware that it then wouldn't match if the instance only had a coding match from one of those two code systems).

view this post on Zulip Chris Moesel (Sep 05 2019 at 16:53):

That drives me to the next Part. I've never worked with patterns before. So I am unsure how it can solve my problem...
I thought your problem had to do with multiple levels of slicing; in which case, using a pattern to fix the code means you don't have to slice coding anymore (so now you only have one level of slicing). If I misunderstood the problem, I apologize!

I somehow missed that you were using a LOINC code and a SNOMED code together for each component's code property. If you want to enforce that they both must be there, then pattern[x] still seems the appropriate choice. If you want to enforce that either the LOINC code or the SNOMED code is there, then the best approach may be to define value sets grouping the like codes and bind to those -- although @Rob Hausam is better qualified than I am to comment on that.

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 17:19):

@Rob Hausam What I meant was, that e.g. LOINC-Code 39126-8 and SNOMED CT-Code 401238003 both code the wound length. Probably I expressed myself a little bit confusing.

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 17:20):

The loinc code shall be mandatory, the snomed ct code or other codes shall be optional. Probably this makes it easier.

view this post on Zulip Lloyd McKenzie (Sep 05 2019 at 17:30):

Would the SNOMED codes be captured as components or values?

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 17:33):

in case this might help: https://simplifier.net/posithera/observation-example is an example how we think an observation might look.

view this post on Zulip Lloyd McKenzie (Sep 05 2019 at 17:40):

Ok. And the LOINCs are mandatory. The SNOMEDs are optional. Do you need to mention the SNOMEDs at all in the profile? The base rule is that implementers are free to send whatever SNOMED or other codes they like in addition to the 'mandated' code used for slicing. Unless there's some sort of rule around conformance expectations you want a validator to test, it's probably simplest to not talk to the SNOMED at all or just mention the recommended/preferred SNOMED code it in a comment rather than doing a bunch of complicated profile work that'll make the profile harder to read. Only add complexity if it makes a difference from a tooling/validation perspective.

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 17:47):

It was an idea of one of my colleagues who wanted to show that we can have several codings (LOINC, SNOMED, one of our cooperators in a project) and that we can say which codes to use for each CodeSystem.

view this post on Zulip Lloyd McKenzie (Sep 05 2019 at 18:25):

You can show that in examples and provide guidance in text. That keeps the profiles 'easy'. If you're going to encode it in the profiles, there should be a validation reason for doing it - because it's going to make them harder to read/understand. That said, you can certainly do it.

view this post on Zulip Mareike Przysucha (Sep 05 2019 at 18:26):

Thanks. Then I will change the profile accordingly and provide the example in the implementation guide. Thank you all for your help!


Last updated: Apr 12 2022 at 19:14 UTC