Doctors and medical staff can save money and time by creating their own online forms for patients to fill out, thanks to a startup’s app developed by an AOT team

Modern healthcare can be an expensive, complicated affair. What if there was an app to cut costs, speed up the process, allow doctors and staff greater flexibility, and give patients more options?

Using a low-development approach and its array of global teams, AOT Technologies is doing just that by building a Vancouver-based startup’s modern telehealth app in record time—and on a tight budget too.
This is the story of saving time and money to build an app that saves time and money.

A Modern Telehealth App

AOT Technologies has been working closely with the client to develop a comprehensive clinic management and telehealth solution with extensive support for Oscar EMR, a leading system for managing electronic medical records.

AOT’s solution is creating an easy and flexible interface to help patients arrange appointments and review medical records using a single login.

Patients can also use the app to make a range of appointments: a remote consultation by video chat or phone, or an in-person consultation either with their general physician or another doctor based on availability. The app helps patients keep track of clinic visits and history as well as prescriptions, all of which are stored digitally.

On the doctor’s side, the app is integrated with Oscar EMR, an open-source solution built by doctors for doctors, and popular throughout the Canadian healthcare system. AOT’s app helps doctors manage patient appointments and records.

A Low-code Platform to the Rescue

Because patients can book appointments for various reasons, the app we developed had to offer a variety of questionnaires to cover the condition and history of different kinds of patients. Unfortunately, in the beginning the development team had to spend around 30 to 40 hours to program each questionnaire, and each questionnaire might later have to be modified, again requiring a lot of programming time and effort.

Clearly a better solution would be one that took less time and effort, and even bypassed the need for developers when creating or revising these questionnaires. The solution the AOT Technologies team took was to use a low-code approach that would allow questionnaires to be fully managed by office staff or by doctors themselves. We decided the low-code platform engine we were developing should have the following features:

• Easy drag-and-drop form construction
• Options to add features such as data validation, default values, conditional display, and custom JavaScript code
• A minimum of coding not just for form construction but also form management
• Alignment of new forms with the existing healthcare app’s custom CSS and theme
• Custom components to meet the special requirements of doctors and clinic staff
• Ease of use

To solve the form-design challenge, the AOT Technologies team chose Form.io, a low-code platform we were already familiar with, having integrated it into our open-source forms-and-workflow solution formsflow.ai.

Creating the Interface

The interface for building and managing forms was a central feature of our project. We needed to let the business user see a list of all questionnaires and be able to edit the forms as requirements changed. Patients would need to navigate through various questionnaires and steps depending on their medical situation, and be able to provide basic details and history. Then the app would need to set up appointment times and provide the patient’s details to doctors at those appointments.

At the start, incorporating all these features seemed like a mammoth task, but as Desmond Tutu once wisely said, “There is only one way to eat an elephant: a bite at a time.” So let’s go through the work step by step.

Step 1: Building and Using the Form-design Interface

First the AOT team built a form-design interface so doctors and clinic staff could create the questionnaire forms. For the basic view we selected just some of Form.io’s Form Builder components so we could keep the drag-and-drop interface simple enough to not overwhelm the designer.

If the designer requires more features, the form-design interface also offers an advanced view with more form components available including some tailor-made component interfaces.

Whether using the basic or advanced interface, clinic staff and doctors can choose the app’s designer role in order to reach this interface and easily design forms on their own.

Component Options

Each component in the form can be customized using new CSS or existing themes provided by the app. We also created some tailor-made components to make sure they too were available for drag-and-drop design.
In this example, we see the design interface for a text field, allowing us to work our way through options such as changing the component’s label and style, adding validation, and setting conditional rendering.

Custom Components

A very useful feature of Form.io is the ability to create a new component that can later be used in form design by extending the base class of a similar component, perhaps by first modifying the existing component’s default settings. You can define custom logic by modifying the base class’s methods or by creating a new method. To define a component it’s very important to understand the methods you can use. Form.io provides a useful page on custom components if you’d like more information.

In our project we knew the client wanted a component that would convert a comma-separated list into what was essentially a group of checkboxes, as shown in this example:

Once completed, this custom component could then be combined with other components, such as toggle switches, a text box, and another instance of the custom checkbox component, to allow patients to explain their reasons for the appointment and describe their symptoms:

Coding the Custom Component

Every custom component should be derived from the base class most similar in behavior to that of the component you wish to create. You can then extend the component by using the Form.io renderer. (See a list of all of these components and their classes and Form.io’s instructions for extending components.) In this case we started by defining our list component (called “List”):

const JSON_LIST_COMPONENT_OPTIONS: FormioCustomComponentInfo = {
  type: 'jsonlist',
  selector: 'formio-json-list',
  title: 'List',
  group: 'advanced',
  icon: 'fa fa-list-alt',
  editForm: jsonListForm,
};

Although Form.io offers extensive configuration options, we first reduced our tabs and fields to a minimum so we could more easily create our custom component. We then specified the meta settings for the Form.io component, including data validation and the use of custom options to allow multiple selections and comma-separated values:

function jsonListForm() {
  return {
    components: [
      {
        weight: 10,
        type: 'textfield',
        input: true,
        key: 'key',
        label: 'List Name',
        placeholder: 'List Name',
        tooltip: 'The code/key/ID/name of the list.',
        validate: {
          required: true,
          maxLength: 128,
          pattern: '[A-Za-z]\\w*',
          patternMessage:
            'The property name must only contain alphanumeric characters and underscores, and should start with a letter character.',
        },
      },
      {
        label: 'Allow multiple selection',
        defaultValue: false,
        key: 'customOptions.isMultiSelection',
        type: 'checkbox',
        input: true,
      },
      {
        weight: 10,
        type: 'textarea',
        input: true,
        key: 'customOptions.commaSeperatedValue',
        defaultValue: '',
        label: 'Comma separated list items',
        tooltip: 'Comma separated list items',
        placeholder: 'Comma separated list items',
        validate: {
          required: true,
        },
      },
    ],
  };
}

Once we created our custom component we registered it with the particular formio.js package we used—in this case the angular-formio package:

import {registerCustomFormioComponent} from 'angular-formio';
export function registerCustomComponent(injector: Injector) {
  registerCustomFormioComponent(
    JSON_LIST_COMPONENT_OPTIONS,
    FormioJsonListComponent,
    injector
  );
  registerCustomFormioComponent(
    SWITCH_COMPONENT_OPTIONS,
    FormioSwitchComponent,
    injector
  );
  registerCustomFormioComponent(
    DATE_DROP_DOWN_COMPONENT_OPTIONS,
    FormioDateDropDownComponent,
    injector
  );
  registerCustomFormioComponent(
    FILE_UPLOAD_COMPONENT_OPTIONS,
    FormioFileUploadComponent,
    injector
  );
}

So we’ve seen how doctors and clinic staff can create their own forms, and how the AOT Technologies team customized components to use in such forms. Next we’ll look at how the app lets doctors and clinic staff edit and view these forms.

Step 2: List, Display, and Edit Forms

From a list of questionnaires already created staff can choose which ones to publish using an on/off radio-button interface. They can also view each form from the patient’s perspective by clicking the view button (displayed as an eye icon). If changes are needed, the staff member can click an edit button to bring up the Form Builder UI. Here’s a list of available questionnaires with the diabetes questionnaire previewed on the right-hand side of the screen:

 

The process to edit a questionnaire is essentially the same as the process for creating a questionnaire, and uses the same interfaces, except that the initial view shows not the default design but the previously saved design. Here we see the current design of a diabetes form ready to be modified:

Step 3: Filling Out a Form

Returning to the patient view, here’s the bottom half of the questionnaire we saw earlier. Again we can see the use of toggle switches, multiple-selection checkboxes, and text areas for users to provide an answer in their own words.

After the patient clicks the “Complete Questionnaire” button, the information provided can be made available to doctors and staff.

Step 4: Doctor’s View

Using the app, the doctor can view appointment notes and information from patient questionnaires. Submission APIs can tailor the view provided to the physician. The doctor saves time as much of the patient’s medical history and presenting symptoms is already filled out, and the doctor has the option to select additional questionnaires for the patient to complete if needed.

Conclusion

The healthcare app we’ve worked on here at AOT involved two kinds of speed boosts: the goal of the app was to speed up the appointment and patient-history process and the goal of development was to use a low-code approach to put programming power into the hands of staff. I believe we’ve already made tremendous progress on both fronts, as we’ve created a system that lets patients fill out questionnaires ahead of time and make appointments at their convenience, while staff and doctors are freed up from some of the more mundane and time-consuming tasks leading up to an appointment. To top it all off, doctors and staff can create and modify questionnaires quickly and efficiently as new circumstances arise. I believe this project has amply reinforced both the philosophy behind a low-code approach and confirmed the benefits to developers themselves as they work to complete a variety of projects.

 

About the Author

Abhilash K R is the technical lead at AOT Technologies currently heading the team in India developing formsflow.ai, an open-source, low-code forms-and-workflow solution. He is a full-stack developer and JavaScript wizard with over eight years of experience in technologies such as Angular 1.x, React, Angular 2+, Node.js, and Ionic. He loves travelling and getting into gaming when not in the coding hood.