Module: Visit Documents UI 1.2 released

Hi all,

Visit Documents UI 1.2 is out.

New features

  • Allows to add documents to closed visits.
  • Reorients images based on their EXIF metadata.


  • Cannot purge documents with missing underlying complex data file (see TRUNK-5077). This requires Core 1.10.5, 1.11.8, 1.12.1 or 2.0.5 at runtime.
  • Upload fails for portrait images with some EXIF metadata.
  • Thumbnails are not reloaded when clicking on ‘show/hide details’ multiple times on the patient dashboard.
  • Date/time stamps use incorrect locale on the patient dashboard.


  • Make it 100% RESTful by extending VisitDocumentResource's implementation.
  • Refactor it into ‘Patient Documents UI’ since its scope goes beyond attaching documents to visits.
  • Port it to Bahmni.

Cc: @mogoodrich, @mseaton, @hpardess, @ssmusoke


@mksd Thanks for the update, a couple of questions. Will the name for Reference application be ‘Patient Documents UI’ or ‘Visit Documents UI’?

The refactoring into ‘Patient Documents UI’ will apply to all its target environments including the Ref App. ‘Patient Documents UI’ is not a specific refactoring for Bahmni.

But for the time being it remains as Visit Documents UI…

I am using VDUI 1.2 but I observed a change in this version which was not there in VDUI 1.1. Here are the steps i follow 1- Open a visit 2- Click on Visit Document Button I have uploaded 3 images

3- return back to visit page here you will see that for each image a seperate encounter is created. Although i have uploaded them in same time. they should be displayed under one encounter.


This was always the default since version 1.0. You can modify this behavior through setting the visitdocumentsui.encounterSavingFlow global property’s value to “unique”:

Nice work @mksd I have question. Is it possible to link a webpage instead of uploading a document. So you add a link for a webpage, and the module will pick up the image or the document?

Thanks @yadamz.

This is currently not supported but definitely could. What do you have in mind?

  • The image lives somewhere else and would be displayed by VDUI based on its original location (an URL then), or
  • You would like to upload an image within VDUI through providing its URL?

The latter merely represents yet another way to upload a document really.

Thanks @mksd The image lives somewhere else . You post the URL and it captures the image . However , I tried the moduel and it didn’t work . I keep getting flash error message . I tried to upload an image and it also didn’t work . I am using 2.6 ref app

Hi @yadamz,

I just fired up a new Ref App 2.6.0 with VDUI 1.3 and everything works fine. Do you realise that documents can only be added to a visit? Where you by any chance looking at a patient outside a visit? This will likely be relaxed in VDUI 1.4, see this thread.

What Flash error did you get exactly, this?

Webcam.js Error: Adobe Flash Player not found. Please install from and try again.

Also this should not happen if you use Chrome, where you using Chrome?

I suggest to have 3 types of arrangement of photos,

  1. Show all uploaded files in a single encounter of a visit (It is already implemented)
  2. In each encounter show only single uploaded file. (It is also implemented - visitdocumentsui.encounterSavingFlow)
  3. Show all uploaded file under one encounter if they are uploaded together. (Not Implemented)
  • I mean if i upload 4 images together they should be visible under one encounter. if i upload another image later that should be displayed under different encounter. for example, I will have 3 chest x-ray and want to be displayed under one encounter which will have same location and user. then i will have 3 lab test as images which should be uploaded by another user from different location and it should be displayed in different encounter.

Hi @hpardess, yes it is a reasonable requirement. Of course uploads made “together” vs uploads made “later” needs to be defined. Presumably through a time window that should be configurable.

Also those had the edit/delete right should be able to add new/remove existing uploaded files from a specific observation of VDUI.

Will the different encounters created for the images have a sorting and searching option also? Sorting can be by date(default) or by name, which will be a user choice. Searching can be used for finding the documents easily.

+1 Absolutely, thanks @tushar05.
I have added it on the Google Sheet :slight_smile:

Note that at the moment they are always sorted by date descending.

@mksd Clarification questions

  1. Are all file extensions supported? If not, list the ones that supports.
  2. Are all web browsers supported? If not, list the ones that supports.
  3. Why can documents uploaded only during visits? Security issue? Legal/Ethical issue?
  4. Are we uploading legacy pictures of patience or just moving forward from new from here on now?
  5. @yadamz You stated you got a flash error, what was it? if you did not document it can you please replicated and document the error ? Also please try and write down the steps you did when the error occurred if possible.

Yes, and this is already the case btw. The Attachments module handles any MIME content in a generic way, but handles certain MIME types (or rather groups of MIME types) specifically. For those an ad-hoc implementation is provided. So right now:

  • Images are handled specifically (on both the client and server-side).
  • PDF files are handled specifically (on the client-side only, the server-side is generic).
  • Any other content is handled generically.

The main target is Chrome. However we have an implementation site where Safari was used (against our recommendations) leading to this problem for example.

First of all this is not the case anymore since this commit, but then the ability to not follow the visits/encounters workflow has to be explicitly switched on.
Prior to that, when attachments could only associated with visits & encounters, the logic was to adhere to the usual Reference Application workflow: obs are recorded through encounters that occur during visits… etc etc.

The RESTful implementation should handle all scenarios, that’s the bottom line for the extended implementation of AttachmentResource that will be part of Attachments 2.0.0.

I’m not sure I fully understand the question, would you mind trying to reformulate it?

Should I raise a JIRA Ticket for this?

Yes please.

I had already recorded this as a one-liner in the Google Sheet as

Enable attachments sorting & filtering on the main thumbnails page.

It would be great for the JIRA ticket to expand in more details what is desired.

@mksd Downloaded this from git and built the omod. It showed ATTACHMENTS panel in patient dashboard and when I click on that showed me a blank screen. Am I missing something? Using reference app 2.8. Thanks in advance