SMART on FHIR: Securing the App Store for Health

There are over 2 million apps in the Apple App Store, and over 2.5 million apps in Google Play. Some of my favorites are Waze for driving my son to his next obscurely located hockey rink here in New England, LinkedIn and Twitter for keeping up on industry news and topics, and also lately, several different airline apps that speed the check-in process, and let me be one of the first to be notified of flight delays.

There is no doubt that the app model has worked brilliantly for the smartphone market, unlocking incredible disruptive innovations since the original launch of the Apple App Store in July of 2008.

It is not surprising that some of our best thinkers in healthcare information technology, witnessing this success, published an article in JAMA in 2009 outlining what it would take to bring this kind of capability to the healthcare industry. In their article, Dr. Kenneth Mandl and Dr. Isaac Kohane at Boston Children’s Hospital and Harvard Medical School outlined four key ingredients for success:

• There should be liquidity of data — It should be easy to transfer data from one place to another in an agreed-upon form.
• There should be substitutability of applications — We should be able to use a billing system from one vendor and a laboratory information system from another and be able to swap either vendor’s solution out from time to time if we choose.
• The platform should be based on open standards.
• The platform should have a diverse set of applications, enabling an environment of “natural selection” — Let the apps with the highest value and lowest cost win.

The following year, in 2010, the U.S. government-funded the creation and initial development of SMART with a $15 million contract to create standards, open-source technology and initiate a robust community of developers. SMART, which stands for “Substitutable Medical Apps, Reusable Technology,” was born.

The SMART Project rapidly got underway, initially developing its own openly licensed clinical data models. Dr. Joshua Mandel, Lead Architect of the SMART Project in his JAMIA article describes the journey of this new technology development and the eventual transition to HL7 FHIR as it emerged during this same timeframe. FHIR, or Fast Healthcare Interoperability Resources is a next-generation healthcare interoperability framework created by HL7. For more information on FHIR, please read my blog article here. The SMART project transitioned its efforts toward FHIR, and also changed its name to SMART on FHIR.

Securing FHIR

An “App Store” suitably designed for healthcare would need to address a critical design challenge: How do we enable a third party ecosystem of applications while meeting the rigorous security and access control requirements that healthcare demands?

FHIR on its own does not specify an approach to security, nor does it require any particular security implementation. The SMART project not only provides a specification for a layer of security on top of FHIR, but it goes beyond that and takes a huge step forward in terms of solving a conundrum that has plagued many third party healthcare application providers. SMART on FHIR makes it easy for clinicians to launch applications from within the EMR itself. Time and time again, we found that doctors who were forced to provide a login and password to another system — don’t. It is simply too time consuming and inconvenient.

SMART on FHIR has succeeded in delivering a series of specifications that enable a new breed of applications, what Wes Rischel of Gartner has termed “sidecar” applications. Sidecar applications are those that “supplement an enterprise EHR application without taking over the fundamental workflow that is orchestrated by the enterprise app.”

Now, with SMART on FHIR, there is an abundance of sidecar applications that have emerged, from a bilirubin chart to medication management tools, to growth chart apps. And perhaps, the biggest test for SMART on FHIR’s future growth is that large EMRs have embraced SMART on FHIR, notably with Epic’s open.epic.com effort as well as Cerner’s fhir.cerner.com.

How does SMART on FHIR Work?

SMART on FHIR specifies, using the OAuth2 open standard, a way for applications to register themselves with an EMR and ultimately obtain an access token. SMART also uses OpenID Connect, an authentication layer on top of OAuth2, enabling single sign-on. Think of an access token as a single key to one or more P.O. Boxes at the local post office. A SMART on FHIR sidecar application may be configured to read only a patient’s medication and allergy list, but not its list of diagnoses or medical procedures. In this case, only two P.O. boxes will open with the single key or access token. Maybe the medication management application we are developing doesn’t need access to diagnoses or procedures, so it doesn’t request them. This initial request for permissions is called a “scope.” The post office may or may not choose to enable your key to work — it is their P.O. box, after all, you are just renting the box and the key to open it.

After a sidecar application has obtained an access token, it then sends it back to the FHIR server in an HTTP header with FHIR API requests. If the access token is still valid (it hasn’t been revoked by the server for example), and the API request is within the scope that has been negotiated, the FHIR server will service the request.

SMART on FHIR also specifies two ways to launch a sidecar application.

• EMR Launch — SMART on FHIR specifies an ability for a sidecar application to be launched from within the EMR itself, passing along information about the active patient, encounter, and location information to the sidecar application.
• Standalone Launch — Additionally, SMART on FHIR also specifies a way to enable users to launch from the sidecar application’s web page, and log in using an EMR user account. We see the same style of login flow all over the Internet when we are asked to “Sign in using Google” or “Login with Facebook.” SMART on FHIR-enabled EMRs use the same set of standards but instead are enabling secure access to EMR user accounts and data.

Finally, FHIR defines a set of resources — the “R” in FHIR stands for resources. To achieve a level of substitutability that SMART on FHIR aims, FHIR resources need to be further restricted and extended from these base specifications, collectively known as “profiling a resource.” For example, it is insufficient to simply indicate that a solution uses RxNorm for medications and LOINC for observations. Real-world interoperability requires further specificity in terms of insisting that certain data fields be complete, such as a name field when describing a patient, or when presenting a list of medical problems, each problem shall have a current status identified.

The profiling efforts for SMART are currently evolving. SMART defines a set of profiles that are in the process of transitioning toward the Argonaut profiles in the US.

Experience and Lessons Learned

In 2009, at my prior company, Dossia, we used a very similar approach to enable a healthcare ecosystem of third-party solutions, although our target was not clinicians using EMRs, it was patients directly. We offered our solution to health plans and employers. Our product powered health initiatives for over 900 employers consisting of hundreds of thousands of individual users. Dossia’s API was central to our strategy to enable as many compelling, and effective personal health solutions for our customer’s populations.

The core technologies utilized by Dossia’s API included:

• OpenID, which enabled shared identity with our ecosystem partners across web sites
• OAuth to allow secure API authorization
• Representational State Transform (REST), which provided for a simple access method for reading and updating health data

At Dossia, we connected over 40 different personally-controlled health applications. Some we wrote ourselves, but the majority were supplied by third-party application providers. The applications ranged from products written by major healthcare organizations such as Mayo Clinic to small connected health devices built by small startups here in Boston.

SMART on FHIR uses newer versions of OAuth, and much has changed with OpenID since 2009, in that it now rides “on top” of OAuth, however, the same innovative approach is at work here. I would like to share some of our experience with our Dossia journey, and foreshadow some key areas of complexity that, as SMART on FHIR continues to grow, healthcare providers, health plans and health IT vendors who will be adopting it will need to address.

Lessons Learned:

• There is immense power and benefit in opening up an API. We issued a press release about the availability of our API and were flooded with requests to integrate. Prioritizing them was hard, but we established a system to manage them. We found that, over the long term, enabling an API benefited both parties equally. As a platform technology vendor, we could focus on enhancing our core product, and our API developer partners focused on improving theirs. API developers created solutions that our team would never dream up on our own, nor did we have the development capacity to implement them if we did. We were able to offer these solutions to our customers easily and inexpensively.
  The healthcare IT vendor market will follow models from other industries that have seen rapid API adoption. Companies like Salesforce, Yelp, Waze, and many other organizations have extensive public API initiatives. For those health IT vendors who are not yet embracing SMART on FHIR for fear of giving away customer control, or a desire to offer as much capability on your own to your customer base as possible, I would say that those fears are unfounded and you run a greater risk in not acting — in the future, customers may choose vendors who can offer more choice of functionality and substitutability, enabled by SMART on FHIR.
• With great power comes great responsibility. Increased responsibility exists both on the side of the EMR, and the integrating application vendor. We needed to establish a set of “rules of the road” in terms of how to use our API, what was acceptable use, unacceptable use, responsibilities of both parties in terms of data use, clarity of authorizations for our collective users, privacy policies, terms of use and other considerations.
• User Interface Consistency. This is perhaps the single largest challenge of third-party application integration. It matters greatly that the user experience can flow beautifully from one application to the next. At Dossia, we worked hard to provide our application partners with sufficient screen real estate via an integrated iFrame approach as well as guidelines for user interface features. We were unique in our market in that other vendors offered more of a hub framework, and the user experience was quite clunky for them, whereas the vendors who chose to integrate with Dossia had prominent placement, and integrated inside of the Dossia user experience in a way that was consistent and fluid. Small items like button shapes, consistent use of fonts, and consistent styling went a long way to create a really great user experience. Just as the Apple App Store, and Google Play have user interface guidelines, it will be important for SMART on FHIR apps to also follow a similar model. As the number of SMART on FHIR enabled applications increase, it will become more important for these applications to have common visual experience themes. This will be exceptionally important as sidecar applications begin to take on areas of the healthcare delivery system where mistakes made by a user of a poorly designed or inconsistent user interface may place a patient at risk.
• Adequate API Developer Support. EMR vendors who offer FHIR APIs and SMART on FHIR enabled capabilities must professionally and competently support the developer communities that will begin to coalesce around their product. This means having excellent documentation, proper training materials, discussion groups, ways to communicate to knowledgeable engineers, and adequate response times to stumbling blocks that developers may encounter. At Dossia, we initially staffed our API support functions with the developers who created the technology, which worked well, and as time went on, and the requests from API developers were somewhat predictable, we enabled some of our more junior engineers to provide this level of support. This was a great way to train some of our newer members of the staff on the technology, and get a front-line view of how our community of application developers operated. Ultimately, we made the API support function a rotating assignment such that we could spread the knowledge inside our team, and not have any one person in the role for a lengthy period. We found that some of our best enhancement ideas came directly from the API developer community, and it was critical to collect their feedback and improve our product rapidly based on their comments and suggestions.
• Rules of the Road. Enabling FHIR and SMART on FHIR capabilities means that third party application providers will have a copy of EMR data and they will need to comply with HIPAA regulation. But, in addition to HIPAA, there is a set of other complexities that need to be discussed whenever data is copied. What happens if the data in the EMR is changed — a change of a patient’s address for example? How will the sidecar application’s copy be updated in cases where the app doesn’t pull the data from the API on each view? At what frequency? What if there is a means to update data from within the sidecar application? Will that data be sent back to the EMR? Today, some of the EMRs have enabled read-only FHIR servers, but in the future, as EMRs enable write access, it will be important that sidecar application vendors send data back into the EMR system of record consistently and correctly. There are many “rules of the road” details that will need to be articulated, documented, and followed when EMRs enable write access.
• Maintenance Windows. It was important to communicate maintenance windows and to coordinate maintenance with our application partners and customers. The kind of architecture that SMART on FHIR enables means that more people need to be involved in the planning of system maintenance that occurs from time to time.
• Uptime Requirements. Service level agreements with customers often included financial penalties for unplanned downtime. It was important that our application partners also understood these expectations and were able to comply with those requirements.
• Approach to Quality. At Dossia, we ran a professional development organization that included a specific approach to quality, with documented requirements, test plans, regression tests, and other systems, controls, and policies that are found inside organizations that are creating commercial-grade software. Some of the vendors who had an inexperienced development staff sometimes struggled to meet our level of quality expectations and the rigor that goes into producing high-quality software. Organizations that will utilize SMART on FHIR will also need to be very specific in terms of the quality expectations of integrating sidecar applications.
• Environments. We had several separate development, integration, and staging environments and a single production environment. We found that some third-party application vendors sometimes had a development environment, and a production environment, and that was it. We needed them to correct their internal environment set up before we would continue. SMART on FHIR sidecar application vendors should mirror the environment setup of the EMR.
• Security. A tremendous amount of work and resources goes into securing healthcare data systems. Security is a large and continuous task. At Dossia, we also extended our security practices to our API application partners. This meant documented policies, penetration scans, training, audits, and other processes and controls necessary to keep our user’s data safe. SMART on FHIR implementations needs to examine and potentially refresh their security policies and approach to security now that these newer capabilities exist.
• Change Control. Communicating changes to environments, new releases, changes to APIs, and other, potentially breaking changes is critical in an environment that SMART on FHIR enables.
• IT Governance. Hospitals and other healthcare organizations likely do not yet have the necessary IT governance, procedures, and policies in place that contemplate SMART on FHIR sidecar applications. Healthcare IT executives and the teams that work under them work very hard to ensure the security, reliability, consistency and availability of internally deployed products. It takes an entirely new set of skills, processes, procedures, and controls when transitioning to a more open IT governance supporting open APIs.

SMART on FHIR’s Rapid Growth Path

Living in Boston has some excellent advantages. Recently, we attended the first meeting of the Boston SMART on FHIR Interest Group. Dr. Ken Mandl kicked off the meeting and speakers included Dan Gottlieb, Product and Technical Lead, SMART Project / Boston Children’s Hospital, and Josh Mandel, Lead Architect, SMART on FHIR. It was a well-attended event with many engineers, scientists, MDs and enthusiastic informaticists in the room. Josh gave a presentation on CDS Hooks which is a pattern for invoking decision support capabilities that builds on SMART on FHIR.

At the most recent FHIR Connectathon in San Antonio, the growth of FHIR, and SMART on FHIR was most evident. There were no less that 4 tables of attendees participating in the CDS Hooks track.

Summary

SMART on FHIR opens the door to entirely new levels of interoperability, user experience and integration while maintaining rigorous security and privacy requirements that were never possible before. With these new capabilities, come additional levels of responsibilities not only by organizations who have implemented EMRs, but also the developer’s community who are creating integrating applications.

About Us

Helios Software is a Boston-based health technology company that delivers professional product engineering services, and also offers a FHIR-based clinical data solution. We are actively implementing SMART on FHIR solutions for clients. Please get in touch if you are looking for assistance.