I recently joked that I’m in “Grade 23” — K-12, 4 years of a Bachelor of Science, 2 years of a Master’s of Applied Science, 4 years of medical school, and now I’m one year into a 4-5 year residency in Internal Medicine. I took a bit of meander through the woods of academia and the back alleys of industry to get here, but my journey isn’t atypical.

So why does it take so long to become a doctor? Obviously there’s a huge body of knowledge to wrestle with, and any med school grad about to start their first day of internship on July 1 will tell you that after 4 years of med school, they still know nothing. (If they tell you otherwise, find another doctor.)

But even senior physicians will lament that, the day after they’ve passed their Royal College (board) exams, their knowledge begins to fall out of date. Guidelines for the standard of care are constantly changing as new evidence and new treatments emerge; you really have to be reading constantly to stay up to date. That’s why it’s called the practice of medicine — we are engaged in the pursuit of a goal that will forever remain just out of reach. What I’ve learned in the last 5 years of my medical training is that the content knowledge isn’t what matters. You can look things up in seconds, and what you memorize now may well be irrelevant in 2 years anyway. 

What matters is 1) How to communicate with clinicians, and 2) How to think like a physician. 

This post is about communication. I’ll talk about number 2 later. (Of course learning how to communicate with the patient is vital, but that’s a much more of an art that varies in performance depending on the practitioner and the patient.)

The most dangerous moments in healthcare happen in transitions, when responsibility for a patient is passed from one clinician to another. You may have heard an argument for 24-hour-plus call shifts in medicine because it minimizes the number of handovers, and thus actually may be safer than having a sleep-deprived resident make medical decisions. Inevitable human errors of omission aside, this is because trying to capture the multidimensional picture of a patient and his or her clinical trajectory is incredibly hard. My job as the resident is to analyze 40 variables, pick out the salient ones, and compress this object into a coherent narrative so that the next team can properly assess response to treatment and address new developments. In the jargon of tech, this is lossy compression (and at a low bitrate, no less; more on that in a later post).

So we’ve come up with ways to systematize this transfer of information. We learn about SBAR for short communications — Situation, Background, Assessment, Recommendation. For example:

“Situation: I need your help with a patient with increasing oxygen requirements.

Background: He’s a 65-year-old with ischemic cardiomyopathy and heart failure. Just now his systolic was in the 190s.

Assessment: I think he may be in flash pulmonary edema from a hypertensive crisis.

Recommendation: I think he needs blood pressure control, diuretics, and help from the respiratory therapist for noninvasive ventilatory support.”

For detailed consults, we have a structure of Chief Complaint, History of Present Illness, Past Medical History, Medications, Allergies, etc. The structure and rhythm of a consult helps the clinician approach each unique patient presentation systematically, matching symptoms to illness scripts learned through years of practice. 

It takes time for the medical student to learn how to communicate with this structure. In the beginning you’re not sure what information belongs where, what should be said up front. You’ve done the hard work of gathering all the information, and you have a picture of the patient in your mind, but you have to transform that raw data into a form that another clinician can accept and easily digest. You need to learn an API.

What is an API? An Application Programming Interface is the computer engineering analogue to the structured communication tool of a medical consult or SBAR. It applies broadly to all programming, but let’s take the example of EHRs. The bedrock of the backend of your EHR is probably a large database of key-value pairs describing the attributes of a patient:

{ 
  name: Henry Molaison, 
  age: 45, 
  sex: male, 
  health record number: 234329940,
  diagnoses: [     
    {label: Essential hypertension, ICD10: I10},     
    {label: Anterograde amnesion, ICD10: R41.3},     
    {label: Chronic kidney disease, ICD10: N18.9}],
  medications: [     
    {generic name: ramipril, dose: 5mg, frequency: bid, route: po, prescriber: “Dr. Milner, Brenda"}      
    …],
  visits: [     
    {date: “06-12-1967”, visitType: “outpatient”, specialty: “neurology”…} ],
 … 
}

You can start to see that with a hodgepodge of strings, integers, nested arrays of objects, things can quickly get complicated. And we can debate endlessly about details of implementation (should a health record number be an integer or a string?). If a programmer requests information about a patient from a database, how can they be sure that the data they get is in a form that their program is prepared to accept?

To solve this problem we focus on the key bottleneck: transitions when data is passed from one function to another. In fact, before coding any of the implementation details, we can specify the API:

Patient Class
--------------------
Constructor 

Name: healthID     
Type: string   
Description: The patient's health record number 

Name: age        
Type: int        
Description: The patient’s age .

--------------------
Methods 

addVisit(date: date, visitType: string, specialty: string) getHomeRx(): returns array of Medication objects ...

The API is all that you need to expose to the world of third-party developers. They don’t need to know your implementation details in order to read from and write to the database. And once they have the data, they can present it in a way that best suits the end user.

This concept of standardized frameworks for transfer of information is not new to medicine; a huge part of medical training is devoted to learning how to communicate in a standardized way. Radiology and cardiology are two specialities for which standardized reporting of diagnostic tests has become mainstream (see, for example, the American College of Radiology TI-RADS standard for reporting thyroid ultrasounds). Standardization makes the report easier to read, lowers the risk of errors of omission, and increases adherence to guideline-directed therapy that improves patient outcomes.

So clinicians should naturally demand that their IT tools also support standardized communication protocols, because standardization is what has been sorely lacking in this field that seems resistant to tech’s promised efficiency gains. 

Fortunately for us, the folks at HL7 have been working on FHIR for almost a decade, and HL7v2 and v3 for much longer before that. Colleagues who have been invested in this space for longer than I have pointed out recent progress by the ONC for using standards to enforce interoperability between different healthcare IT systems. Since Canada seems intent on following the American way, I hope this brings meaningful change to our EHR systems.