Stream: cimpl
Topic: Nested Sections Bug
Kurt Allen (Jul 16 2019 at 23:53):
Hello @Chris Moesel and @Mark Kramer
I think there may be a bug in how nested Composition sections are handled. I create a section called "Findings", and then create two sections under findings (Left Breast Finding" and "Right Breast Finding". Finding gets created correctly, but it looks like the sub sections never get created, and Findings.Section is not sliced for left and right. Could this have anything to do with my mapping? I have attached the CIMPL and map file.
Alternately, you can grab the whole project at
https://github.com/applicadia/Fhir-BreastRadiologyReport
Thanks!
Kurt A.
BreastRadiologyDocument.txt BreastRadiologyDocument_map.txt
structuredefinition-breastrad-BreastRadiologyDocument-extension.json
structuredefinition-breastrad-BreastRadiologyDocument.json
Chris Moesel (Jul 17 2019 at 14:09):
Hi @Kurt Allen
The mapping for composition is missing a slicing directive for section. If you look at the Composition mapping in obf_foundation_map_r4.txt, you need to change the line that maps section to this:
Section maps to section (slice on = code; slice strategy = includes)
This will tell it to slice sections using code as the differentiator -- and that the CIMPL includes constraint defines what the slices are.
Note that the latest mappings in our shr_spec dev6 branch already contain this fix here and also contain some other fixes that may benefit you (for example, fixes to invalid value sets that get reported in the IG qa.html). If possible, you may want to consider updating all of the definitions you copied over from us (like obf, shr.core, etc) so you can benefit from our recent updates.
After applying the mapping change above, I found that your BreastRadiologyReport seemed more like you would expect. Here's a partial screenshot of the results:
Kurt Allen (Jul 17 2019 at 17:25):
Yo @Chris Moesel
I must be doing something wrong here. I got the latest shr-spec from git, copied it over and deleted the deprecated*.txt files (they caused compile errors), rebuilt shr-cli (6.2.2 #219) and reran everything.
I get a findings section, but no FindingsLeftBreast or FindingsRightBreast.
Attached is the html file, and the git hub repo is up to date (development branch).
Also, FYI: I tried getting 6.3, but had compile errors in the shr-spec files. I see that you tightened type checking (yah!!!) and some of the shr-spec files had some issues. 6.3 showed me some errors in my code that I needed to clean up,so kudos on 6.3, but shr-spec probably needs some attention.
Any ideas?
Best,
Kurt A.
Breast-Radiology-Reporting.html
Chris Moesel (Jul 17 2019 at 17:50):
Hi Kurt. Yes, 6.3 was just released today and the spec team is catching up on fixing some of the type inconsistencies it brings to light. I expect the fixes will be pushed to shr_spec soon.
As for the continued issue w/ the Findings, I'll take a look. I'm not sure why you'd get something different than I get.
Kurt Allen (Jul 17 2019 at 18:08):
thx
Chris Moesel (Jul 17 2019 at 18:19):
Oh... I see now. You're using sub-sections. In the master branch (that I originally tested with), FindingsLeftBreast and FindingsRightBreast were in the top-level sections. But I see here that you are now employing nested sections, so Findings is the top-level section and the left/right breast findings are a nested section within that.
Hopefully we can support that! It will require at least some additional mapping... I'm working on it -- but if you don't hear from me for a while it's because I'm currently in an airport and due to board soon.
Chris Moesel (Jul 17 2019 at 18:24):
OK. It looks like I got it to work. I'm assuming you don't want to modify the files that we (the SHR team) provide, so... you can update the specific BreastRadiologyDocument mapping to be this:
Grammar: Map 6.0
Namespace: breastrad
Target: FHIR_R4
BreastRadiologyDocument maps to Composition:
Section.Section maps to section.section (slice on = code; slice strategy = includes)
Section.Section.Title maps to section.section.title
Section.Section.Code maps to section.section.code
Section.Section.Author maps to section.section.author
Section.Section.FocalSubject maps to section.section.focus
Section.Section.Narrative maps to section.section.text
Section.Section.Type maps to section.section.mode
Section.Section.SortOrder maps to section.section.orderedBy // terrible FHIR name!
Section.Section.DomainResource maps to section.section.entry (slice on = reference.resolve(); slice on type = profile; slice strategy = includes)
Section.Section.EmptyReason maps to section.section.emptyReason
Section.Section.Section maps to section.section.section
You can see that I essentially just mapped one more level down. You'd need to continue to do that for each level of section you need. We probably need to figure out a way to define recursive mapping statements! Anyway, that worked for me. Hopefully it will work for you too!
Chris Moesel (Jul 17 2019 at 18:25):
(FYI -- it inherits all the other mappings from the parent mapping, which is why I just have the new mappings defined above)
Chris Moesel (Jul 17 2019 at 18:25):
Gotta get on my plane. Good luck!
Kurt Allen (Jul 17 2019 at 20:29):
Hey @Chris Moesel
Looks like that worked.
This approach might get cumbersome if nesting gets very deep. I wonder if you don't need to add some form of mapping resource fragments like
BreastRadiologyDocument.Section maps to Composition.section:
...
and then this mapping could be applied recursively to itself unless explicitly overruled in a specific rule for a specific nested element.
(i.e. BreastRadiologyDocument.Section.Section, BreastRadiologyDocument.Section.Section.Section, ... would all have BreastRadiologyDocument.Section applied to them since they are all BreastRadiologyDocument.Section's)
Just a thought.
Anyways, this item is fixed and many thanks. Hope your flite is extremely uneventful and that you are flying somewhere fun!
Best,
Kurt A
Chris Moesel (Jul 17 2019 at 22:48):
Yeah, I was thinking maybe something along those same lines. We'd have to think on it a bit more... We're also considering a significant rewrite of the mapping language -- so maybe a new grammar would lend itself to a more obvious solution as well.
Last updated: Apr 12 2022 at 19:14 UTC
