Saving records

The results from the submission of a form - called an encounter - is saved in the table associated with its form - if it's Delivery Summary, it's saved in the deliverysum table. When the record is serialised to a data file in the synchronization process, it uses a class closely associated with the form. for example, the Delivery Summary form has a class called org.cidrz.project.zeprs.valueobject.DeliverySum, These classes are dynamically generated by the Dynasite system in Zcore.

Note that each form class extends EncounterData, which implements BaseEncounter. The Encounters page in the Database Schema section has more information and a diagram about how encounters are persisted.

Encounters are saved in two tables - encounter and the table associated with the form, such as patientregistration. Metadata for the form is stored in encounter:

• id (which is the same id on the form table)
• patient_id
• form_id (this could be useful for teasing out the class or name of the form, if you're doing standard sql query)
• last_modified (timestamp)
• created (timestamp)
• lastModified_by (string - username)
• created_by (string - username)
• site id
• flow_id
• date_visit
• pregnancy_id
• referral_id

All of the data submitted in the form is saved in the form table (such as patientregistration). The column names of the fields in each form table are usually shortened versions of their labels on each form. Some of the column names in the ZEPRS application have the field id concatenated at the end. These column names are configurable in the admin section of the ZEPRS app.

Data is stored in columns according to their datatype in current Zcore implementations. Example columns from patientregistration:

• surname_6 - String
• birth_date_17 - Date
• education_st_11 - Integer

Important Methods for Record Persistence

FormAction is the action that persists most form data. Records that are saved from forms posted via AJAX are handled by the remote.Encounter class.

Some forms in ZEPRS such as Previous pregnancies form are recursive; therefore, they are forwarded back to themselves if the user presses "Next." Otherwise, the forms are forwarded to the next form in the flow, which is resolved by FormAction .createForward.

PopulatePatientRecord.saveForm is the first step in persisting a form. It create data structure to save form data to its table, save data (via FormDAO.create), run form through EncounterProcessor to see if it triggers any outcome exceptions.

FormDAO.create does the following (some of these steps are ZEPRS-specific):

• Initialize timestamp fields, create a transaction to ensure data integrity,
• Create/set eventId (pregnancyId in ZEPRS),
• Create the encounter,
• ZEPRS: Handle updates to patient_status and (if form 1, pregnancy)
  • Note the logic for which forms update currentFlowId and currentFlowEncounterId.
  • Do not update the current flow or encounterId if the form is from history, labs, ultrasound, uth, or unassigned flows.
• ZEPRS: Update pregnancy if this is observations or prob/labour form that triggers admission
• ZEPRS: Update referral status if this is a UTH-related form
• ZEPRS: Pregnancy conclusion form - creates a record in prevPregnancies
• ZEPRS: Extended Lab Tests - update extendedLabId in labtest table
• Update values in patient table (updatePatientValues) for dead, hiv, height.
• Commit transaction