Empowering individuals to better manage their health.PCHA – Devices Task Force

Adding UDI Support to the PCHAContinua Guidelines – v3

Erik MollDevices TF chair

1

Empowering individuals to better manage their health.PCHA – Devices Task Force

UDI Support in the Continua Guidelines?

2

• Background:– FDA is establishing a unique device identification

system to adequately identify medical devices through their distribution and use. When fully implemented, the label of most devices will include a unique device identifier (UDI) in human- and machine-readable form. Device labelers must also submit certain information about each device to FDA’s Global Unique Device Identification Database (GUDID). The public will be able to search and download information from the GUDID.

– see http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/default.htm?utm_source=Members-Only%20Updates

Empowering individuals to better manage their health.PCHA – Devices Task Force

intro

3

• We are looking into support for UDI in the Continua guidelines / interfaces– It seems relevant & useful to be prepared for this FDA requirement– IEEE 11073 and BLE sensor device specifications could be updated to

be enable transmission of a device UDI to an AHD• in BLE it could be in device information service as optional characteristic(s) &

added to transcoding• This could also be done in IEEE -20601 as optional attribute(s) in MDS

– There needs to be support for UDI in IHE-PCD01 – to transport UDIs from the AHD and sensor devices on the WAN interface

– Use case: see benefits of a UDI system• http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDe

viceIdentification/BenefitsofaUDIsystem/default.htm

– Physical label will be required first; no requirement yet on electronic communication of the UDI, but that can be expected in the near future.

Empowering individuals to better manage their health.PCHA – Devices Task Force

Example UDI label

4

Empowering individuals to better manage their health.PCHA – Devices Task Force

UDI Basics

5

• A UDI is a unique numeric or alphanumeric code that consists of two parts:– a device identifier (DI), a mandatory, fixed portion of a UDI that

identifies the labeler and the specific version or model of a device, – and a production identifier (PI), a conditional, variable portion of a

UDI that identifies one or more of the following when included on the label of a device:• the lot or batch number within which a device was manufactured;• the serial number of a specific device;• the expiration date of a specific device;• the date a specific device was manufactured;• the distinct identification code required by §1271.290(c) for a human cell,

tissue, or cellular and tissue-based product (HCT/P) regulated as a device

– UDI = DI + PI

Empowering individuals to better manage their health.PCHA – Devices Task Force

GUDID

6

• As part of the system, the device labelers are required to submit information to the FDA-administered Global Unique Device Identification Database (GUDID). – The GUDID will include a standard set of basic identifying elements for each device with a UDI,

and contain ONLY the DI, which would serve as the key to obtain device information in the database. PIs are not part of the GUDID. Most of this information will be made available to the public so that users of medical devices can easily look up information about the device. The UDI does not indicate, and the GUDID database will not contain, any information about who uses a device, including personal privacy information.

– The labeler must submit product information concerning devices to FDA's Global Unique Device Identification Database (GUDID), unless subject to an exception or alternative.• http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/UniqueDeviceIdentification/UDIExcep

tionsAlternativesandTimeExtensions/default.htm

• The GUDID provides two options for submission of device identification information:– GUDID Web Interface – enables structured input of device information as one DI record at a

time.– HL7 SPL submission – enables submission of device information as xml files

Empowering individuals to better manage their health.PCHA – Devices Task Force

GUDID

7

Empowering individuals to better manage their health.PCHA – Devices Task Force

Automatic processing

8

• Each UDI must be provided in a plain-text version and in a form that uses automatic identification and data capture (AIDC) technology.– Automatic identification and data capture (AIDC)

means any technology that conveys the UDI or the device identifier of a device in a form that can be entered into an electronic patient record or other computer system via an automated process.

Empowering individuals to better manage their health.PCHA – Devices Task Force

Fit in IEEE 11073-20601option 1: System Model [& Id]

9

---- SystemModel contains manufacturer name and manufacturer specific model information.-- While model-number field name suggests a number, there is no requirement that the field-- contains numeric values. The format of the manufacturer name and model number strings-- are decided upon by the agent vendor, but shall be printable ASCII.--SystemModel ::= SEQUENCE {

manufacturer OCTET STRING, -- string size shall be evenmodel-number OCTET STRING -- string size shall be even

}

System-Model

MDC_ATTR_ID_MODEL SystemModel This attribute defines manufacturer and model number of the agent device.

MandatoryStatic

System-Id MDC_ATTR_SYS_ID OCTET STRING This attribute is an IEEE EUI-64, which consists of a 24-bit unique organizationally unique identifier (OUI) followed by a 40-bit manufacturer-defined ID. The OUI shall be a value assigned by the IEEE Registration Authority (http://standards.ieee.org/regauth/index.html) and shall be used in accordance with IEEE Std 802-2001.

MandatoryStatic

DI defines the labeler and the specific version or model of a device.This is similar to System-Model in the MDS.Also the System-Id OUI part could be used – but since FDA assigns DI values, this cannot be used…

Empowering individuals to better manage their health.PCHA – Devices Task Force

Option 2: Production Spec

10

---- ProductionSpec deals with serial numbers, part numbers, revisions, etc.-- Note that an agent may have multiple components; therefore, the prod-spec should be an -- ASCII printable string of the format “spec-type: vendor-specified-str” where spec-type is-- replaced by the string representation of spec-type. The format of the vendor-specified-str-- is determined by the vendor.--ProductionSpec ::= SEQUENCE OF ProdSpecEntry ProdSpecEntry ::= SEQUENCE { spec-type INT-U16 { unspecified(0), serial-number(1), part-number(2), hw-revision(3), sw-revision(4), fw-revision(5), protocol-revision(6), prod-spec-gmdn(7) -- see note on GMDN below }, component-id PrivateOid, prod-spec OCTET STRING -- string size shall be even}Production-Specification

MDC_ATTR_ID_PROD_SPECN

ProductionSpec This attribute defines component revisions, serial numbers, and so on in a manufacturer-specific format.

OptionalStatic

• ProductionSpec can be extended with a bit for UDI and/or separate bits for DI/PI is an option:fda-udi(8),fda-di(9),fda-pi(10)

• This allows carrying multiple UDIs in the MDS.• Could this be used in the proxy situation as well to have the UDI of the proxied components being

reported by the agent as well?

Empowering individuals to better manage their health.PCHA – Devices Task Force

Option 3: new attribute in the MDS

11

• Add UDI as a new attribute to the MDS– Not worked out yet…

Empowering individuals to better manage their health.PCHA – Devices Task Force

Discussion in IEEE / DC sessionFurther looking inside the UDI DI+PI parts

12

• The actual UDI label can be formatted in various ways– See “UDI formats by FDA-Accredited Issuing Agency” and “

GUDID Data Elements Reference Table - May 7, 2014”• The following fields could be supported in the ProductionSpec and then be used to compose

the UDI by concatenating them:– DI – Manufacturing/Production Date– Expiration Date– Batch/Lot Number– Serial Number

• This would be simple for the GS1 formatted UDI. The GS1 issuing agency is one of the currently 3 FDA accredited bodies.– GS1 UDI example: (01)51022222233336(11)141231(17)150707(10)A213B1(21)1234– HIBCC UDI example:

+H123PARTNO1234567890120/$$420020216LOT123456789012345/SXYZ4567890123 45678/16D20130202C

– ICCBBA UDIexample: :=/A9999XYZ100T0944=,000025=A99971312345600=>014032=}013032&,1000000000000XYZ123

• Before adding any of this to 11073 we want to know what will happen in EU and how much variety there will be in the formatting of the UDI

Empowering individuals to better manage their health.PCHA – Devices Task Force

Discussion in IEEE – supporting composite / proxy products

13

How to support multiple UDIs exactly – for composite devices / proxy devices?

• The proxy use case is not specific for UDI, also the other ProdSpecEntries could be coming from a “proxied” or composite device. – There is no mechanism in 11073 yet to give any semantics to multiple

ProdSpecEntries for proxied or composite devices– There is no defined mechanism yet to handle updates for new proxied

devices that connect via the proxy agent• Is there a practical need for this? Will it be used in actual

products?• Can we find a simple scheme to support such hierarchies?

Hierarchies are probably not needed – sequences are enough

Empowering individuals to better manage their health.PCHA – Devices Task Force

Supporting multiple FDA UDIs in 11073

14

• Option: Use a sequence of ProdSpecEntries as supported in 11073 now– Determine that the first entry would be that of the “main” part

of the sensor device if that’s needed– Subsequent elements could be used for components of the

device that have their own UDI– More information can be provided by using more sequence

elements within the ProdSpecEntry • Would this be sufficient?

– E.g. for CGM a sequence of 2 or 3 UDIs would be sufficient (for sensor & disposable & transmitter parts)

• Other options?

Empowering individuals to better manage their health.PCHA – Devices Task Force

Alignment with other initiatives / non-US regulatory bodies

15

• IHE / HL7 – support is planned in V2.8• OpenSDC – supported • “Classic” IEEE-11073 – should be aligned

• Non-US bodies: may propose similar schemes….

Empowering individuals to better manage their health.PCHA – Devices Task Force

UDI – What’s next?

16

• We asked BLE Med WG & IEEE PHD WG to look into UDI support as an option to Device Information Service / MDS respectively…– It is somehow possible

• Align with IHE / HL7 for support in PCD-01 on the WAN interface– There is a place for it on the WAN interface (HL7 v2.8 elements)– AHD needs to have it’s own UDI

• Timing: not that urgent – this may go in one of the next releases of the Continua Design Guidelines…

• So, we take a step back:– We should follow use case process as well (fast track is an option) – further alignment may be needed – with other SDOs, WAN/HRN interface , and

with what happens elsewhere (Europe, …)– the whole E2E path should be covered.

Empowering individuals to better manage their health.PCHA – Devices Task Force

Discussion material

17

Empowering individuals to better manage their health.PCHA – Devices Task Force

IHE / HL7

18

Information from Paul Schluter / GE:• The FDA UDI has also been a popular discussion topic in the IHE PCD domain, and several of us have been

involved in discussion regarding how it will be encoded in IHE PCD DEC, HL7 V2.8, FHIR, CDA R2 and other messaging formats.

• The current (and long term) solution for HL7 V2 messaging is to use the new PRT segment to convey the FDA UDI and other identifiers (including the EUI-64! ;-). This will be finalized in HL7 V2.8, expected to be published in 2015.

• Two forms of the FDA UDI are supported by the PRT segment: the first is the intact human readable string (with likely translation of the parenthesis “(“ and “)” to “[“ and “]” to avoid breaking existing HL7 V2 parsers), conveyed in PRT-10. The PRT-10 field is a repeatable field, and can also include the EUI-64 as well as user ID tags, etc. This is simplest for the sender in most cases, except that translating the raw bar code and identifying the (nn) subfields could be somewhat non-trivial.

• The second form of the FDA UDI is supported by sending the component (nn) subfields of the FDA UDI using PRT-16 through PRT-20.

• The sender sends only PRT-10 or PRT-16/20, but not both to ensure consistency; receivers must support both formats.

• It is likely that the use of OBX-18 for conveying the device identifier will be deprecated in the future given that the PRT segment is intended to provide a general representation to convey the identity of patients, clinicians and things of all sorts. That said, OBX-18 has the benefit of being ‘conveniently deployable’ in any OBX without requiring a PRT segment on a device or lab data summary that aggregates data obtained from multiple devices.

• So, bottom line, everyone is working on how to encode the FDA UDI into an HL7 V2.8 messages, and the IHE PCD DEC Technical Framework as well as the Continua WAN interface can selectively add certain future enhancements from future HL7 (2.8) version to the core baseline based on HL7 V2.6. And, rest assured, you will have a ‘home’ for this information on the Continua WAN and other enterprise-facing interfaces.

Empowering individuals to better manage their health.PCHA – Devices Task Force

OpenSDC / DPWS

19

Information from Stefan Schlichting, Draeger:• UDI is also a topic for openSDC.

Currently the openSDC DIM has solved it differently:– Besides something like “ProductionSpecification” we have

for an MDS an element called “MetaData”. This explicitly contains the UDI and is related to the physical thing that is connected to the network.

– ProductionSpec will be used by MDS, VMD, Channel. MetaData is only available for an MDS. ProductionSpec can be used to give further details about the device component.

• Also the gateway question we solved differently: – As we use DPWS and DPWS device already needs a UUID-

which can be a UDI – we rely on the UUID field of the DPWS Device metadata for each network endpoint. If the DPWS device itself is a medical device with MDS etc. than the DPWS Device metadata and the MDS metadata are the same. If it is a gateway than the DPWS device metadata and the MDS metadata will be different.

– DPWS = Devices Profile for Web Services from OASIS [TBC]

Empowering individuals to better manage their health.PCHA – Devices Task Force

OpenSDC – metadata and production specification

20

Empowering individuals to better manage their health.PCHA – Devices Task Force

“Classic” IEEE 11073

21

• MDS includes similar attributes:– VMD-Model– Production-Specification

• Should use same approach to store FDA UDI

Empowering individuals to better manage their health.PCHA – Devices Task Force

From earlier discussions

22

• From Malcolm Clarke / Brunel:– ProductionSpec is the obvious extension for the UDI of the device, but it is not clear how this works for an "agent"

that is working as a "proxy" as in the case of -10471 and could not be so clear for CGM and insulin pump as there would then be 2 UDIs, one for the agent and one for the proxy.

• From Jan Wittenber:– For 'embedded' devices with this property, though, some kind of VMD-like, "embedded" UDI-based component

context would be needed, it seems to me. However, for 11073 devices, I don't think it is practical to require indefinite extent of nesting (reflecting multiple levels of nested devices with such ID's; VMD is as far as it seemed necessary and sufficient for "classic" 11073).

– But it might be necessary in extended use contexts, such as information systems. For example, consider the case of a multi-patient flowsheet processor that gets data from an HDO LAN or WAN-based concentrator that gets data from a "smart" PoC or PHD aggregator (i.e. one that can run 'apps' that reuse medical data from embedded devices) that gets data from a medical device that interfaces another medical device that embeds a sensor. [This level of nesting relative to 'end-use' is not uncommon.] If data derivation/delivery "pathway" info is not determinable somehow, then there may be an issue w.r.t. clinical usability of a given metric from a given device; for example, a Heart Rate might be derived from ECG (with centralized [ar]rhythm analyzer) or Pleth; or a Resp Rate could be derived from SABTE or Ventilator or even ECG/Resp; and either could be communicated through a "smart" intermediary, which may have a CDS (e.g. Arrhythmia Analyzer or Calculator or Alarm algorithm) or forensic analysis app that needs to provide provenance "meta-info" when it passes information on.

Empowering individuals to better manage their health.PCHA – Devices Task Force

Useful links

23

• FDA UDI resources– http://www.fda.gov/MedicalDevices/DeviceRegula

tionandGuidance/UniqueDeviceIdentification/ChangesbetweenUDIProposedandFinalRules/default.htm

• TüV article on UDI and GS1 (in German):– http://www.tuv-akademie.at/fileadmin/dateien/U

nique_Device_Identification_Mag._Dorner.pdf

• EU recommendation for EU UDI system:– http://

eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:099:0017:0024:EN:PDF