Printer Friendly, PDF & Email Printer Friendly, PDF & Email

§170.315(a)(14) Implantable device list

Updated on 03-11-2024
Regulation Text
Regulation Text

§ 170.315 (a)(14) Implantable device list

  1. Record Unique Device Identifiers associated with a patient's Implantable Devices.
  2. Parse the following identifiers from a Unique Device Identifier:
    1. Device Identifier; and
    2. The following identifiers that compose the Production Identifier:
      1. The lot or batch within which a device was manufactured;
      2. The serial number of a specific device;
      3. The expiration date of a specific device;
      4. The date a specific device was manufactured; and
      5. For an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).
  3. Obtain and associate with each Unique Device Identifier:
    1. A description of the implantable device referenced by at least one of the following:
      1. The “GMDN PT Name” attribute associated with the Device Identifier in the Global Unique Device Identification Database.
      2. The “SNOMED CT® Description” mapped to the attribute referenced in in paragraph (a)(14)(iii)(A)(1) of this section.
    2. The following Global Unique Device Identification Database attributes:
      1. “Brand Name”;
      2. “Version or Model”;
      3. “Company Name”;
      4. “What MRI safety information does the labeling contain?”; and
      5. “Device required to be labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437).”
  4. Display to a user an implantable device list consisting of:
    1. The active Unique Device Identifiers recorded for the patient;
    2. For each active Unique Device Identifier recorded for a patient, the description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section; and
    3. A method to access all Unique Device Identifiers recorded for a patient.
  5. For each Unique Device Identifier recorded for a patient, enable a user to access:
    1. The Unique Device Identifier;
    2. The description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section;
    3. The identifiers associated with the Unique Device Identifier, as specified by paragraph (a)(14)(ii) of this section; and
    4. The attributes associated with the Unique Device Identifier, as specified by paragraph (a)(14)(iii)(B) of this section.
  6. Enable a user to change the status of a Unique Device Identifier recorded for a patient.
Standard(s) Referenced

None

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): 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.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(14). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024

Testing components

Attestation: As of September 21, 2017, the testing approach for this criterion is satisfied by attestation.

The archived version of the Test Procedure is attached below for reference.

 

System Under Test

ONC-ACB Verification

The health IT developer will attest directly to the ONC-ACB to conformance with the §170.315(a)(14) Implantable device list requirements.

The ONC-ACB verifies the health IT developer attests conformance to the §170.315(a)(14) Implantable device list requirements.

 

 

Archived Version:
Updated on 06-11-2024
Regulation Text
Regulation Text

§ 170.315 (a)(14) Implantable device list

  1. Record Unique Device Identifiers associated with a patient's Implantable Devices.
  2. Parse the following identifiers from a Unique Device Identifier:
    1. Device Identifier; and
    2. The following identifiers that compose the Production Identifier:
      1. The lot or batch within which a device was manufactured;
      2. The serial number of a specific device;
      3. The expiration date of a specific device;
      4. The date a specific device was manufactured; and
      5. For an HCT/P regulated as a device, the distinct identification code required by 21 CFR 1271.290(c).
  3. Obtain and associate with each Unique Device Identifier:
    1. A description of the implantable device referenced by at least one of the following:
      1. The “GMDN PT Name” attribute associated with the Device Identifier in the Global Unique Device Identification Database.
      2. The “SNOMED CT® Description” mapped to the attribute referenced in in paragraph (a)(14)(iii)(A)(1) of this section.
    2. The following Global Unique Device Identification Database attributes:
      1. “Brand Name”;
      2. “Version or Model”;
      3. “Company Name”;
      4. “What MRI safety information does the labeling contain?”; and
      5. “Device required to be labeled as containing natural rubber latex or dry natural rubber (21 CFR 801.437).”
  4. Display to a user an implantable device list consisting of:
    1. The active Unique Device Identifiers recorded for the patient;
    2. For each active Unique Device Identifier recorded for a patient, the description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section; and
    3. A method to access all Unique Device Identifiers recorded for a patient.
  5. For each Unique Device Identifier recorded for a patient, enable a user to access:
    1. The Unique Device Identifier;
    2. The description of the implantable device specified by paragraph (a)(14)(iii)(A) of this section;
    3. The identifiers associated with the Unique Device Identifier, as specified by paragraph (a)(14)(ii) of this section; and
    4. The attributes associated with the Unique Device Identifier, as specified by paragraph (a)(14)(iii)(B) of this section.
  6. Enable a user to change the status of a Unique Device Identifier recorded for a patient.
Standard(s) Referenced

None

Certification Dependencies

Design and Performance: The following design and performance certification criteria (adopted in § 170.315(g)) must also be certified in order for the product to be certified.

  • Safety-enhanced design (§ 170.315(g)(3)) must be explicitly demonstrated for this criterion.
  • Quality management system (§ 170.315(g)(4)): 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.
  • Accessibility-centered design (§ 170.315(g)(5)): When a single accessibility-centered design standard is used, the standard only needs to be identified once. Otherwise, the accessibility-centered design standards need to be identified for every capability to which they were applied; or, alternatively, the developer must state that no accessibility-centered design was used.
Privacy & Security Requirements

This certification criterion was adopted at § 170.315(a)(14). As a result, an ONC Authorized Certification Body (ONC-ACB) must ensure that a product presented for certification to a § 170.315(a) criterion includes the privacy and security criteria (adopted in § 170.315(d)) within the overall scope of the certificate issued to the product.

  • The privacy and security criteria (adopted in § 170.315(d)) do not need to be explicitly tested with this specific paragraph (a) criterion unless it is the only criterion for which certification is requested.
  • As a general rule, a product presented for certification only needs to be presented once to each applicable privacy and security criterion (adopted in § 170.315(d)) so long as the health IT developer attests that such privacy and security capabilities apply to the full scope of capabilities included in the requested certification. However, exceptions exist for § 170.315(e)(1) “View, download, and transmit to 3rd party (VDT)” and (e)(2) “Secure messaging,” which are explicitly stated.
  • § 170.315(d)(2)(i)(C) is not required if the scope of the Health IT Module does not have end-user device encryption features.

For more information on the approaches to meet these Privacy and Security requirements, please review the Privacy and Security CCG.

Revision History
Version # Description of Change Version Date
1.0

Initial publication

03-11-2024
1.1

Removed resources listed under Additional Resources in the Standards Referenced accordion to eliminate redundant information found within clarifications.

06-11-2024

Certification Companion Guide: Implantable device list

This Certification Companion Guide (CCG) is an informative document designed to assist with health IT product certification. The CCG is not a substitute for the requirements outlined in regulation and related ONC final rules. It extracts key portions of ONC final rules’ preambles and includes subsequent clarifying interpretations. To access the full context of regulatory intent please consult the Certification Regulations page for links to all ONC final rules or consult other regulatory references as noted. The CCG is for public use and should not be sold or redistributed.

The below table outlines whether this criterion has additional Maintenance of Certification dependencies, update requirements and/or eligibility for standards updates via SVAP. Review the Certification Dependencies and Required Update Deadline drop-downs above if this table indicates “yes” for any field.

 

Certification Requirements
Technical Explanations and Clarifications

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
  • 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:
  • 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]