Generic File Upload Functionality

Continuing the discussion from Importing CSV Data into OpenMRS:

I am looking into the first part of this feature needed for our implementation, and wondering if there is a recommendation or plan for generic file upload functionality that can be used across Ref App? So essentially anyone who wants to upload a file would extend the controller and use the file for whatever they need to do - or configure locations of saved files etc

@mksd I know you have been working on the attachment module, any recommendations? I am trying to write as little code as possible that needs to be maintained.

I think it would be trivial to let AttachmentResource handle a non-patient centric file when the appropriate instructions are provided. This would happen somewhere here.

@ssmusoke would you mind creating an ATT ticket for this with as much details as possible? Would you be able to work on this ticket, or would you be in a position to assign someone to it?

Cc @zouchine

Agreed that the Attachments module seems like the obvious place to add this functionality.

Take care, Mark

@darius @dkayiwa Just a wild idea, does this flow make sense?

  1. Upload file

  2. Deconstruct file into line items

  3. Create a REST payload to save the file contents?

3b. Or does this it make sense to create POJOs and save through hibernate?

Is 2 an automatic step triggered by 1? If so then Attachments will have to fire some sort of event to broadcast that a generic file was successfully uploaded.

Looks like the rest of your bullet points should be part of another thread.

@mksd after going into the code a little more, attachment will need quite a bit of change for a generic use case where:

  1. The uploaded files are not stored on the file system or database

  2. The purpose of upload is like a batch data entry

  3. Will this not pollute the attachment namespace, would it be better to have a bulkupload one which can do the following:

  • Upload the file
  • Provide an interface for reading and processing the uploaded file
  • Provide feedback to the end user on the results of processing the uploaded file - probably overall, and line-by-line errors similar to what Metadata deploy does here

Or am I overthinking this?

I think you should clarify what your bottom line is.

Attachments already provides the UI and backend to upload and store files. If that’s your bottom line then leverage it! I thought that it could make sense to customize/extend its UI and REST API to handle the case of non-patient centric files. So basically that would mean that Attachments would now have a admin-related view to upload files outside of a patient’s workflow. I think that’s great.

Okay… but surely they will at least be stored temporarily somewhere, awaiting their processing? In which case Attachments could also help.

I am not concerned about polluting the Attachments namespace (whatever that means). I can only tell you that its UI components are designed to display what fits the intended use case. For example the gallery widget can be configured to display a list of files based on a custom query. You would just have to fit this (with the ad-hoc query) in a page intended for generic attachments.

However strictly speaking the post-processing belongs somewhere else. We can think of ways to hook that in though.

Yes, I intend to

I had not thought about that - now that you mention it, I think it makes sense to review the uploads done at a later stage

Exactly its the hook that I am looking for - so that an upload can define a class to be used for processing

Thanks for the clarifications.

So I am thinking of the ticket as Enable upload of non-patient related files and file processing implementation support

But do you intend this processing to happens right after a successful upload, or should this be triggered manually at a later stage?

I mean I would create a ticket framing the work around a non-patient centric file upload feature, but I wouldn’t mix the post processing in there.

@mksd Thank you for your patience, and I agree with you - it may be simpler than I actually thought see

I am even thinking it can use the same concept name, and locations. These files will not be shown on the patient dashboard since they are not tied to an encounter hence patient.

However an obs must be associated to a person. So we have a design choice to make here, which person should be associated with those complex obs that are saved outside of the usual (patient centric) EMR workflow?

User #2 daemon seems like a good choice - better if we can make this a configuration parameter

Daemon is a User, not a Person.

Daemon and admin are both tied to the same person with ID 1

Ok so that should work.

(Caveat: I haven’t looked at the code or UI of the attachment module at all…)

IMHO this seems like a bad direction to go. I would keep the attachment module focused on uploading files that are attached to a patient.

Uploading a file with a workflow around (extensible) processing and review sounds like a different use case to me and should have its own module.

“Uploading a file” is not a very hard thing to do with modern web libraries, and it’s not worth conflating two separate use cases just to avoid duplicating this.

I agree with Darius, with the caveat being that if you really want to create a complex_obs and associate with a person (say perhaps to associate a PDF with a user or a provider), it seems like it would make sense to expand the Attachments module to do this.

But it sounds like that is all tangential in this use case, if I’m understanding @ssmusoke correctly… it sounds like you want to use this for batch data entry… do you mean like uploading a row-per-patient CSV that creates a set of patients in the system? This does seem like a separate use case from the Attachments module.

Take care, Mark

@darius @mogoodrich Thanks so will look into a custom module that can be extended later for this and leave attachments for now

Does this addressed, I am trying to upload image with respect to person, Is it possible?

@zeeshanih this is and old thread. I suggest that you start a new conversation and provide as much details as possible about what you’re trying to achieve.