US Core Implementation Guide (Release 1.1.0 Ballot )

This page is part of the US Core (v1.1.0: STU2 Ballot 1) based on FHIR R3. The current version which supercedes this version is 5.0.1. For a full list of available versions, see the Directory of published versions

SD.5 StructureDefinition-us-core-device

This profile sets minimum expectations for the Device resource to record, search and fetch UDI information associated with a patient. 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-Device profile:

  • Query for a Patient’s Devices
  • Record a Patient Device
Mandatory Data Elements and Terminology

The following data-elements are mandatory (i.e data MUST be present). These 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 UDI string (“udicarrier”)
  2. a code identifying the type of resource
  3. a patient

Profile specific implementation guidance:

  • none

Examples

SD.5.1 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-device

Published on Mon Aug 01 00:00:00 AEST 2016 as a draft by HL7 US Realm Steering Committee.

This profile builds on Device


Complete Summary of the Mandatory Requirements

  1. One udicarrier string in Device.udicarrier
    • The Human Readable Form (HRF) representation of the barcode string as printed on the packaging of the device SHALL be used. The AIDC representation cannot be conveyed in FHIR, Because of limitations on character sets in XML and the need to round-trip JSON data through XML.
  2. A code in Device.type which has an extensible binding to:
  3. One patient reference in Device.patient
NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*US Core Implanted Device Profile
... 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: Common Languages (extensible)
... text I0..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
... udi SΣI1..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringxml:id (or equivalent in JSON)
.... extension 0..*ExtensionAdditional Content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored
.... deviceIdentifier Σ0..1stringMandatory fixed portion of UDI
.... name Σ0..1stringDevice Name as appears on UDI label
.... jurisdiction 0..1uriRegional UDI authority
.... carrierHRF Σ0..1stringUDI Human Readable Barcode String
.... carrierAIDC Σ0..1base64BinaryUDI Machine Readable Barcode String
.... issuer 0..1uriUDI Issuing Organization
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... type S1..1CodeableConceptWhat kind of device this is
Binding: FHIR Device Types (extensible)
... lotNumber 0..1stringLot number of manufacture
... manufacturer 0..1stringName of device manufacturer
... manufactureDate 0..1dateTimeDate when the device was made
... expirationDate 0..1dateTimeDate and time of expiry of this device (if applicable)
... model 0..1stringModel id assigned by the manufacturer
... version 0..1stringVersion number (i.e. software)
... 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 resource is found
... url 0..1uriNetwork address to contact device
... note 0..*AnnotationDevice notes and comments
... safety Σ0..*CodeableConceptSafety Characteristics of Device
Binding: DeviceSafety (example)

doco Documentation for this format

Complete Summary of the Mandatory Requirements

  1. One udicarrier string in Device.udicarrier
    • The Human Readable Form (HRF) representation of the barcode string as printed on the packaging of the device SHALL be used. The AIDC representation cannot be conveyed in FHIR, Because of limitations on character sets in XML and the need to round-trip JSON data through XML.
  2. A code in Device.type which has an extensible binding to:
  3. One patient reference in Device.patient

Snapshot View

NameFlagsCard.TypeDescription & Constraintsdoco
.. Device I0..*US Core Implanted Device Profile
... 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: Common Languages (extensible)
... text I0..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
... udi SΣI1..1BackboneElementUnique Device Identifier (UDI) Barcode string
.... id 0..1stringxml:id (or equivalent in JSON)
.... extension 0..*ExtensionAdditional Content defined by implementations
.... modifierExtension ?!Σ0..*ExtensionExtensions that cannot be ignored
.... deviceIdentifier Σ0..1stringMandatory fixed portion of UDI
.... name Σ0..1stringDevice Name as appears on UDI label
.... jurisdiction 0..1uriRegional UDI authority
.... carrierHRF Σ0..1stringUDI Human Readable Barcode String
.... carrierAIDC Σ0..1base64BinaryUDI Machine Readable Barcode String
.... issuer 0..1uriUDI Issuing Organization
.... entryType 0..1codebarcode | rfid | manual +
Binding: UDIEntryType (required)
... status ?!Σ0..1codeactive | inactive | entered-in-error | unknown
Binding: FHIRDeviceStatus (required)
... type S1..1CodeableConceptWhat kind of device this is
Binding: FHIR Device Types (extensible)
... lotNumber 0..1stringLot number of manufacture
... manufacturer 0..1stringName of device manufacturer
... manufactureDate 0..1dateTimeDate when the device was made
... expirationDate 0..1dateTimeDate and time of expiry of this device (if applicable)
... model 0..1stringModel id assigned by the manufacturer
... version 0..1stringVersion number (i.e. software)
... 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 resource is found
... url 0..1uriNetwork address to contact device
... note 0..*AnnotationDevice notes and comments
... safety Σ0..*CodeableConceptSafety Characteristics of Device
Binding: DeviceSafety (example)

doco Documentation for this format

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

 

SD.5.2 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.

GET /Device?patient=[id]

Example: GET [base]/Device?patient=1032702

Support: Mandatory to support search by patient.

Implementation Notes: Search for all implantable device UDIs for a patient. Fetches a bundle of all Device resources for the specified patient (how to search by reference).