Feature: Link scanned medical documents with patient entity about bhima HOT 4 CLOSED

This is a very good overview of a feature that I think should be
prioritised for this round of development - it has been in discussion
for a while and should not take too much time with our new development
standards.

My one comment would be that it may be better to first achieve storing
documents on only one server and simply reporting that the file is not
available if another server (PAX for example) tried to gain access to
the file. Given this base case I think we'll be in a strong position to
add the rsync policy in the future. Primarily this is because BHIMA does
not officially support symmetric or syncing databases across multiple
nodes - implementing this feature right now would specifically be for
our current implementation case.

We could also add a user_uuid or uploader_uuid and note field to
keep track of some additional meta data.

On 02/02/2016 09:12, Jonathan Niles wrote:

  Feature Proposal: Patient Documents

This feature proposal expands the medical history records of the
application.

One way to preserve patient documents is to scan them into the
computer, upload them, and directly link them to a patient entity. In
order to successfully accomplish this, we'll need to develop an
appropriate method of linking, storing, backing up, and syncing
patient documents.

In brief, a new database table, |patient_attachment|, will need to be
created with the following columns: |patient_uuid|, |document_uuid|,
|label|, |timestamp|. Any uploaded document will have the file name
rewritten to a |new uuid()|. The |patient_attachment| table stores the
original document name in the |label| field (editable in the future).
The documents are stored on disk in a folder specified by the
environmental variable |UPLOAD_DIR|.

We will need to design a way to sync documents across radio networks
as well. Something like rsync https://en.wikipedia.org/wiki/Rsync
might come in handy there.

The server side API should support the following routes:

• |POST /patients| should allow an additional array of "attachments"
  (five maximum).
• |POST /patients/:uuid/attachments| should add attachments to the
  patient
• |DELETE /patients/:uuid/attachments/:uuid| should delete an
  attachment from the patient's attachments matching the provided ID.
• |DELETE /patients/:uuid/attachments| should delete all attachments
  from the patient entity.
• |GET /patients/:uuid| should return an |attachments| array on the
  patient object with ids for all of the entity's attachments
• |GET /patients/:uuid/attachments/| should return a list of patient
  attachments
• |GET /patients/:uuid/attachments/:uuid| should serve the
  attachment to the browser as a download.

On the client side, the |/patients/:uuid/edit| route should allow a
user to upload, remove, and show attachments much like patient groups
or debtor groups.

Interested in feedback on this @IMA-WorldHealth/local-contributors
https://github.com/orgs/IMA-WorldHealth/teams/local-contributors.

—
Reply to this email directly or view it on GitHub
#63.

from bhima.

I would favor user_uuid for simplicity with the rest of our database.

I agree, getting the initial uploading of documents should be the development focus. Once on the ground at PAX we can judge how strong the need is to share the scanned documents between locations.

from bhima.

In working on this, I think Patient Documents will make a lot more sense to our users. I'll be renaming this feature to Patient Documents, but implementing identical functionality.

from bhima.

Closed via #452.

from bhima.