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.