Positive Patient Id and Medical Device Data: Essential Safety Requirements

1. Positive Patient Id and Medical Device Data: Essential Safety Requirements

2. Describing current work – thanks to participants in related projects: • IHE (Integrating the Healthcare Enterprise) Patient Care Device domain, Point-of-Care Identity Management Work Group (Robert Flanders, GE, chair) • HL7 Health Care Devices / Patient Care Detailed Clinical Models – Medical Devices (VA Device Connectivity group, Ioana Singureanu, methodology lead) • IEEE 11073 Medical Device Communications Upper Level Committee (CCoM) – Jan Wittenber, chair

3. Patient Identity travels with Patient Data • That just happens, right? • Oh, really? • What are the preconditions for it to “just happen” • What are the consequences if it doesn’t

4. The status quo • We’re talking about automated data flow from devices but in the “real world” manual transcription is still prevalent • Anything we change here should kick off a good risk analysis

5. The hazards • Treating patient based on wrong data • Potential consequences extremely serious • Missing data that ought to contribute to proper treatment • At least you might know it’s not there and therefore that something is wrong • again, harm can be serious • Data may be gone forever; not even available for “backfilling” by manual transcription – since many devices do not persist data at all, or for long

6. ECRI Institute, for one, notices ECRI Institute

7. What’s the current situation, best case? • Data start to flow when the patient is admitted to the location (e.g. fixed bed, or OR) • (Note well that there are many medical device situations this does not cover) • Even the “easiest” cases depends on correct, coordinated actions in multiple systems (device, device manager if any, patient registration system) and people (registration operator, clinician at point-of-care or unit console)

8. What can possibly go wrong? • Patient registration system has wrong (e.g. out-of-synchrony) information • Data loss (bad) • Data mis-attribution (data to wrong patient’s record – really bad) • At point-of-care, association not made, made wrongly, not checked

9. Breaking it down: Domain Analysis • Reduce entities, relations, and actions to their essences • Pay attention to use cases and work flows

10. Reducing identity to its essence • All about “same” and “different” • All medical data belonging to the same patient accessible together • Multifactor identification: using name, gender, date of birth • Need at least one identifier that maps one-to-one with the patient • Unique identifier for device also needed (IEEE EUI-64, GS1, FDA UDI project in progress)

11. Patient ID-capable devices • Middle to high-end devices with capable user interfaces, e.g. high-end patient monitors • Users emphatic that they don’t want to admit patient to multiple systems – that is risky anyway

12. The problem of 'floating' devices with little or no patient id capability • Spot-check monitors • Telemetry packs • Infusion pumps • Point-of-care lab devices

13. Identification aids • Bar code reader (or RFID, or similar) can help: patient id from wristband, action can be “signed” by user by scanning own identity, devices can have scannable labels • But what system supports the barcode? • How is the information joined together with the device data?

14. What is the system flow? • Is there an authoritative patient index? • What does it track, and not track? • What are the sources of its updates? • What are the latencies and delays possible?

15. What are the necessary information exchanges? • Available now: IHE Patient Data Query – basically a transaction to search the patient registry using one or more identification factors. Wild cards may be used. • Events – associate a patient with a location or device • A positive patient identity • Instant consistency checking • If error, instant notification

16. IEEE 11073 Clinical Context Object Management IEEE 11073-P20301

17. NOT normative HL7 analysis, modified after Corepoint Health

18. Mismatch to classic HL7 Patient Administration • Administrative inpatient admit or start encounter not the same as associating a patient with a device • Better, but not perfect, match to HL7 paradigm for scheduling a patient with a resource (under investigation IHE PCD PCIM)

19. Consider system context • device use cases • device capabilities • communications • data repertoire • legacy serial connection • network • locational clues • fixed network port

20. The participants • Patient care devices at point-of-care • Target system for data - EMR • Patient index system or similar • other • clinical decision support • multi-device systems of systems at point-of-care • ICE Integrated Clinical Environment (see mdpnp.org)

21. Location-based identification • fixed topology (e.g. known switch ports) • discoverable topology (device ID discoverable) • dynamic location sensing (e.g. RTLS) • human role in completing / confirming the ID • confirm with UI • confirm with id assist • barcodes

22. Dynamic association • Applicable to “floating devices” • Many risks to be analyzed • What are all the systems involved? • Transactions (IHE PCD Point-of-care Identity Management (PCIM) working on) • Associate device with patient • Break association of device with patient

24. HL7 DCM-MD

25. HL7 DCM-MD

26. work in progress • IHE Patient Care Devices • HL7 Detailed Clinical Models - Medical Devices • Driven by VA • IEEE 11073 CCoM • Want to participate? Come on in

27. All work products are open and cost-free to get and to use. Much information on wiki and open ftp site • For you to participate in meetings, your organization be a member – find out from the website (IHE.ORG) if it already is • If not, joining is simple and cost-free (only pain is likely to be getting legal department to read agreement) • Wiki.ihe.net – search for “PCIM”

28. HL7 • Must be a member to vote, but not to participate in meetings. HL7 is connected to ANSI, which has an open meetings policy • hl7.org > Resources > Work Groups > Health Care Devices • Sign up on listserv

30. Parking lot

31. What is a topological admit and how does it work?