HL7 FHIR® US Core Implementation Guide (Release 3.0.1 STU3 Update for Comment)

This page is part of the US Core (v3.0.1: STU3 Ballot 3) 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

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 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
  3. the Device Identifier (UDI-DI)

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. 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.
  2. 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.
  • 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 Sun Aug 11 00:00:00 EDT 2019 as active by the HL7 US Realm Steering Committee.

This profile builds on Device

Device

Summary of the Mandatory 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 CodeableConcept in Device.type with an extensible binding to FHIR Device Types
  3. A Patient Reference in Device.patient

Summary of the Must Support Requirements

  1. A string in Device.distinctIdentifier
  2. A dateTime in Device.manufactureDate
  3. A dateTime in Device.expirationDate
  4. A string in Device.lotNumber
  5. A string in Device.serialNumber

Summary of Constraints

  1. At least one of the Production Identifiers (UDI-PI) SHALL be present.
NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*Item used in healthcare
us-core-9: At least one of the Production Identifiers (UDI-PI) SHALL be present.
... id Σ0..1idLogical 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
... 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ΣI1..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 SΣ0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣ0..1stringUDI Human Readable Barcode String
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... statusReason 0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible)
... distinctIdentifier S0..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 I0..*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)
... 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)
... 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 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 I0..*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 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 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

Device

Summary of the Mandatory 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 CodeableConcept in Device.type with an extensible binding to FHIR Device Types
  3. A Patient Reference in Device.patient

Summary of the Must Support Requirements

  1. A string in Device.distinctIdentifier
  2. A dateTime in Device.manufactureDate
  3. A dateTime in Device.expirationDate
  4. A string in Device.lotNumber
  5. A string in Device.serialNumber

Summary of Constraints

  1. At least one of the Production Identifiers (UDI-PI) SHALL be present.

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*Item used in healthcare
us-core-9: At least one of the Production Identifiers (UDI-PI) SHALL be present.
... id Σ0..1idLogical 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
... 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ΣI1..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 SΣ0..1base64BinaryUDI Machine Readable Barcode String
.... carrierHRF SΣ0..1stringUDI Human Readable Barcode String
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... statusReason 0..*CodeableConceptonline | paused | standby | offline | not-ready | transduc-discon | hw-discon | off
Binding: FHIRDeviceStatusReason (extensible)
... distinctIdentifier S0..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 I0..*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)
... 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)
... 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 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 I0..*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 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 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

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, search parameter combinations SHALL be supported. Any listed search parameter modifiers, comparators, chains and composites SHALL also be supported UNLESS they are listed as “optional” in which case they SHOULD 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 parameters, search parameter combinations and search parameter modifiers, comparators, chains and composites 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)