Implantable Device

Overview

Unique Device Identifier(s) for a Patient’s Implantable Device(s) are recorded in the system using FHIR Device resource. Device is a type of a manufactured item that is used in the provision of healthcare without being substantially changed through that activity. The device may be a medical or non-medical device.

Each Device has next elements:

• a code identifying the type of device
• a patient

Each Device supports next elements:

• The Device Identifier (UDI-DI)
• A Unique Device Identifier (UDI) numeric or alphanumeric code
  • as the Human Readable Form (HRF) string representation of the barcode
  • or the Automatic Identification and Data Capture (AIDC) representation
• 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.
• 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

This resource conforms to USCDI V1 profile for Device - refer to StructureDefinition US Core Implantable Device. Device response will be provided in JSON (refers to Capability Statement) format as per FHIR standard R4 version.

Must support elements, mandatory and optional search parameters

Device must support these elements:

• udiCarrier
  • deviceIdentifier
  • carrierAIDC
  • carrierHRF
• distinctIdentifier
• manufactureDate
• expirationDate
• lotNumber
• serialNumber
• type
• patient

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

The syntax used to describe the interactions is described here.

SHALL support searching for all Devices for a patient using the patient search parameter:

GET [base url]/Device?patient={Type/}[id]

The following search parameter combinations SHOULD be supported (optional):

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

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

The response to any search operation is always a list of resources in a Bundle or an Operation Outcome.

Device By Patient Id

Search for Device by patient.

METHOD GET

[base url]/Device?patient={Type/}[id]

PARAMS

• [base url] - FHIR base url
• [id] - Id for the Patient

HEADERS

The Authorization token SHALL be obtained during Authentication and Authorization process. Goto Authentication and Authorization for further details.

RESPONSES

EXAMPLE:

curl --location --request GET 'https://demo.kodjin.com/fhir/Device?patient=Patient/c5137fa5-3216-b12a-cbbc-a0c6bef361g7' \
--header 'Authorization: Bearer fe1cd986-1ac7-4c26-b8b3-d632a48408fd'

Device By Id

Get Device by ID.

METHOD GET

[base url]/Device/{id}

or

[base url]/Device?_id={id}

PARAMS

• [base url] - FHIR base url
• {id} - Id for Device resource

HEADERS

The Authorization token SHALL be obtained during Authentication and Authorization process. Goto Authentication and Authorization for further details.

RESPONSES

EXAMPLE:

curl --location --request GET 'https://demo.kodjin.com/fhir/Device/c5137fa5-3216-b12a-cbbc-a0c6bef361g7' \
--header 'Authorization: Bearer fe1cd986-1ac7-4c26-b8b3-d632a48408fd'

Device by patient and type search parameters

Get Devices using the combination of the patient and type search parameters:

METHOD GET

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

PARAMS

• [base url] - FHIR base url
• {Type/} - Type for the Reference. Example: Patient
• [id] - patient id
• {system|} - terminology system used to identify device code
• [code] - device code

HEADERS

The Authorization token SHALL be obtained during Authentication and Authorization process. Goto Authentication and Authorization for further details.

RESPONSES

EXAMPLE:

curl --location --request GET 'https://demo.kodjin.com/fhir/Device?patient=Patient/fe1cd986-1ac7-4c26-b8b3-d632a48408fd&type=http://snomed.info/sct|468063009 \
--header 'Authorization: Bearer 1239b275-909e-4754-8f73-1e411fd6769e'