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 @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
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 get.adobe.com/flashplayer 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,
Show all uploaded files in a single encounter of a visit (It is already implemented)
In each encounter show only single uploaded file. (It is also implemented - visitdocumentsui.encounterSavingFlow)
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.
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.
Are all file extensions supported? If not, list the ones that supports.
Are all web browsers supported? If not, list the ones that supports.
Why can documents uploaded only during visits? Security issue? Legal/Ethical issue?
Are we uploading legacy pictures of patience or just moving forward from new from here on now?
@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?
@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
