Adding UDI Support to the PCHA Continua Guidelines – v3 Erik Moll

Adding UDI Support to the PCHA Continua Guidelines – v3 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/MedicalDevices/DeviceRegulationandGui dance/UniqueDeviceIdentification/default.htm?utm so PCHA urce Members-Only%20Updates – 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-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/UniqueDevic eIdentification/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. 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 FDAadministered 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/UDIExceptionsAlt ernativesandTimeExtensions/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 PCHA – Devices Task Force Empowering individuals to better manage their health. 6

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

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 SystemModel System-Id MDC ATTR ID MODEL SystemModel 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 Mandatory Static --- 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 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 --- 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) }, component-id PrivateOid, prod-spec OCTET STRING } ProductionSpecification -- see note on GMDN below MDC ATTR ID PROD SPECN -- string size shall be even ProductionSpec This attribute defines component revisions, serial numbers, and so on in a manufacturer-specific format. Optional Static 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? 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 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 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 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 PCHA – Devices Task Force Empowering individuals to better manage their health. 13

Supporting multiple FDA UDIs in 11073 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? PCHA – Devices Task Force Empowering individuals to better manage their health. 14

Alignment with other initiatives / non-US regulatory bodies IHE / HL7 – support is planned in V2.8 OpenSDC – 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 / 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. 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 / HL7 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. PCHA – Devices Task Force Empowering individuals to better manage their health. 18

OpenSDC / DPWS 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 UUIDwhich 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

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

“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: – 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 multipatient 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. PCHA – Devices Task Force Empowering individuals to better manage their health. 22

Useful links FDA UDI resources – http://www.fda.gov/MedicalDevices/DeviceRegulation andGuidance/UniqueDeviceIdentification/Changesbet weenUDIProposedandFinalRules/default.htm TüV article on UDI and GS1 (in German): – http://www.tuv-akademie.at/fileadmin/dateien/Uniqu e Device Identification Mag. Dorner.pdf EU recommendation for EU UDI system: – http:// eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri OJ:L:2 013:099:0017:0024:EN:PDF PCHA – Devices Task Force Empowering individuals to better manage their health. 23