Update a patientForm

processingStatus

the ID of the patient who filled out the answers for this form.

The completion status of the patient form under the patient's perspective, knowingly:

• pending: the initial status, not seen by the patient, created when a message is sent out with the form link;
• unstarted: set when the patient clicked on the link to open the form but only saw the welcome screen, without actually answering any questions;
• started: when the patient started answering at least one question, but hasn't finished the form yet;
• completed: the patient has finished answering all the questions and cannot edit the form anymore.

the date/time when the patient finished all the responses of this form.

The internal staff's management status for a completed form, serving the purpose of organizing which answers were analysed by a staff member or not.

• open: the form was completed by a patient but not seen by any staff member yet;
• in-progress: a staff user is analysing the answers;
• closed: the form has been completely analysed by a member of the staff team.

the ID of a staff user who analysed the responses of this completed patient form and changed its processingStatus.

the date/time when a staff user analysed the responses of this completed patient form and changed its processingStatus.

flag to signal whether a form was filled out in the shape of a patient chat with a bot.

the ID of an appointment related to this form.

the ID of a fileUpload related to this form.

the time it took (in minutes) for the patient to complete this form.

deprecated: custom patient form url, basically to identify any patient in survey monkey, an external forms service that's not being used anymore by Luma.

The code of the current question the patient was last shown, before answering it. Such a code must be the content of any responses.pages[0].questions[x].id, or success. Usually this will contain each id, in sequence, but patients can go back and forth. Also, forms can have jump logic, and some questions might not be displayed to the patient. When the form is completed, this is updated to success.

the ID of the template of questions that was displayed for the patient.

the name of the template of questions used as a basis for these form answers. See patientFormTemplates.

A flag to help filter forms by their originally desired purpose. The form structure and behavior is identical, but depending on the settings screen, some forms may be displayed as a selectable option or not. Also, CCDA forms enable some more form components/questions that are compatible with EHR systems nation wide.

• intake: a regular form, intended to be sent to patients manually, or in reminders, or even custom actions.
• pre-qualification: a form to be displayed before the scheduler is shown to patients. In the scheduler settings page, you can only select a pre-qualification form to be displayed before the patient actually schedules an appointment.
• feedback: a form to be sent to patients after their visits, to rate the service they've received. On the feedback settings page, you can only select a form with this flag.
• ccda: a form containing special questions that conform to the standard format which can be read by EHR Systems.

Indicates what this is about. Depending on this value, you also know what the parameter refId refers to.<br/>

• reminder (refId will be the ID of a Reminder)<br/>
• referral-reminder (refId will be the ID of a Reminder)<br/>
• feedback-reminder (refId will be the ID of a Reminder)<br/>
• followup (refId will be the ID of a Reminder)<br/>
• outbound-referral-reminder (refId will be the ID of a Reminder)<br/>
• form-reminder (refId will be the ID of a Reminder)<br/>
• reschedule (refId will be the ID of a Reminder)<br/>
• waitlist (refId will be the ID of a Waitlist)<br/>
• appointment-offer (refId will be the ID of a Offer)<br/>
• chat-notification (refId will be the ID of a Message)<br/>
• pin-verification (refId will be the ID of a Message)<br/>
• chat (refId will be the ID of a ChatActivity)<br/>
• chat-audit (refId will be the ID of a ChatActivity)<br/>
• chat-audit-tz (refId will be the ID of a ChatActivity)<br/>
• feedback (refId will be the ID of a Feedback request)<br/>
• waitlist-offer (refId will be the ID of an Appointment)<br/>
• referral-followup (refId will be the ID of a Referral)<br/>
• outbound-referral-outreach (refId will be the ID of a Referral)<br/>
• referral-redirect (refId will be the ID of a Referral)<br/>
• broadcast (refId will be the ID of a Broadcast)<br/>
• generic (refId will refer to the same object of the previous message to this same patient)<br/>
• stop (refId will refer to the same object of the previous message to this same patient)<br/>
• bot:followup (refId will be the ID of a Patient)<br/>
• telehealth (refId will be the ID of a Telehealth object)<br/>
• waiting-room-patient (refId will be the ID of a WaitingRoomPatient object)<br/>

The ID of the Object refereced by the ref field.

The ID of an appointment Offer related to these form answers.

The language in which the form was answered by the patient.

IP address of the patient who filled out the form.

PreviousPatientForm and nextPatientForm will be used to make it possible for forms to be able to jump to another form with another template so we can reduce the number of unecessary questions in a single form, which should help with organization and performance. One form must call the jump template, at which time we create a new patientForm and set the previous form ID on its previousPatientForm property.

PreviousPatientForm and nextPatientForm will be used to make it possible for forms to be able to jump to another form with another template so we can reduce the number of unecessary questions in a single form, which should help with organization and performance. One form must call the jump template, at which time we create a new patientForm and set the new form ID on the first form's nextPatientForm property.

Not used, and always filled with an empty string. Rather, see reponses.finalDisposition