Week 12 – Controller Finished – SMART in final development

This week was very productive in terms of quality and quantity. Finally, the module is FINISHED !!

This week, I finished the Client Management REST Controller. Initially all testing was done against the authenticationManager used by the token services. So, I made a new authenticationManager one custom to server the needs of the REST Controller.

The controller supports the following endpoints :

  • GET /clientManagement?username=xyz&password=xyz
  •          This will return all the clients registered by the client developer xyz.
  • POST /clientManagement?username=xyz&password=xyz?name=abc….
  •          This will create a new client for the client developer xyz
  • DELETE /clientManagement?username=xyz&password=xyz?client_id=abc
  •          This will unregister the client with client_id abc
  • UPDATE /clientManagement?{details here}
  •          This will update the client details

 

Progress on SMART ?

All initial research was finished and discussed thoroughly with Mayank (my mentor, @maany) this week and all the authorization endpoints were completed in the module. The next step is to code the JavaScript based SMART on FHIR client which will run against the OAuth module, get a token and access FHIR resources. The JavaScript client is in development phase at the time of writing the blog and I am expected to finish it by Tuesday.

What next?

After the SMART on FHIR client is completed, I will be documenting all the work done in this summer and create a static github.io page explaining all the work and give useful statistics about my work.

 

 

Week 11 – Back to Controller

So last week, I was having some troubles with integrating the Client Management REST controller into the module. The troubles were about managing the entry point for the URL mapping. Finally, me and my mentor Mayank decided to do it the way IETF (Internet Engineering Task Force) describes. Like the document here and also manage the client dynamically using protocols defined here.

So I’ve implemented the process using the standards defined by IETF.

Next Problem ? (Because there’s always one  😛 )

 org.codehaus.jackson.map.JsonMappingException: Direct self-reference leading to cycle (through reference chain: java.util.ArrayList[0]->org.openmrs.module.oauth2.Client["creator"]->org.openmrs.User["creator"])

The client class inherits fields like “creator” and “voided” from the BaseOpenMRSData which in turn inherits org.openmrs.User. This leads to a recursive cycle and causes a Jackson JsonMappingException.

Meaning? We simply can’t return OAuth client objects and expect Jackson to convert them into JSON (like it’s supposed to)

Fix? Convert your objects into JSONObjects manually using JSON classes and then send them with the appropriate Http Message.

Progress on SMART ?

As mentioned in the last week’s blog post, the next piece of business was supposed to be SMART. I worked and researched a lot on SMART. SMART on FHIR is a use-case for the module and it’s highly necessary that it is completed in this year’s GSoC.

My initial plan was to use the SMART on FHIR sample JS application and modify it to our needs. However after spending lots of time on 17000 and so lines of code on the fhir-client.js it turns out the app was designed only to be run against their own sandbox server 🙁

So the work on SMART is put on hold for now and further work will be done after a call with my mentor (The call is scheduled for 15th Aug 9:30 pm IST).

 

Week 10 – Work on SMART started

Finally, one of the major tasks for the summer (Project migration) was completed and now we can start work with the SMART application.

Overview of SMART on FHIR : 

SMART on FHIR is a set of open specifications to integrate apps with Electronic Health Records, portals, Health Information Exchanges, and other Health IT systems.

The SMART application we’ll be creating will serve as a use-case for OpenMRS Community.

When an OpenMRS user launches the SMART app, we’ll get a “launch request” notification. Just ask for the permissions you need using OAuth scopes like patient/*.read and once you’re authorized you’ll have an access token with the permissions you need – including access to clinical data and context like:

  • which patient is in-context in the OpenMRS
  • which encounter is in-context in the OpeMRS
  • the physical location of the OpenMRS user
  • access to a patient data using FHIR module

The SMART will be a JavaScript application. The original plan was to make a REST based application, however there’s not much documentation available for implementing SMART using REST. The javaScript application that I’ll be making in the next ten days or so will be based entirely on the sample JavaScript by smart helthcare.

SMART is a tech stack for health apps. More information about this can be found here.