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