homepage | hl7 international - introduction · web view2020/05/06 · clinical information...

HL7_PROVENANCE_CCDA_FHIR_R1_INFORM_2020MAY

HL7 Guidance: Basic Provenance for C-CDA and FHIR, Release 1 - US Realm

May 2020

HL7 Informative DocumentSponsored by:

Security Work GroupCommunity-Based Care and Privacy (CBCP) Work Group

Electronic Health Records (EHR) Work GroupPatient Care Work Group

Structured Documents Work Group

Copyright © 2020 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Use of this material is governed by HL7's IP Compliance Policy.

Brett Marquard, 05/05/20,

Lynn to finalize.

IMPORTANT NOTES: HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm. If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Materials. Licensee shall take no action contrary to, or inconsistent with, the foregoing.

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.

Following is a non-exhaustive list of third-party terminologies that may require a separate license:Terminology Owner/ContactCurrent Procedures Terminology (CPT) code set

American Medical Associationhttps://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT SNOMED International http://www.snomed.org/snomed-ct/get-snomed-ct or [email protected]

Logical Observation Identifiers Names & Codes (LOINC)

Regenstrief Institute

International Classification of Diseases (ICD) codes

World Health Organization (WHO)

NUCC Health Care Provider Taxonomy code set

American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

HL7 Guidance: Basic Provenance for C-CDA and FHIR, Release 1 - US Realm© 2020 Health Level Seven International. All rights reserved. May 2020

Primary Editor

Brett Marquard WaveOne [email protected]

Primary Editor

Russell OttDeloitte Consulting [email protected]

Co-Chair Kathleen ConnorU.S. Department of Veterans [email protected]

Co-Chair Alexander MenseHL7 [email protected]

Co-Chair/Co-Editor

John MoehrkeBy Light Professional IT Services [email protected]

Co-Editor Lisa [email protected]

Co-Chair Chris ShawnU.S. Department of Veterans [email protected]

Co-Chair Patricia Williams PhD MScHL7 [email protected]

Co-Editor Carlos PolkDefense Health [email protected]

Co-Editor David [email protected]


mailto:[email protected]





Contents1 Introduction.........................................................................................................................................5

1.1 Purpose........................................................................................................................................5

1.2 Audience......................................................................................................................................5

1.3 Requisite Knowledge...................................................................................................................5

2 Context for Basic Provenance..............................................................................................................7

2.1 Use Cases.....................................................................................................................................7

2.1.1 Use Case 1 - Basic Exchange...................................................................................................8

2.1.2 Use Case 2 - HIE Redistribution..............................................................................................8

2.1.3 Use Case 3 - HIE Transformation............................................................................................9

2.1.4 Use Case 4 - Clinical Information Reconciliation and Incorporation (CIRI)...........................10

3 Implementation Guidance.................................................................................................................12

3.1 Basic Provenance Practices........................................................................................................12

3.2 CDA and C-CDA..........................................................................................................................13

3.2.1 C-CDA Provenance Practices................................................................................................13

3.3 FHIR...........................................................................................................................................14

3.3.1 FHIR Provenance Practices...................................................................................................14

A. Advanced Provenance Efforts............................................................................................................15

A.1. Resources for Advanced Implementers.....................................................................................15

B. Provenance - Author Participation....................................................................................................16

C. Provenance - Assembler Participation...............................................................................................19

Table of Figures

Figure 1: Basic Exchange Scenario - No clinical content transformation.....................................................8

Figure 2: HIE Redistribution - No clinical content transformation...............................................................9

Figure 3: HIE Transformation - Clinical content is transformed.................................................................10

Figure 4: Clinical Information Reconciliation and Incorporation (CIRI) from two Organizations...............11

Figure 5: CIRI After Accepting Reconciliation, No Changes........................................................................11

Figure 6: Provenance - Author Participation..............................................................................................18

Figure 7: Provenance – Assembler Participation.......................................................................................20


1 Introduction1.1 PurposeThe Basic Provenance Informative guide provides the functional and technical guidance for communicating ‘Minimum Viable Provenance’ in CDA and FHIR when information is moved from the source to downstream systems. The guidance here complements other more advanced HL7 and industry provenance efforts (see Advanced Provenance Efforts).

A more advanced definition of provenance from the HL7 FHIR Provenance Resource1:

Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility. Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance. Provenance statement indicates clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.

ONC published the U.S. Core Data for Interoperability (USCDI) v1 February 20202, which specifies Provenance alongside data many other data classes and data elements. While many of those data classes have already been defined within the CDA and FHIR standards, “provenance” has not been. For interoperability to be achieved with this data class, functional and technical guidance are needed regarding what details constitute “provenance”, how provenance information should be represented technically in the CDA and FHIR standards, and the best practices around that representation.

This informative guide is a prioritized first step towards including more robust provenance in clinical data exchange.

1.2 AudienceThe audience for this Informative Guide includes, but is not limited to providers, healthcare consumers, and their software developers, vendors, and other health IT implementers wishing to share information through the use of CDA documents and FHIR. It also includes Health IT stakeholders who exchange information, such as Payors, other support service providers, registries, and researchers.

1.3 Requisite KnowledgeReaders of this Informative Guide are assumed to have functional knowledge of HL7 concepts including the base CDA specification, FHIR and knowledge of value sets and data types. Readers should also have knowledge of Extensible Markup Language (XML)3 and XPath4 syntax. Additionally, readers should have an understanding of terminologies such as SNOMED CT®, LOINC®, CPT®, ICD®, and RxNorm®.

1 http://hl7.org/fhir/provenance.html22 https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf3 For additional information on Extensible Markup Language, visit http://www.w3.org/TR/xml/.


http://www.w3.org/TR/xml/

https://www.healthit.gov/isa/sites/isa/files/2020-03/USCDI-Version1-2020-Final-Standard.pdf

http://hl7.org/fhir/provenance.html

4 For additional information on XPath syntax, visit http://www.w3.org/TR/xpath/.


http://www.w3.org/TR/xpath/

2 Context for Basic ProvenanceThe Office of the National Coordinator (ONC) proposed rule to support the 21st Century Cures Act5 included 3 key Provenance data elements:

author, which represents the person(s) who is responsible for the information; author’s timestamp, which indicates the time6 the information was recorded; the author’s organization

During the design of this informative standard additional Provenance elements were considered to support the 5ws of attribution7, Who, What, When, Where, Why. Perspectives from both sender and receiver were considered and the implementation community considered adding data transmitter to be a 4th element to the 3 ONC proposed. When considering what an end user would review the community strongly supported scoping the Basic Provenance two key elements, Author Organization and timestamp. The Author (human) is important but not mandatory. In certain cases the Transmitter is also important, but this is optional for both CDA and FHIR.The intention of this guide is not to limit senders and receivers from including additional elements beyond those identified as constituting “basic provenance”, but rather to define a testable minimum-viable implementation for systems to build upon. Implementers interested in supporting additional elements and workflows are encouraged to bring them forward for Standards consideration to improve standard exchange. Existing efforts are noted in Appendix A. Advanced Provenance Efforts. This informative guide assumes transports used cover technical capabilities inclusive of authenticity, integrity, and confidentiality.

2.1 Use CasesThis informative guide was developed with the participation of the HL7 community, and was scoped to focus on clinicians reviewing provenance data in the course of care in four use cases:

1. Basic Exchange2. Health Information Exchange (HIE) Redistribution3. HIE Transformation4. Clinical Information Reconciliation and Incorporation (CIRI)

These four use cases increase in complexity and help take the abstract concept of ‘Provenance’ into concrete guidance. The use cases are agnostic to any content or transmission standards. Only use Case 4 - Clinical Information Reconciliation and

5 https://www.healthit.gov/topic/laws-regulation-and-policy/notice-proposed-rulemaking-improve-interoperability-health6 Systems exchanging information must have an agreed upon time source7 https://www.hl7.org/fhir/fivews.html


https://www.hl7.org/fhir/fivews.html

https://www.healthit.gov/topic/laws-regulation-and-policy/notice-proposed-rulemaking-improve-interoperability-health

https://www.healthit.gov/topic/laws-regulation-and-policy/notice-proposed-rulemaking-improve-interoperability-health

Incorporation (CIRI) includes a human actor. Throughout this informative guide the following terms are used:

‘last hop’ – system prior to current one that provide the information Author - represents the person, or organization, who is responsible for the

information. This informative guide uses Authorship quite broadly to cover more than one potential role (e.g. Reconciler). Advanced provenance efforts may have more nuanced role of reconciliation.

Transmitter – The entity that provided the copy to your system. Transformer – A system that operates independently of an author for data extraction of

existing information for purpose of generating a new artifact. Assembler and transformer are considered equivalent in this informative guide.

2.1.1 Use Case 1 - Basic Exchange

The most basic provenance scenario is the direct transmission of information from one provider to another provider. This transmission could be sent by a DIRECT message, web services based exchange, or a FHIR REST push, or pull, to a single FHIR server. While it is important to know which system passed you the information, the primary concern of the clinician end-user is the author of the content, the author organization, and a timestamp on the information. The transmission information is helpful for auditing and troubleshooting communication, however, transmission doesn’t change the clinical content and tracking is not a requirement in this guide.

Figure 1: Basic Exchange Scenario - No clinical content transformation

Receiving systems interested in tracking the data transmitter may capture and store it from the transport.

2.1.2 Use Case 2 - HIE Redistribution

A Health Information Exchange (HIE) is a technology to facilitate exchange from one to many partners. In certain HIE scenarios they only redistribute information, while in others they store, transform, and redistribute information. Use Case 2 (Figure 2) focuses on storage and redistribution only, no transformation of content is done.

When the HIE is only redistributing content, the requirements match the requirements of Use Case 1 - Basic Exchange.


The HIE must keep fidelity of the clinical content, (original author, author organization, and timestamp). The HIE must keep track of who sent them the information for auditing, however, they are not required to include the original transmitter when redistributing content.

Figure 2: HIE Redistribution - No clinical content transformation

Receiving systems interested in tracking the data transmitter would record the HIE from the transport.

2.1.3 Use Case 3 - HIE Transformation

Different from Use Case 2 - HIE Redistribution, Use Case 3 includes transformation of data. Information is received (e.g. v2 lab, other CCDs) and transformed by a HIE, stored, and then passed in a new format (e.g. CCD). Source data is not manipulated beyond transforming into a new format.

Transformation of data from one format to another does not change the authorship of the information. The HIE is only the author/author organization if they produce and include new information.

For example, if a v2 lab message is received and stored into the HIE, and then subsequently included in a CDA document, the author/author organization of the lab from the original message MAY be included. The addition of terminology translations, or additional identifiers, should not influence the authorship of the information. A transformer agent (assembler) must be included when the HIE performs manipulations8.

Alternatively, the HIE is the author/author organization if they created new information, such as calculation of a quality measure score. If specific clinical elements were included to support the quality calculation, they would reference their original author/author organization.

Figure 3: HIE Transformation - Clinical content is transformed

8 The Provenance Resource in FHIR R4 includes a section on Import and Transform guidance. See CONF: 1003 in this guide.


HIE

http://hl7.org/fhir/provenance.html#import

In Figure 3, the HIE is receiving information from 3 different source systems, adding their own additional information, and transforming into a new content payload. The HIE is only the author/author organization of the new content.

2.1.4 Use Case 4 - Clinical Information Reconciliation and Incorporation (CIRI)

Clinical Information Reconciliation and Incorporation (CIRI) is a process where a user reviews and updates (or accepts) information into their system. The process includes identification and remediation of missing, duplicate, overlapping, conflicting or superseded content. The information could come from a Health Information Exchange (HIE), a 3rd-party FHIR server, or a patient providing information. Figure 4 represents information being provided from two different sources, Good Health organization and Sunshine Health Organization. Dr. Reconciled reviews the information in Figure 4, updates the peanut allergy reaction to hives, and stores into the Future Health Organization system. When a mobile app requests the information, they receive Dr. Reconciled as the Author9 and Future Health as the organization.

Figure 4: Clinical Information Reconciliation and Incorporation (CIRI) from two Organizations

Dr. Reconciled is the latest author after updating the reaction on 5/15/2019 and accepting to the local data store. The acceptance of the information indicates that the provider is taking over the authorship responsibility. Dr. Reconciled may note prior authorship, and systems may expose this information, when relevant for clinical care10.

Figure 5: CIRI After Accepting Reconciliation, No Changes represents receiving and accepting clinical information from a single source.

9 This informative guide is using Authorship quite broadly to cover more than one potential role (e.g. Reconciler), advanced may have more nuanced role of reconciliation.10 See CONF: 1005


Figure 5: CIRI After Accepting Reconciliation, No Changes

Dr. Accepted is the latest author after verifying the problem on 5/2018 and accepting the problem data into their local data store, since it went through an interactive reconciliation process. This type of authorship change is only relevant for data fit for reconciliation, such as medications, allergies, problems. If Dr. Accepted had saved other clinical content into his EHR that aren't reconciled but simply stored, such as clinical notes, that content must retain its original author.

3 Implementation GuidanceThis section describes how to meet the requirements of Basic Provenance using CDA and FHIR.

This informative guide includes a design for ‘last hop’ only, even though both standards provide the capability to carry provenance from multiple organizations.

Full Provenance of clinical data requires details from the original asserter and all intermediary actors that updated the data. Members of the Argonaut community and the HL7 security working group discussed the current sharing approaches, and display to end user, and agreed the most important information is the prior system providing the data, the ‘last hop’. Participants didn’t dispute the potential need to share, and display full provenance (full chain of custody), but didn’t see this as relevant to the immediate end-user. Systems must support full provenance through an organizational discovery process.

3.1 Basic Provenance PracticesThe following guidance applies to provenance, regardless of whether CDA or FHIR are being used to convey data:

The Author Organization SHALL be the health system or clinic responsible for the care when the author creates or updates the data. When a patient updates the information, the organization MAY be populated with the nullFlavor NA (Not Applicable). (CONF: 1000)


Data exchanged (and stored) with no user reconciliation process (e.g. V2 message) SHALL retain the Author, Author Organization, and Author Timestamp (Provenance) of the source system. (CONF: 1001)

Data exchanged through an intermediary with no modification of the data (e.g. HIE) SHALL retain the Author, Author Organization, and Author Timestamp (Provenance) of the source system. (CONF: 1002)

Data transformed through an intermediary (e.g. V2 to CDA or FHIR), with no change of the content meaning, SHALL retain the Author, Author Organization, and Author Timestamp (Provenance) of the source system. The transformer (assembler) organization and timestamp SHALL be included as an additional actor. (CONF: 1003)

Data exchanged and stored through a user reconciliation process (e.g. Allergies, Medications) SHALL update the Author, Author Organization, and Author Timestamp (Provenance) to reflect the user who performed the reconciliation. (CONF: 1004)

When multiple authors have acted upon data within an institution, the system SHALL reflect the last author who took action in the Author, Author Organization, and Author Timestamp (Provenance), and MAY include earlier authors in additional Author, Author Organization, and Author Timestamp instances. (CONF: 1005)

Author, and Author Organizations must be well established and any assertions placed into Provenance are statements of fact to the best of the ability and in keeping with the local Policy.

3.2 CDA and C-CDA The Clinical Document Architecture (CDA) and Consolidated CDA (C-CDA) implementation guide support an author participation at the header, section, or entry levels. The Author participation is generic so the editors of this guide submitted a new constrained Author participation template to the 2019 C-CDA Templates for Clinical Notes STU Companion Guide. The Provenance – Author Participation defines key constraints and vocabulary to record the Author, Author Organization, and Timestamp in CDA documents. A copy of this template is included in Appendix B. Provenance - Author Participation for information purposes only, the formal design is in the C-CDA companion guide.

3.2.1 C-CDA Provenance Practices

A C-CDA document is required to include an Author in the Header. The Author at the header conducts throughout the document and is responsible for all content unless an Author is present at the section or entry level.

The Provenance – Author Participation11 SHALL be present at the header (CONF: 1006) If a document includes information for a different author or organization at the section or entry

level, the Provenance – Author Participation SHALL be present at the section or entry. (CONF: 1007)

11 The Basic Provenance template is more restrictive than the prior DS4P: requires Author organization, timestamp. If your system wishes to conform to both you may assert both templates. The security work group submitted a request to extend the STU period of DS4P.


When generating a C-CDA document, if only a free text provider is available, systems SHALL include the provider’s Organization and MAY include the free text provider in the narrative. (CONF: 1008)

If the author organization of the free text provider is unknown the sender/query responder SHALL be recorded as the author organization. Systems SHOULD include the free text provider in a second author participation.12. (CONF: 1008)

Receiving systems SHALL be capable of parsing the Provenance – Author Participation at the header, section, or entry level. (CONF: 1009)

The functional community involved with the development of this guide recommended systems display the Author Organization and timestamp with clinical information, however, local implementation practices and display may vary.

3.3 FHIRThe FHIR specification includes the Provenance Resource to record the Author, Author Organization, and timestamp. It also contains several advanced features, for example, policy or signature. These features exceed the requirements of Basic Provenance so a FHIR profile, constraint, is required to guide implementation community. After the developers gathered the initial requirements for this guide, the Argonaut Implementation Community selected Provenance as a project for 2019. The editors of this informative guide collaborated with the Argonaut community and the formal profile is published as US Core Provenance.

System implementations of the provenance resource SHALL conform to the US Core Provenance profile.13 (CONF: 1010)HL7 reviewed the proposed Argonaut Provenance profile within the fall 2019 US Core STU update. The best practices from the profile are copied here.

3.3.1 FHIR Provenance Practices

If a system receives a provider as free text they must capture who sent them the information as the organization.

When only a free text provider is sent, systems SHALL include the transmitting Organization and MAY include the free text provider, including their qualifications, in the Practitioner Resource. When the author is a patient the organization MAY be omitted. (CONF: 1011)

The Provenance.lastUpdated SHOULD only change when the target it references is updated. A business identifier and the lastUpdated should allow a client to determine if the reconciliation process is required again. (CONF: 1013)

12 If an organization stores information that doesn't include authorship and passes the information along (DIRECT, push, response to query) they must take responsibility for the information.13 HL7 published the US Core Provenance profile November 6, 2019


http://hl7.org/fhir/us/core/StructureDefinition-us-core-provenance.html



http://argonautwiki.hl7.org/index.php?title=Main_Page

http://argonautwiki.hl7.org/index.php?title=Main_Page

A.Advanced Provenance EffortsWhile this guide was developed to establish a standard practices for a bare-minimum implementation of provenance, should implementers be interested in pursuing a more advanced implementation, references have been included in this section to inform such efforts.

This informative guide is a prioritized first step towards including more robust provenance in clinical data exchange. Advanced Provenance efforts will fully support the 5Ws and additional use cases beyond clinical care such as:

Legal Discovery

The ‘why’ of information being present

Data quality tracing back through several hand offs

Clinical Decision Support (CDS) and Quality Measurement

A.1. Resources for Advanced ImplementersBelow are resources for implementers interested in advanced provenance efforts:

Data Segmentation for Privacy (DS4P)

HL7 Version 3 Standard: Privacy and Security Architecture Framework - Volume 3 Provenance, Release 1 (recent ballot)

HL7 EHR-System Functional Model, R2 (profile on the FHIR Provenance resource)

IHE set of profiles

o Mobile access to Helath Documents (MHD)

o Query for Existing Data for Mobile (QEDM)

o Reconcilliation of Clinical Content and Care Providers (RECON)

ONC Health Data Provenance Challenge

ONC S&I Initiative on Data Provenance (led to CDA IG)

HL7 CDA® R2 Implementation Guide: Data Provenance, Release 1 - US Realm

EHR Lifecycle events defined in ISO 21089 – how an EHR manages a record over lifecycle events – focused on CRUD (27 lifecycle events)

The HL7 Community Based Care and Privacy (CBCP) and Security Work Group


https://www.iso.org/standard/66936.html

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=420

https://www.cccinnovationcenter.com/challenges/provenance-challenge/

https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_RECON.pdf

https://wiki.ihe.net/index.php/Query_for_Existing_Data_for_Mobile

https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)


https://secure-web.cisco.com/1JKnl3Q4H874U411fyg0xvOCP0Ts3XPKKmiCVtkdVz96uCGfdyW6AzP8BSblbM8otvO_VgA_jzK7x89FfvAaRbXDH2vyi4lT_b6heU2sxVcRVFZKUzHjM4l5X5W0X5Dwz08Ewb8A8xwY_rQrZerUzjWryV-aOqOfybpRHyHoRGB28Nv86b-TO1yG5lejh_JWUHjTUFLokhVR6H-fwUQZstCgTq6qJ9T0DP7DfLcQLuF6pUsgC9xLuqINz9RjbEcNxuZEtpL8aIRjJ_N_ydt8IszD0v-ntX3za_vnUWQdVkBgHpbvRBUJ3N-WBa9aoXzLZBKKycSFYTukP6fC3Q8Mx3sJS4Vy6M1KwvhzwSfRQUXEkhdwjKU7lrvS7okpOaR652cImRlVz39Y7oAPU8jZOawrttXQ84nvwTvaF55MLnm6zR3vG6iKgOXKhvThBya8Hxd2NWoKjBKBmRx2rETh5lCLhSoM3Ob0YnXpAzlGYkhwDGQGY9ZssS2rLyq5WgTo5/https%3A%2F%2Fconfluence.hl7.org%2Fpages%2Fviewpage.action%3FpageId%3D66914456

https://secure-web.cisco.com/1JKnl3Q4H874U411fyg0xvOCP0Ts3XPKKmiCVtkdVz96uCGfdyW6AzP8BSblbM8otvO_VgA_jzK7x89FfvAaRbXDH2vyi4lT_b6heU2sxVcRVFZKUzHjM4l5X5W0X5Dwz08Ewb8A8xwY_rQrZerUzjWryV-aOqOfybpRHyHoRGB28Nv86b-TO1yG5lejh_JWUHjTUFLokhVR6H-fwUQZstCgTq6qJ9T0DP7DfLcQLuF6pUsgC9xLuqINz9RjbEcNxuZEtpL8aIRjJ_N_ydt8IszD0v-ntX3za_vnUWQdVkBgHpbvRBUJ3N-WBa9aoXzLZBKKycSFYTukP6fC3Q8Mx3sJS4Vy6M1KwvhzwSfRQUXEkhdwjKU7lrvS7okpOaR652cImRlVz39Y7oAPU8jZOawrttXQ84nvwTvaF55MLnm6zR3vG6iKgOXKhvThBya8Hxd2NWoKjBKBmRx2rETh5lCLhSoM3Ob0YnXpAzlGYkhwDGQGY9ZssS2rLyq5WgTo5/https%3A%2F%2Fconfluence.hl7.org%2Fpages%2Fviewpage.action%3FpageId%3D66914456


B.Provenance - Author Participation[author: identifier urn:oid:2.16.840.1.113883.10.20.22.5.6 (open)]

This template represents the key information to record Provenance in an Author Participation.

This Participation is appropriate to use at the CDA Header, CDA Section, or CDA Entry.

This template is consistent with the C-CDA Author Participation, however, it doesn’t use a formal ‘conforms to’ relationship. All constraints for conformance are defined in this template which specializes the Author Participation (2.16.840.1.113883.10.20.22.4.119).

The assignedAuthor/id may be set equal to (a pointer to) an id on a participant elsewhere in the document (header or entries) or a new author participant can be described here.

1. SHALL contain exactly one [1..1] templateId (CONF:4440-6) such that ita. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.5.6"

(CONF:4440-15).b. SHALL contain exactly one [1..1] @extension="2019-10-01" (CONF:4440-36).

2. SHALL contain exactly one [1..1] time (CONF:4440-7).3. SHALL contain exactly one [1..1] assignedAuthor (CONF:4440-1).

a. This assignedAuthor SHALL contain at least one [1..*] id (CONF:4440-2).b. This assignedAuthor SHOULD contain zero or one [0..1] id (CONF:4440-20) such

that it

If id with @root="2.16.840.1.113883.4.6" National Provider Identifier is unknown then

i. MAY contain zero or one [0..1] @nullFlavor="UNK" Unknown (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:4440-21).

ii. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:4440-22).

iii. SHOULD contain zero or one [0..1] @extension (CONF:4440-23).

When the author is a person who is not acting in the role of a clinician, this code encodes the personal or legal relationship between author and the patient.

c. This assignedAuthor SHOULD contain zero or one [0..1] code (CONF:4440-33).i. The code, if present, SHALL contain exactly one [1..1] @code, which

SHOULD be selected from ValueSet Personal And Legal Relationship Role Type urn:oid:2.16.840.1.113883.11.20.12.1 DYNAMIC (CONF:4440-34).

d. This assignedAuthor SHOULD contain zero or one [0..1] assignedPerson (CONF:4440-3).


i. The assignedPerson, if present, SHALL contain at least one [1..*] name (CONF:4440-9).

1. Such names SHALL contain exactly one [1..1] family (CONF:4440-17).

2. Such names SHALL contain at least one [1..*] given (CONF:4440-18).

e. This assignedAuthor MAY contain zero or one [0..1] assignedAuthoringDevice (CONF:4440-32).

f. This assignedAuthor SHALL contain exactly one [1..1] representedOrganization (CONF:4440-4).

A nullFlavor of "NA" is allowed If the assignedAuthor is not a cliniciani. This representedOrganization MAY contain zero or one [0..1] @nullFlavor

(CONF:4440-35).ii. This representedOrganization SHALL contain at least one [1..*] id

(CONF:4440-10).iii. This representedOrganization SHALL contain exactly one [1..1] id

(CONF:4440-24) such that it

If id with @root="2.16.840.1.113883.4.2" Tax ID Number is unknown then1. MAY contain zero or one [0..1] @nullFlavor="UNK" Unknown

(CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:4440-25).

2. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.2" Tax ID Number (CONF:4440-26).

3. SHOULD contain zero or one [0..1] @extension (CONF:4440-27).iv. This representedOrganization SHOULD contain zero or one [0..1] id

(CONF:4440-28) such that it

If id with @root="2.16.840.1.113883.4.6" National Provider Identifier is unknown then

1. MAY contain zero or one [0..1] @nullFlavor="UNK" Unknown (CodeSystem: HL7NullFlavor urn:oid:2.16.840.1.113883.5.1008) (CONF:4440-29).

2. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.4.6" National Provider Identifier (CONF:4440-30).

3. SHOULD contain zero or one [0..1] @extension (CONF:4440-31).v. This representedOrganization SHALL contain exactly one [1..1] name

(CONF:4440-11).vi. This representedOrganization SHOULD contain at least one [1..*] telecom

(CONF:4440-12).


Figure 6: Provenance - Author Participation

<author>  <templateId root="2.16.840.1.113883.10.20.22.5.6"/> <time value="201308011235-0800"/> <assignedAuthor>  <id root="2.16.840.1.113883.4.6" extension="1234567"/> <assignedPerson> <name> <given>Nurse</given> <family>Nightingale</family> <suffix>RN</suffix> </name> </assignedPerson> <representedOrganization>  <id root="2.16.840.1.113883.5.1008" nullFlavor="UNK"/>  <id root="2.16.840.1.113883.4.6" extension="1104145838"/> <name>Good Health Hospital</name> <telecom value="tel:+1(555)867-5309"/> </representedOrganization> </assignedAuthor></author>

C.Provenance - Assembler Participation[participant: identifier urn:hl7ii:2.16.840.1.113883.10.20.22.5.7:2020-05-19 (open)]

This template represents the organization that supported generation of a CDA document. The Assembler Organization may be different than the Author Organization, and may be different from the Organization that developed the software used to generate the document.

This Participation is appropriate to use in the CDA Header because it applies to the entire content in the document.

This template is consistent with the prior Assembler Document Participant (2.16.840.1.113883.3.5019.1.1) in the 2016 HL7 Data Provenance guide, however, makes no claim about representing the software organization. All constraints for conformance are defined in this template.

Note, the CDA Participant does not support a software device or the organization that created the software. The Assembler role can only be expressed at the level of organization. This a known issue with the current CDA R2 model.

1. SHALL contain exactly one [1..1] @typeCode="DEV" Device (CONF:4440-55).2. SHALL contain exactly one [1..1] templateId (CONF:4440-40) such that it

a. SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.5.7" (CONF:4440-44).

b. SHALL contain exactly one [1..1] @extension="2020-05-19" (CONF:4440-53).3. SHALL contain exactly one [1..1] functionCode (CONF:4440-38).

a. This functionCode SHALL contain exactly one [1..1] @code="assembler" Assembler (CONF:4440-45).

b. This functionCode SHALL contain exactly one [1..1] @codeSystem (CodeSystem: ProvenanceParticipantType urn:oid:2.16.840.1.113883.4.642.4.1131) (CONF:4440-41).

4. SHALL contain exactly one [1..1] time (CONF:4440-42).5. SHALL contain exactly one [1..1] associatedEntity (CONF:4440-39).

Note: The template does not require any elements from the associatedEntity since the information is recorded in the scopingOrganization.

a. This associatedEntity SHALL contain exactly one [1..1] @classCode="OWN" Owned Entity (CONF:4440-54).

b. This associatedEntity SHALL contain exactly one [1..1] scopingOrganization (CONF:4440-43).

i. This scopingOrganization SHALL contain at least one [1..*] id (CONF:4440-50).

ii. This scopingOrganization SHALL contain at least one [1..*] name (CONF:4440-51).


iii. This scopingOrganization SHOULD contain zero or more [0..*] telecom (CONF:4440-52).

iv. This scopingOrganization SHOULD contain zero or more [0..*] US Realm Address (AD.US.FIELDED) (identifier: urn:oid:2.16.840.1.113883.10.20.22.5.2) (CONF:4440-47).

Figure 7: Provenance – Assembler Participation

<participant typeCode="DEV"> <templateId root="2.16.840.1.113883.10.20.22.5.7" extension="2020-05-19" /> <functionCode code="assembler" codeSystem="2.16.840.1.113883.4.642.4.1131" codeSystemName="ProvenanceParticipantType"/> <time value="20191206011130-0400" /> <associatedEntity classCode="OWN"> <scopingOrganization>  <id root="2.16.840.1.113883.19.5" extension="4"/> <name use="L">Good Health HIE</name> <telecom value="tel:+1(202)776-7700" use="WP" /> <addr use="WP"> <streetAddressLine partType="SAL">555 Badger Way</streetAddressLine> <city partType="CTY">Amherst</city> <state partType="STA">WI</state> <postalCode partType="ZIP">01002</postalCode> <country partType="CNT">US</country> </addr> </scopingOrganization> </associatedEntity></participant>