Moving forward with Radiology

Projects Radiology
1

Hello everyone

This post is to make public the discussions that have been made about radiology for reference purposes. Some of these discussions happened on chat, my gsoc blog posts and in person. During GSoC I learnt a lot about lh-radiology and made some propositions about the way forward which @judywawira and @arastogi were on board with.

  1. Instead of saving Radiology reports as files embedded in complex obs, we’ll be saving them as strings. The current method adds unnecessary complexity to the code base and makes it not very user friendly as to have it work you’d have to make a lot of configurations to use complex obs. By the way we see no added benefit of saving them as files. And this also has the advantage that we can just expose a rest endpoint that has a text or body field in the json representing the report body in html. This also means the report templates that are currently been stored as files will be stored as strings.

  2. Deprecate RadiologyOrder and replace it with ProcedureRequest which for now we’ll have to implement our selves. Why? The current RadiologyOrder inherits a lot from OpenMRS implementation of Order hence making us tired to this implementation and it’s complexities that does not much fit in our workflow. So we’ll be implementing ProcedureRequest as specified by the latest fhir standard to replace RadiologyOrder

  3. Completely remove the legacy UI from the Radiology module and having an OWA instead. The module will just remain a Java API and a REST API. This will significantly reduce the complexity of the code base making it easy to get started with the radiology module. Because backend developers won’t have to worry about UI stuffs and frontend developers won’t have to worry about Java. But unlike OpenMRS we will not be maintaining a Java UI for radiology since we don’t have the man power to maintain two modules and there’s a lot more we could be doing instead.

At the Open Source Summit in LA, I told Judy that my goal now was to be able to move all the current UI functionalities to the OWA and when that was done we’ll commence removal of the legacy Java UI from the radiology module.

But the OWA is RESTful and to completely move the current workflow of Radiology to the OWA will mean we have to have REST endpoints working properly for all resources.

Now this means two things,

  1. We make the changes to the backend at once like implement ProcedureRequest and making endpoint for it and also changing the way reports and reports templates are stored then make and endpoint that just has a field property of “text” containing the report and report template body as html. Note this also means we’ll have to be making changes to the Java UI too to make sure it’s backwards compatible with the backend.

Or

  1. We could just make the endpoints that will just support the current backend and later change it when we have removed the Java UI and are ready to change the backend implementation. That is we could make endpoints that instead of exposing the template as strings we’ll be manipulation file resources. And when we finally make the change to store templates as strings, we then reimplement the REST endpoints.

Non of the two approaches seem like a good idea to me. With the first one, we have to simultaneously maintain the legacy UI while making changes to the backend else we’ll end up significantly breaking the code and make it completely unusable. Simultaneously modifying the legacyui to move along with the changes to backend is a waste of time as we’ll endup deleting it. That will be efforts wasted in implementing and writing test cases.

The second approach of implementing the REST endpoint and the OWA to just support the current backed and have everything tested and working before moving on to removing the current UI will also endup in efforts been wasted as after removing the legacyui, the changes to the backend implementation will require a re-write of the REST endpoints and how the OWA interacts with it.

My proposal is that we start with the removal of the of the legacyui even thought the new UI is not complete. We should remove it completely and then make the changes to the backend implementation then the REST API and the webapp can just use it.

This may sound drastic but I think it’s most reasonable compared to the others. Given my experience working with Radiology code, I know what is involved in making the proposed backend changes. It’s not just change some property type from File to String or changing one Java class from RadiologyOrder to ProcedureRequest. There’s a lot of work to be done to have that change especially when you have to make sure you don’t break the frontend while doing so. And if that work ends up been thrown away then it’s a waste of time.

And to make sure we don’t lose a lot of years effort on Radiology to try something we not sure will work, this is what I propose we do

  1. Move the current Radiology code as it is to a maintenance branch on GitLab say 1.0

  2. Change the snapshot version in Radiology from 0.1.0-SNAPSHOT to 2.0.0-SNAPSHOT. This way it makes it clear that the changes to be introduced in this version will not be backwards compatible with the old version.

  3. Proceed with removal of legacy java UI.

  4. Safely make changes to the Java API without worrying about breaking the legacy java frontend

  5. Implement the REST endpoints based on the newly implemented Java API

  6. Connect the owa with the backend

With this we’ll be avoiding a possible maintenance nightmare.

I’d like to hear your thoughts on this. Maybe I’m seeing things different.

Thanks

cc @sunbiz

1 Like
2

I am in agreement with this plan but would also like @sunbiz blessing and other folks within the community

1 Like
3

I like the above quoted idea. At least till the time the OWA is ready and well tested. I think we should keep the legacyui because other parts of the toolkit will continue to use it, till everything else is OWA-based. I think the REST endpoints should be implemented with the RestXXXController pattern and then we will continue to live with the old Java API till the UI is moved to OWA to use the REST backend.

1 Like
4

Ok cool. Makes sense.

Can you explain a little more about this? Because currently to implement a REST endpoint using the webservices module you just have to subclass an appropriate resource class. For example to implement REST endpoints for RadiologyOrder which inherits from BaseOpenmrsData, you have to create a class RadiologyOrderResource that inherits from DataDelegatingCrudResource. Does the proposed pattern differ from this?

5

Right, that is how the webservices.rest pattern is. I didnt know if all of the Radiology resources were planned and if they were just a sub-class of RestController. But what you write is fine, if you will also write the resources and ensure that they are inherited from DataDelegatingCrudResource

PS: I am still of the opinion that we need to move away from this highly normalized, relational data model to more simple JSON/docstore representation. But thats just me talking without cycles to write code!

1 Like