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

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 2

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 3

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 4

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 5

6. ECRI Institute 6 ECRI Institute, for one, notices

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

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 8

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

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) 10

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 11

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 12

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

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? 14

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 15

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

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

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

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) 20

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 21

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 22

23. 23

24. HL7 DCM-MD24

25. HL7 DCM-MD25

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 26

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” 27

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 28

29. 29

30. Parking lot 30

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

32. 32

33. 33

34. 34