A proposal to solve the patient data problem. (Yes, this is a manifesto)

Transcription

1 A proposal to solve the patient data problem (Yes, this is a manifesto) Author: Jeroen W.J. Baten Version: 0.2 Date: April 7th, 2014

2 Table of Contents Introduction...3 History...3 Ground rules...3 The basics of a proposed solution...4 Q & A...5 Business models...6 Techno bable...7 Database...7 Interface...7 The data...7 Client interface...7 Database layout...8 Data table...8 Patient table...8 Log table...8 Health provider table...9

3 Introduction Let's start with describing the problem: every patient wants to get his hands on his own patient data, every time and everywhere, but it must be stored absolutely safe, and with no risk to the patient for evil usage by anyone. All initiatives so far fail to address the core issues at hand: safety privacy availability This documents proposes a different way to solve the problem at hand. History For some time now there have been numerous initiatives around the world to distribute patient data in a safe and secure way. It is possible to exchange messages from a general practitioner to a pharmacy and/or to a hospital or vice versa. There is even a generally available standard for these messages called HL7. Many hospitals have a HL7 message server that routes messages from all departments to all other departments. Mainly address info, lab results, medicine prescriptions, etc. This works all fine and in a stable way but the patient has no say in the matter and can not get to this data, unless a hospital puts it on a website. Which means they will upload it to some web server and store it in a (as securely as possible) database and grant access to everyone with the correct username and password. But this has the adverse side effect of increased vulnerability since every system build this way almost by definition is insecure in some way. Local message exchange initiatives became regional message exchange initiatives became countrywide message exchange initiatives. Still, the patient had no access to his data, unless, again, somebody put it on a website behind a login. But with the existence of laws like the Patriot Act in the US you can bet that if your data is on a server somewhere, somebody can get to it. People are unfortunately not completely stupid so initiatives by Microsoft and Google to launch products like Health Vault (using the word Vault would in a magically way make it all more secure) have been met with a cold response from the intended user and, again, for good reason. At the moment of writing websites are being hacked on a daily basis making security a key issue at hand. There are also certain governments who really like to know if a citizen for example is HIV infected. There are also organizations like the CIA who would really like to known if a high ranking enemy has some sort of health problem. Still, if you think about it, a good solution can be easily attained. But I am getting ahead of myself. Ground rules Just suppose, for a minute, that we can start again. What would then be the fundamental rules to build a solution on? I propose the following groundrules: All data in a globally accessible patient record system belongs to the patient. All medical data is based on his person, so he has every right access it. All data in a globally accessible patient record system must me stored absolutely safely. The usage of a globally accessible patient record system must be easy for both patient and the medical population.

4 Pull before push. This means focusing on what people want and not what somebody else wants (industry, medical world, large search providers, etc). The basics of a proposed solution Suppose, just for a minute, that we still store all patient data in a globally accessible patient record system, but everything is encrypted with a password that only the patient knows? In turn the patient distributes his password to those people that he trusts. His personal general practitioner, his own hospital, his own pharmacy, etc. Or not, if he choses not to. Systems that supply data to the database encrypt it with the users password (that is in their possesion) and this, now encrypted, data will be stored in the central database. This means the contents of this database are unreadable for everybody that does not know the magic password. All data of all patients is encrypted with individual passwords so decrypting the complete database is in practice undoable. All those who have the patients password can download and access the patient data and add new information to the central database if they have write access (we come to that later). If the patient wants to exclude one or more of his previous readers he simply changes his password, all data is converted based on old and new password and available again for all those who have been given the new password. There is no central organization governing this system. The software that makes this all happen is released as open source software. This makes it available for everyone to check its integrity, to foster innovation and facilitate the creation of more than one patent record database in the world. Patients chose for themselves where to store their data. A simple check is applied to check if some writer has knowledge of the patients password and only then this information is stored. What I described so far is the basis of the solution. In the next chapters I go in more detail how the solution is build.

5 Q & A Q: Why should a health provider send data to a globally accessible patient record system? A: Because the globally accessible patient record system will keep track of organizations who supply data. This way patients can choose to use an organization that gives information back to the patient. Q: Why not continue the way we have been. A: There are to many doubts and concerns raised. The patient is still at the mercy of the medical industry. Q: What happens if I forget or lose my password? A: There are several options: 1. The patient can no longer access his data. But neither can somebody else. 2. The patient visits his personal physician and asks for a copy of the password that he once gave them. 3. The patient choses at registration time to have an with the password being send to him/her. There are security objections involved. 4. At the time of registration the patient choses to also archive the password at the service provider. Upon supplying sufficient credentials he is gives access to his former password. Maybe there is a certain fee involved. There are security objections involved. Q: Can a patient see his data? A: Yes, a patient can always see his data (after supplying his unique id number and personal password). A simple desktop view application will be developed. There will be a market for more advanced data viewers. Q: Can a patient relocate his data to another service provider? A: Yes, you can always relocate your data to another service provider. It is possible to automatically inform your health suppliers of this change of location. Q: How can a manufacturer of healthcare products be prevented from storing encrypted data into the system that only this manufacturer can decrypt. A: The only place where all data gets decrypted is at the patient or health provider. If an audit establishes that a certain product produces encrypted data the service organization is obligated to publish the name of the manufacturer and product name on its website. Since no manufacturer wants to take this risk there is little chance this will actually happen.

6 Business models Setting up a system as described earlier costs money. The software needs to be designed in detail and hardware needs to be set up. So where it the money in this solution? It is not up to any government to pay for this. Why would they. History in the Netherlands has proven that this only produces overweight unpopular systems with lots of privacy concerns at the cost of 300 million euros. It is also not the patient that is willing to pay for something he sees as basic infrastructure. This leaves the health organizations and insurance companies. Both aim to please the patient and have enough money to pay for access to a system as described here. By sharing the costs over multiple health organizations this is a scenario worth investigating. Hospitals have a lot of patients so are expected to pay more than smaller health organizations like general practitioners. The market will create a product pull from the patient population. People like to have access to data they consider to be their own. This makes for the option of a patient to select his or hers preferred health provider. This creates the pull for health organizations to want to obtain a write subscription to the central database. Because the software is not exclusively owned by one business entity a competitive market will balance the fees involved.

7 Techno bable Database All data is stored in a database. The solution is currently database agnostic, but due to size and reliability an open source database is my personal preference. The jury is currently out whether this should be a NoSQL db or PostgreSQL. Character coding is mandatory UTF-8. Interface The data interface is REST with JSON data. The encryption method is for now AES but can change before the first release. The interface has basically the following methods: Request: Get data after supplying identification and password Insert: Insert data after supplying identification and password of patient and after loging in as an authenticated data-writer. Several implementations of this interface will be developed in popular programming languages to allow software producers to add these to their products: Java Python.Net C++ The data Basically the data stored in the central system are all encrypt as much as possible. Basically they contain the HL7 messages send in by health organization. accompanied by an unencrypted timestamp (thus facilitating easy search). The field with the ID of the person is a hash of his personal identification number. This can be a social security number of other number that uniquely identifies a person within a country. When a health provider connects to the system they can retrieve all data stored since the last date of synchronization. By merging all records of the same type in sequence of date their current value can be established where applicable. Client interface A GPL licensed open source client will be developed with which users/patients of the system can see their own data. This way is should be possible to store a message when relocating to another address. Next to address information this client can also show lab results (preferably also in a graph). This way people with diabetes or undergoing chemo can get informed easily about the current blood values. The storage of graphic material is currently up for debate (because of the sheer size of the data files). Maybe this can be optional with a paid subscription to facilitate the cost of storage.

8 Database layout Data table The data table contains all data for a patient. A record consists of the following fields: id autoincrement id for uniquely identifying a single record enc_pid A hashed version of a patient identification number. All data of a single person all have the same hashed value. timestamp Date and time at which these data have been stored enc_type With which encryption method are these data stored. Type 1 is currently AES. If the encryption method ever gets unreliable it is possible to switch to another encryption method. msg_type src_org What type of message is this? Free text? HL7, and if so, which type? (ADT, ORU, ORM, etc.) Id of organization that provided the data data The actual message in encrypted form Patient table This table contains data of all known patients/users. id enc_pid enc_challenge Autoincrement id for uniquely identifying a single record The unique patient identification number in hashed form. All data of a single person all have the same hashed value. A string only known to the service organization has been encrypted with the users password. This way a patient can prove to the system that it has knowledge of the original password. Log table All transactions with the system are logged and even these log messages are encrypted with the users password. Yes, this involves a round trip to the client for all logging data. This way the user can always see who has had access to what data. id enc_pid enc_type enc_msg Autoincrement id for uniquely identifying a single record The unique patient identification number in hashed form. All data of a single person all have the same hashed value. An encoded string containing the type of this log message An encoded string containing the actual contents of this log message

9 Health provider table This table contains information about health providers that are allowed to store information into the system. id org_name username Password Autoincrement id for uniquely identifying a single record The name of the organization Username used by the organization to connect to the system A hashed version of the password uses to gain access to the system