Presentation is loading. Please wait.

Presentation is loading. Please wait.

Empowering individuals to better manage their health. PCHA – Devices Task Force Adding UDI Support to the PCHA Continua Guidelines – v3 Erik Moll Devices.

Similar presentations


Presentation on theme: "Empowering individuals to better manage their health. PCHA – Devices Task Force Adding UDI Support to the PCHA Continua Guidelines – v3 Erik Moll Devices."— Presentation transcript:

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

2 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 andGuidance/UniqueDeviceIdentification/default.htm ?utm_source=Members-Only%20Updates andGuidance/UniqueDeviceIdentification/default.htm ?utm_source=Members-Only%20Updates

3 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 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 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 eDeviceIdentification/BenefitsofaUDIsystem/default.htm eDeviceIdentification/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.

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

5 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 § (c) for a human cell, tissue, or cellular and tissue-based product (HCT/P) regulated as a device – UDI = DI + PI

6 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).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. DIExceptionsAlternativesandTimeExtensions/default.htm DIExceptionsAlternativesandTimeExtensions/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. GUDID Web Interface – HL7 SPL submission – enables submission of device information as xml files HL7 SPL submission

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

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

9 Empowering individuals to better manage their health. PCHA – Devices Task Force Fit in IEEE option 1: System Model [& Id] 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 { manufacturerOCTET STRING,-- string size shall be even model-numberOCTET STRING-- string size shall be even } System- Model MDC_ATTR_ID_MODELSystemModelThis attribute defines manufacturer and model number of the agent device. Mandatory Static System-IdMDC_ATTR_SYS_IDOCTET STRINGThis 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 http://standards.ieee.org/regauth/index.html Mandatory Static 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…

10 Empowering individuals to better manage their health. PCHA – Devices Task Force 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) -- see note on GMDN below }, component-id PrivateOid, prod-spec OCTET STRING -- string size shall be even } Production- Specification MDC_ATTR_ID_PROD_ SPECN ProductionSpecThis 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?

11 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…

12 Empowering individuals to better manage their health. PCHA – Devices Task Force Discussion in IEEE / DC session Further 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”UDI formats by FDA-Accredited Issuing AgencyGUDID 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) (11)141231(17)150707(10)A213B1(21)1234 – HIBCC UDI example: +H123PARTNO /$$ LOT /SXYZ /16D C – ICCBBA UDIexample: :=/A9999XYZ100T0944=,000025=A =>014032=}013032&, XYZ12 3 Before adding any of this to we want to know what will happen in EU and how much variety there will be in the formatting of the UDI

13 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 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

14 Empowering individuals to better manage their health. PCHA – Devices Task Force Supporting multiple FDA UDIs in Option: Use a sequence of ProdSpecEntries as supported in 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?

15 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 – should be aligned Non-US bodies: may propose similar schemes….

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

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

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

19 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]

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

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

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

23 Empowering individuals to better manage their health. PCHA – Devices Task Force Useful links 23 FDA UDI resources – /UniqueDeviceIdentification/ChangesbetweenUDIProposedandFinal Rules/default.htm /UniqueDeviceIdentification/ChangesbetweenUDIProposedandFinal Rules/default.htm TüV article on UDI and GS1 (in German): – akademie.at/fileadmin/dateien/Unique_Device_Identification_Mag. _Dorner.pdf akademie.at/fileadmin/dateien/Unique_Device_Identification_Mag. _Dorner.pdf EU recommendation for EU UDI system: – lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:099:0017:00 24:EN:PDF lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2013:099:0017:00 24:EN:PDF


Download ppt "Empowering individuals to better manage their health. PCHA – Devices Task Force Adding UDI Support to the PCHA Continua Guidelines – v3 Erik Moll Devices."

Similar presentations


Ads by Google