Adding UDI Support to the PCHA Continua Guidelines

Adding UDI Support to the PCHA Continua Guidelines – v 3 Erik Moll Devices TF chair PCHA – Devices Task Force Empowering individuals to better manage their health. 1

UDI Support in the Continua Guidelines? • 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/Medical. Devices/Device. Regulatio nand. Guidance/Unique. Device. Identification/default. ht m? utm_source=Members-Only%20 Updates PCHA – Devices Task Force Empowering individuals to better manage their health. 2

intro • 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-PCD 01 – 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/Medical. Devices/Device. Regulationand. Guidance/Uniqu e. Device. Identification/Benefitsofa. UDIsystem/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. PCHA – Devices Task Force Empowering individuals to better manage their health. 3

Example UDI label PCHA – Devices Task Force Empowering individuals to better manage their health. 4

UDI Basics • 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 PCHA – Devices Task Force Empowering individuals to better manage their health. 5

GUDID • 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/Medical. Devices/Device. Regulationand. Guidance/Unique. Device. Identification/ UDIExceptions. Alternativesand. Time. Extensions/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. – HL 7 SPL submission – enables submission of device information as xml files PCHA – Devices Task Force Empowering individuals to better manage their health. 6

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

Automatic processing • 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. PCHA – Devices Task Force Empowering individuals to better manage their health. 8

Fit in IEEE 11073 -20601 option 1: System Model [& Id] 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… System. Model System-Id MDC_ATTR_ID_MODEL System. Model MDC_ATTR_SYS_ID OCTET STRING This attribute defines manufacturer and model number of the agent device. 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. Mandatory Static --- System. Model 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. -System. Model : : = SEQUENCE { manufacturer OCTET STRING, -- string size shall be even model-number OCTET STRING -- string size shall be even } PCHA – Devices Task Force Empowering individuals to better manage their health. 9

Option 2: Production Spec --- Production. Spec 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. -Production. Spec : : = SEQUENCE OF Prod. Spec. Entry : : = SEQUENCE { spec-type INT-U 16 { 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 Private. Oid, prod-spec OCTET STRING -- string size shall be even } Production. Specification • • • MDC_ATTR_ID_PROD_ SPECN Production. Spec This attribute defines component revisions, serial numbers, and so on in a manufacturer-specific format. Optional Static Production. Spec 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? PCHA – Devices Task Force Empowering individuals to better manage their health. 10

Option 3: new attribute in the MDS • Add UDI as a new attribute to the MDS – Not worked out yet… PCHA – Devices Task Force Empowering individuals to better manage their health. 11

Discussion in IEEE / DC session Further looking inside the UDI DI+PI parts • 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 Production. Spec 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 GS 1 formatted UDI. The GS 1 issuing agency is one of the currently 3 FDA accredited bodies. – GS 1 UDI example: (01)51022222233336(11)141231(17)150707(10)A 213 B 1(21)1234 – HIBCC UDI example: +H 123 PARTNO 1234567890120/$$420020216 LOT 123456789012345/SXYZ 4567890123 45678/16 D 20130202 C – ICCBBA UDIexample: : =/A 9999 XYZ 100 T 0944=, 000025=A 99971312345600=>014032=}013032&, 1000000 XYZ 12 3 • 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 PCHA – Devices Task Force Empowering individuals to better manage their health. 12

Discussion in IEEE – supporting composite / proxy products How to support multiple UDIs exactly – for composite devices / proxy devices? • The proxy use case is not specific for UDI, also the other Prod. Spec. Entries could be coming from a “proxied” or composite device. – There is no mechanism in 11073 yet to give any semantics to multiple Prod. Spec. Entries 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 PCHA – Devices Task Force Empowering individuals to better manage their health. 13

Supporting multiple FDA UDIs in 11073 • Option: Use a sequence of Prod. Spec. Entries 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 Prod. Spec. Entry • 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? PCHA – Devices Task Force Empowering individuals to better manage their health. 14

Alignment with other initiatives / non-US regulatory bodies • IHE / HL 7 – support is planned in V 2. 8 • Open. SDC – supported • “Classic” IEEE-11073 – should be aligned • Non-US bodies: may propose similar schemes…. PCHA – Devices Task Force Empowering individuals to better manage their health. 15

UDI – What’s next? • 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 / HL 7 for support in PCD-01 on the WAN interface – There is a place for it on the WAN interface (HL 7 v 2. 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 E 2 E path should be covered. PCHA – Devices Task Force Empowering individuals to better manage their health. 16

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

IHE / HL 7 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, HL 7 V 2. 8, FHIR, CDA R 2 and other messaging formats. • The current (and long term) solution for HL 7 V 2 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 HL 7 V 2. 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 HL 7 V 2 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 HL 7 V 2. 8 messages, and the IHE PCD DEC Technical Framework as well as the Continua WAN interface can selectively add certain future enhancements from future HL 7 (2. 8) version to the core baseline based on HL 7 V 2. 6. And, rest assured, you will have a ‘home’ for this information on the Continua WAN and other enterprise-facing interfaces. PCHA – Devices Task Force Empowering individuals to better manage their health. 18

Open. SDC / DPWS Information from Stefan Schlichting, Draeger: • UDI is also a topic for open. SDC. Currently the open. SDC DIM has solved it differently: – – • Besides something like “Production. Specification” we have for an MDS an element called “Meta. Data”. This explicitly contains the UDI and is related to the physical thing that is connected to the network. Production. Spec will be used by MDS, VMD, Channel. Meta. Data is only available for an MDS. Production. Spec 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] PCHA – Devices Task Force Empowering individuals to better manage their health. 19

Open. SDC – metadata and production specification PCHA – Devices Task Force Empowering individuals to better manage their 20 health.

“Classic” IEEE 11073 • MDS includes similar attributes: – VMD-Model – Production-Specification • Should use same approach to store FDA UDI PCHA – Devices Task Force Empowering individuals to better manage their health. 21

From earlier discussions • From Malcolm Clarke / Brunel: – • Production. Spec 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" Po. C 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. PCHA – Devices Task Force Empowering individuals to better manage their health. 22

Useful links • FDA UDI resources – http: //www. fda. gov/Medical. Devices/Device. Regulationand. Guidance /Unique. Device. Identification/Changesbetween. UDIProposedand. Final Rules/default. htm • TüV article on UDI and GS 1 (in German): – http: //www. tuvakademie. at/fileadmin/dateien/Unique_Device_Identification_Mag. _Dorner. pdf • EU recommendation for EU UDI system: – http: //eurlex. europa. eu/Lex. Uri. Serv. do? uri=OJ: L: 2013: 099: 0017: 00 24: EN: PDF PCHA – Devices Task Force Empowering individuals to better manage their health. 23