US-Core CI Build

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

D.4.1 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

D.4.1.1 Formal Views of Profile Content

The official URL for this profile is: 

http://hl7.org/fhir/us/core/StructureDefinition/us-core-device

This profile builds on Device.

This profile was published on Mon Aug 01 00:00:00 AEST 2016 as a draft by Health Level Seven International (FHIR-Infrastructure).

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

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
... udiCarrier S1..1IdentifierUnique Device Identifier (UDI) Barcode string
... status ?!∑0..1codeavailable | not-available | entered-in-error
Binding: DeviceStatus (required)
... type S1..1CodeableConceptWhat kind of device this is
Binding: 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

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
... udiCarrier S1..1IdentifierUnique Device Identifier (UDI) Barcode string
... status ?!∑0..1codeavailable | not-available | entered-in-error
Binding: DeviceStatus (required)
... type S1..1CodeableConceptWhat kind of device this is
Binding: 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

doco Documentation for this format

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

 

D.4.1.2 Quick Start

Below is an overview of the required search and read operations.

Summary of Argonaut Search Criteria for StructureDefinition-us-core-device

Clients

  • A client has connected to a server and fetched all Unique device identifier(s)(UDI)for a patient’s implantable device(s)using GET /Device?patient=[id].

Servers

  • A server is capable of returning all Unique device identifier(s)(UDI) for a patient’s implantable device(s) using GET /Device?patient=[id].

  • A server has ensured that every API request includes a valid Authorization token, supplied via:Authorization: Bearer {server-specific-token-here}
  • A server has rejected any unauthorized requests by returning an HTTP 401 Unauthorized response code.

GET /Device?patient=[id]

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).

Response Class:

  • (Status 200): successful operation
  • (Status 400): invalid parameter
  • (Status 401/4xx): unauthorized request
  • (Status 403): insufficient scope

Example:

GET http://fhir2.healthintersections.com.au/open/Device/uscore-udi-1