HL7 FHIR® US Core Implementation Guide CI Build

US Core, published by HL7 International - US Realm Steering Committee. This is not an authorized publication; it is the continuous build for version 3.1.1). This version is based on the current content of https://github.com/HL7/US-Core-R4/ and changes regularly. See the Directory of published versions

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

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-device

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

This profile builds on Device


Device

Summary of the Mandatory Requirements

  1. A CodeableConcept in Device.type with an extensible binding to FHIR Device Types
  2. A Patient Reference in Device.patient

Summary of the Must Support Requirements

  1. A Udicarrier in Device.udiCarrier
    • which must have a string value in Device.udiCarrier.deviceIdentifier
    • which should have a base64Binary value in Device.udiCarrier.carrierAIDC
    • which should have a string value in Device.udiCarrier.carrierHRF
  2. A string in Device.distinctIdentifier
  3. A dateTime in Device.manufactureDate
  4. A dateTime in Device.expirationDate
  5. A string in Device.lotNumber
  6. A string in Device.serialNumber

Summary of Constraints

  1. Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
  2. For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.
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 SI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SI0..1stringUDI Human Readable Barcode String
... distinctIdentifier SI0..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)
... 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 ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... language I0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier I0..*IdentifierInstance identifier
... definition I0..1Reference(DeviceDefinition)The reference to the definition for the device
... udiCarrier SΣI0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... deviceIdentifier SΣI1..1stringMandatory fixed portion of UDI
.... issuer I0..1uriUDI Issuing Organization
.... jurisdiction I0..1uriRegional UDI authority
.... carrierAIDC SΣI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣI0..1stringUDI Human Readable Barcode String
.... entryType I0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!ΣI0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... statusReason I0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible)
... distinctIdentifier SI0..1stringThe distinct identification string
... manufacturer I0..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 I0..*BackboneElementThe name of the device as given by the manufacturer
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... name I1..1stringThe name of the device
.... type I1..1codeudi-label-name | user-friendly-name | patient-reported-name | manufacturer-name | model-name | other
Binding: DeviceNameType (required)
... modelNumber I0..1stringThe model number for the device
... partNumber I0..1stringThe part number of the device
... type SI1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible)
... specialization I0..*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 I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... systemType I1..1CodeableConceptThe standard that is used to operate and communicate
.... version I0..1stringThe version of the standard that is used to operate and communicate
... version I0..*BackboneElementThe actual design of the device or software version running on the device
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type I0..1CodeableConceptThe type of the device version
.... component I0..1IdentifierA single component of the device version
.... value I1..1stringThe version text
... property I0..*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 I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type I1..1CodeableConceptCode that specifies the property DeviceDefinitionPropetyCode (Extensible)
.... valueQuantity I0..*QuantityProperty value as a quantity
.... valueCode I0..*CodeableConceptProperty value as a code, e.g., NTP4 (synced to NTP)
... patient SI1..1Reference(US Core Patient Profile)Patient to whom Device is affixed
... owner I0..1Reference(Organization)Organization responsible for device
... contact I0..*ContactPointDetails for human/organization for support
... location I0..1Reference(Location)Where the device is found
... url I0..1uriNetwork address to contact device
... note I0..*AnnotationDevice notes and comments
... safety ΣI0..*CodeableConceptSafety Characteristics of Device
... parent I0..1Reference(Device)The parent device

doco Documentation for this format

Device

Summary of the Mandatory Requirements

  1. A CodeableConcept in Device.type with an extensible binding to FHIR Device Types
  2. A Patient Reference in Device.patient

Summary of the Must Support Requirements

  1. A Udicarrier in Device.udiCarrier
    • which must have a string value in Device.udiCarrier.deviceIdentifier
    • which should have a base64Binary value in Device.udiCarrier.carrierAIDC
    • which should have a string value in Device.udiCarrier.carrierHRF
  2. A string in Device.distinctIdentifier
  3. A dateTime in Device.manufactureDate
  4. A dateTime in Device.expirationDate
  5. A string in Device.lotNumber
  6. A string in Device.serialNumber

Summary of Constraints

  1. Implantable medical devices that have UDI information SHALL represent this information in either carrierAIDC or carrierHRF.
  2. For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.

Differential 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.
... udiCarrier S0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... deviceIdentifier S1..1stringMandatory fixed portion of UDI
.... carrierAIDC SI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SI0..1stringUDI Human Readable Barcode String
... distinctIdentifier SI0..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)
... 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 ΣI0..1MetaMetadata about the resource
... implicitRules ?!ΣI0..1uriA set of rules under which this content was created
... language I0..1codeLanguage of the resource content
Binding: CommonLanguages (preferred)
Max Binding: AllLanguages
... text I0..1NarrativeText summary of the resource, for human interpretation
... contained 0..*ResourceContained, inline Resources
... extension I0..*ExtensionAdditional content defined by implementations
... modifierExtension ?!I0..*ExtensionExtensions that cannot be ignored
... identifier I0..*IdentifierInstance identifier
... definition I0..1Reference(DeviceDefinition)The reference to the definition for the device
... udiCarrier SΣI0..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... deviceIdentifier SΣI1..1stringMandatory fixed portion of UDI
.... issuer I0..1uriUDI Issuing Organization
.... jurisdiction I0..1uriRegional UDI authority
.... carrierAIDC SΣI0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣI0..1stringUDI Human Readable Barcode String
.... entryType I0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!ΣI0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... statusReason I0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible)
... distinctIdentifier SI0..1stringThe distinct identification string
... manufacturer I0..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 I0..*BackboneElementThe name of the device as given by the manufacturer
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... name I1..1stringThe name of the device
.... type I1..1codeudi-label-name | user-friendly-name | patient-reported-name | manufacturer-name | model-name | other
Binding: DeviceNameType (required)
... modelNumber I0..1stringThe model number for the device
... partNumber I0..1stringThe part number of the device
... type SI1..1CodeableConceptThe kind or type of device
Binding: FHIRDeviceTypes (extensible)
... specialization I0..*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 I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... systemType I1..1CodeableConceptThe standard that is used to operate and communicate
.... version I0..1stringThe version of the standard that is used to operate and communicate
... version I0..*BackboneElementThe actual design of the device or software version running on the device
.... id 0..1stringUnique id for inter-element referencing
.... extension I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type I0..1CodeableConceptThe type of the device version
.... component I0..1IdentifierA single component of the device version
.... value I1..1stringThe version text
... property I0..*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 I0..*ExtensionAdditional content defined by implementations
.... modifierExtension ?!ΣI0..*ExtensionExtensions that cannot be ignored even if unrecognized
.... type I1..1CodeableConceptCode that specifies the property DeviceDefinitionPropetyCode (Extensible)
.... valueQuantity I0..*QuantityProperty value as a quantity
.... valueCode I0..*CodeableConceptProperty value as a code, e.g., NTP4 (synced to NTP)
... patient SI1..1Reference(US Core Patient Profile)Patient to whom Device is affixed
... owner I0..1Reference(Organization)Organization responsible for device
... contact I0..*ContactPointDetails for human/organization for support
... location I0..1Reference(Location)Where the device is found
... url I0..1uriNetwork address to contact device
... note I0..*AnnotationDevice notes and comments
... safety ΣI0..*CodeableConceptSafety Characteristics of Device
... parent I0..1Reference(Device)The parent device

doco Documentation for this format

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


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 Conformance requirements 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=[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)