Stream: cda to fhir
Topic: Mapping for Composition.date
Lloyd McKenzie (Jul 20 2017 at 02:19):
In the current mappings, it says that Composition.date (which is when the Composition was last changed) maps to StructuredDocument.effectiveTime. From a pure RIM perspective, I would have presumed StructuredDocument.author.time. Is that not the convention with which the elements are actually used in CDA?
Stephen Royce (Jul 21 2017 at 02:58):
We're using that mapping (StructuredDocument.author.time) in Australia.
Stephen Royce (Jul 21 2017 at 02:58):
Actually, technically, "We're planning to use that mapping..."
Lloyd McKenzie (Jul 21 2017 at 03:31):
@Rick Geimer @Brett Marquard Thoughts?
Brett Marquard (Jul 21 2017 at 03:46):
based on the current definition on Composition.time, author.time is a more appropriate mapping. It is making me question whether we got the definition on Composition.date correct. Will think about it tonight
Rick Geimer (Jul 21 2017 at 13:31):
For starters, in the CDA world how often are ClinicalDocument.effectiveTime and ClinicalDocument.author.time actually different? I usually see them set to the same value in practice, so maybe authoring time becomes an extension in FHIR. 2nd, if we do decide that Composition.time is the authoring time, then we probably need to add Bundle.time to store the actual document creation time (and no, the server modification date is not sufficient, because it could be a historical date).
dr Kai U. Heitmann (Aug 08 2017 at 12:05):
For starters, in the CDA world how often are ClinicalDocument.effectiveTime and ClinicalDocument.author.time actually different? I usually see them set to the same value in practice, so maybe authoring time becomes an extension in FHIR. 2nd, if we do decide that Composition.time is the authoring time, then we probably need to add Bundle.time to store the actual document creation time (and no, the server modification date is not sufficient, because it could be a historical date).
From my (long) CDA experience: I saw almost never a CD.author.time being populated, it is almost always in CD.effectiveTime
Richard Townley-O'Neill (Feb 08 2018 at 01:58):
@Lloyd McKenzie @Rick Geimer @Brett Marquard
Where did this settle?
How does FHIR's Composition.date relate to CDA's StructuredDocument.effectiveTime and StructuredDocument.author.time?
Brett Marquard (Feb 09 2018 at 18:06):
Hi Richard, did you checkout the mapping in the composition resource - http://build.fhir.org/composition-mappings.html
Richard Townley-O'Neill (Feb 12 2018 at 00:36):
Hi Brett
The mappings and definition have not changed since DSTU2. The postings in 2017 left the question unanswered.
I guess the answer is in Rick's post, which I interpret as: CD.effectiveTime maps to Composition.date. As CD.author.time repeats CD.effectiveTime, it also maps to Composition.date, unless it is different and the difference is important, in which case it needs an extension.
Brett Marquard (Feb 14 2018 at 01:34):
Sorry Richard, you are correct, there isn't a current spot for author.time in Composition. I don't remember being pushed to add.
Lisa Nelson (Mar 07 2020 at 13:50):
@Joe Lamy @Brett Marquard @David Riddle
This discussion should also take into consideration the workflow of "on demand documents". This was deeply discussed in the Joint CommonWell-Carequality WG calls and documented in their Implementation Guide. It appears to be a more dominant workflow for document creation than the "create upon completion of the visit". In an "on demand" use case, the author is entering the encounter information in the EHR as the visit is happening (or within a day or two to finish their notes), but no document for information exchange is produced until someone (or some system) asks for it. Once asked (queried) the document is created.
The definition of ClinicalDocument.effectiveTime is: Signifies the document creation time, when the document first came into being. Where the CDA document is a transform from an original document in some other format, the ClinicalDocument.effectiveTime is the time the original document is created. The time when the transform occurred is not currently represented in CDA.
LRN-IMO> I think this means that if an encounter happened on 5/1/2019, and an Encounter Summary document is request and produced by the EHR or some other service on 1/1/2020 by transforming the encounter summary information in the EHR system into a CDA document for exchange of the information, then the ClinicalDocument.effectiveTime of that document should be 5/1/2019, not 1/1/2020 @Joe Lamy can you confirm if this supposition is supported by current implementer practice for Encounter Summary type documents?
So when the "on demand document" is an encounter summary, the clinicalDocument.effectiveTime should equal the encompassEncounter.effectiveTime. However, for a CCD Patient Summary, the clinicaDocument.effectiveTime will be the point in time that the summary information was extracted from the systems, transformed in the CCD format, and loaded into an xml file for exchange. The author of a CCD document is usually a deviceAuthor. However, author.time associated with the information within the document could vary wildly from the ClinicalDocument.effectiveTime. Currently the majority of C-CDA documents being exchanged are CCDs (Over 98%). Thus, often, the author.time of the document should be expected to equal the clinicalDocument.effectiveTime, if you assume you are only processing CCDs with a single author.authoringDevice.
If you start to imagine a world where all relevant authors (and their associated respresented organization) are documented (and assigned an id) once in the header, then more space-efficiently referenced by id from entries within the body of the document, you could end up with a messy relationship between the document author.time and the ClinicalDocument.effectiveTime.
I think we need to ground people to help them think more accurately about what ClinicalDocument.effectiveTime means. Once that is clear, we can determine the better way for thinking about what it should be the same as within a document.
@Joe Lamy Please confirm:
For Encounter Summary documents generated on demand:
ClinicalDocument.effectiveTime = encompassingEncounter.effectiveTime
For a Patient Summary documents generated on demand:
ClinicalDocument.effectiveTime = author.deviceAuthor.time
@David Riddle Perhaps you could include the corresponding fields that this information would map to in the Provenance resource for the Composition Resource.
Lloyd McKenzie (Mar 07 2020 at 16:22):
With FHIR, we typically don't want the creation of on-demand documents. The purpose behind a document is one clinician wanting to tell a story where a human being needs to be in control of the ordering and presenting of information to establish clinical context. Documents are also used when you want a snapshot of data that will be persisted "as-is" for a long period of time and/or where there's need for formal human attestation of a complete set of content. Examples of where these requirements typically occur is pathology reports, discharge summaries, etc.
If you're looking at automatically generating a document, then in most cases, the 'document' aspect is unnecessary and you should instead be using query. With CDA, sharing a document was the only way of sharing data. With FHIR, it's not, so the "automatically package data into a document" is (or at least should be) a much less common flow. By and large, we don't want data flowing in documents because data from documents is harder to integrate - and integrated data is the key to making a real clinical difference.
Lisa Nelson (Mar 11 2020 at 21:35):
I would be interested to hear the Payer perspective on this. I believe the use case for a signed "snap shot" that tells the story of an encounter is a very common use case. @Lloyd, when you say, "By and large, we don't want data flowing in documents", who is the "we?" Who are you speaking on behalf of?
Grahame Grieve (Mar 11 2020 at 21:38):
I agree with challenging Lloyd on that statement. but... everyone wants data to flow. Why should it flow as documents as opposed by other means?
Lisa Nelson (Mar 11 2020 at 21:42):
I see valuable uses for both. I just challenge statements that don't seem to have a balanced perspective on this. There are needs for both document-based information exchange and data focused information exchange. We don't need to steer implementers away from using documents. Better to describe the benefits of each, so implementers can decide what fits their needs better.
Lloyd McKenzie (Mar 11 2020 at 22:56):
I think we should steer implementers away from "documents by default". Documents impose additional costs and challenges that are only sometimes justified. I agree with the notion of a document as a signed snapshot of an encounter (aka discharge summary). But that's not the same as an auto-generated document. It's possible that there's an auto-generation step to form the additional frame, but if you're really going to have a 'document', then a human should be tuning it to actually tell the story. (Computer generation, at least at this point, tells really lousy stories...)
REST interactions make the data queriable and manipulatable in ways that documents don't/can't and are much more use-case independent. There's a reason why much of the early adoption of FHIR has focused on REST rather than FHIR documents. I'm not saying that documents shouldn't be used. But I am saying that the notion of an auto-generated document should be a red flag that raises the question of whether 'document' is really the right paradigm to use.
John Moehrke (Mar 12 2020 at 15:03):
Lloyd, I don't think there is enough evidence to prove your statement of discouraging 'documents by default' when it comes to communications between organizations, especially when it is mitigated by a federated network. The principles of a document become far more important in these cases.
I am not saying it is wrong. I just don't think we have enough evidence to discourage 'documents by default'.
I do agree with the spirit that recommendation FOR 'documents by default' is clearly wrong. Just not clear evidence to discourage
Lloyd McKenzie (Mar 12 2020 at 15:12):
Not sure what sort of evidence you'd be looking for. My assertion is based on both the innate characteristics of the paradigm and demonstrated implementer choice.
Last updated: Apr 12 2022 at 19:14 UTC
