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.
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 spending some more time, we have come up with one more approach which is resulting in the same above mentioned.
Create a new concept attribute type as “Url”, datatype as “free text”. This will be to provide the path of the image
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)
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
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.
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:
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.