USCDI Export for the Public

A PACP may contain a person’s quality of life priorities based on their personal values for what is important to them in order to have a good quality of life. They may value such things as being able to take care of themselves without needing physical help from loved ones, or being able to live without depending on machines to keep them alive, or living as long as possible by receiving all the medical care doctors believe will help them. The intent of the quality of life priorities is to provide guidance to the future care team, in a situation where the person is unable to communicate for his or her self, that informs their healthcare agent as to what is important to them and provides guidance to the care team when treatment decisions need to be made on the person’s behalf.

HL7 CDA® R2 Implementation Guide: Personal Advance Care Plan (PACP) Document, Release 1 - US Realm STU Release 2 The PACP document is a CDA document template designed to share information created by an individual to express his or her care and medical treatment goals, preferences, and priorities for some future point in time, under certain circumstances when the individual cannot make medical treatment decisions or communicate his or her goals, preferences, and priorities with the care team. The purpose of the PACP document is to ensure that the information created by the individual is available and considered in clinical care planning, and the focus of the standard is sharing patient generated information. It should not matter if the source information is documented on a piece of paper, in a video recording, or in a consumer-controlled application that exists for this purpose. The standard provides a means to share this information in a standard way with a system that maintains a clinical record for the person. It is not intended to be a legal document or a digitization of a legal document. However, a PACP can reference a legal document, and it can represent information contained in a legal document such as the appointment of healthcare agents and the identity of witnesses or a notary.

This resource is defined by HL7 FHIR as "a material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.” See HL7 FHIR R4 specification for additional details (http://hl7.org/fhir/biologicallyderivedproduct.html). The major components of the BiologicallyDerivedProduct data class are comprised of the following components below: 1. Product information 2. Storage information

ISBT-128 for biologically derived products of human origin (blood components, fluid, cells, tissues, or organs), and NDC/RxNorm for productized biologics such as blood derived products (e.g. IVIGs, clotting factors, and others). Links URLs (added here to enable sharing multiple): - ISBT: http://www.iccbba.org/tech-library/iccbba-documents/databases-and-reference-tables/product-description-codes-database2 - RxNorm: https://www.nlm.nih.gov/research/umls/rxnorm/index.html - NDC: https://www.fda.gov/drugs/drug-approvals-and-databases/nati

This set of data elements describe the product’s storage information within the blood bank or other appropriate entity storing the product: a. Description (FHIR R4: description): this is a free-text field for describing how the product is stored. b. Temperature (FHIR R4: temperature): temperature used for storage. c. Temperature Units (FHIR R4: scale): units for temperature used for storage (e.g. Celsius or Fahrenheit). d. Storage Duration (FHIR R4: duration): duration of storage before administration.

ISBT-128 for biologically derived products of human origin (blood components, fluid, cells, tissues, or organs), and NDC/RxNorm for productized biologics such as blood derived products (e.g. IVIGs, clotting factors, and others). Links URLs (added here to enable sharing multiple): - ISBT: http://www.iccbba.org/tech-library/iccbba-documents/databases-and-reference-tables/product-description-codes-database2 - RxNorm: https://www.nlm.nih.gov/research/umls/rxnorm/index.html - NDC: https://www.fda.gov/drugs/drug-approvals-and-databases/nati

This set of data elements describes information related to the biologically derived product: a. Product Code (productCode): this is the data element which can store 1 to many codable concepts describing the product. We propose the ability to use the following product codes to identify biologically derived products: a.i. ISBT-128 Product Code: identifies the biologically derived product type, such as blood components, fluids, tissues, organs, or cells. a.ii. ISBT-128 Donation Identification Number: uniquely identifies a biologic product donation, such as blood components, fluids, tissues, organs, or cells. a.iii. NDC or RxNorm codes can be used for biologically derived products that are manufactured and labeled with an NDC, such as blood derived products (e.g. IVIG’s, clotting factors). Vaccines shall use the Immunization Data Class resource. b. Product Type/Category (FHIR R4: productCategory): this element identifies the product type (e.g. organ | tissue | fluid | cells | biologicalAgent). c. Collector (FHIR R4: collector): identifies the collection entity practitioner resource instance, if appropriate. d. Source (FHIR R4: source): linkage to Patient or Organization resource identifying the biologically derived product donation source. e. Collected date/time (FHIR R4: collected): date and time of biologic product collection. f. Quantity (FHIR R4: quantity): quantity of biologic product identified in the resource instance.

ISBT-128 for biologically derived products of human origin (blood components, fluid, cells, tissues, or organs), and NDC/RxNorm for productized biologics such as blood derived products (e.g. IVIGs, clotting factors, and others). Links URLs (added here to enable sharing multiple): - ISBT: http://www.iccbba.org/tech-library/iccbba-documents/databases-and-reference-tables/product-description-codes-database2 - RxNorm: https://www.nlm.nih.gov/research/umls/rxnorm/index.html - NDC: https://www.fda.gov/drugs/drug-approvals-and-databases/nati

The person who received the administered medication. While seemingly self-evident as a part of an administration record, the requirement of the patient being linked to the drug administered is critical (assuming Medication Administrations become part of USCDI

In FHIR R4, https://www.hl7.org/fhir/medicationadministration-definitions.html#Medi…

Advance care plan is a general term for any documentation or other recordation of a person’s medical treatment goals, preferences, and priorities for some future point in time, under certain circumstances when the individual cannot make medical treatment decisions or communicate his or her goals, preferences, and priorities with the care team. An advance care plan places an emphasis on communication, as opposed to legal formalities. A PACP is a term specifically defined by HL7 as a template to facilitate the sharing of information expressed in advance care plans. A PACP may include the type of information contained in a living will and/or a durable medical power of attorney, and it also may include other medical interventions experience preference and instructions that help a healthcare agent make treatment decisions on the person’s behalf, and can be used by medical professionals to inform their medical interventions and treatment planning for the patient. Within the family of documents that have been defined under Consolidated CDA, the PACP document can be classified as a type of patient-generated document. The PACP document facilitates digital exchange of information previously and currently captured and shared using paper documents. Digital exchange of this type of data has become particularly critical within the context of COVID-19. To reduce the spread of disease, hospitals have disallowed patient family members and/or representatives to be present when the patient is admitted and as medical interventions are rendered, while also prohibiting acceptance of paper documents due to concerns of contagion. A PACP may include information relating to the appointment of a healthcare agent and alternate agents and establishing their authorized powers and limitations. It also may include information relating to any or all of the following: goals, preferences, and priorities for medical interventions (e.g., palliative and/or hospice care), including medical treatment preferences, based on the patient’s individual values, spiritual and religious beliefs, and personal definitions of quality of life; instructions to be followed after death (e.g., organ donation and autopsy); and information about who has signed, witnessed, and notarized the information authored by the individual, if available and appropriate. The set of recognized kinds of advance directive documents include concepts from the value set: Advance Directives Categories urn:oid:2.16.840.1.113883.11.20.9.69.4 which is openly available for reference in the National Library of Medicine’s Value Set Authority Center. It can be referenced using this url: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.11.20.9.69.4/definition

HL7 CDA® R2 Implementation Guide: Personal Advance Care Plan (PACP) Document, Release 1 - US Realm STU Release 2 The PACP document is a CDA document template designed to share information created by an individual to express his or her care and medical treatment goals, preferences, and priorities for some future point in time, under certain circumstances when the individual cannot make medical treatment decisions or communicate his or her goals, preferences, and priorities with the care team. The purpose of the PACP document is to ensure that the information created by the individual is available and considered in clinical care planning, and the focus of the standard is sharing patient generated information. It should not matter if the source information is documented on a piece of paper, in a video recording, or in a consumer-controlled application that exists for this purpose. The standard provides a means to share this information in a standard way with a system that maintains a clinical record for the person. It is not intended to be a legal document or a digitization of a legal document. However, a PACP can reference a legal document, and it can represent information contained in a legal document such as the appointment of healthcare agents and the identity of witnesses or a notary.

A POU tag is the 0..* component of a Security Label that conforms to follows the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 syntax to indicate the circumstances under which an authorized recipient is permitted to perform an activity such as create, collect, access, use, or disclose. For HL7 POU codes, see POU value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v3-PurposeOfUse.html We recommend creating a value set of POU codes to value the POU tag, which are specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development.

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

A Confidentiality tag is the 1..1 component of a Security Label that conforms to the HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) syntax to represent the level of protection prescribed by a policy governing the information to which a label is assigned. The HL7 Healthcare Privacy and Security Classification System (HCS), Release 1 (HCS) can be found at: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=345 HL7 recommends creating a value set of Confidentiality codes specific to priority US policies as discussed in the HL7 Cross-Paradigm US Regulatory Security Labeling Implementation Guide, which is under development and can be found at: https://build.fhir.org/ig/HL7/us-security-label-regs/branches/master/index.html For v3 HL7 Confidentiality Codes, see the Confidentiality value set at: https://build.fhir.org/ig/HL7/UTG/ValueSet-v2-0952.html For background on use of Confidentiality codes, see https://confluence.hl7.org/display/SEC/Use+of+Confidentiality+Codes+in+HL7+Security+Labeling . For use of Confidentiality codes in CDA, see HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1. For use of Confidentiality codes in FHIR see http://hl7.org/fhir/uv/security-label-ds4p/2020May/background.html For use of Confidentiality codes in HL7 Version 2, see v2.9 ARV Segment.

HL7 v3 code systems and value sets, and HL7 standards listed in the Data Elements above, and discussed in the use cases. All be the Cross Paradigm for US Regulatory Security Labeling, FHIR US Regulatory Security Labeling IG, and the FHIR DS4P IG are normative.

Were you born with a variation in your physical sex characteristics? (This is sometimes called being intersex or having a Difference in Sex Development, or DSD.)
 No
 Yes, my chromosomes, genitals, reproductive organs, or hormone functions were observed to be different from the typical female/male binary at birth and/or I have been diagnosed with an intersex variation or Difference of Sex Development
 I don’t know
Source: Intersex Data Collection: Your Guide to Question Design. interACT: Advocates for Intersex Youth. 2020. Accessed September 29, 2022. https://interactadvocates.org/intersex-data-collection/

LOINC has an intersex response option, 99502-7, for Recorded sex or gender. LOINC has an intersex response option. We do not endorse the way LOINC conceptualizes intersex (as corresponding to an X response to a sex or gender question).

This element is used to describe how intense or severe the sensation of pain is on a 1-10 scale.

LOINC: 38208-5 Pain severity – Reported

Various: FHIR DSTU2, 3 and 4, CDA Release 2.0, HL7 V2 PL Data Type

The Source of information received by an organization. The Source defines at a high level the standard used to exchange the information.

The Da Vinci Project has developed a code system and value set to represent the Source of information as represented in an extension to the FHIR R4.0.1 Provenance resource. It is available as part of the Payer Data Exchange FHIR Implementation Guide

All pending results and contact information for how to obtain

ICD 10, SNOMED, LOINC, RxNorm

Recommended to have element for Terminal Illness Status in this Data Class in USCDI V3. This is a matter of interest to Next of Kin/Related Parties and of high value to Care Team (needed for revised Care Plan) and would immensely help with timely and seamless Transition and Coordination of Care between different settings and care givers.

Terminal illness (Code 300936002) SNOMED code.

https://www.hipaaspace.com/medical_billing/coding/snomed/300936002

https://www.findacode.com/snomed/162607003--terminal-illness-early-stag…

https://build.fhir.org/ig/cqframework/opioid-cds-r4/ValueSet-limited-li…

Violence between individuals, subdivided into family and intimate partner violence and community violence. (World Health Organization, World Report on Violence and Health, p. 6 (2002).)

Yes, a vocabulary/terminology standard and/or technical specification exists for each proposed data element. The Gravity Project attaches a letter with an overview. For (1) Food Insecurity: LOINC, SNOMED-CT, ICD-10-CM, and CPT/HCPCS terminologies are specified by value set in NLM’s Value Set Authority Center (VSAC). For (2) Housing Instability and Homelessness, (3) Inadequate Housing, (4) Transportation Insecurity, (5), Financial Strain, (6) Social Isolation, (7) Stress, (8) Interpersonal Violence, (9) Education, (10) Employment, and (11) Veteran Status: • The corresponding value sets are under development by the Gravity Project; • The value sets will be complete prior to publishing of USCDI v2.0; • Even if a particular value set might be incomplete, the value set will be citable. The technical specifications for value sets under each data element are described below: • Assessments: LOINC • Health Concerns/Problems/Diagnoses: SNOMED-CT, ICD-10-CM • Goals: LOINC • Procedures/Interventions: SNOMED-CT (clinical), CPT/HCPCS (billing) • Outcomes: LOINC (NCQA measures) • Consent (where needed): based on existing HL7 code systems

A subjective state that arises when an individual recognizes a situation as threatening, but dealing with the threat requires more resources than the individual has available. (Institute of Medicine, Capturing Social and Behavioral Domains in Electronic Health Records, Phase 2, p. 76 (2014).)

Yes, a vocabulary/terminology standard and/or technical specification exists for each proposed data element. The Gravity Project attaches a letter with an overview. For (1) Food Insecurity: LOINC, SNOMED-CT, ICD-10-CM, and CPT/HCPCS terminologies are specified by value set in NLM’s Value Set Authority Center (VSAC). For (2) Housing Instability and Homelessness, (3) Inadequate Housing, (4) Transportation Insecurity, (5), Financial Strain, (6) Social Isolation, (7) Stress, (8) Interpersonal Violence, (9) Education, (10) Employment, and (11) Veteran Status: • The corresponding value sets are under development by the Gravity Project; • The value sets will be complete prior to publishing of USCDI v2.0; • Even if a particular value set might be incomplete, the value set will be citable. The technical specifications for value sets under each data element are described below: • Assessments: LOINC • Health Concerns/Problems/Diagnoses: SNOMED-CT, ICD-10-CM • Goals: LOINC • Procedures/Interventions: SNOMED-CT (clinical), CPT/HCPCS (billing) • Outcomes: LOINC (NCQA measures) • Consent (where needed): based on existing HL7 code systems

The date on which a device is manufactured. Taken from FDA Data Elements Reference Table - see https://www.fda.gov/media/88408/download

Please see FDA UDI regulation and FDA Data Elements Reference Table - see https://www.fda.gov/media/88408/download. Please see FDA Formats by Accredited Issuing Agency that shows the structured of each of the parts of the UDI as a complete standard - https://www.fda.gov/media/96648/download UDI-DI and all AccessGUDID data elements are listed in NCI Thesaurus. See https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/NCI_FDA/index.html#:~:text=%20The%20NCI%20Thesaurus%20includes%20the%20following%20FDA,Global%20Unique%20Device%20Identification%20Database%20%28GUDID%29%20More%20

The patient's country of nationality.

HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) based on FHIR R4
HL7 CDA® R2 Implementation Guide: Public Health Case Report - the Electronic Initial Case Report (eICR) HL7
FHIR: Country of Nationality profile HL7
CDA: Country of Nationality template
SNOMED: 186034007 |Ethnicity / related nationality data (observable entity)|
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=519
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=436

The date by which the label of a device states the device must or should be used. Taken from FDA Data Elements Reference Table - see https://www.fda.gov/media/88408/download

Please see FDA UDI regulation and FDA Data Elements Reference Table - see https://www.fda.gov/media/88408/download. Please see FDA Formats by Accredited Issuing Agency that shows the structured of each of the parts of the UDI as a complete standard - https://www.fda.gov/media/96648/download UDI-DI and all AccessGUDID data elements are listed in NCI Thesaurus. See https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/NCI_FDA/index.html#:~:text=%20The%20NCI%20Thesaurus%20includes%20the%20following%20FDA,Global%20Unique%20Device%20Identification%20Database%20%28GUDID%29%20More%20

Radiation dose delivered to the target volume in fulfilling the prescription (e.g. 7200 cGy).