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.
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.
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?