Stream: implementers
Topic: bundle.type qualities
Jens Villadsen (Aug 30 2018 at 08:10):
Should a bundle with bundle type valueset document be treated as a transaction? It seems a bit fluffy that there are valuetypes (eg. transaction and batch) that describes the behaviour of how the collection of elements should be handled mixed with what is contained (document and message). Ain't that two different qualities that mixed together? Is it not something that is orthogonal on eachother and should not be mixed?
Lloyd McKenzie (Aug 30 2018 at 08:16):
What gets done with a Bundle depends on what you do with it. If you POST it to the Bundle endpoint, the base expectation is that you'll store it as-is. However, a system MAY choose to process it as a transaction too - creating or updating resources at various other endpoints based on the content of the Bundle. If you POST the document to the root endpoint, then some servers might opt to treat the Bundle as a transaction, though without the specific instructions on whether to POST or PUT the data, the server would have to make up its own business rules. And of course, the server would be well within its rights to reject the POST as invalid. In general, the only thing that you can count on being treated as a transaction is a Bundle of type "transaction". The primary purpose of a document Bundle is to be stored and to be rendered in a particular way.
Jens Villadsen (Aug 30 2018 at 08:18):
Where does the spec say anything about rendering of document Bundles?
Jens Villadsen (Aug 30 2018 at 08:22):
would you agree to the fact that how and what are sort of mixed together in this valueset?
Lloyd McKenzie (Aug 30 2018 at 08:24):
It's all about the "what". A transaction and a document are different things. The rules around processing documents is here
Jens Villadsen (Aug 30 2018 at 08:31):
you stated that servers MAY choose to process documents as transactions too - which makes sense to me - and this in my perspective qualifies as how.
Jens Villadsen (Aug 30 2018 at 08:42):
to me it seems a bit shoehorned that there is a special transactional type for bundles containing a composition (given that one can treat a document as a transaction) - but it might just be the special case that makes the world spin. And why must composition be the first resource? Wouldn't it be adequate to say that it must contain at least one or only one? Is the order important?
Lloyd McKenzie (Aug 30 2018 at 08:43):
Processing a document as a transaction is an unusual thing. Servers can do whatever they like. But if something is a document, the expectation is that it'll be processed like a document - i.e. stored and rendered.
Lloyd McKenzie (Aug 30 2018 at 08:43):
Composition must be the first resource because it's the anchor for the content. It defines how the document is rendered and provides all the metadata needed when searching for the document.
Jens Villadsen (Aug 30 2018 at 08:45):
but you would like the document being processed by a server as an atomic commit, right?
Jens Villadsen (Aug 30 2018 at 08:53):
Composition must be the first resource because it's the anchor for the content. It defines how the document is rendered and provides all the metadata needed when searching for the document.
The need you describe only require the composition to be within the bundle. It does not describe a need for it to be first
Lloyd McKenzie (Aug 30 2018 at 08:53):
No. When you post adocument, you want it stored as a Bundle
Lloyd McKenzie (Aug 30 2018 at 08:54):
Making the composition first means that servers don't have to wade through a Bundle of 100+ resources looking for it.
Lloyd McKenzie (Aug 30 2018 at 08:55):
Documents are "special", just like messages and history and all the other types of Bundle. Each has rules around what content is expected to be present and where it's expected to appear. Those rules allow the behaviors associated with those types to be performed appropriately and efficiently.
Jens Villadsen (Aug 30 2018 at 08:59):
Making the composition first means that servers don't have to wade through a Bundle of 100+ resources looking for it.
if the argument is for performance reasons wouldn't it be suitable to suggest an order for all resources in all types of bundles - e.g. patients before encounters and so on?
Lloyd McKenzie (Aug 30 2018 at 09:06):
There's no general purpose rule for a transaction bundle - we have no clue what they might contain. But a Document will always contain one "defining" Composition. And that Composition is key to it being a document. (In fact, in some rare cases, a document Bundle could theoretically contain multiple compositions, so insisting that the defining one be first has additional importance.)
Lloyd McKenzie (Aug 30 2018 at 09:07):
There's no ordering of the content within a document bundle beyond the requirement that the defining Composition must come first (just as the MessageHeader must come first in a message Bundle).
Jens Villadsen (Aug 30 2018 at 09:08):
There's no general purpose rule for a transaction bundle - we have no clue what they might contain. But a Document will always contain one "defining" Composition. And that Composition is key to it being a document. (In fact, in some rare cases, a document Bundle could theoretically contain multiple compositions, so insisting that the defining one be first has additional importance.)
A document bundle cannot pr. spec contain multiple compositions - that would violate the rule about it having to be first as both cannot be first
Jens Villadsen (Aug 30 2018 at 09:09):
There's no ordering of the content within a document bundle beyond the requirement that the defining Composition must come first (just as the MessageHeader must come first in a message Bundle).
I cant see the need for the MessageHeader to come first either
Lloyd McKenzie (Aug 30 2018 at 09:10):
Where does the spec say that multiples are prohibited? The defining Composition must be first, but I don't see any rule prohibiting others.
Lloyd McKenzie (Aug 30 2018 at 09:11):
When you're processing a message, the first thing you want to see (so you know whether you even want to process it or not) is the MessageHeader. Having the MessageHeader anywhere else in the instance is just inefficient.
Jens Villadsen (Aug 30 2018 at 09:12):
I'd rather spec those extra bucks on a CPU doing the traversal of +100 resources than spending time on development tuning my serializer to enforce a rule about certain elements to come first - but that is a subjective matter of opinion.
Lloyd McKenzie (Aug 30 2018 at 09:15):
Well, if you're serializing a document, the root object that you're working with is going to be the Composition, so making it the first entry in the Bundle should be a pretty natural thing to do. (Same for MessageHeader and a message)
Jens Villadsen (Aug 30 2018 at 09:16):
Well, if you're serializing a document, the root object that you're working with is going to be the Composition, so making it the first entry in the Bundle should be a pretty natural thing to do. (Same for MessageHeader and a message)
- back to my performance argument. I would either buy more CPU - or globally define a relational order for all elements - but that is my own subjective opinion
Jens Villadsen (Aug 30 2018 at 09:18):
Where does the spec say that multiples are prohibited? The defining Composition must be first, but I don't see any rule prohibiting others.
I'm in deep water here and I wouldn't expect multiple compositions. If there exists something as a 'defining' composition, I would suggest it to be modelled in the datafields - not in the order I read it
Lloyd McKenzie (Aug 30 2018 at 09:27):
Breaking out the Composition or MessageHeader as separate elements would introduce a significant amount of other complexity - as you'd then have to handle those resources pointing to entries in the Bundle and entries in the Bundle pointing to them. On balance, requiring that the "special" resources come first is much simpler. Order has to be retained and order is allowed to have significance. We take advantage of that where we need to. (Just as we require that the "first" name of a Patient is the first repetition of Patient.name.given...)
Last updated: Apr 12 2022 at 19:14 UTC
