This is an interesting week for Facebook. I quit using Facebook about 8 years ago and never signed up for Instagram. I did not see any value in these services. And looking at the recent revelations by the whistleblower, I am glad that I am not on these platforms. But I (have to) use WhatsApp to stay connected with my family and friends. There is no alternative. There is strong social pressure in India that requires the use of WhatsApp. My parents use it. Our extended families are hooked to WhatsApp. All my friends are on WhatsApp. Even if I dislike Facebook’s business practices, WhatsApp is a necessary evil. When these systems went down, I was expecting minor inconvenience due to the unavailability of WhatsApp.

But Facebook’s downtime irritated me even so. What happened was mildly interesting. Vaidehi is due for her set of first Flu shots. She needs to take 2 shots, separated by 30 days. During her last wellness visit, her pediatrician indicated that the Flu vaccines would be available in the first week of October. Vaidehi’s regular visit is in the first week of November. I thought it would be a good idea to plan her first shot in early October so she could take the second shot at her regular wellness visit in November.

Her pediatrician’s office depends on Facebook to inform the vaccine schedule. It’s convenient to check their Facebook page to see if vaccines are available and what are the visit times. The alternative is to call the office and stay on hold for 15-20 minutes. As the pandemic has caused nationwide shortages in healthcare, especially nursing care, these appointment slots fill up fast. Due to this, I wanted to get in front of the line to schedule the appointment as soon as it was available. But Facebook was down, and we couldn’t get the information in time.

Anyway, it was not a big deal. I was able to get an appointment by following up over the phone. But it kept me wondering about the situation we are in. A single company has so much control over how the information could be disseminated. The promise of the internet was to make it easy to exchange the information. But if a mistake in the DNS configuration for one company’s servers brings the internet to halt, something has gone very wrong.

This year was my second attempt to make the clay Ganesha idol at home to celebrate Ganesh Utsav. I am not much of an artist. Actually, I am afraid to draw, paint, sing, play an instrument, dance, or do any sort of work that’s considered remotely artistic in nature.

When I was in school, drawing and painting were my Achilles' heel. I would get the lowest grade possible in these subjects. In fact, I had to leverage my personal relationships with teachers, so they couldn’t flunk me in these subjects. Even with my excellent brownnosing, I distinctly remember scoring 40% in drawing one year. The same year I scored 90%+ marks in STEM subjects. Out of the peer pressure I also attempted the Elementary Drawing exam conducted by the Govt of Maharashtra and failed spectacularly in it. Simply put, I suck at art. That was enough of a deterrent not to try something heroic like making your own idol of a god, especially the one who is considered the master of all artistic skills.

In spite of my reservations about my mediocre skills, I decided to make an idol last year. Before investing in the procurement of supplies and committing to delivering the idol, I built a small prototype using clay doh. That wasn’t very bad. It looked like Ganapati. The mouse was even more adorable.

Encouraged by this prototype, I purchased supplies and various colors. My weekend was put into good use. Instead of mindlessly watching television or scrolling on social media, I built something with my hands. Granted that it was mediocre, that was still my best attempt yet. When I started painting it, I realized that the eyes are the most difficult part of an idol. The idol’s personality is by the eyes. Even a minor imperfection would completely ruin the idol. I became very anxious about it and decided to not draw the eyes but rather glued them. The rest of the adornment was easy. I used craft stones and golden chains along with my wife’s cosmetic bindis to decorate it. The result was pretty good.

Inspired by my earlier success of the first attempt in 2020, I tried making an idol again this year. I was more confident about handling not only the clay but also the brush while painting the idol. It turned out very well.

As a pixel pusher who rarely builds things with hands, creating this idol was such a fantastic and fulfilling experience.

Another practice I put into action was Giving myself an ‘A’. This practice talks about unconditional self-acceptance without judging your skills. Instead of getting bogged down by expectations and performance pressure, this simple act of giving yourself an ‘A’ can do wonders.

I recently read Thinking in Bets by Annie Duke. The book is about making better decisions when you don’t have all the facts.

Often times we confuse the quality of our decisions with the quality of the outcomes. Annie advocates that it is not the right approach. To make better decisions, it’s important to decouple the quality of decisions from the quality of outcomes. She talks about the hazards of resulting - the term poker players use to describe our tendancy of using outcomes to determine the quality of the decisions. The book highlights the irrational nature of our brain. From a survival perspective, our brains aren’t built for rationality. It has to make fast decisions, which can blindside us. For me, the most important takeaway was about redefining wrong - and using uncertainty as an advantage. Instead of thinking in a binary mode of right vs wrong, I liked the approach probabilistic percentages for better decision-making and self-compassion.

While I loved the book and got some good nuggets from it. The content was way too repetitive for my taste. After I completed half of the book, I felt like I am reading the same chapter over and over. There is a lot of filler content, the anecdotes weren’t resonating with me. I overlooked two chapters that talked about the buddy system and future planning.

Overall its a good book with the ideas applicable in professional and personal life.

The highlight of this past weekend was completing Vaidehi’s OCI application.

As soon as her passport arrived, I started working on it. The application process could’ve been so much easier, but turned out to be unnecessarily difficult.

First of all, The information is scattered across two different websites.

• VFS - The visa and technology outsourcing company providing services to the Government of India
• OCI portal of Government of India.

In more than a couple of places, the instructions are confusing and even conflicting with one another. E.g. The background of the applicant’s photograph can either be white or light-colored depending on which source you are referring to.

When filling out these forms, there are typos and inconsistencies everywhere. E.g. My current country of residence is referred to as the USA, UNITED STATES and UNITED STATES OF AMERICA in the same form.

There isn’t a tooltip or quick help available for some questions asked in a very bureaucratic language. E.g. What is the applicant’s ‘Relationship to the root of the Indian’? What does this question even mean? I had to google it to find an answer.

Getting an acceptable photograph of a 6-month-old baby is a matter of luck. I understand its not unique to the OCI application. But I was warned by a friend whose application was rejected because he used the same photograph as the passport application. So I preferred to use a new photograph. I also needed a fingerprint of her left thumb. But when I looked more closely, I actually had to get the right thumbprint for a girl child. No matter how many times I tried, Vaidehi’s thumbprints were never identical. The uploaded digital image and the thumbprint on the printed form looked very different.

Notarizing this whole thing was another minor challenge. I wasn’t sure how many forms to get notarized. The parental authorization form had clear instructions about notarizing. But the actual application form also needed notarization. The passport could be ‘self notarized’. I wasn’t sure if I could sign the copy of the passport on my daughter’s behalf or should I get her thumbprint on it.

Beyond the challenges with paperwork, the technology experience has a lot of friction. As a user it’s one application for me, but I have to register on two separate websites. Upload some documents on one website, and download the checklist and acknowledgement receipt from another. The OCI site looks straight from the 80s. Even after registration and getting a login id, I have to use some combination of a passport number, date of birth and application number to retrieve or update my data. This whole thing could be packaged in just one application for the end user.

It took me the whole 2 days to get this done. It was surprising because my previous experience with passport renewal was so much better..

After I dropped off the application package at FedEx, I felt a sense of achievement and relief. I hope this gets issued without any challenges and I won’t have to do it again for the next 20 years.

Today practitioners and patients want to use innovative healthcare apps. Oftentimes they have their favorite app that they already use. To provide the best practitioner and patient experience, these apps need access to patient’s personal health information like allergies, or medications. This type of clinical information is stored inside the electronic health record systems (EHRs). Ultimately the apps are dependent on backend systems like EHRs to power their functionality.

There are more than 50 EHR systems popular in the US alone. For an healthcare application developer this would be a nightmare, if he needs to build his app to work with 50 different EHR systems.

Thanks to industry standards like FHIR and SMART on FHIR, this problem is easily solved.

FHIR provides a standardized data model to represent healthcare data, whereas the SMART on FHIR provides a consistent approach to security and data access requirements.

In this post let’s see some basics of SMART on FHIR.

What is SMART on FHIR

SMART stands for Substitutable Medical Applications and Reusable Technology.

SMART app is a web or mobile app, embedded in an Electronic Health Record (EHR) system or standalone. It’s substitutable, which means if you don’t like a particular app, you can choose another one or substitute it with something else. The app is reusable and should work with any EHR or backend system.

Simply put, SMART on FHIR provides a workflow to securely request access to data, as well as receive and use the data. And ultimately enables Electronic Health Record systems to become more like platforms.

SMART on FHIR addresses these key concerns

• Identity and access management
• Access to the data
• Launch framework
• Scopes and launch context

Let’s look into the details of each of these for a bit.

Identity and access management

SMART relies on the OIDC - OpenID Connect identity management protocol.

Built on top of OAuth 2.0, it is essentially a flavor or a profile of OIDC, customized for use in healthcare applications.It defines a method through which an app requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource.

Access to the data

SMART on FHIR uses FHIR to access the data.

FHIR provides a standardized representation of healthcare data, irrespective of how it is stored or where it is coming from. Using a standardized representation of the data makes these apps substitutable as well as reusable.

Launch framework

SMART on FHIR provides a framework for four different use cases

• Patient apps that launch standalone
• Patient apps that launch from an EHR portal
• Provider apps that launch standalone
• Provider apps that launch from an EHR portal

Scopes and launch context

SMART provides three different categories of scopes for different kinds of data. Launch context is a negotiation where client asks for specific launch context parameters, and server decides which launch context parameters to provide using client’s request as an input.

• Clinical data

  SMART on FHIR defines read and write permissions for patient specific and user level access.

  E.g.

  • patient/Observation.read
  • user/Appointment.read
  • patient/*.*

• Contextual data

  Apps typically rely on contextual data like the currently open patient record in an EHR. They explicitly request the EHR context by using scopes like

  • launch=xyz
  • launch/patient
  • launch/encounter

• Identity data

  Some apps need to authenticate the clinical end-user. They use following openid connect scopes to request the identity information.

  • openid
  • fhirUser

This concludes my brief introduction to SMART on FHIR.

SMART on FHIR provides an open, free and standards based API. Developers can use to write an app once and have it run anywhere in healthcare IT system.