This past Tuesday, I held my first meeting with developers from the BitShares team as well as with my colleague from IBM, Ian Balina. We managed to find a great room on the GWU campus in Washington D.C. – complete with plenty of seats, a podium and several whiteboards. We spent several hours mapping out the initial architecture on two whiteboards which you can see below:
The first board detailed the most essential aspects of our Decentralized EHR – loading of patient records on the blockchain, how the patient will use the system and how the system’s machine learning model will calculate predicted diagnoses for new patients. The second board dealt with the more advanced features of the system such as the performance-based incentivized platform, the ranking/scheduling system and a brief description of witnesses for our Delegated Proof of Stake (DPOS) blockchain solution.
Well aware that you guys will be unable to read most of what’s written on both boards, I reviewed the two snapshots when I got home and later reproduced the diagrams to make them look more readable and aesthetically pleasing.
I will devote the following post to detailing the initial architecture of the system with the newly reproduced diagrams. So sit back, grab a notebook if you want to take notes and enjoy!
Loading of patient records
When a new patient is admitted to the hospital or rehab center or visits a clinic for a checkup, the nurse is the first person to create a new profile for the patient. Examples of information initially entered into the profile include Chief Complaint, Past Medical History, Medications, Allergies, Vital Signs, Differential Diagnosis and Plan.
The physician will usually see the patient afterwards and will prepare their own SOAP (Subjective-Objective-Assessment-Plan) note which will include a description of the patient’s Chief Complaint, Physical Exam, Differential Diagnosis and Plan/Treatment. This SOAP note will also be loaded into the patient’s profile on the blockchain.
Finally whenever the patient has access to this system, they will use the Medical Record Number (MRN) to access the system and create a unique username and password. With these login credentials, a patient now has 100% open access to their medical record at any time from anywhere in the world.
How a patient uses the system
As the sole owner of their medical record, the patient can now grant permission to their physician(s) to see their medical record at any time from anywhere in the world. If the patient only has a Primary Care Physician (PCP), they can simply give permission to this PCP to view their entire medical history. If the patient is currently being seen by other specialists too, such as cardiologists, neurologists, gastroenterologists, etc., the patient can also grant permission to these specialists to allow them to view their entire medical history.
Each physician will also have their own profile on the system which will be accessed by their own unique username and password and will contain information such as their location, specialty and rank.
At any time from anywhere in the world, a patient can communicate with their physicians (those who have permission to view the medical record) by sending messages over the blockchain, such as status updates on their condition, new symptoms and questions. The physician can receive, view and respond to these messages at any time.
At the conclusion of care – when a patient is discharged from the hospital or rehab or receives treatment at the clinic – the patient can rescind permission for specific doctors or for all the doctors currently accessing their medical record. For example, after the patient is discharged home, they can continue to only communicate with their PCP and thus rescind permission for their other specialists – cardiology, neurology, GI, etc. Thus you will notice in the diagram above that each doctor has a P+ (permission granted) or a P – (permission rescinded).
A Machine Learning model for computing predicted diagnoses
Our Decentralized EHR system will have a built-in machine learning (ML) model that will compute predicted diagnoses for new patients. This ML model will be trained with preexisting medical data - thousands of historical patient records with fields for symptoms, demographics (age and gender) and diagnosis. Thus, the features to be analyzed by the ML model will be the chief complaint (CC) and demographics (DG) and the label to be predicted will be the diagnosis (D).
For new patients added to the EHR blockchain, their chief complaint and demographics will be passed to the ML model, which will compute a predicted diagnosis for each new patient. The physician can then use this predicted diagnosis to focus their physical exam and determine the most appropriate diagnostic tests to be ordered.
Finally, the physician will make their own diagnosis – the computed diagnosis – which will be subsequently added to the database powering the ML model, in order to further improve the accuracy of future predicted diagnoses.
This ML function will be on a system separate from the EHR blockchain in order to spare the main chain from getting bogged down by excessive computations and data storage. However, the output of the ML function – the predicted diagnosis – will in fact be stored on the main chain.
A performance-based incentivized system
All patients will be able to upvote or downvote their physicians based on the quality of care, level of comfort and other criteria important to the patient for assessing their hospital/rehab stay or clinic visit.
Each upvote by a patient will reward a physician with tokens as well as increase their rank on the system. The token can be used by the physician to increase their earnings, since it can be traded on exchanges for Bitcoin and USD.
Each downvote by a patient will not reward a physician with any tokens and will decrease their rank on the system.
All patients can also upvote or downvote nurses based on the quality of care, level of comfort and other criteria relevant to the patient for assessing their interactions with the nurse in the hospital, rehab or clinic.
Each upvote by a patient will reward a nurse with tokens, which will increase their earnings. Each downvote by a patient will not reward a nurse with any tokens. Since nurses are not ranked on the system, each upvote and downvote by a patient solely controls the amount of tokens they can earn.
Nurses and physicians can also upvote patients based on cooperation, medication compliance, good behavior and other criteria decided by these healthcare practitioners to assess their interactions with the patient.
Each upvote by a nurse or physician will reward a patient with tokens, which will increase their earnings. A patient however cannot be downvoted by a nurse or physician. If a patient is ever uncooperative, noncompliant with medications, exhibits bad behavior, etc., a nurse and physician can simply choose not to upvote the patient.
A token increases the earnings of patients, doctors and nurses on the platform since they can be exchanged for Bitcoin and USD. A token also provides a patient with higher-weight upvotes; the amount of tokens held by a patient is directly proportional to their voting power on the platform. Thus, a patient can choose to hold tokens on the system (instead of cashing out to BTC and USD) in order to directly influence the rankings of physicians and earnings of physicians and nurses on the platform.
While tokens are directly tied to a patient’s voting power on the platform, they do not influence physician rankings. Regardless of the amount of tokens possessed by a physician, their ranking on the platform is ONLY influenced by the number of upvotes received from patients.
What’s coming up next?
I hope you noticed that I decided to exclude discussion of the ranking/scheduling system and witnesses from the architecture. These are more advanced considerations that we shall save for a later time especially after we begin development of the prototype. For example, the scheduling system will simply draw data from the physician’s profile – location, specialty and rank – and will order the physicians according to rank in order to allow patients to choose whom to schedule for an appointment.
Thus, the development of the prototype will most likely commence with the first two parts of the architecture – the loading of patient records on the blockchain and the machine learning function. Upon fleshing out the economics of our token in more detail, we can include the incentivized system in our solution and later create the scheduling system.
Now that we have created the initial architecture, the development team is currently working on a plan/roadmap for the prototype. Our goal is to have the prototype completed before November, ideally for a chance to present our project at SteemFest2.
The team will also secure the domain name and website for our project in the coming days. As soon as this is complete, I will officially announce the name of our Decentralized EHR solution and launch a competition to find the best logo right here on Steemit.
We will meet again next week to discuss if there are any modifications/additions to be made to the initial architecture – especially to the first two parts – before starting development of our prototype. Rest assured, I will keep the entire community posted every step of the way right up to our expected launch in November – stay tuned!
Please let me know if you have any questions about our project. If you have experience or know anyone working in the healthcare or blockchain industries, please contact me by either leaving a comment below or emailing me at journeyoface@gmail.com.
Until next time, keep acing life!
