Source: https://www.healthit.gov/test-method/implantable-device-list
Timestamp: 2018-11-15 16:28:12
Document Index: 528636354

Matched Legal Cases: ['§170', '§ 170', '§ 170', '§ 170', '§ 1271', '§ 801']

Implantable device list | HealthIT.gov
Removed active UDI from step in paragraph (a)(14)(iv).
Updated paragraph (a)(14)(ii)(A), paragraph (a)(14)(ii)(B), and paragraph (a)(14)(iii)(A) to clarify in all formats established by the 3 UDI issuing Agencies.
Updated paragraph (a)(14)(iv)(A) to UDIs, plural.
§170.315(a)(14) Test Procedure
Included additional clarifications regarding the recording, parsing, and easily readable plain-text format of UDIs; provided additional resources for UDI attribute look-up.
Added requirement and link for Safety-enhanced design that was erroneously excluded from the initial publication. Minor regulation text updates from the correction notice. Additional development and testing resources. Clarification that “active” means implanted.
Minor copy edits and removal of redundant clarification for paragraph (a)(14)(i).
Added clarification for recording and parsing, and for representing devices in the C-CDA. Also added reference links for FDA best practices and for finding samples for the three Unique Device Identifier (UDI) issuing agencies.
Corrected error of omission for requirement of safety-enhanced design certification for health IT presented for certification to this criterion.
Certification Companion Guide: Implantable device list
Privacy and Security: This certification criterion was adopted at § 170.315(a)(14). As a result, an ONC-ACB must ensure that a product presented for certification to a § 170.315(a) “paragraph (a)” criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.
When a single quality management system (QMS) is used, the QMS only needs to be identified once. Otherwise, the QMS need to be identified for every capability to which it was applied.
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 https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/
Sample UDI label
There are some examples on the C-CDA Examples Task Force webpage, available at: http://cdasearch.hl7.org/examples/view/bacadc7c7194815ce4fcd741108f96a96a3a97a1, that highlight for implementers how the information may be coded.
Paragraph (a)(14)(i)
Technical outcome – Health IT is able to record Unique Device Identifier(s) (UDI(s)) associated with a patient’s implantable device(s).
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 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]
Paragraph (a)(14)(ii)
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.
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]
21 CFR § 1271.290(c) 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).
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.
Paragraph (a)(14)(iii)
Technical outcome – Health IT is able to obtain and associate with each Unique Device Identifier (UDI) a description and specific Global Unique Device Identification Database attributes described in (a)(14)(iii)(B)(1)-(5).
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 Global Unique Device Identification Database (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, including the following for attribute look-up: http://accessgudid.nlm.nih.gov/docs. [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.
Paragraph (a)(14)(iv)
Technical outcome – Health IT is able to display to a user a visible list consisting of: (1) all active Unique Device Identifiers (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.
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]
Paragraph (a)(14)(v)
Technical outcome – Health IT enables a user to access an expanded set of identifier and attribute information associated with a patient’s Unique Device Identifier(s) (UDI(s)) that may not necessarily be displayed to a user by default.
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]
Paragraph (a)(14)(vi)
Technical outcome – Health IT enables a user to change the status of a Unique Device Identifier (UDI) recorded for a patient.
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]