Stream: CCDA / FHIR mapping stream
Topic: Mapping C-CDA author element data to FHIR Provenance
David Riddle (Jan 21 2020 at 15:42):
I am stuggling with what scope of C-CDA author elements should be included as FHIR Provenance for a FHIR resource (Condition, AllergyIntolerance, MedicationRequest, Immunization…) derived from a C-CDA. For example, for an AllergyIntolerance resource derived from a C-CDA Allergy – Intolerance Observation (/observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.7']) that has its own author element, should the Provenance for that AllergyIntolerance be limited to strictly data from that immediate author element, or should additional Provenance instances derived from the Allergy – Intolerance Observation ancestor authors (e.g., the C-CDA Header author element) be associated with the derived AllergyIntolerance resource?
Based on the 'The CDA Header sets context for the entire document. A propagating value specified in the document header holds true throughout the document, unless explicitly overridden' description of CDA Context found here, I believe that an Allergy – Intolerance Observation level author (/observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.7']/author) overrides authors defined at higher levels of that observation’s hierarchy. So setting the Provenance.agent.type.coding.code = ‘author’ (‘A party that originates the resource and therefore has responsibility for the information given in the resource’ - Provenance Agent Types) on the Provenance.agent derived from that observation level author feels appropriate. What is less clear to me, is whether or not it is appropriate to include data from any higher level authors as additional Provenance instances associated with the derived AllergyIntolerance resource, each with their own Provenance.agent and a Provenance.agent.type other than 'author'?
The arguments I have encountered for including higher level C-CDA authors (when a lower level author element exist) as additional Provenance instances are rooted in concerns that end users will expect some form of organization context Provenance to be associated with any clinical concept resource derived from a C-CDA document. The assertion is that when lower level C-CDA author elements do not include a representedOrganization (see the example below), the end users need visibility to any organization context (representedOrganization) defined/available in the ancestor author elements (e.g., parent C-CDA Section and Header author elements). Since a lower level C-CDA author element overrides higher level author elements, it seems clear that under these circumstances, any higher level author/assignedAuthor/representedOrganization is not know to be the “author’s organization” as defined by pg. 6 Office of the National Coordinator (ONC) proposed rule to support the 21st century cures act4 described in the HL7 Guidance: Basic Provenance for C-CDA and FHIR. So when a lower level author element exist, if any Provenance.agents are derived from higher level author elements, they should not have a Provenance.agent.type.coding.code = ‘author’. That said, should the data from any higher level authors be used to associate additional Provenance instances of some non-author Provenance.agent.type (e.g. document author) with a derived clinical concept resource? Is that an appropriate interpretation of C-CDA data and use of the FHIR Provenance resource?
Using the HL7 Allergies Section found here to further flesh out the AllergyIntolerance Provenance example… It seems clear that at a minimum, a single Provenance instance representing the Allergy – Intolerance Observation level author Henry Seven (/observation[templateId/@root = '2.16.840.1.113883.10.20.22.4.7']/author) should be associated with an AllergyIntolerance resource derived from this C-CDA observation.
C-CDA Allergy – Intolerance Observation:
<entryRelationship typeCode="SUBJ">
<observation classCode="OBS" moodCode="EVN">
<!-- allergy observation template -->
<templateId root="2.16.840.1.113883.10.20.22.4.7" extension="2014-06-09"/>
<id root="4a2ac5fc-0c85-4223-baee-c2e254803974"/>
<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>
<text>
<reference value="#AllergyIntoleranceObservation_1.1"/>
</text>
<statusCode code="completed"/>
<effectiveTime>
<low value="20100315"/>
</effectiveTime>
<value xsi:type="CD" code="59037007" displayName="Drug intolerance (disorder)" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<author>
<templateId root="2.16.840.1.113883.10.20.22.4.119"/>
<time value="20140103102500-0500"/>
<assignedAuthor>
<id extension="99999999" root="2.16.840.1.113883.4.6"/>
<code code="207Q00000X" codeSystem="2.16.840.1.113883.6.101" codeSystemName="Health Care Provider Taxonomy" displayName="Family Medicine"/>
<telecom use="WP" value="tel:555-555-1002"/>
<assignedPerson>
<name>
<given>Henry</given>
<family>Seven</family>
</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
Provenance resource derived from this Allergy – Intolerance Observation's author element:
Provenance.recorded = 2014-01-03… Provenance.agent.coding.code = author Provenance.agent.who = Henery Seven…
As indicated above, it is not clear whether or not it is appropriate or recommended to also associate additional, discrete Provenance instances that represent the higher level C-CDA author elements (e.g., the header author, not shown in the HL7 example ) with an AllergyIntolerance resource derived from this C-CDA observation? For sake of argument, assume the header of the document that contained this Allergy – Intolerance Observation included the following author element:
<author>
<time value="20140210111500-0500"/>
<assignedAuthor>
<id root="1.2.777.999900.1.1" extension="1.9.9"/>
<addr nullFlavor="NA"/>
<telecom nullFlavor="NA"/>
<assignedAuthoringDevice>
<manufacturerModelName>Manufacture XYZ</manufacturerModelName>
<softwareName>ABC - Version 3.5</softwareName>
</assignedAuthoringDevice>
<representedOrganization>
<id root="1.2.999.999999.1.99.660.2.9.5.699911" extension="99900"/>
<name>Health System XYZ</name>
<telecom nullFlavor="NA"/>
<addr use="WP">
<streetAddressLine>9999 Main St.</streetAddressLine>
<county>WILSON</county>
<city>Gotham</city>
<state>AR</state>
<postalCode>99999</postalCode>
<country>USA</country>
</addr>
</representedOrganization>
</assignedAuthor>
</author>
Should an additional Provenance resource with the following attributes be associated with the AllergyIntolerance resource derived from this C-CDA?
Provenance.recorded = 2014-02-10… Provenance.agent.coding.code = document author Provenance.agent.who[Device].manufacturer = Manufacture XYZ Provenance.agent.who[Device].deviceName.name = ABC - Version 3.5 Provenance.agent.who[Device].owner.name = Health System XYZ
Drew Torres (Jan 21 2020 at 21:18):
I think there is a hierarchy that C-CDA conveys that should/may be recreated in FHIR. The way I look at it. The “provenance” of the document represents the the responsible party for the document. The section level represent the party responsible for the section. Finally the entry author articulates the party who is responsible for that piece of data.
I think the question to ask… How do you recreate the “section” in FHIR?
In the absence of that…. You have 1 provenance “author" for that allergy…. That allergy has another provenance with an entity that is the document. That DocumentReference resource then will have its own provenance record that can be used.
Lloyd McKenzie (Jan 21 2020 at 23:17):
Sections would be defined in the Composition
Drew Torres (Jan 22 2020 at 00:44):
I think that is only possible when the Allergy lives inside of the section of the composition. If you wanted to represent the allergy as a stand alone resource, what can be done to represent the section for that allergy?
Grahame Grieve (Jan 22 2020 at 00:47):
how can it be in a section if it's standalone?
Drew Torres (Jan 22 2020 at 00:54):
The use-case: An allergy parsed from a C-CDA document.
Drew Torres (Jan 22 2020 at 00:54):
It is then stored in the "Allergies table" of some system.
Drew Torres (Jan 22 2020 at 00:54):
How do you convey the same levels of provenance that the C-CDA did?
David Riddle (Jan 22 2020 at 10:52):
@Andrew Torres is correct. The use-case is not to recreate the entire document using FHIR resources, but rather to 'extract' clinical concepts from the document and represent them as FHIR resource instances.
How do you recreate the "section" in FHIR?
FWIW - On that section question, those arguing for associating the additional higher level C-CDA authors directly with the extracted AllergyIntolerace have proposed the following:
-Create a discrete Provenance instance to represent each author element.
-The Provenance instance that represents the section level author element would have a Provenance.agent.type.coding.code value that conveys the 'section author' concept (the provenance-agent-type value set does not currently include a code that is a semantic match for this 'section author' concept, but the value set binding is extensible).
-Associate each of these Provenance instances directly with the AllergyIntolerace so that downstream consumers do not have to pursue an indirect connection like the DocumentRefernence's Provenance to obtain the higher level author information.
Based on the description of CDA Context found here, my counter argument has been that when author elements are included at multiple levels of the hierarchy, only the author element(s) found at the lowest level of the hierarchy should be expressed as Provenance resources with a direct connection to the extracted resource (a direct connection to the AllergyIntolerace in our example). Furthermore, only those lowest level author(s) represent an author of the resource as defined here: author - 'party that originates the resource and therefore has responsibility for the information given in the resource'
NOTE: It is understood that the FHIR Provenance resource supports 1..* Provenance.agent entries; however, since each C-CDA author element has its own time/@value, discrete Provenance instances for each discrete author element seems necessary to support independent Provenance.recorded values.
Brett Marquard (Jan 22 2020 at 13:10):
@David Riddle This is a great set of questions -- I agree with your last statement '...only the lowest level of the hierarchy should be expressed as Provenance resources..'.. A use case may come forward requiring systems that parse FHIR resources to state that this particular clinical concept was included in a specific document, but on initial glance it's not clear to me how that would help the end user (in auditing, this absolutely must be tracked). Rather, i think it's time we start making it clear the provider organization is required -- this requirement is in the latest US Core Provenance and he new C-CDA Author Provenance Template.
David Riddle (Jan 22 2020 at 13:42):
@Brett Marquard Thank you for your feedback on this.
@Grahame Grieve , @Andrew Torres and @Lloyd McKenzie,
Given my 'extract' clinical concepts from the document and represent them as FHIR resource instances use case, do you agree with this statement?
only the author element(s) found at the lowest level of the hierarchy should be expressed as Provenance resources with a direct connection/association to the extracted resource
Lloyd McKenzie (Jan 22 2020 at 14:02):
Typically you'd have Provenances on the document and then a single Provenance that represented the extraction process from document to allergy. Someone would trace that back to find the document and the full set of Provenances that show the document creation, editing, approval, etc.
David Riddle (Jan 22 2020 at 14:21):
@Lloyd McKenzie
Typically you'd have Provenances on the document and then a single Provenance that represented the extraction process from document to allergy
For further clarification, do you agree that the 'single Provenance that represented the extraction process from document to allergy' would not contain data from higher level C-CDA author elements as additional Provenance.agent entries? i.e., That only the data from the author element found at the lowest level of the hierarchy (the author element found closest to the Allergy - Intolerance Observation) would be included as a Provenance.agent entry on the ''single Provenance that represented the extraction process'.
Lloyd McKenzie (Jan 22 2020 at 14:44):
I wouldn't really expect any of the Provenance data from the original document provenances to be in the 'extraction' provenance. The extraction provenance would talk about the who/what/when/where/why of the extraction process. It wouldn't talk about the origination of the document at all - to see that, you'd need to go look at the provenances tied to the document. If you wanted to convey the AllergyIntolerance with its full story, you'd need the AllergyIntolerance, the Provenance showing its extraction from the document, the document, all of its provenances (some of which might show that the allergy section was itself extracted from elsewhere, etc.
David Riddle (Jan 22 2020 at 15:14):
@Andrew Torres, @Brett Marquard and @John Moehrke ,
It sounds like @Lloyd McKenzie would not create a direct association between a Provenance instance that represents data from the C-CDA author elements and the extracted clinical entity (AllergyIntolerance in our example). He indicated...
It wouldn't talk about the origination of the document at all - to see that, you'd need to go look at the provenances tied to the document
Do you agree?
Lloyd McKenzie (Jan 22 2020 at 16:07):
That's my understanding. @John Moehrke, you're the Provenance expert - do you have comments? :)
Brett Marquard (Jan 22 2020 at 17:00):
@David Riddle Will you carry forward the CDA Allergy author into AllergyIntolerance.asserter? I think it's important to carry forward the CDA entry author
John Moehrke (Jan 22 2020 at 17:17):
I have had the first post in this thread in my backlog to read, still haven't read it... but based on the discussion I will offer the following. Provenance COULD be attached to every resource, covering the full history of that resource back to the origination This is possible... but I don't think that is useful. This is why I am working with Brett on the Basic Provenance to define what is a minimal-viable Provenance use that is more realistic.
I will also point out that we have a concept in FHIR that much of the function of Provenance is often built into the Resource definition when that function of Provenance is fundamental to that Resource. So for example Composition has elements holding who, what, where, when, and why. Thus a standalone Provenance resource instance is not minimally necessary. (see this crosswalk of Provenance functionality to core elements of all the resources -- http://build.fhir.org/fivews )
Thus minimally a Composition likely doesn't need a Provenance at all... But minimally is not always best either. SO I do expect that there will be Implementation Guides that will ask to layer in increasingly more use of Provenance. Stage 1 is likely one Provenance within the Composition Bundle indicating WHEN and by WHOM created that Bundle (which might be the author, or might be an automated process). Stage 2 might be use-case specific where the use-case knows that various sections of the Composition are uniquely assignable Provenance...
John Moehrke (Jan 22 2020 at 17:30):
to be clear, comprehensive Provenance is useful and important at the Medical Record retention; but when data are communicated between parties (e.g. serialized into Composition Bundle) the set of useful Provenance needs to be more realistic.
Lloyd McKenzie (Jan 22 2020 at 18:21):
@John Moehrke The basic question is whether Provenance is expected to be data about a single data-manipulation event or whether it can/should also be used to summarize a whole set of data manipulation events (creation, updates, conversions, redactions, etc.) I certainly wasn't aware that it could be used to summarize multiple events - nor how that could be expressed and distinguished from the first use-case.
John Moehrke (Jan 22 2020 at 18:30):
thanks for the clarity. Each of those lifecycle events would be represented as an independent Provenance, when comprehensive Provenance is recorded. It is possible to have many lifecycle events transition in exactly one FHIR version increment, and when that one update with multiple lifecycle transitions is the responsibility of one agent using one unified set of inputs, then one could record one Provenance for that multiple transition update. But where there are different responsibilities for different parts of the lifecycle transition exist, then multiple Provenance records would be recorded against the same update version.
Lloyd McKenzie (Jan 22 2020 at 18:35):
This would be a situation where the updates happen widely dispersed in time with different participants (and potentially happening on different systems). Is it possible to have a 'comprehensive' Provenance that would squish all of those events into a single record?
David Riddle (Jan 22 2020 at 18:37):
David Riddle Will you carry forward the CDA Allergy author into AllergyIntolerance.asserter? I think it's important to carry forward the CDA entry author
@Brett Marquard ,
Actually I had planned to also map the CDA Allergy author to the FHIR AllergyIntolerance.recorder and the CDA Allergy informant (if included) to the FHIR AllergyIntolerance.asserter. It sounds like you believe that the C-CDA author element(s) found closest to the CDA Allergy - Intolerace Observation align better with the AllergyIntolerance.asserter than the AllergyIntolerance.recorder. Any particular reasoning for that?
Also, due to the cardinality differences between C-CDA Allergy - Intolerace Observation/author 0..* vs. the FHIR AllergyIntolerance.asserter 0..1 and AllergyIntolerance.recorder 0..1, I am going to be forced to pick only data from one of the C-CDA author elements if more than one is associated with the C-CDA Allergy - Intolerance Observation.
All that said, I have a downstream use case that wants to obtain notions of authorship/'source' via. a clinical resource model agnostic mechanism. So rather than have logic that knows for AllergyIntolerance instances it needs to look at AllergyIntolerance.recorder and for Immunization it needs to look at Immunization.informationSource to obtain notions of 'source', the proposal is that the logic could reason with Provenance instances that are directly associated with the clinical resource (AllergyIntolerance, Immunization...) and reason with those Provenance resource instances consistently.
Also, there is a MU regulatory certification test scenario that requires the 'last modified date' defined as either A) the author/time/@value of the document header level author element or B) the author/time/@value of the entity level author (e.g., Allergy - Intolerance Observation/author), to be displayed to the end-user. The proposal was to use a Provenance.recorded value pulled from the C-CDA author/time/@value to meet that need. FWIW - There has been a great deal of contention about that use/interpretation of the Provenance.recorded attribute.
Brett Marquard (Jan 22 2020 at 19:15):
Whoops -- FHIR AllergyIntolerance.recorder is what you want. I went back and re-read the definitions :thinking:
John Moehrke (Jan 23 2020 at 11:08):
sounds like you have use-case driven requirements that make using "some" explicit Provenance records needed. That is the kind of thing that should drive an Implementation Guide to call for specific and explicit use of Provenance. Yes, the ability to have all of these provenance functions using the same Provenance resource does enable generic finding of the provenance; that is a use-case need. However i would caution that just because there are requirements to 'display' something, doesn't mean there is a compelling explicit need for a specific Provenance use. so, I don;t have a decision for you, it must be made by the consensus of your audience.
David Riddle (Jan 23 2020 at 16:16):
@John Moehrke indicated...
However i would caution that just because there are requirements to 'display' something, doesn't mean there is a compelling explicit need for a specific Provenance use
I agree, but using our extracted AllergyIntolerance resource example, I don’t believe there is an attribute on the AllergyIntolerance resource itself that is intended to convey the concept of ‘last modified date’ that we need to display. Using a Provenance resource to track the information (e.g., when and who) about the authorship activity (conveyed in the C-CDA author element) which created or updated the C-CDA Allergy – Intolerance Observation that the extracted AllergyIntolerance instance is essentially a copy of, seems like it aligns with both A) the FHIR Provenance Scope and Usage and B) the ‘3 key Provenance data elements’ (author, author’s timestamp & author’s organization) described on pg. 6 of the HL7 Guidance: Basic Provenance for C-CDA and FHIR.
I feel like this ‘extract C-CDA clinical concepts and transform them into FHIR Resource instances’ use case loosely aligns with the 2.1.3 Use Case on pg. 8 of the HL7 Guidance: Basic Provenance for C-CDA and FHIR. Assuming that is correct, the HL7 guidance indicates that ‘Transformation of data from one format to another does not change the authorship of the information’. Thus the desire to carry forward the CDA Allergy – Intolerance Observation authorship activity using a Provenance resource instance explicitly associated with the derived/extracted AllergyIntolerance resource.
In my mind, the C-CDA Allergy – Intolerance Observation authorship activity that I am trying to propagate forward belongs in its own discrete Provenance resource instance that is separate from any Provenance resource instance intended to track information about the extraction of the AllergyIntolerance resource and from any Provenance resource intended to track information about the authorship of the document that the Allergy – Intolerance Observation/AllergyIntolerance was delivered in/via. I think that aligns with @John Moehrke 's ‘Each of those lifecycle events would be represented as an independent Provenance, when comprehensive Provenance is recorded.’ statement above, but I am not sure. I also am unclear on what constitutes an ‘update version’ or ‘version increment’?
I don’t have a decision for you, it must be made by the consensus of your audience
Understood. I don’t know that I am looking for a decision, but rather some consensus from the FHIR community on whether or not this usage (conversion of C-CDA author element data into Provenance resource instances associated with clinical concept FHIR Resources derived from the C-CDA) aligns with the intended Scope and Usage of the FHIR Provenance resource and if so, whether or not the proposed conversion rules (e.g., the scope of C-CDA author elements to be converted into Provenance and which author elements should be converted to Provenance.agent.type.coding.code = ‘author’) make sense.
David Riddle (Jan 23 2020 at 22:08):
@John Moehrke ,
I have what is hopefully a more focused question for you...
Looking at the example Provenance resource for a Procedure extracted from a CDA here, would it be appropriate to include the CDA document header level author(s) as Provenance.entity.agent(s) with Provenance.entity.agent.type.coding.code = ‘author’? i.e., Would it be appropriate to attribute the extracted Procedure's Provenance DocumentReference entity to the CDA document header author(s)?
The CDA header author(s) did not author/generate the DocumentReference resource, but they did author the document it describes.
Pardon my shorthand below...
"entity": [
{
"role": "source",
"what": {
"reference": "DocumentReference/example",
"display": "CDA Document in XDS repository"
}
"agent": {
"type": "author"
....
}
}
]
John Moehrke (Jan 24 2020 at 13:35):
I think it is well-enough understood that a Provenance and a DocumentReference are metadata resource types holding metadata about the thing they point at. Thus I think it would be understood as you describe. I am however always surprised at how what is logical to me is not how others see it. But, if you documet in your IG that this is what you are doing, then it should be better understood.
Last updated: Apr 12 2022 at 19:14 UTC
