Material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.

Data Element
Product Code
Description

Provides a description of and supports traceability for a product
Submitted By: Barbee Whitaker / Food and Drug Administration (FDA) Center for Biologics Evaluation and Research (CBER)
Data Element Information
Use Case Description(s)
Use Case Description Background: Biologically derived products represent a unique, yet widely-used, domain within healthcare. The BiologicallyDerivedProduct is defined within HL7 FHIR as “a material substance originating from a biological entity intended to be transplanted or infused into another (possibly the same) biological entity.”

Blood and blood components, mainly represented by the ISBT-128 code system, are extensively collected and exchanged today via various data paradigms including HL7 V2, CDA, FHIR, and OHDSI OMOP. Also, accrediting organizations in the United States and many other countries require their members to use ISBT 128 coding and labeling for cellular therapies and ocular tissue (AABB [https://www.aabb.org/news-resources/resources/cellular-therapies/isbt-128-for-cellular-therapy], the Foundation for the Accreditation of Cellular Therapy (FACT) [https://news.factwebsite.org/isbt-128-audit-tool-for-cellular-therapy-provides-additional-resource-for-verifying-labels/] and the Eye Bank Association of America (EBAA) [http://restoresight.org/wp-content/uploads/2016/01/ISBT-Webpage-Implementation-Guide-Use-of-ISBT-128-in-North-American-Eye-Banks-v130.pdf]). The remaining product types (tissues, cells, milk, and organs) can be represented by a number of different code systems, such as United Network for Organ Sharing (UNOS) tracking system.

It is important to note that while there are a wide range of biologically derived products, not all product types should be associated with the Biologically Derived Product data class. Specifically, vaccines should be captured in the Immunization data class and blood-derived products (e.g., immune globulins) should be captured in Medications data class.

The incorporation of this class into USCDI will enable high-priority use cases from both a clinical care and policy perspective. Clinically, biologically derived products are so wide-spread that roughly 70% of patients will receive a blood product during their lifetimes (Hay, S., Scanga, L. and Brecher, M. (2006), Life, death, and the risk of transfusion. Transfusion, 46: 1491-1493. https://doi.org/10.1111/j.1537-2995.2006.00935.x). Additionally, blood transfusions alone constitute the most common inpatient procedure (https://www.hcup-us.ahrq.gov/reports/statbriefs/sb165.jsp). Biologically derived products are also administered in outpatient, skilled nursing, and home settings, as well as processed through a complex supply chain of collection and procurement centers, hospital laboratories, hospital blood banks, researchers, labs, and clinical organizations. Biologically derived products’ unique properties and risks apply not only across product types, but also at the unit level (e.g., individual blood component) due the product’s human or animal origins. From a policy perspective, the current lack of interoperability has impacted high priority policy areas including COVID-19 response (i.e., convalescent plasma) and social determinants of health (e.g., addressing disparities in patient outcomes that necessitate transfusions), as well as public health (e.g. emerging infectious disease monitoring such as for Zika Virus) and research (e.g., novel therapies for hemoglobinopathies, such as sickle cell therapies). Therefore, it is critical to track these products in an interoperable manner.

Recommendation: To address this interoperability need, we recommend ONC adopt the Biologically Derived Product data class as part of USCDI. This class will directly map to the existing HL7 FHIR BiologicallyDerivedProduct resource (http://build.fhir.org/biologicallyderivedproduct.html). Additionally, robust product code systems, particularly ISBT-128, already exist and are in wide-spread use, although they are stored in a complex and diverse set of locations within different EHR systems.

Use Cases: This proposal lists four categories of interoperability use cases: (1) providers and patients, (2) providers and public health, (3) providers and providers, and (4) providers and suppliers / labs / blood banks.

Use Case #1 – Providers and Patients: It is critical that patients with biologic product exposures are able to access data from their medical records, given that each product has a unique set of properties and risk profiles. These data are valuable to patients for continuity of care and empowerment to communicate the specific details of their biologic exposures across often disparate provider systems (see Use Case #3). Interoperability will also enable patients to contribute these essential data elements to registries – which will benefit other patients, researchers, and public health stakeholders as well.
Estimate the breadth of applicability of the use case(s) for this data element 3 stakeholders are involved in this use case: patients [~70%] (access, use, exchange), providers (capture, access, use, exchange), and researchers (access, use).
Use Case Description Use Case #2 – Providers and Public Health:

Biologic products require regulatory oversight and surveillance for safety and effectiveness, including but not limited to adverse event reporting by healthcare providers to Federal regulatory and surveillance agencies (i.e., FDA and CDC), and conducting large-scale observational epidemiological studies using EHR data. Given the unique nature of each biologic product, it is essential that product codes, such as ISBT-128 codes, are captured to ensure sufficient product identification granularity for monitoring and tracking any issues that may be associated with the product. The cost of the current lack of interoperability in this area was reinforced during the recent rollout of COVID-19 convalescent plasma therapies. Without ISBT product codes, it is not possible to differentiate between convalescent plasma use, traditional plasma therapy, or any blood component transfusion. This caused significant limitations for FDA CBER and researchers performing safety and effectiveness surveillance in EHR systems. Thus, these data elements are critical to this use case.

Link below to HL7 project for the related FHIR Implementation Guide on Transfusion and Vaccine Adverse Event Reporting.
Estimate the breadth of applicability of the use case(s) for this data element 5 stakeholders are involved in this use case: regulators (access, use, exchange), clinicians (capture, exchange), blood banks (capture, exchange), researchers (access, use, exchange) and patients (access, capture).
Link to use case project page https://confluence.hl7.org/display/FHIR/FHIR+Implementation+Guide+for+Transfusion+and+Vaccination+Adverse+Event+Reporting
Use Case Description Use Case #3 – Providers and Providers:

Patients receiving biologically derived products typically experience complex courses of care that require high levels of coordination. This often involves transfers between multiple hospital facilities, networks, and patient care teams. For example, currently, if a patient is transferred between different hospital networks, the destination hospital blood bank / transfusion service location must call the pertinent originating healthcare location to obtain information regarding a patient’s history of blood product(s) transfused, immuno-serological problems, and any hemotherapy adverse reactions/episodes reported to the originating entity. Such information is typically conveyed verbally via telephone and/or via fax of the paper records. Product administrations are not confined to the inpatient hospital setting – they can be performed in hospital outpatient settings, skilled nursing care facilities, physician and dentist offices, hemodialysis centers, emergency medical transport conveyances including land-based ambulance vehicles and aeromedical evacuation aircraft (e.g., fixed-wing and helicopter assets) and even in the patient’s own home setting.

This is particularly important for patient safety involving specialty attribute products that have been modified/prepared and have been designated with “special attributes” status (e.g., Red Blood Cell (RBC) units negative for pertinent blood group antigen(s), platelet products negative for certain HLA antigens, units leukocytes reduced, washed or gamma-ray/ X-ray irradiated, units treated with emerging technologies for pathogen reduction, etc.). For example, if a patient was transfused within the past 3 months, it is critical that clinicians and blood bank staff know this information prior to performing any RBC antigen phenotyping studies, as a history of recent blood transfusion will impact interpretation and potentially alter the hemotherapy management of a patient and the course of care.
Estimate the breadth of applicability of the use case(s) for this data element 3 stakeholders are involved in this use case: clinicians [most common inpatient procedure] (capture, use, access, exchange), blood banks (capture, use, access, exchange), and patients (access).
Use Case Description Use Case #4 – Providers and Suppliers / Labs / Blood Banks:

Biologically derived products characteristically involve complex supply chains requiring multiple oversight points to ensure their safety and effectiveness. Blood banks and clinical laboratories in particular play critical roles in this process by testing specimens and processing orders. Blood banks also perform specific diagnostic/cross-matching testing to appropriately prepare blood for transfusion purposes. Such activities are typically either performed within a hospital system or by an outside blood bank and/or laboratory. It is critical that product orders are closely tracked to ensure that the right unit and dosage are administered to the right patient. Currently, interoperability limitations mean that numerous manual and potentially error-prone processes must be performed to achieve this objective. Due to their complex nature, blood banking IT systems are often separated from the patient’s electronic medical record (EMR) and rely on separate add-on modules that use a heterogeneous set of computer interface solutions to achieve interoperability. This makes it difficult for provider organizations to standardize workflows (or SMART apps) such as transfusion safety monitoring. Providers would also benefit from the ability to more easily notify blood banks / transfusion services regarding the development of certain transfusion-associated infections (e.g., babesiosis, viral hepatitis, and HIV) that may not manifest themselves immediately thus allowing the blood banks / transfusion services to perform “reverse lookback” investigations that may uncover other transfusion recipients/ blood donors at potential risk.
Estimate the breadth of applicability of the use case(s) for this data element 6 stakeholders are involved in this use case: clinicians [most common inpatient procedure] (capture, use, access, exchange), suppliers (capture, use, exchange), pharmacies (use, exchange), blood banks (capture, use, access, exchange), labs (capture, use, access, exchange), and patients (access).
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) ISBT-128 Product Description Code
https://www.isbt128.org/uri/ProductDescriptionCode
Additional Specifications FHIR Implementation Guide for Transfusion and Vaccination Adverse Event Detection and Reporting (https://build.fhir.org/ig/HL7/fhir-icsr-ae-reporting/branches/main/index.html), which references the HL7 FHIR R4 BiologicallyDerivedProduct Resource (http://build.fhir.org/biologicallyderivedproduct.html). This IG is currently being balloted as part of the HL7 September 2021 process.
Current Use Extensively used in production environments
Supporting Artifacts Resource: Endorsed by HL7 as part of the FHIR standard. BiologicallyDerivedProduct is a resource approved by HL7 Orders & Observations (O&O) as FHIR maturity level 1 – meaning that it is substantially complete and ready for implementation including building successfully with no warnings. Additionally enhancements to the resource are currently being made within the HL7 O&O workgroup for adoption as part of R5.

Element / Code System: The data elements and code systems referenced above are extensively used in production systems today. In particular, ISBT-128 data are routinely collected and exchanged today via various data paradigms including HL7 V2, CDA, FHIR and OHDSI OMOP.
http://build.fhir.org/biologicallyderivedproduct.html; http://www.iccbba.org/tech-library/endorsements
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts See comments above regarding extensive use in production environments. See above links.
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) The use and exposure of ISBT-128 codes within clinical and patient records are not proprietary. However, the full dictionary for ISBT-128 codes and their associated descriptions are currently proprietary to contributing members of ICCBBA, which consists of member blood/organ banks.
Restrictions on Use (e.g. licensing, user fees) There is no restriction on the use of data elements, but as mentioned above, a licensing fee is required to obtain the ISBT-128 data dictionary. This should not cause significant issues with their nationwide exchange.

Additionally, it is important to note that the inclusion of Biologically Derived Product in USCDI would not require the use of a particular identification standard if it is not currently being exchanged by an organization.
Privacy and Security Concerns Much like other unique identifiers used within FHIR resources (e.g. a patient or encounter identifier), the ISBT-128 Donor Code could potentially uniquely identify the donor, however the risk is significantly mitigated since the key is held securely by the collection organization.
Estimate of Overall Burden Access (moderate burden): Data are captured when codes are scanned or recorded prior to administration or from blood bank orders. Integration of EHR and blood bank systems is heterogeneous – typically through HL7 V2. This paradigm can be expanded to conform to the BiologicallyDerivedProduct resource in FHIR, with participation from EHR vendors and provider networks.

Clinician (low burden): The data does not need to be calculated and does not require additional time not currently part of provider workflow. It is important to note that nearly 100% of the US blood supply currently uses the ISBT-128 standard due to AABB’s Standards for Blood Banks and Transfusion Services. ISBT-128 is accepted by FDA as a machine-readable label type for the labeling of blood and blood components.

IT (low burden): The current EHR systems capture the relevant information or can obtain it through expanding the existing V2 paradigm to conform to the BiologicallyDerivedProduct resource in FHIR. Additionally, in order to crosswalk coding system descriptions, licenses for data dictionaries for proprietary coding systems will need to be obtained by the entities exchanging data (e.g. licenses for ISBT-128 data dictionaries are obtained from ICCBBA).
Other Implementation Challenges Each biologically derived product represents a somewhat unique subdomain (e.g. advanced therapies such as CAR-T cell therapies compared to blood components). This proposal recommends focusing initially on implementing data elements associated with biologic products of human origin, such as blood components, which are covered by the ISBT-128 terminologies.
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 2 - Data element is electronically exchanged between more than two production EHRs or other HIT modules of different developers using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 2 - Use cases apply to most care settings or specialties.

Comment

Log in or register to post comments