Patient ID Proof of Concept for SIIM 2016 Hackathon

This slide deck describes our entry into the SIIM 2016 Hackathon. It utilizes a novel approach of hashing patient information to ensure patient records are correlated between disparate systems without sharing of private data or the same patient ID number.

Transcript

1. Universal Patient ID Proof of Concept @CommerceKitchen commercekitchen.com @ClevelandClinic my.clevelandclinic.com
2. The Issues How can we identify a patient across multiple disparate systems without knowing the foreign system’s patient ID? How can we ensure the highest level of confidence that these systems are accurately correlating the same patient? How can we make the correlation without exposing data that other systems do not have?
3. Scope of POC 1. Focus on verifying the uniqueness of a match among patient information. 2. Ensure rapid confirmation of a unique match.
4. Outside Scope of POC Mediating trust between communicating systems. Encryption of data being sent between systems. For items outside the scope of this POC, a recommendation would be to use well established public key cryptography.
5. Initial Concept Define an array of easily collectable data. (Info patients or caregivers should be able to easily access and provide.) Communicate the data available to each party in a way that does not disclose the values of the data. Construct a cryptographic hash based on data known by both systems for identification of a patient’s records.
6. The “Handshake” Given 8 potential sources of information, Server 1 has access to 5 sources. It also knows two possible names or aliases that the patient has used in the past. The possible names are hashed (SHA256) and sent to Server 2, which Server 1 needs to request records from, and sent along with an identifying key that correlates to the data that Server 1 knows.
7. The “Handshake” Server 2 searches it’s database for names that have the same hash as one of the hashes that was sent over from Server 1. If Server 2 finds a name hash match, it can then send a response back to Server 1, indicating which information sources it has that overlaps with the name hashes it found.
8. The “Handshake” Server 1 then creates a second hash, using the information sources that Server 2 indicated it also has, and sends this “info hash” to Server 2. Server 2 then checks the info hash against the patient info hashes of the names it initially matched. If both name hash and info hash match without ambiguity, then the patient is successfully found in both systems. Information sharing can commence.
9. Issues Solved Many patients may share the same name, however, by communicating which sets of information the servers share via the “Info Hash”, identification of a single patient across multiple systems can be ensured. The specification for this “Hash Handshake” could be extended with further sources of information, increasing the entropy of the “Info Hash” and enabling increased certainty of the match. This extension can be made in a fully backward- compatible fashion.
10. Servers Before “Hash Handshake”
11. Servers After “Hash Handshake”
12. The Road Ahead Create an API and POC to prove servers communicating automatically to match patient records. Find/create a set of anonymous/generated data for testing on a larger scale. Create a working group to define a common standard and work with other groups to integrate the spec into their software and systems.
13. Jared Koumentis @shepbook github.com/shepbook Corey Davis @coreyd303 github.com/coreyd303 Thank You Engineering Team Git Repository: https://github.com/ShepBook/patient_id_poc