Implantable device list

Clarifications:

• There is no standard required for this certification criterion.
• This criterion is not aimed at surgical specialties, settings, or systems. It is aimed at delivering information to all clinicians so that they can know what devices their patients have and use that information to deliver safer and more effective care. [see also 80 FR 62630]
• A Unique Device Identifier (UDI) is a unique numeric or alphanumeric code that consists of two parts: (1) a device identifier (DI), a mandatory, fixed portion of a UDI that identifies the labeler and the specific version or model of a device, and (2) a production identifier (PI), a conditional, variable portion of a UDI that identifies one or more of the following when included on the label of a device: the lot or batch number within which a device was manufactured; the serial number of a specific device; the expiration date of a specific device; the date a specific device was manufactured; the distinct identification code required by 21 CFR 1271.290(c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device. 21 CFR 801.3. [see also Food and Drug Administration (FDA) UDI System] 
• The health IT must be able to satisfy this criterion using the three UDI formats from the three issuing agencies. The allowable issuing agency formats and sample labels are available at the FDA's USDI System webpage.  
• The National Library of Medicine (NLM) has made available several application program interfaces (APIs) to assist with the parsing of UDIs, to access Global Unique Device Identification Database (GUDID) data elements, and other functions related to UDIs. These APIs are available at NLM's AccessGUDID webpage. Note that if a developer certifies to this certification criterion using any of the NLM APIs to perform the function(s) required by this certification criterion, the developer must list the(se) API(s) as relied-upon software.
• FDA accredits organizations to be issuing agencies for assignment of UDIs through an application process. The list of FDA-accredited agencies and the dates of their accreditations are listed on their website.
  • Sample UDI label
• Paragraphs (a)(14)(i) and (a)(14)(ii)(A) may or may not be separate steps. The certified health IT must be able to record the UDIs for a patient. By record, ONC means that the software must store the UDI in the patient’s record, whence it can later be retrieved by a user and displayed and used according to paragraphs (a)(14)(ii)-(vi). If the developer chooses to meet the recording requirement by parsing the UDI and storing it in that parsed state, then paragraph (a)(14)(ii)(A) could be demonstrated while demonstrating paragraph (a)(14)(i). By contrast, if the developer chooses to record the UDI in its unparsed state, it would have to separately demonstrate that it can parse the UDI as needed to perform the capabilities described in paragraphs (a)(14)(ii)-(vi).
• ONC refers to FDA for best practices. For further recommendations on best practices for UDI downloads, please consult the FDA support resources for guidance.
• Implantable Medical Devices are entered in a Procedure Activity Procedure section of the Consolidated Clinical Document Architecture (C-CDA) 2.1. This section requires that a medical device is entered as an entry underneath the procedure it is related to. Thus, in the optimal case, the procedure is coded as the device is implanted or removed. In this case, ideal coding would include the detailed code that accurately reflects the procedure performed. However, for various reasons, it may not be possible at the time of the procedure or when coding a device after the actual procedure occurred to obtain a granular code reflecting the specific procedure performed. In this case, it is appropriate to either use a generic code or a null value to enter the UDI.
• There are some examples on the C-CDA Examples Task Force webpage that highlight for implementers how the information may be coded. 

Technical outcome – Health IT is able to record Unique Device Identifier(s) (UDI(s)) associated with a patient’s implantable device(s).

Clarification:

• This requirement focuses solely on the ability of the technology to record UDIs for a patient’s implantable devices. This certification criterion is agnostic as to how the UDI is initially captured and focuses instead on ensuring that UDIs for a patient’s implantable devices can be exchanged, recorded, and used in a standardized manner “downstream” by all Certified Health IT Modules. [see also 80 FR 62626]
• This requirement focuses on recording a UDI and not on the technologies that may be used to assist in the process to initially capture UDIs (e.g., Automatic Identification and Data Capture (AIDC) technology or receipt from an “upstream” system). [see also 80 FR 62626]
• This certification criterion does not require users to manually enter UDIs. Developers and providers are left the flexibility to best determine the method(s) used to allow users to enter or “capture” UDIs, if at all. [see also 80 FR 62626]

Technical outcome – Health IT is able to parse a Unique Device Identifier (UDI) and allows a user to access the identifiers that compose the UDI.

Clarifications:

• The term “identifier” is used to refer to the items in paragraphs (a)(14)(ii)(B)(1)-(5), which compose and are required to be included in the Production Identifier when required to be included on the label of a device. [see also 80 FR 62627]
• For a human cells, tissues, and cellular and tissue-based product (HCT/P) regulated as a device, a distinct identification code is required by this section (for tracking purposes). [see also 21 CFR § 1271.290(c)]
• For testing and certification, the health IT must demonstrate it is able to parse a UDI. In practice, if a health IT product receives a UDI that has already been parsed, and the system would not need to reparse the UDI. For example, the first time an implantable device is captured in a patient record, the UDI could be parsed from the AIDC format into the parts listed in provisions (a)(14)(ii)(A) and (B) (i.e., the Device Identifier and five Production Identifiers). When the UDI is received, if it is in a parsed format, the parsed elements could be used and there is no need to parse the UDI again. If the UDI received is not already parsed, the health IT should parse the UDI in an easily readable plain-text form. [see also 21 CFR 801.40]
• The UDI can be found on the label of the implantable device near the AIDC format of the UDI. Even if the UDI is captured using AIDC, it should be converted to an easily readable plain-text form [see also 21 CFR 801.40] and parsed, consistent with the Consolidated CDA Release 2.1 standard.

Technical outcome – Health IT is able to obtain and associate with each Unique Device Identifier (UDI) a description and specific GUDID attributes described in (a)(14)(iii)(B)(1)-(5).

Clarifications:

• The term “attribute” is used to refer to certain information not included in the UDI itself but that is associated with the UDI and can be retrieved using the GUDID. [see also 80 FR 62627]
• The GUDID is now available via a web interface called AccessGUDID. In addition, web services are available via the AccessGUDID website. [see also 80 FR 62628] Health IT Modules can meet the requirement at paragraph (a)(14)(iii)(A) by obtaining and associating with a UDI either the “GMDN PT Name” attribute for the UDI or the “SNOMED CT^® Description” mapped to the “GMDN PT Name” attribute. The latter method may be preferable to developers for easier deployment of clinical decision support and other functionality. [see also 80 FR 62628]
• The AccessGUDID web services will return the GUDID attributes referenced by this certification criterion as well as the “SNOMED CT^® Identifier” and “SNOMED CT^® Description” mapped to the Global Medical Device Nomenclature (GMDN) code set. [see also 80 FR 62628]
• The attributes described in paragraphs (a)(14)(iii)(B)(1)-(5) can be retrieved from the GUDID using the AccessGUDID's web interface, web services, downloadable module, or any other method of retrieval permitted under FDA's GUDID guidance. Thus, GUDID attributes could be retrieved from a local system, provided the information in that system is up to date and is based upon the data downloaded from the GUDID. We encourage the use of the AccessGUDID web services, which are being designed specifically to support health IT developers to meet this implantable device list certification criterion. [see also 80 FR 62629]
• Examples of all three UDI issuing agencies can be found by searching the AccessGUDID database:
  • http://accessgudid.nlm.nih.gov/devices/search?query=iccbba
  • http://accessgudid.nlm.nih.gov/devices/search?query=gs1
  • http://accessgudid.nlm.nih.gov/devices/search?query=hibcc
• In reference to paragraph (a)(14)(iii)(B)(5), 21 CFR § 801.437 concerns user labeling for devices that contain natural rubber.
  • The term “natural rubber latex” means rubber that is produced by the natural rubber latex process that involves the use of natural latex in a concentrated colloidal suspension. Products are formed from natural rubber latex by dipping, extruding, or coating.
  • The term “dry natural rubber” means rubber that is produced by the dry natural rubber process that involves the use of coagulated natural latex in the form of dried or milled sheets. Products are formed from dry natural rubber by compression molding, extrusion, or by converting the sheets into a solution for dipping.

Technical outcome – Health IT is able to display to a user a visible list consisting of: (1) all active UDIs recorded for the patient; and (2) for each UDI in the list, the description associated with the UDI per (a)(14)(iii)(A). The list may but need not contain inactive UDIs recorded for the patient. If inactive UDIs are recorded for a patient and not displayed, the list must display to the user a method (such as a jump link) for accessing such UDIs.

Clarifications:

• If a device is still implanted in the patient, it is considered to be “active”.
• “Implantable device list” refers to the visible list that is displayed to the user of health IT certified to this criterion and that must show, at a minimum: (1) A patient's active UDIs, meaning all UDIs recorded for the patient that have not been designated inactive; (2) the corresponding description of each UDI in the list (which, as discussed above, may be either the GUDID attribute “GMDN PT Name” or the “SNOMED CT® Description” mapped to that attribute); and (3) if one or more inactive UDIs exist but are not included in the list, a method of accessing those UDIs and their associated information from within the list. [see also 80 FR 62629]
• The above represents the minimum information that must be displayed to the user. However, additional information must be accessible to a user as described by the next paragraph “(a)(14)(v)” of this criterion.
• Providing a display of each of the discrete components (Device Identifier + Production Identifier(s)) to a user is considered the equivalent of displaying the full UDI in an easily readable plain-text form. [see also 21 CFR 801.40]

Technical outcome – Health IT enables a user to access an expanded set of identifier and attribute information associated with a patient’s UDI(s) that may not necessarily be displayed to a user by default.

Clarifications:

• If the implantable device list does not contain these identifiers and attributes, then the health IT would need to enable a user to access them (for example, by presenting them when a user clicks on an item in the implantable device list). [see also 80 FR 62629]
• Similarly, the implantable device list may but need not include inactive UDIs, so long as these UDIs are accessible from within the list. For example, the implantable device list could display only active UDIs so long as it also contained a link or other obvious way for a user to access all other UDIs recorded for the patient. [see also 80 FR 62629]
• Providing the user access to each of the discrete components (Device Identifier + Production Identifier(s)) is considered the equivalent of providing access to the full UDI in an easily readable plain-text form. [see also 21 CFR 801.40]

Technical outcome – Health IT enables a user to change the status of a UDI recorded for a patient.

Clarifications:

• Health IT certified to this criterion must enable a user to change the status of a UDI recorded for a patient to indicate that the UDI is inactive. We also expect that developers will implement this functionality in a manner that allows users to indicate the reason that the UDI's status was changed to inactive. Consistent with the policy that UDIs should not be deleted from the implantable device list or from a patient's electronic health record, a UDI that has been designated inactive must still be accessible to the user so that users can access information about the device, even if it was explanted or recorded in error. [see also 80 FR 62629]