Putting the patient in the loop and protecting yourself while being more efficient
One of the biggest challenges for healthcare systems is the request/result reconciliation. When a prescriber makes a lab or imaging request, they can’t always know where their patient will go or when the test will be done, or even if the test isn’t done.
Accustomed to the adage “No news, good news”, a patient who has taken a test with a fundamentally abnormal result will feel comforted if his doctor, who did not get the result, does not contact him! Even if the abnormal result could be read by the patient in the carnet Santé Québec 30 days after it is available to his doctor, this does not relieve the doctor of his medico-legal responsibility.
It should be noted that the obligation to preserve confidentiality requires that the information be transmitted to the patient himself after having verified his identity. While this is easy to do in the office, it is not so easy to do so by e-mail, text message, voice mail or even portal. Indeed, all portals are susceptible to hacking because the information posted there persists.
For obvious reasons, the importance of shortening the time it takes to communicate results, ensuring confirmation of receipt and the confidentiality of the communication is even more acute in the case of STI (sexually transmitted and blood-borne infections) screening results. Telephoning the results is not only impractical and very expensive in terms of time and money, but how can you really be sure who is Jules and who is Jim if you contact one of them a week after seeing them in the clinic to communicate the results?
In the context of STI screening, it quickly became apparent that the patient, who owns his or her own information, should be able to share his or her right to know the results with a third party via a reading right. Indeed, why should Jim have blind confidence in the words of Jules? There is nothing better than being able to read the official results in Jules’ file if Jules grants Jim a specific right to read that information.
So what is the best communication solution? End-to-end encrypted email like Proton? Encrypted communication over Signal? This seems totally unrealistic and impractical. So in 2015, faced with this dilemma, I contacted Yves Le Borgne, a computer scientist friend, and asked him if it would be possible to use the cell phone as an authentication key. Indeed, the cell phone is the computer that we carry with us and, already in 2015, it appeared that it would be the preferred instrument of communication by the majority. Thus was born Portable EHR for Portable Electronic Health Record.
The major challenges we had to face were multiple: security, confidentiality, non persistence of information on any transmission relay, no persistence of information outside the medical record, non persistence of information in the phone after reading the result, acknowledgement of receipt with logging of all steps of the communication, fallback mechanism to notify the sender if the recipient failed to read the communication beyond a configurable time. To this, we must add programming in native code to avoid unintentionally including any backdoor delivered with commercial code (Alphabet, Apple, Meta, Amazon, Microsoft).
It soon became apparent that we could not send electronic information from the medical record to the patient because information providers tend to copy the shipments to relays or storage areas. So the phone itself had to come and get that information. However, it is unthinkable to allow thousands of phones to have direct access to an Electronic Medical Record (EMR). Therefore, it is the role of the application server to act as an identity verification hub and consent manager to filter all requests. When the patient’s identity is validated, it allows only those requests that meet the identity verification requirements to pass through and only allows access to the portion of that individual’s EMR for which the physician has reported an available result with recommendations for review.
In short, the application server does not know any medical information and only acts as a referral agent after authenticating the recipient. This verification is based on 3 identity factors recorded in the EMR and associated with its digital identity in the application server: photo ID issued by a valid jurisdiction (RAMQ, driver’s license or passport), cell phone number, email. In addition, the application server will require the phone to certify that it is the authorized user who has it in hand (facial recognition, fingerprint or PIN) before allowing the reading of any medical information. The cell phone thus becomes a personal key to identity management and access to information that the patient owns and that he or she can communicate with his or her logged consent.
Furthermore, this technology, already tested and used in clinics, has three emerging properties that make it unique:
- It allows the owner of the information (the patient) to grant a reading right into the source system to a third party anywhere on the internet
- Interfaced with the EMR and if a feedback mechanism is added, it will allow to question or converse with the patient in an asynchronous way while ensuring his identity (this improvement will be presented at the “Premières Lignes” conference held at the Palais des Congrès de Montréal on April 27th and 28th)
- It allows identity intermediation between systems that are by design non-interoperable, notably between distinct EMRs, EMR and Radiology Information System (RIS), EMR and Laboratory Information System (LIS). This will be the subject of another article.
