US Core Implementation Guide
3.2.0 - ballot

This page is part of the US Core (v3.2.0: STU4 Ballot 1) 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:3.2.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 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.
    • UDI may not be present in all scenarios such as historical implantable devices, patient reported implant information, payer reported devices, or improperly documented implants.
    • Servers are not required to support both carrierAIDC and carrierHR.
  • 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

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: 8 elements

Structures

This structure refers to these other structures:

This structure is derived from Device

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*DeviceItem used in healthcare
us-core-12: Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
... udiCarrier S0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier S1..1stringMandatory fixed portion of UDI
.... carrierAIDC I0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF I0..1stringUDI Human Readable Barcode String
... distinctIdentifier I0..1stringThe distinct identification string
... manufactureDate SI0..1dateTimeDate when the device was made
... expirationDate SI0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber SI0..1stringLot number of manufacture
... serialNumber SI0..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 I0..*DeviceItem used in healthcare
us-core-12: Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
... 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 ΣI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF ΣI0..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 I0..1stringThe distinct identification string
... manufacturer 0..1stringName of device manufacturer
... manufactureDate SI0..1dateTimeDate when the device was made
... expirationDate SI0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber SI0..1stringLot number of manufacture
... serialNumber SI0..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 I0..*DeviceItem used in healthcare
us-core-12: Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
... udiCarrier Σ0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier Σ1..1stringMandatory fixed portion of UDI
... manufactureDate I0..1dateTimeDate when the device was made
... expirationDate I0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber I0..1stringLot number of manufacture
... serialNumber I0..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: 8 elements

Structures

This structure refers to these other structures:

Differential View

This structure is derived from Device

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*DeviceItem used in healthcare
us-core-12: Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
... udiCarrier S0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier S1..1stringMandatory fixed portion of UDI
.... carrierAIDC I0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF I0..1stringUDI Human Readable Barcode String
... distinctIdentifier I0..1stringThe distinct identification string
... manufactureDate SI0..1dateTimeDate when the device was made
... expirationDate SI0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber SI0..1stringLot number of manufacture
... serialNumber SI0..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 I0..*DeviceItem used in healthcare
us-core-12: Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
... 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 ΣI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF ΣI0..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 I0..1stringThe distinct identification string
... manufacturer 0..1stringName of device manufacturer
... manufactureDate SI0..1dateTimeDate when the device was made
... expirationDate SI0..1dateTimeDate and time of expiry of this device (if applicable)
... lotNumber SI0..1stringLot number of manufacture
... serialNumber SI0..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: Schematron

Terminology Bindings

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

Constraints

IdPathDetailsRequirements
us-core-12DeviceImplantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
: udiCarrier.empty() or (udiCarrier.carrierAIDC.exists() or udiCarrier.carrierHRF.exists())
us-core-9DeviceFor implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
: udiCarrier.empty() or (manufactureDate.exists() or expirationDate.exists() or lotNumber.exists() or serialNumber.exists() or distinctIdentifier.exists())

Notes:

Quick Start

Below is an overview of the required set of Server RESTful FHIR interactions - for example, search and read operations - for this profile. See the Capability Statements 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)