GSoC 2020: SMART-on-FHIR Project Final Evaluation

Community GSoC
, , , ,
1
  • Project Title : SMART on FHIR
  • Primary mentor: @ibacher Ian Bacher
  • Backup mentor: @jecihjoy Jacinta Gichuhi
  • Student: Siddharth Vaish
  • Project Link: SMART on FHIR

Overview

I was selected for the project named “Advancement of OAuth2 Module and Improvements in SMART OWA”. The basic idea of this project was to be able to run existing SMART apps on OpenMRS via FHIR. This would allow users of OpenMRS to take advantage of already existing health apps without writing a single line of code. It would also give a Plug and Play functionality to OpenMRS (just like we install apps on our Android/IOS devices through Play Store/App Store)

Just after the proposal submission period was over I started working on the project after discussing it with my mentor (and as the title suggests) I started working on improving the existing OAuth2 Module 1. Some of that work can be found here.

To enable SMART Apps, an important requirement is an Authorisation server which was earlier fulfilled by the existing OAuth2 module, which used Spring Security’s OAuth project to provide an OAuth2 server. But recently Spring released a Deprecation Notice which stated

“The Spring Security OAuth project is deprecated. The latest OAuth 2.0 support is provided by Spring Security. See the OAuth 2.0 Migration Guide for further details.”

But the major problem was that, in Spring Security oauth2 there was no Authorisation server included so we were stuck on the earlier version of Spring Security OAuth project. My mentor Ian and I still tried to work on the earlier version of Spring oauth2 but as most of the classes were depreciated we had to shift to a different approach for an Authorisation server.

Ian suggested to completely come out of the Spring trap and try to make things work with Keycloak. Keycloak is basically an Open Source Identity and Access Management software. For our purpose it works as an Authorisation server.

The first task was to find a way to get the OpenMRS users to keycloak’s user database. So for this we implemented Keycloak’s following providers:

  1. UserLookupProvider
  2. UserStorageProvider
  3. UserQueryProvider

And with the help of UserStorageProviderFactory add the OpenMRS user store to Keycloak. Link to repository

The next task was to Support DSTU3 profiles with OpenMRS FHIR2 server because many SMART Apps used DSTU3 standard to communicate with the FHIR server. This was pretty simple and hardly took 2 weeks to complete. Link to commit

The difficult part started with the Standalone Launch Sequence. So I had planned to implement the EHR launch sequence first and then the Standalone Launch sequence but Ian and I found an implementation of Standalone Launch Sequence with the igia organisation had already been done, so we started with the Standalone Launch Sequence first.

Initially we tried to leverage the igia repository itself and maintain a fork for OpenMRS SMART on FHIR implementation but as the code base was not maintained we faced a lot of errors. We decided to start from scratch and develop our own implementation for the Standalone Launch Sequence.

Soon we were able to come up with two new repositories openmrs-module-smartonfhir and openmrs-contrib-keycloak-smart-authentication. Smartonfhir repository was necessary to maintain the modularity of OpenMRS because earlier I was adding all the SMART-on-FHIR related stuff to the FHIR2 repository which was not how it should have been so we shift to smartonfhir repository, a dedicated repository will the SMART-on-FHIR stuff. Smart-authentication repository was something similar to the openmrs-contrib-keycloak-auth repository in the sense that it had nothing to do with the openmrs code as it had only the code required for Authentication flow of the SMART App. Basically it talked to Keycloak only.

During the 11th week of GSoC we were able to launch a dummy SMART App with OpenMRS users, patients and FHIR server but many things were hard coded so our next task was to remove the hard coded stuff with well polished and easy to implement code. The 12th and 13th week of coding period went in removing the hard coded part and making keys and configurations loadable through json files.

My mentor and I are still working to enable the SMART-on-FHIR implementation to support all the SMART Apps available.

SMART App Demo with OpenMRS FHIR Server

Project Objectives

The one and only goal of the project was to enable SMART-on-FHIR for OpenMRS.

  1. Objective 1 — Add OpenMRS userstore to Keycloak (COMPLETED)
  2. Objective 2 — Add method to get user by username (COMPLETED)
  3. Objective 3 — Add support for DSTU3 (COMPLETED)
  4. Objective 4 — Register a Client with Keycloak (ALMOST COMPLETED)
  5. Objective 5 — Verify Client validity with the Keycloak server (COMPLETED)
  6. Objective 6 — Implement SMART App Launch Conformance(COMPLETED)
  7. Objective 7 — Expire the OAuth2 token when the user logs out of OpenMRS (INCOMPLETE)
  8. Objective 8 — Add support for Standalone launch sequence (INCOMPLETE)
  9. Objective 9 — Add Page for appending token to url for patient context (COMPLETED)
  10. Objective 10 — Support dynamic Client Registration with Keycloak (PENDING)

Contributions

Repositories

  1. Openmrs-module-smartonfhir
  2. Openmrs-contrib-keycloak-smart-auth
  3. Openmrs-contrib-keycloak-auth
  4. Openmrs-module-fhir2

Pull Requests

  1. FM2–65 Add support for telecom to Patient (#70)
  2. FM2–73 Remove the OpenMRS Services from Translators (#73)
  3. FM2–74 Rename Task to FhirTask (#74)
  4. FM2–61 Add support for Observation.referenceRange (#82)
  5. FM2–89 Fix tests for Observation (#89)
  6. FM2–79 Improve Search for Encounter (#86)
  7. FM2–88 OpenMRS FHIR2 Module
  8. FM2–92 Add support for AND / OR queries using References (#115)
  9. FM2–173: Fix Type Mismatch (#169)
  10. FM2–183: Add support for DSTU3 (#158)
  11. FM2–237: Add method to get user by user name (#221)
  12. Expose conformance statement without authentication (#271)

Talk Thread links

  1. GSoC’20 : Advancement of OAuth2 Module and Improvements in SMART OWA (SMART on FHIR)
  2. Breaking down walls and attracting more devs to OpenMRS

Weekly Blog Posts

  1. Google Summer of Code 2020 with OpenMRS Organisation
  2. GSoC 2020 at OpenMRS | Community Bonding Period
  3. GSoC’20 @OpenMRS | Coding Period | Week 1
  4. GSoC’20 @OpenMRS | Coding Period | Week 2
  5. GSoC’20 @OpenMRS | Coding Period | Week 3
  6. GSoC’20 @OpenMRS | Coding Period | Week 4
  7. GSoC’20 @OpenMRS | Coding Period | Week 5
  8. GSoC’20 @OpenMRS | Coding Period | Week 6
  9. GSoC’20 @OpenMRS | Coding Period | Week 7
  10. GSoC’20 @OpenMRS | Coding Period | Week 8
  11. GSoC’20 @OpenMRS | Coding Period | Week 9
  12. GSoC’20 @OpenMRS | Coding Period | Week 10
  13. GSoC’20 @OpenMRS | Coding Period | Week 11
  14. GSoC’20 @OpenMRS | Coding Period | Week 12

Resources

  1. SMART-on-FHIR Documentation
  2. igia-keycloak Repository

Future Work

The SMART-on-FHIR project is vast with a lot of dynamic parts involved. Although we were able to lay a solid foundation with a flexible framework but still the project needs a lot of polishing. The major part I was able to cover was the Standalone Launch Sequence which basically means that a SMART App can be launched from outside the EHR and can get authenticated and finally talk to OpenMRS FHIR server. The part which I was not able to complete is the EHR Launch Sequence which involves a similar approach with some small changes. Undoubtedly it’ll be something very useful for the OpenMRS community. Also as of now the Client registration to Keycloak is a manual process but it will be nice if we could make it sort of automatic. Finally we would like to dockerize the whole project so that it’s easy for the OpenMRS implementer to use the SMART-on-FHIR functionality.

Thoughts on GSoC

It was an amazing experience working as a student in Google Summer of Code. The kind of learning that I gained during these 3 months is unparalleled. I have all praises for OpenMRS community and especially my mentor Ian Bacher. Ian has helped me every single day, may it be issues with my environment or git or any problem in understanding the codebase, he has always been there to help. During these 3 months I have gained a lot of interest in OpenSource and I will continue contributing to it in future as well. I am really thankful to Google for providing such an amazing platform to students like me.

Thanks for reading : )

4 Likes
2

Congratulations for the good work done.

1 Like
3

Great explanation on the entire flow with the evolving thought process. This article has given a good overall understanding on what’s needed and how its being implemented.

We are on the similar lines trying to build Smart on FHIR capabilities for ehr and standalone launch. As far as I understood, we need to tweak the auth server for adding context information and accepting launch parameter from the 3rd party App. Has there been any progress made on the same? I see the note at end that’s in future roadmap. Any approximate timelines on how soon it may be completed.

Appreciate your help!

4

Thanks a lot @sagarshah1983 for taking out time are going through all this.

Yes @ibacher and I are working on this and you can find all the related work here

So basically we are almost done with the Standalone Launch flow and now we are working on implementing the EMR Launch Flow

So honestly I am not very sure about how much time it’ll take to complete both the flows.

5

Great to know! Thank you for all the updates @sidvaish97 . I will take a look in detail and may reach out if any questions.

1 Like
6

So I was trying to refer the code in github that does the following, but could not find out or may be I am looking at wrong place. Could you please point me in right direction? Here’s where I was expecting it - https://github.com/openmrs/openmrs-contrib-keycloak-smart-auth/tree/master/openmrs-keycloak-smart-auth/src/main/java/org/openmrs/contrib/keycloak/smart/auth

For standalone launch - we need to display patient selection and once patient is selected, we need to return access token response including “patient” as an additional field along with access_token, scope, expiry, refresh_token, etc.

Any help is appreciated!

7

So you are absolutely right we need a patient field. So for the OAuth server we are using Keycloak and keycloak doesn’t allows adding custom claims to the AccessTokenResponse as of now.

For this Ian has made a PR to the Keycloak community. Please have a look https://github.com/keycloak/keycloak/pull/7371

I hope this helps.

8

Thanks @sidvaish97. That exactly is the thing I was looking for. Similarly auth server requires the launch parameter (launch token) for EHR launch sequence. Is that something also in plan. I assume keycloak does not have support for that at the moment, but it could be implemented using the extensions?

Thanks again for your response.

9

This is what we are working on currently. You can find the PR for this here

Hope this helps

10

Great! Thanks for all your inputs!

1 Like
11

anynone here can help me to configure smart fhir using keycloak

am failing to get login form