US Core Implementation Guide
4.0.0 - STU4 Release

This page is part of the US Core (v4.0.0: STU4) 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

Resource Profile: US Core Implantable Device Profile

Defining URL:http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device
Version:4.0.0
Name:USCoreImplantableDeviceProfile
Title:US Core Implantable Device Profile
Status:Active as of 2019-09-17
Definition:

Defines constraints and extensions on the Device resource for the minimal set of data to query and retrieve a patient's implantable device(s).

Publisher:HL7 International - US Realm Steering Committee
Copyright:

Used by permission of HL7 International, all rights reserved Creative Commons License

Source Resource:XML / JSON / Turtle

The official URL for this profile is: 

http://hl7.org/fhir/us/core/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. The profile is intended to only be used for implantable devices. For non-implantable devices (for example, software or crutches) use the base FHIR Device resource or other use case specific Device 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 must always be present (Mandatory definition]) 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 Implantable 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 Implantable Device must support:

  1. A Unique Device Identifier (UDI) numeric or alphanumeric code as the Human Readable Form (HRF) string representation of the barcode
  2. The Device Identifier (UDI-DI)
  3. the manufacture date
  4. the expiration date
  5. the lot number
  6. the serial number
  7. 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 and follows the HL7 Cross Paradigm Implementation Guide: UDI Pattern guidelines for exchanging information about the use of and/or implantation of medical devices in patients.

    • A unique device identifier (UDI) is a unique numeric or alphanumeric code. There is a machine-readable version (AIDC - the Automatic Identification and Data Capture) as well as a human-readable version of the UDI (HRF - Human Readable Form string). This profile specifies that only the HRF must be supported. Considering the complexity of parsing AIDCs there is no expectation at this time that one converts an AIDC to HRF upon receipt from a FHIR source that is not conformant to this profile or is using another interchange standard (e.g., C-CDA, HL7 v2, etc). The UDI generally consists of a mandatory Device identifier (DI) and a conditional Production identifier (PI) that identifies one or more of the five UDI-PI elements. The UDI and its components are mapped to the US Core Implantable Device Profile elements in the table below:

      UDI component US Core Implantable Device Profile element
      UDI HRF string Device.udiCarrier.carrierHRF
      DI Device.udiCarrier.deviceIdentifier
      manufacture date (UDI-PI element) Device.manufactureDate
      expiration dat (UDI-PI elemente Device.expirationDate
      lot number (UDI-PI element) Device.lotNumber
      serial number (UDI-PI element) Device.serialNumber
      distinct identifier (UDI-PI element) Device.distinctIdentifier

    • 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 the UDI code in Device.udiCarrier.carrierHRF.
    • All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element.

    UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants. If UDI is not present and the manufacturer and/or model number information is available, they SHOULD be included to support historical reports of implantable medical devices as follows:

    data element US Core Implantable Device Profile element
    manufacturer Device.manufacturer
    model Device.model
  • 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

Formal Views of Profile Content

Description of Profiles, Differentials, Snapshots and how the different presentations work.

This structure is derived from Device

Summary

Mandatory: 2 elements (1 nested mandatory element)
Must-Support: 9 elements

Structures

This structure refers to these other structures:

This structure is derived from Device

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device 0..*DeviceItem used in healthcare
... udiCarrier S0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier S1..1stringMandatory fixed portion of UDI
.... carrierHRF S0..1stringUDI Human Readable Barcode String
... distinctIdentifier 0..1stringThe distinct identification string
... manufactureDate S0..1dateTimeDate when the device was made
... expirationDate S0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber S0..1stringLot number of manufacture
... serialNumber S0..1stringSerial number assigned by the manufacturer
... type S1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible): Codes to identify medical devices

... patient S1..1Reference(US Core Patient Profile)Patient to whom Device is affixed

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. Device 0..*DeviceItem used in healthcare
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages: A human language.

... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier 0..*IdentifierInstance identifier
... definition 0..1Reference(DeviceDefinition)The reference to the definition for the device
... udiCarrier SΣ0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... deviceIdentifier SΣ1..1stringMandatory fixed portion of UDI
.... issuer 0..1uriUDI Issuing Organization
.... jurisdiction 0..1uriRegional UDI authority
.... carrierAIDC Σ0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣ0..1stringUDI Human Readable Barcode String
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required): Codes to identify how UDI data was entered.

... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required): The availability status of the device.

... statusReason 0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible): The availability status reason of the device.


... distinctIdentifier 0..1stringThe distinct identification string
... manufacturer 0..1stringName of device manufacturer
... manufactureDate S0..1dateTimeDate when the device was made
... expirationDate S0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber S0..1stringLot number of manufacture
... serialNumber S0..1stringSerial number assigned by the manufacturer
... deviceName 0..*BackboneElementThe name of the device as given by the manufacturer
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... name 1..1stringThe name of the device
.... type 1..1codeudi-label-name | user-friendly-name | patient-reported-name | manufacturer-name | model-name | other
Binding: DeviceNameType (required): The type of name the device is referred by.

... modelNumber 0..1stringThe model number for the device
... partNumber 0..1stringThe part number of the device
... type S1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible): Codes to identify medical devices

... specialization 0..*BackboneElementThe capabilities supported on a device, the standards to which the device conforms for a particular purpose, and used for the communication
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... systemType 1..1CodeableConceptThe standard that is used to operate and communicate
.... version 0..1stringThe version of the standard that is used to operate and communicate
... version 0..*BackboneElementThe actual design of the device or software version running on the device
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type 0..1CodeableConceptThe type of the device version
.... component 0..1IdentifierA single component of the device version
.... value 1..1stringThe version text
... property 0..*BackboneElementThe actual configuration settings of a device as it actually operates, e.g., regulation status, time properties
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type 1..1CodeableConceptCode that specifies the property DeviceDefinitionPropetyCode (Extensible)
.... valueQuantity 0..*QuantityProperty value as a quantity
.... valueCode 0..*CodeableConceptProperty value as a code, e.g., NTP4 (synced to NTP)
... patient S1..1Reference(US Core Patient Profile)Patient to whom Device is affixed
... owner 0..1Reference(Organization)Organization responsible for device
... contact 0..*ContactPointDetails for human/organization for support
... location 0..1Reference(Location)Where the device is found
... url 0..1uriNetwork address to contact device
... note 0..*AnnotationDevice notes and comments
... safety Σ0..*CodeableConceptSafety Characteristics of Device
... parent 0..1Reference(Device)The parent device

doco Documentation for this format
NameFlagsCard.TypeDescription & Constraintsdoco
.. Device 0..*DeviceItem used in healthcare
... udiCarrier Σ0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier Σ1..1stringMandatory fixed portion of UDI
.... carrierHRF Σ0..1stringUDI Human Readable Barcode String
... manufactureDate 0..1dateTimeDate when the device was made
... expirationDate 0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber 0..1stringLot number of manufacture
... serialNumber 0..1stringSerial number assigned by the manufacturer
... type 1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible): Codes to identify medical devices

... patient 1..1Reference(US Core Patient Profile)Patient to whom Device is affixed

doco Documentation for this format

This structure is derived from Device

Summary

Mandatory: 2 elements (1 nested mandatory element)
Must-Support: 9 elements

Structures

This structure refers to these other structures:

Differential View

This structure is derived from Device

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device 0..*DeviceItem used in healthcare
... udiCarrier S0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier S1..1stringMandatory fixed portion of UDI
.... carrierHRF S0..1stringUDI Human Readable Barcode String
... distinctIdentifier 0..1stringThe distinct identification string
... manufactureDate S0..1dateTimeDate when the device was made
... expirationDate S0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber S0..1stringLot number of manufacture
... serialNumber S0..1stringSerial number assigned by the manufacturer
... type S1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible): Codes to identify medical devices

... patient S1..1Reference(US Core Patient Profile)Patient to whom Device is affixed

doco Documentation for this format

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device 0..*DeviceItem used in healthcare
... id Σ0..1stringLogical id of this artifact
... meta Σ0..1MetaMetadata about the resource
... implicitRules ?!Σ0..1uriA set of rules under which this content was created
... language 0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages: A human language.

... text 0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension 0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!0..*ExtensionExtensions that cannot be ignored
... identifier 0..*IdentifierInstance identifier
... definition 0..1Reference(DeviceDefinition)The reference to the definition for the device
... udiCarrier SΣ0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... deviceIdentifier SΣ1..1stringMandatory fixed portion of UDI
.... issuer 0..1uriUDI Issuing Organization
.... jurisdiction 0..1uriRegional UDI authority
.... carrierAIDC Σ0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣ0..1stringUDI Human Readable Barcode String
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required): Codes to identify how UDI data was entered.

... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required): The availability status of the device.

... statusReason 0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible): The availability status reason of the device.


... distinctIdentifier 0..1stringThe distinct identification string
... manufacturer 0..1stringName of device manufacturer
... manufactureDate S0..1dateTimeDate when the device was made
... expirationDate S0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber S0..1stringLot number of manufacture
... serialNumber S0..1stringSerial number assigned by the manufacturer
... deviceName 0..*BackboneElementThe name of the device as given by the manufacturer
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... name 1..1stringThe name of the device
.... type 1..1codeudi-label-name | user-friendly-name | patient-reported-name | manufacturer-name | model-name | other
Binding: DeviceNameType (required): The type of name the device is referred by.

... modelNumber 0..1stringThe model number for the device
... partNumber 0..1stringThe part number of the device
... type S1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible): Codes to identify medical devices

... specialization 0..*BackboneElementThe capabilities supported on a device, the standards to which the device conforms for a particular purpose, and used for the communication
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... systemType 1..1CodeableConceptThe standard that is used to operate and communicate
.... version 0..1stringThe version of the standard that is used to operate and communicate
... version 0..*BackboneElementThe actual design of the device or software version running on the device
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type 0..1CodeableConceptThe type of the device version
.... component 0..1IdentifierA single component of the device version
.... value 1..1stringThe version text
... property 0..*BackboneElementThe actual configuration settings of a device as it actually operates, e.g., regulation status, time properties
.... id 0..1stringUnique id for inter-element referencing
.... extension 0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type 1..1CodeableConceptCode that specifies the property DeviceDefinitionPropetyCode (Extensible)
.... valueQuantity 0..*QuantityProperty value as a quantity
.... valueCode 0..*CodeableConceptProperty value as a code, e.g., NTP4 (synced to NTP)
... patient S1..1Reference(US Core Patient Profile)Patient to whom Device is affixed
... owner 0..1Reference(Organization)Organization responsible for device
... contact 0..*ContactPointDetails for human/organization for support
... location 0..1Reference(Location)Where the device is found
... url 0..1uriNetwork address to contact device
... note 0..*AnnotationDevice notes and comments
... safety Σ0..*CodeableConceptSafety Characteristics of Device
... parent 0..1Reference(Device)The parent device

doco Documentation for this format

 

Other representations of profile: CSV, Excel, Schematron

Terminology Bindings

PathConformanceValueSet
Device.languagepreferredCommonLanguages
Max Binding: AllLanguages
Device.udiCarrier.entryTyperequiredUDIEntryType
Device.statusrequiredFHIRDeviceStatus
Device.statusReasonextensibleFHIRDeviceStatusReason
Device.deviceName.typerequiredDeviceNameType
Device.typeextensibleFHIRDeviceTypes

Notes:

Quick Start

Below is an overview of the required Server RESTful FHIR interactions for this profile - for example, search and read operations - when supporting the US Core interactions to access this profile’s information (Profile Support + Interaction Support). Note that systems that support only US Core Profiles (Profile Only Support) are not required to support these interactions. See the US Core Server CapabilityStatement for a complete list of supported RESTful interactions for this IG.

  • The syntax used to describe the interactions is described here.
  • 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={Type/}[id]

    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={Type/}[id]&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)