I need a field in the Patient Attachments for storing the file name and file caption. The reason for the file name is that I’m uploading the base64 content file and there’s no way to give the base64 content a file name. Since the requirement is for the user to edit the file name and file caption, I need a fileName field. Currently there is a fileCaption field available, I need a fileName field as well.
This is a high priority task for me, please try to help me asap.
Thanks a lot!
Hi @abertnamanya!
I’m working on the same file actually.
As you can see, we are sending a file along with the base64Content, but the name stored on the backend is not the one passed on as the file.
To my understanding the file names are auto generated in the back-end to avoid overwriting of existing files with same name. You know , you can’t be sure that the users will be able to input different file names.
Or like @dkayiwa said you could concatenate the fileCaption and fileName when fetching the file you split the caption string to display the fileName
It seems from the design there is a desire to have a human readable name as well as description, as well as the actual file name. Let’s take the following designs for an example.
In this image upload there is a field for “image name” and “image description”. Although the example here shows inputing “imagename.jpg” really this is free text and what the user enters here will not affect the file name of the uploaded picture. On the next design you can see why this is the case. The attachment “labels” include things like “Bandage hand” which is not a valid file name, but a very good human readable name.
It seems historically the database field “fileCaption” was used for the human readable name, as actual file names can be messy and really we shouldn’t care too much what they are. It seems like in the first design the “image name” would really be the “fileCaption” field behind the scenes. This leaves image description as a new field which is not yet existing in the data model.
Rather than concatenate and then separate a “name” and “description” in fileCaption field, would it be possible to implement a new field “fileDescription” to hold data for the new design?
FWIW, the fileCaption does not have its dedicated field in the obs table. It is currently stored in the obs.comments field. And below is the original intention of the comments field.
Obs comments were meant to correlate with HL7's NTE (notes & comments) segment. It's meant to collect plain text detail about that particular observation. The examples given by HL7 are instructions, reason, and remark. The trick is to approach this as a brief comment about the observation itself and avoid using it as a clinical note. The paper-based analogy for obs comment would be a sticky note or handwritten comment attached to the result sheet. The comment can inform the person reviewing the result of additional, pertinent detail. As such, the comment "traces of blood" could be recorded in the obs comment of a diagnosis observation, assuming a free text comment is appropriate. Any code rendering an observation should be aware & capable of rendering the comment. The size of 255 characters was chosen, in part, to ensure that people did not use the field for clinical notes (and to avoid another large text field in an obs table that may hold hundreds of millions of observations). That column size may be a bit too restrictive.
@dkayiwa that’s really interesting. Just curious if you have the link for the above comment?
@pauladams or @cduffy , is it possible to please clarify what should happen with ‘image description’ field seen in the designs? Is this is a requirement from the users? Do you know the max character size for this, or how it should be stored with the attachment?
The question
The current things which already exists are:
file name - the actual name of the file being saved like “12415_arm_15.jpg”
fileCaption - a description field that gets stored as obs.comment which historically (OMRS2.x) is used as the file ‘label’ for human readable viewing like “Left Arm”
By looking at the design I assume these are the things which are needed:
file name - actual name to store a file, as above
image name - this appears to be the same analog as fileCaption above - a human readable label for a file
image description - maybe extra information about the image that is longer than a short label?
Is ‘image description’ a requirement from the users as I’ve imagined it above? And if so should we find a proper way to represent this data on the backend?
Why it matters
Backwards compatibility. 2.x systems coming into 3.x only have fileCaption as human readable name, and should be displayed as the primary label. Not knowing if an obs came from a 2.x frontend or 3.x means we should always use fileCaption for this purpose.
We should not rely on actual file name for the file label. I’m assuming either we aren’t allowed to change the actual file name or the backend sets it to some reasonable has value as it needs to resolve conflicts, etc (leftarm202208018.jpg, leftarm20220818(2).jpg). Also, file names including the extension “leftarm.jpg” are harder to read. This is also indicating to use fileCaption as the label.
Image description field from design implies we have a separate place, not the image label, to store a sticky-note like description.
The current PR from @vasharma05 for this tries to code a ‘name’ and ‘description’ information into the fileCaption field. Aside from the fact that the JSON string representation alone takes up 28 characters out of 255, and the actual name and description have to share the rest which limits what they can be and/or creates really complex logic to validate that this doesn’t char overrun before posting, there is the bigger issue of having obs.comment be a human readable string most of the time until its not for this one case where the obs is an image attachment and it needs to be parsed json except when it was from a legacy version… All in all a messy system to implement let alone support long term.
I would very much like to avoid the frontend abusing the obs.comment field to support “name” and “description” if possible, and instead find a way to properly allocate these in the data model as appropriate if this is really needed.
Thanks everyone for your patience bearing with me here. It’s a small pebble that I’m worried will become rock in our shoe down the road if not properly looked at now.
Given the number of fields that you are capturing together with the attachment, how about modeling it as a concept set and store the values as an obs group?
Oh, super interesting! Yeah that sounds like it can work… Unfortunately I really don’t know how to do this. Is there a good reference on how to do that?
Thanks @dkayiwa for providing the links.
As far as I am able to understand (correct me if I’m wrong), you are saying that we should make a concept set, say PatientAttachment, and set Obs set in it, where we can save Image caption in one obs and the description in another obs. Am I right?
If I’m right, then it would mean that we store our attachments as a conccept and leverage these concept sets, right?
@vasharma05 the PATIENT ATTACHMENT concept set would have members like (the image itself, caption, description, filename, etc) and these are each stored as different obs in the same obs group.
