This page is part of the US Core (v3.1.0: STU3) based on FHIR R4. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

• Narrative Content
• Detailed Descriptions
• XML
• JSON

StructureDefinition-us-core-implantable-device

This profile sets minimum expectations for the Device resource to record, search, and fetch UDI information associated with a patient’s implantable device(s). It identifies which core elements, extensions, vocabularies and value sets SHALL be present in the resource when using this profile.

Example Usage Scenarios:

The following are example usage scenarios for the US Core Implantable Device profile:

• Query for a Patient’s Implantable Devices
• Record or update a Patient Implantable Device

Mandatory and Must Support Data Elements

The following data-elements are mandatory (i.e data MUST be present) or must be supported if the data is present in the sending system (Must Support definition). They are presented below in a simple human-readable explanation. Profile specific guidance and examples are provided as well. The Formal Profile Definition below provides the formal summary, definitions, and terminology requirements.

Each Device must have:

1. a code identifying the type of device
2. a patient

In addition, the following data-elements must be supported if the data is present in the sending system (Must Support definition):

Each Device must support:

1. The Device Identifier (UDI-DI)
2. A Unique Device Identifier (UDI) numeric or alphanumeric code
   • either as the Human Readable Form (HRF) string representation of the barcode
   • or the Automatic Identification and Data Capture (AIDC) representation.
3. The following parsed Production Identifiers (UDI-PI) from the UDI
   • the manufacture date
   • the expiration date
   • the lot number
   • the serial number
   • the distinct identifier (i.e., the distinct identification code)

Profile specific implementation guidance:

• This profile supports the requirement to retrieve an 170.315(a)(14) Implantable device list. Implementers are encouraged to use the FDA Global UDI Database (GUDID) and associated APIs to parse and validate the UDI:
  • The AccessGUDID API provides access to device records in GUDID including safety information and UDI. It includes APIs to query and download a complete list of implantable devices registered in GUDID.
  • The Parse UDI API allows users to pass a UDI and return each part of the UDI in a structured format (specifically the serialNumber, lotNumber, expirationDate, distinctIdentifier (returned as donation_id) or manufactureDate).
• Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF. (Note that the UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants.)
• For Implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
• Servers SHOULD support query by Device.type to allow clients to request the patient’s devices by a specific type. Note: The Device.type is too granular to differentiate implantable vs. non-implantable devices.

• In the Quick Start section below, searching for all devices is described. Records of implanted devices MAY be queried against UDI data including:

  • UDI HRF string (udi-carrier)
  • UDI Device Identifier (udi-di)
  • Manufacturer (manufacturer)
  • Model number (model)

  Implementers MAY also adopt custom SearchParameters for searching by:

  • lot numbers
  • serial number
  • expiration date
  • manufacture date
  • distinct identifier

Examples

• Device-UDI-1
• Device-UDI-2
• Device-UDI-3

Formal Views of Profile Content

Description of Profiles, Differentials, and Snapshots.

The official URL for this profile is: http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-deviceCopy

Published on Tue Sep 17 00:00:00 AEST 2019 as active by the HL7 US Realm Steering Committee.

This profile builds on Device

---

Downloads: StructureDefinition: (XML, JSON), Schema: XML Schematron

Quick Start

Below is an overview of the required set of RESTful FHIR interactions - for example, search and read operations - for this profile. See the Conformance requirements for a complete list of supported RESTful interactions for this IG.

• See the General Guidance section for additional rules and expectations when a server requires status parameters.
• See the General Guidance section for additional guidance on searching for multiple patients.

Mandatory Search Parameters:

The following search parameters and search parameter combinations SHALL be supported.:

1. SHALL support searching for all devices for a patient, including implantable devices using the patient search parameter:

   GET [base]/Device?patient=[reference]

   Example:

   1. GET [base]/Device?patient=1137192

   Implementation Notes: Fetches a bundle of all Device resources for the specified patient (how to search by reference)

Optional Search Parameters:

The following search parameter combinations SHOULD be supported.:

1. SHOULD support searching using the combination of the patient and type search parameters:

   GET [base]/Device?patient=[reference]&type={[system]}|[code]

   Example:

   1. GET [base]/Device?patient=1316024&type=http://snomed.info/sct|468063009

   Implementation Notes: Fetches a bundle of all Device resources for the specified patient and type. (how to search by reference and how to search by token)