Stream: implementers
Topic: Profile on Bundle or Composition or both
Alexander Henket (Jan 23 2017 at 13:12):
Hi. We're working on a Composition Bundle for spirometry and we're wondering what to profile. Bundle, Composition or both. Looking through the C-CDA on FHIR specs it seems that only the Composition was profiled, but that seems to leave a gap at Bundle level. Any advice appreciated.
Vadim Peretokin (Jan 23 2017 at 13:14):
What do you mean by "leave a gap at Bundle level"?
Alexander Henket (Jan 23 2017 at 13:15):
without a Bundle profile, I can send a Bundle with a different Composition, of a different Bundle.type etc.
Vadim Peretokin (Jan 23 2017 at 13:22):
Why? You could specify multiple profiles in http://www.hl7.org/FHIR/elementdefinition-definitions.html#ElementDefinition.type.profile, including one for a Bundle
Alexander Henket (Jan 23 2017 at 13:23):
Question is whether or not to create a profile for Bundle at all, not howto when I do :-) So you are advising me to create a Bundle profile here?
Vadim Peretokin (Jan 23 2017 at 13:24):
Nope. I didn't understand your original question and now I understand that you saw a flaw with their profile
Vadim Peretokin (Jan 23 2017 at 13:25):
I'd go for a Composition as well, but I don't know your data model...
Alexander Henket (Jan 23 2017 at 14:39):
So you would not profile the bundle to reference the composition profile explicitly.
Vadim Peretokin (Jan 23 2017 at 14:53):
I'd profile the reference for a composition or the resource for a bundle either way. Though putting a bundle into a composition to begin with seems redundant to me, but perhaps your data model dictates that's the best.
Alexander Henket (Jan 23 2017 at 14:58):
No, we're not reading eachother well :-) This is the thing:
Bundle
Bundle.entry.resource.Composition
Bundle.entry.resource.Observation (panel)
Bundle.entry.resource.Observation (FEV1 observation)
Bundle.entry.resource.Observation (0..* other panel observations)
Bundle.entry.resource.Organization (producer)
Bundle.entry.resource.Patient
...
Composition profile will tell me what other spirometry panel resources I need/can have. So at minimum I need a Composition profile. But... Composition is not the entry resource: Bundle is. So: without a Bundle profile, I need to inspect the Bundle.type and Bundle.entry.resource.Composition.meta.profile before I know what validation/processing I need to load.
Vadim Peretokin (Jan 23 2017 at 15:07):
Ack, sorry, the error is on my part and I see what you mean now. Creating a profile on Bundle would be a nice solution to this, agreed. It would cover off both identification at runtime and constraint validation.
Alexander Henket (Jan 23 2017 at 15:57):
That's what I thought, but then I found that C-CDA on FHIR did not do this and I starting doubting
Lloyd McKenzie (Jan 23 2017 at 16:14):
You don't really need to profile the entries in the Bundle beyond the first as you can (and should) use the "aggregation" property on your various Reference elements to flag what should be in the bundle vs. not. So a single generic profile for FHIR documents (we should probably do that at the international level) plus a more restrictive profile that says "this document instance must have a Composition that complies with profile X" should be sufficient.
Alexander Henket (Jan 23 2017 at 16:20):
Would StrucDoc be open for defining such an international profile? It would be nice indeed
Alexander Henket (Jan 23 2017 at 16:26):
Just checking: is it possible to leave open at panel level whether or not stuff is bundled, and specify at Bundle or Composition level that all immediate references and references in references shall be bundled? The only way to specify that in my mind is an invariant, right?
Lloyd McKenzie (Jan 23 2017 at 17:36):
Hi Alexander,
Lloyd McKenzie (Jan 23 2017 at 17:37):
The base document profile would presumably enforce that the core composition references would be within the Bundle. No need to use an invariant. I'm not clear on whether references inside extensions on Composition must be in the bundle too.
Alexander Henket (Jan 23 2017 at 20:41):
This might be me but I'm not reading that http://build.fhir.org/elementdefinition-definitions.html#ElementDefinition.type.aggregation is a recursive statement. I.e. it would control the current reference, but I do not read that if the referred resource in turn contains references, that these also shall be bundled. If that is the intention then a tracker item for clarification is in order
Last updated: Apr 12 2022 at 19:14 UTC
