<style>.markdown-body { max-width: 1500px; }</style>

The metadata, or extra information about data, regarding who created the data and when it was created.

## :new: Provenance Data Elements

<!-- image of summary of changes-->

Draft

Final

<!-- markdown table summary of proposal use adobe to convert to excel and then script to markdown or just copy/paste -->

DATA ELEMENT|APPLICABLE VOCABULARY STANDARD(S)<br/>Standards listed are required. If more than one is listed, at least one is required unless otherwise noted. Where an applicable vocabulary standard has not been identified, this field will remain empty.|US Core V8 Proposal
---|---|---
**Author** <br/>Actor that created or revised the data.<br/><br/>Usage note: The actor may be a provider, a patient, a device, an outside medical record, or something else. The source of the information can be used to form assessments about its quality, reliability, trustworthiness, or can indicate where to go to determine the origins of the information. || 1. The - [US Core Provenance Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-provenance.html) already supports [agent:ProvenanceAuthor](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-provenance-definitions.html#Provenance.agent:ProvenanceAuthor "Slice ProvenanceAuthor")and is used to assert changes to the record at the *organizational level*.<br /> 2. **Original strawman proposal:** ~~Update `agent.who` US Core Practitioner and Patient target references to *Must Support*~~ <br />:point_right: **New strawman proposal:** Because systems typically do not represent this information for patients and practitioners in FHIR using "big-P" Provenance, use the various FHIR resources' existing elements that track the "small p" provenance* at the *individual level*. Propose adding a mapping table to the [Provenance page](#) that documents these "small-p" provenance data elements. See the [Mock up](#) and [background](#Provenance-Background) below.
**Author Role**<br/>Category of actor that participated in the creation or revision of data.<br/><br/>Usage note: The source of the information can be used to form assessments about its quality, reliability, trustworthiness, or can indicate where to go to determine the origins of the information. <br/><br/>Examples include but are not limited to provider, patient, family member, and device. || **Original strawman proposal:** ~~:new: Update [US Core Provenance Profile](https://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-provenance.html) to support `Provenance.agent.role` as an 𝗔𝗗𝗗𝗜𝗧𝗜𝗢𝗡𝗔𝗟 𝗨𝗦𝗖𝗗𝗜 Element~~ <br />:point_right: **New strawman proposal:** The author role is typically implied by the resource type referenced (e.g. Patient, Practitioner/PractitionerRole, RelatedPerson, Device). Except for Device, more details about the role are contained the resource contents (e.g.RelatedPerson.relationship). See the [Mock up](#) and [background](#Provenance-Background) below.

<!-- ### ONC Requested Specific Feedback

ONC seeks feedback on the new _Author_ and _Author Role_ data elements that would be added to the Provenance data class, specifically, whether there is sufficient implementation across health IT developers.
-->
### USCDI5-Sandbox Mockup Proposal to Adding Author Mapping for all US Core Resources to the Provenance Page

#### Existing [US Core Provenance](https://hl7.org/fhir/us/core/basic-provenance.html#key-provenance-elements) Guidance

> ... agreed the most important information is the last organization making a meaningful clinical update to the data and the prior system providing it - the ‘last hop’.

...

>The Author represents the person(s) responsible for the information.

...

> The HL7 Basic Provenance Informative implementation guide outlines four use cases: Fax, Health Information Exchange (HIE) redistribution, HIE transformation, and Clinical Information Reconciliation and Incorporation (CIRI).

#### Proposed Mappings to Incorporate into Guidance

State that the resources elements provide additional "small -p" provenance Mappings identify the author and author roles.

US Core Profile|USCDI Provenance Author Data Element (e.g., the source)|USCDI Provenance Author Role Data Element|Comment|
|---|---|---|---|
|[US Core Condition Problems and Health Concerns Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-condition-problems-health-concerns.html)|`Condition.asserter`|resource type referenced (Patient, Practitioner/PractitionerRole, RelatedPerson)|vs the "creater/updater"`Condition.recorder`
|[US Core MedicationRequest Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html)|**`MedicationRequest.requester`***|resource type referenced (Patient, **Practitioner***/PractitionerRole, Organization, RelatedPerson, Device)|the "source" of the secondarily reported information **`MedicationRequest.reportedReference`***
|[US Core Procedure Profile](https://hl7.org/fhir/us/core/StructureDefinition-us-core-procedure.html)|`Procedure.asserter`|resource type referenced (Patient, Practitioner/PractitionerRole, RelatedPerson)|vs the "creater/updater"`Procedure.recorder`

\* **Must Support US Core element**

:point_right:["Small-p" Provenance Table for all US Core Profiles](https://1drv.ms/x/c/deea5e002be8d274/EazOGawVCEBBjJmfJXcI5DQBKbAXNqHGcHr4ioRM6s2m0g):point_left:

not in table - Out of Scope:

- US Core Encounter ( US Core use big P Provenance - for org)
- US Core Location
- US Core Organization
- US Core Practitioner
- US Core PractitionerRole
- US Core RelatedPerson
- US Core Medication
- US Core Provenance
- US Core CareTeam
- US Core Coverage
- US Core Specimen

meddisp => performer

Next Steps:

- Discuss adding these elements as *Must Support/Add'l USCDI*
- Discuss adding *MustSupport* on the target resources:
- US Core Patient
- US Core Practitioner
- US Core PractitionerRole
- US Core RelatedPerson
- US Core Organization
- US Core Device
- If not adding *Must Support/Add'l USCDI* then what guidance do we give to meet the requirement?

...

### Known Issues with This Approach

1. What is the USCDI Author? - the "creater/updater" or the "source" of the information? The definition uses both terms and it conflates the notion of a "recorder" vs "source".


- This question does not go away with "big-P" Provenance approach either :thinking_face:

2. Mappings to optional elements and targets, in other words not Must Support elements. Therefore with this approach is follows that we make the elements and the particular reference types Must Support.

for example:


...

<!--
source: https://github.com/Healthedata1/USCDI4-Sandbox

#### US Core Provenance Profile

<iframe width="100%" height="500" src="https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-provenance.html" frameborder="10"></iframe>

source: https://healthedata1.github.io/USCDI5-Sandbox/StructureDefinition-us-core-provenance.html

#### Example

<iframe width="100%" height="500" src="https://healthedata1.github.io/USCDI5-Sandbox//Provenance-79614.html" frameborder="10"></iframe>

source: https://healthedata1.github.io/USCDI5-Sandbox//Provenance-79614.html

### Known issues

1. Terminology choices:

Option 1 (see mock-up) Use the [C-CDA author provenance and role value sets](https://build.fhir.org/ig/HL7/CDA-ccda/StructureDefinition-ProvenanceAuthorParticipation.html) as *example* and *preferred* additional bindings.
Using NUCC codes for clinician roles

However, the preferred binding for [Healthcare Provider Taxonomy](https://vsac.nlm.nih.gov/valueset/2.16.840.1.114222.4.11.1066/expansion) are [NUCC](https://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40) and in US Core, we changed the bindings for `CareTeam.participant.role` and `PractionerRole.code` from NUCC to [Care Team Member Function](https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.30/expansion) (SNOMED CT) for internal consistency and due to concerns raised by AMA (who own NUCC) about using it for roles instead of "qualifications and licensures." CCDA has been using NUCC codes for 15 yrs and seems to be the preference for payers too.

Option 2. Same as option 1 but use *Care Team Member Function* instead of *Healthcare Provider Taxonomy* for the additional clinician binding for internal consistency and to avoid issues with AMA. The downside of this decision is that we are not consistent with CCDA and payers who use NUCC. (NUCC to SNOMED CT role mapping?)

The *example* terminology binding for the base FHIR Provenance is [Security Role Type](https://hl7.org/fhir/R4/valueset-security-role-type.html). It underwent radical change in R5.

2. :thinking_face: Update `agent.who` US Core Practitioner and Patient target references to *Must Support* ( see comment by Isaac )

### Decisions

- Add Author Mapping for all US Core Profiles resources elements provide additional "small -p" provenance for the author and author roles.

### IG Updates

- [ ] USCDI Mapping Table
- [ ] Update US Core Profile
- [ ] Implementation Specific Guidance
- [ ] New Example(s)
- [ ] Update Example(s)

## Provenance Background

### Provenance in FHIR

>The Provenance resource tracks information about the activity that created, revised, deleted, or signed a version of a resource, describing the entities and agents involved. This information can be used to form assessments about its quality, reliability, trustworthiness, or to provide pointers for where to go to further investigate the origins of the resource and the information in it.

> Provenance resources are a record-keeping assertion that gathers information about the context in which the information in a resource was obtained. Provenance resources are prepared by the application that initiates the create/update etc. of the resource.

> Many other FHIR resources contain some elements that represent information about how the resource was obtained, and therefore they overlap with the functionality of the Provenance resource. These properties in other resources should always be used in preference to the Provenance resource, and the Provenance resource should be used where additional information is required, or explicit record or provenance is desired. Details on this overlap can be found on the FiveWs, including a mapping from the at the Resource Element level.

In FHIR, the various FHIR resources to track the the "small p" provenance* information at the *individual level*, in other words activities *by the patient or provider* that created or revised a resource. US Core documents using "big P" Provenance* to assert where the data came *only at an organizational level or system level*, and expect them to be consistent with the "small p" provenance information contained within the resource.** US Core is mostly silent on using "big P" Provenance to track individual activities.

>So, for every piece of Data there might be a Provenance record, or it might be contained within the Data. One Provenance record can point at many pieces of Data.**

\* see the Argo Write Project [Provenance of Client Supplied Data](https://hackmd.io/@erichaas/rkssSK8o_) for a definition of Provenance and using it for Client Supplied Data.

\** https://healthcaresecprivacy.blogspot.com/2016/03/provenance-vs-audit-it-is-not.html

### Five Ws
- 5W's is a journalism concept
- [Five Ws logical model](https://hl7.org/fhir/R4/fivews.html#resource)
- There is a `who.author` element but no `who.author.role` element because the role is typically the resource type referenced (e.g. Patient, Provider, RelatedPerson, Device). More details about the role are contained the resource contents (e.g.`RelatedPerson.relationship`)
- edge case what about if only gives a display name? :thinking_face:
- What about the patient roles? There is an [Extension](http://fhir.ch/ig/ch-ems/StructureDefinition-ch-ems-ext-personrole.html) to define the role of the involved participant in Swiss guide.
- Device roles not fleshed out at this time. What are examples of Device Roles (besides "author") :thinking_face:
- how does ADI handle this?
- Screen capture of the FiveWs Logical Model Author Element
- See the [Provenance mapping page](https://hl7.org/fhir/R4/provenance-mappings.html) for other mappings of `Provenance.agent.role`
- [Five Ws Mapping](https://hl7.org/fhir/R4/fivews.html#mappings)

- Five Ws Mapping table summary (showing the first three rows below):
- The table explained: Each non-grey cell contains a number, the number of elements and extensions (if > 0) mapped in the resource that are mapped to the pattern element in the column. If there are 0 elements and extensions, the number is not shown. In addition, the cell has a color and some character flags.
- Colors:
- Grey: the resource has no element or extension for the pattern element
- White: the resource has an element that implements the pattern element with the same name
- Yellow: the resource has a documented extension that implements the pattern element with the same name
- Blue: the resource has an element that implements the pattern element with a different name
- Red: the resource has an element that implements that pattern element, but the type or cardinality does not match
- Flags:
- E: pattern element implemented by an extension
- N: pattern element implemented by an element with a different name
- T: pattern element implemented by an element with a different type
- C: pattern element implemented by an element with a different cardinality
- Each FHIR resource is mapped to the Five W's Pattern
for example for [MedicationRequest]():
- These mapping are part of the resource definition in US Core
For example, for US Core MedicationRequest:

~~~yaml
resourceType: StructureDefinition
id: us-core-medicationrequest
#...snip ...
snapshot:
element:
- id: MedicationRequest.performer
#...snip ...
mapping:
- identity: workflow
map: Request.requester
#============ Five Ws mapping element ==============
- identity: w5
map: FiveWs.author
#============ Five Ws mapping element ==============
- identity: rim
map: '.participation[typeCode=AUT].role'
- identity: argonaut-dq-dstu2
map: MedicationOrder.prescriber
~~~

---