Website Forms

Most website forms do not require patients to check-in (authenticate); patients simply open the link, usually accessed from the clinic's website, to view and begin completing the website form. These unauthenticated website forms are convenient for basic intake form, such as a waitlist, vaccine notification report, or appointment cancellation request. However, since the agent accessing the form could be anyone on the Internet, the form itself knows nothing about the patient's information within the EMR/EHR, if any such information even exists. Furthermore, since the form author may have malicious intent, the form will not accept attachments. The form's submission will not interact with the integrated system until the submission is reviewed and "Accepted"" by the clinic in the Website Form Submissions app within the Ocean portal.

Due to these limitations, clinics may also configure a patient-authenticated website form link (PAWF for short), which requires patients to check-in before they can access the form. The check-in is designed to ensure that the patient indeed exists within the clinic system and that they know enough of their personal health information to serve as a basic form of patient authentication. These PAWF forms have the additional capability of allowing patients to upload certain kinds of attachments (mainly PDFs and image files) along with a secure message.

Sequence of Connections With FHIR Resources

1. Patient Check-In (Patient-Authenticated Website Forms Only)

The check-in process is similar to the check-in process for online booking. Once the website form link is opened in the browser, the patient is prompted to enter their the name, birth date, and health number, then click Check-In.

The check-in triggers Cloud Connect to search for a matching patient using the Patient endpoint:

• GET Patient?identifier=, where hn is the health number entered for the patient.

If no match is found, the patient is presented with an appropriate error. If multiple matches are found, the patient is also presented with an error. Ocean insists that the identifier match be unique in this case to avoid privacy risk of accessing the wrong chart. If a single match is found, CC validates that the birth date and surname match as expected. If either the birth date or surname are missing in the chart, the check-in will fail with an error.

2. Form Completion

Once the check-in completes, the patient proceeds to complete the website form(s). The form is configured within the Ocean portal. The form does not interact with the integrated system during the form completion process. If the form is a PAWF, the patient may also include a series of attachments (historically with a total maximum size of 10 MB)

Once the form is completed, its data is submitted to the "New" section of the Website Form Submissions section in the Ocean portal. No interaction with the integrated system is required at this stage (not even for PAWFs).

A notification email is sent to the clinic staff to review the form.

3. Form Submission Acceptances

Once the staff Accepts the website form submission, Cloud Connect attempts to link the submission to an existing patient within the integrated system. To do this, it first checks whether the form has a health number or equivalent identifier available. PAWFs will always have this identifier, since it is required as part of the check-in, as noted above.

Unauthenticated website form link submission may also have a health number, if the form(s) associated with the submission prompted for a health number (and this health number field on the form is appropriately tagged in the form editor as a "Health Number" field.)

If no health number is available within the form submission, Ocean does not attempt to send the submission to the integrated system (since there is no patient record available to store it). In this case, clinics may save the note for future use, or import it somewhere manually.

If a health number is provided within the form subnmission, Cloud Connect queries the integrated system as follows:

• GET Patient?identifier=, where hn is the health number entered for the patient (or equivalent identifier).

4. Patient Chart Creation

If there is no matching patient, Cloud Connect checks whether the Ocean site has been configured to permit the creation of new charts within the integrated system. If so, it creates a new chart with:

• POST Patient If this create-patient request succeeds, Cloud Connect expects to receive a status 201 "created" FHIR result, with a response header with key "Location" with value https://yourfhirserverBaseURL/Patient/[id]/_history/[vid] (based on the FHIR create standard ).

5. Form Completion

Once Cloud Connect has a Patient resource to work with (whether it was pre-existing or just created), it proceeds to make a series of updates to the Patient's FHIR resources based on the form data. Often this includes a subsequent PUT Patient call for more detailed information about the patient, along with a DocumentReference to store the form's summary note, and related resources such as Condition for the medical history. See the Form Completions section for details, since this patient update functionality based on form data is essentially the same across all Ocean products.

6. Patient Secure Message and Attachment Uploads

If the form submission was a PAWF and it contains attachments, Cloud Connect uploads each attachment as a separate DocumentReference, containing an attachment of type "application/pdf". Check the DocumentReference profile for more information.

• POST DocumentReference