Backend support for draft forms/encounters

Development
18

Hello everyone, I know I’m late to the party but maybe have an interesting proposal.

I would propose persisting draft objects in an unserialized state. Any frontend module can dump draft blobs in JSON format to a /draft endpoint in some format like

#POST /draft
{
   module_name: 'form7',
   data: {JSON OBJECT}
}

being stored in table drafts with columns: [user_id (clinician, not patient), module_name, data]

and then retrieve data by calling GET /draft/{module_name}. When a clinician resumes working with a patient they can check the draft data and load up ui elements appropriately. When they save real data this goes through normal workflow as usual and /draft/{module_name} gets emptied with a DELETE

This has the advantage of 1. allowing the saving of unverified data if a clinician doesn’t have time to clean data to the point of database validation and 2. existing tables are left as-is, all data in those tables is always valid.

This technique could be extended to support encounters by adding an optional ‘encounter_id’ to the draft table and a query param in the GET like /draft/{module_name}?encounter={encounter_id} and a DELETE like /draft/encounter/{encounter_id}

Let me know if this is helpful

2 Likes