Stream: implementers
Topic: Paradigms
René Spronk (May 16 2017 at 08:34):
Looking at the various Paradigms supported by FHIR, wouldn't it be better to call them: CRUDS, Composition, Message and Service ? REST isn't an architecture (REST implies CRUDS, but not the other way around), CRUDS could be implemented on other protocol stacks. Document implies text whereas one may wish to do Compositions without text (CDA is a profile on Composition which requires text).
Grahame Grieve (May 17 2017 at 06:01):
probably technically more accurate if you pust CRUDS+HTTP but who knows what that means?
René Spronk (May 17 2017 at 15:00):
So what's the HTTP architectural aspect that one wouldn't have when implementing CRUDS (let's say) as 5 webservices ? What does it add (from an architectural standpoint) beyond CRUDS ?
Lloyd McKenzie (May 17 2017 at 16:29):
From a marketing perspective - and a recognition perspective - I think it makes sense to stick with the term REST
René Spronk (May 18 2017 at 07:44):
@Lloyd McKenzie In training courses the Architects keep hammering me - which is why I'd really want to move away from using REST as the name of a paradigm. "CRUDS (over HTTP)" or "CRUDS (based on REST)" are probably things I can get away with.
Grahame Grieve (May 18 2017 at 07:45):
so change your slides...
René Spronk (May 18 2017 at 07:49):
Nobody commented on the suggested change from Document to Composition, i.e. allowing for compositions that don't have text in their "sections" versus documents (a profile thereof which requires text). We're seeing use cases (e.g. NHS Digital) where sections have no text, receivers can create text if it so pleases them. To allow for Documents without text is a bit of a misnomer, hence the suggestion to use Composition.
Grahame Grieve (May 18 2017 at 09:52):
I don't understand what you think is different there
René Spronk (May 18 2017 at 12:13):
In the mind of most people, a "document" contains text. A composition may consist of sections (without text) and entries, and as such may not contain any text. So the paradigm (in my mind) is "Documents (with or without text)" or "Composition" whereby the latter has the advantage/disadvantage that to most who read the term it'll be an entirely new one. If we call it Document we'll have to subsequently tell them that documents may have no text, which goes contrary to expectations. From a pure marketing standpoint Document works better, for it's the more familiar one in healthcare.
John Moehrke (May 18 2017 at 15:04):
I think the larger majority (silent) is fine with the use of RESTful. I don't think CRUDS is all that more helpful.
Lloyd McKenzie (May 18 2017 at 16:09):
If we're talking about a FHIR Document, we're talking about text and human-readability. That's an intrinsic part of the paradigm. We don't have the notion of passing around arbitrary bundles
Lloyd McKenzie (May 18 2017 at 16:09):
(Unless we're doing messaging, services or REST)
Grahame Grieve (May 18 2017 at 18:10):
so a composition that doesn't have text but is still wrapped up inside a document bundle? Why would it be useful to do that if the composition doesn't have any text int it?
René Spronk (May 19 2017 at 07:03):
Why do 13606 or OpenEHR do compositions? It's not because of the textual part, it is the fact that one creates a hierarchical structure of selected FHIR resources that are semantically grouped (and profiled) into sections and subsections. That's a very specific kind of bundle.
Text is not essential in such a context. There is no trigger event, and it's client side orchestrated, so no, that's not messaging.
This reflects how the NHS is currently using composition, it reflects most of the use of CCDA and CCD (where any text is basically ignored by almost all recievers, who just strip out the coded entries). We need to reflect the actual use of such structures in the FHIR standard itself. Insisting that text shall be present seems a folly - one can create a profile that requires text (that would be the CDA on FHIR profile), but out of the box a section should not require text, just as resources in general are not required to have text.
This thread proposed to call the wider architectural paradigm "Composition" (i.e. with or without text), and to use "Document" for a profile on "composition" which requires text.
Grahame Grieve (May 19 2017 at 09:44):
so I think you are still talking about packaging things up in a bundle of type document, but without text, and without the document obligations.
Grahame Grieve (May 19 2017 at 09:45):
if so, that's wrong. it's not Document. It should be Bundle of type collection. and then it's perfectly legal
René Spronk (May 19 2017 at 12:17):
I missed the fact that collection has been added, but OK, let's call it that at the bundle level. I can include hierarchies based on Composition and Section within it - but those still require text.
Why does Composition have to be a document and have text ? If I replace document with package or structure in its definition everything still holds true:
"A set of healthcare-related information that is assembled together into a single logical <strike>document</strike> <add>package</add> that provides a single coherent statement of meaning, establishes its own context and that has clinical attestation with regard to who is making the statement. While a Composition defines the structure, it does not actually contain the content: rather the full content of a <strike>document</strike> <add>package</add> is contained in a Bundle, of which the Composition is the first resource contained."
Lloyd McKenzie (May 19 2017 at 14:03):
Collections have no notion of sections and subsections. The organization of the data in a Collection would not be hierarchical, it would be an interlinked web. So far, FHIR does not support the organization of data into a hierarchy for exchange except for human-readability purposes. And I can't conceive of a use-case where imposing a hierarchy on naturally non-hierarchical data would make sense for computability purposes.
Lloyd McKenzie (May 19 2017 at 14:03):
So we'd need to start with a use-case. And the use-case would need to move beyond "other standards have done this".
Grahame Grieve (May 19 2017 at 17:30):
"Why does Composition have to be a document and have text" - it doesn't. Only when used in a document in the document paradigm do document expectations apply. You can - and we do - use Composition in the other paradigms. You could create a task to clarify the latter part of the text you quoted, that those rules apply to it's usage in the Document context
René Spronk (May 20 2017 at 07:39):
Done - http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=13426
@Lloyd McKenzie Use cases include epSOS, where the burden of generating human narrative is up to the receiver because of language differences between the EU countries; English NHS which burdens the receiver with creating a visualisation of the data (they have good profiling at the resource level, so a receiver can be expected to create clinically safe text); most of CCD/CCD-A where receivers ignore the narrative, they're only interested in the structured data.
As for why people would choose a "hierarchical collection" instead of a "meshed net of resources": I guess the human mind works that way (grouping items), and with-the-CDA-templating-mindset (which I know some FHIR core team members to abhor): sections are easier to profile than meshed nets of interlinked resources.
Lloyd McKenzie (May 20 2017 at 13:26):
My question is "what's the purpose of a table of contents if you don't have human readability?". You can share all of the discrete data without imposing the burden of sections and sub-sections. Sections and subsections have no value computably - their sole purpose is organizing the narrative content for presentation. If a receiver is expected to generate their own narrative, why can't they also generate their own hierarchy based on their own conventions? In FHIR terms, why not just send the underlying resources and let the receiver generate the composition structure? Because it's not as though you have a proper attestation of known content by the sender if you don't have the text the sender actually saw.
René Spronk (May 20 2017 at 17:03):
I agree that computably there's little difference in terms of overall semantics. But it's not about that, it's about the human aspect. If one likes to work top-down (pick the 5 most relevant resources [and associated leaf-resources] for categories (sections) x, y, z) appeals to some, whereas other may go for a fully meshed interconnected set of resources.
Personally I don't care either way, they are just 2 different ways of organizing the data, and more important yet, 2 rather different views on how one wishes to do profiling. If one cares to profile (in v3 speak) clinical statements at the section level, a hierarchy is the way to go for. If you wish to do profiling (only) at the individual resource level, a fully meshed interconnected set of resources will be your thing.
Most importantly to me, I see the use-case, so I just want to make sure FHIR supports it next to documents-which-require-text-and-have-other-CDA-like-doc-properties (like attestation).
Grahame Grieve (May 20 2017 at 19:40):
sure it supports it. Other than the loose wording you quoted that implied that Composition is only used in documents, I haven't seen any other problem - nor is it a problem with the paradigms, to me.
René Spronk (May 21 2017 at 06:51):
I don't see a problem with the current paradigms; but if one starts thinking about the use of Composition as part of a collection-bundle (for which we effectively already have implementations, although these still use the document bundle without any text anywhere), or Compositions as the focal resource of a FHIR message (could be useful, have to think about that one), aren't we introducing new paradigms? I don't think so.
This thread started with the thought of renaming some of the paradigms. CRUDS (REST) will probably be the name I'll use for one of them, the other is likely to become either "Compositions (Documents, Hierarchical collections)" or (for marketing/simplicity reasons) "Documents (with & without text)"
Grahame Grieve (May 21 2017 at 09:43):
so I don't think that it's write to change the Document paradigm to allow for non-document behaviour. I just think that using Composition like this is something else. Perhaps it's not a documented paradigm per se, but I'm not sure that's a problem
René Spronk (May 21 2017 at 11:32):
agree - although if we start seeing use of the paradigm in production we'll have to add some documentation, probably as a new paradigm.
Last updated: Apr 12 2022 at 19:14 UTC
