Need to create a new Concept class to show a static image in observation forms

In our implementation, we are doing few enhancements for Bahmni where one of the features is having below kind of forms.

We want to create a form with an image as a reference for observations as shown below. This reference image will be a static image. Now we want to create a new concept class(as no concept class exists in OpenMRS which can show an image in the form) to display an image in the form.

We are NOT using Form Builder, How can we achieve this?

@angshuonline @darius @mksd @ramses @pramidat @binduak @swathivarkala @sruti

This is somewhat worrying to me. I don’t think the image is a concept. It is a manifestation of a concept. We had discussed moving away from a 1:1 concept class relationship to concept-based attributes. It would seem that an image would be an attribute on a concept (or a URL to an image).

After our analysis, we have come up with the following approach:

  1. Create a new concept attribute type as “url”. This will be to provide the path of the image.
  2. Create a concept “Image” with datatype “complex” and handler as “Imagehandler”.
  3. While creating the form we can include this image concept to our form’s concept set.

Please let us know if this is the correct way of achieving it.

1 Like

After spending some more time, we have come up with one more approach which is resulting in the same above mentioned.

  1. Create a new concept attribute type as “Url”, datatype as “free text”. This will be to provide the path of the image
  2. Create a concept “Static Image” with datatype “N/A”.(N/A as because we never capture any information in form regarding this concept, as it should be a reference static image)
  3. While creating the form we can include this image concept to our form’s concept set.

Please let us know if this is the correct way of achieving it

Thanks

@saikumarv that seems to make sense. Can you show an example of what this URL might be?

@mksd Thanks for your response.

The URL property here will store path of the Image file.

Example: Assume there is a concept named “Static Image” One of it’s concept attribute will be “URL”, which is a free text datatype, if the image is located at /…/…/Downloads/image.jpg. Then url will store this path. It could be a relative or absolute path which we will resolve while rendering the image on the form.

Please let me know if this answers your question. Also, which approach out of the two mentioned above do you think is more appropriate?

I don’t think this URL attribute is necessary if you intend to use a complex obs with Core’s ImageHandler. Out of the box the value_complex field/member will contain the necessary metadata telling the handler how to find the image.

However if you are not happy with the implementation of that handler, then you can always implement your own handler. However it will have to live somewhere… (meaning, ‘in some OMOD’).

Attachments is my baby so I’m rather keen on pushing it forward. But rather than implementing yet another handler (if you are unhappy with ImageHander) You could also use Attachments’ REST API to save and retrieve that image. I have always hoped to package Attachments with the Bahmni distro but this was never a priority high enough to get down to it.

See here for instance: Bahmni PAT call 20-Jun-2018 - QA/UAT for 0.91

@saikumarv:

Actually I’m rolling back a little here.

Using concepts complex means using obs. In other terms your images will be stored as obs, and the concept complex handler will direct how to fetch the image-obs. An obs must be linked to a patient and my understanding is that it is not what you want.

You want an image to be available throughout the application and that can be referenced to in forms. It looks like your earlier suggestion seems to make a lot of sense:

As suggested by @mksd, we have consolidated the below mentioned steps to have a static image on the forms:

  1. Create a new concept attribute “url” to store the path of the image.
  2. Create a new concept with concept class “Anatomy”.
  3. Datatype would be “N/A”.

@akanter : Please suggest if you see any issues with this approach.

Thanks

Just to be clear, you want to have concepts for different anatomical sites linked to a URL where an image will be seen. There are currently 144 anatomy concepts in CIEL. I would recommend using one of them if possible. Right now, concept attributes are not supported in CIEL/OCL. So you would have to add these attributes locally until they can be managed in the cloud. The concept would be of any class (but Anatomical site would be Anatomy) and the URL will be a custom attribute.

Thanks @akanter. But so, using the ‘Anatomy’ data class is an appropriate choice, correct?

I don’t know to what extent it will be feasible to identify possible matches out of the 144 existing concepts. That’ll be up to the implementation team to assess whether this exercise falls in their scope.

The concept class depends on the concept to which the image applies, not the image itself. If you are creating images for anatomical sites, then anatomy is the correct concept type. If you wanted an image for an appendectomy procedure, then the procedure would be the concept that has the image.

@saikumarv and @nehagupt, why not use a second concept attribute that says “this is a form static image concept”? Could that work to help discriminate, within the set for the form, which ones should have the URL concept attribute discovered and then processed?

It’s true that in the general case those images won’t only be anatomical sites.

Thanks @akanter.

Has this ever been implemented? Is it possible with the current Bahmni product to show static images in forms?

@saikumarv @angshuonline @mksd @nehagupt