Intro

In order to be seen by a doctor, patients need to complete some forms in the clinic. This is called "check-in for an appointment."
Forms can include some demographic information, information related to the reason for a patient's visit, medical history, and consent forms that they need to sign up for.

The check-in flow:

There is a step in the workflow where a receptionist selects the forms to be completed by a patient.

This step can be improved. 
The improvements imply developing the functionality that allows to define which survey or form should be displayed to a particular patient, in order to be seen by a doctor. The functionality is based on some rules, which have to be set up by the implementation engineer or clinic staff in advance.

The functionality will have a significant impact on the check-in process in a clinic since it will allow to:


  1. Reduce queues

  2. Provide individual approach for each patient

  3. Eliminate errors that might arise due to manual forms selection

Problems

Current flow is not ideal because it includes a lot of manual work that needs to be done by a receptionist who is busy doing other things at work.
It may cause human-errors and may not be very comfortable for patients, who may want to check-in by themselves using a phone or kiosk which can be placed in the reception area.


  1. Receptionist has to select surveys/forms for each patient manually, which is time consuming

  2. The lack of transparency when defining what exact forms need to be completed by a patient before they are ready to be seen by a doctor

  3. It is impossible to use self check-in functionality where patients could be checked in by themselves, without a receptionist involved

Business Opportunity

From a business perspective, new improved functionality may help clinics to reduce the number of receptionists needed, or reorganize their work to make them switch to more important tasks. Other opportunities include:


  • Decrease the duration of the check-in process, which will allow to accept more patients and increase clinic's revenue

  • Save receptionist's time by identifying surveys that have to be collected from a patient automatically

  • Reduce the risk of selecting the wrong forms or not selected the needed ones for a particular encounter

  • Support a kiosk mode for self-check-ins to reduce the load on the receptionist and to make the check-in process more convenient for a patient

Target Users

The functionality will be used by the implementation engineers or clinic staff who are responsible for clinic administration.

I assumed that the audience can be divided into technology savvy people who are used to complex functionality and may know some code syntax, and those who are not as savvy as the first ones.They may perform less complex tasks like uploading content.

Metrics

To measure success of the new functionality the following metrics were selected:

  1. The duration of the check-in process

  2. The number of times the pre-selected surveys were changed (to check if the rules were set up correctly from the first time)

  3. The number of self check-ins per a total number of check-ins per a clinic

  4. The number of check-ins done with the rules compared to the total number of check-ins

Research

By working with clients (clinics) in the early stages of the process, we defined what the rules may look like, what criteria they may include, and how several rules may work together. Regular rules and/or conditions may be written like this:

VisitType == "AppointmentVisitType.I" and (PrimaryFinClass == "PrimaryFinancialClass.TRICARE_OTHER_REGION" or PrimaryFinClass == "PrimaryFinancialClass.PSYCH_TRICARE_UHC" or PrimaryFinClass == "PrimaryFinancialClass.CHAMPVA" or PrimaryFinClass == "PrimaryFinancialClass.TRICARE_PRIME_UHC" or PrimaryFinClass == "PrimaryFinancialClass.TRICARE_EXTRA_UHC" or PrimaryFinClass == "PrimaryFinancialClass.TRICARE_FOR_LIFE" or PrimaryFinClass == "PrimaryFinancialClass.TRICARE_STANDARD_UHC" or SecondaryFinClass == "SecondaryFinancialClass.TRICARE_OTHER_REGION" or SecondaryFinClass == "SecondaryFinancialClass.PSYCH_TRICARE_UHC" or SecondaryFinClass == "SecondaryFinancialClass.CHAMPVA" or SecondaryFinClass == "SecondaryFinancialClass.TRICARE_PRIME_UHC" or SecondaryFinClass == "TertiaryFinancialClass.PSYCH_TRICARE_UHC" or TertiaryFinClass == "TertiaryFinancialClass.CHAMPVA" or TertiaryFinClass == "TertiaryFinancialClass.TRICARE_PRIME_UHC" or TertiaryFinClass == "TertiaryFinancialClass.TRICARE_EXTRA_UHC" or TertiaryFinClass == "TertiaryFinancialClass.TRICARE_FOR_LIFE" or TertiaryFinClass == "TertiaryFinancialClass.TRICARE_STANDARD_UHC")

It has the next limitations:

  1. Difficult to set up for a regular user (DSL syntax)

  2. Doesn't have other execution options except by priority

  3. Doesn't allow to see the whole picture, even to read the whole rule at once (it may be too long)

Solution

Although the rule initiates from the clinic settings page (which is where all the settings are located), it opens in a separate tab. The new flow looks like:

The functionality is located in a dedicated area, disconnected from other platform features, so the author of the rule won't be distracted while creating the rule.

Since I have an audience divided into 2 categories of technology savvy and not as savvy people I decided to create 2 modes for each of the categories - Visual mode and Advanced mode.  

Every mode has two parts: criteria and surveys.
In the first part, users should specify criteria, while in the second, users should specify the surveys that will be seen by patients who are aligned with these criteria.

Visual Mode

In a visual mode, there is a possibility to create as many rules as needed. They work as nested logical blocks with AND/OR conditions. Each block can be selected and grouped by the set of rules that can work with another AND/OR login.

There is a predefined list of conditions in a dropdown that was created based on data from the research phase.
The condition dictates the set of parameters for the next dropdown (for example age equal or more than 18 etc.).

Advanced Mode

In advanced mode, there are 2 input fields, where the user may enter an appropriate rule using DSL syntax.

In order to simplify the rule creation while using advanced mode, I suggest implementing a hint that will prompt the correct value.

The same for the surveys section.

All rules are consolidated in one table with a search field for quick access to the needed one and a call-to-action button for creating a new one. All the rules are listed in a table with its statuses (ON / OFF) and extra setting like whether the rule will apply in the order of priority or all at once.

Results

Compliance rules engine became the demand functionality due to its ability to be used in a plenty of use cases.

  1. The duration of the check-in process decreased from 5 min to 2 min which is significant

  2. The number of times that the pre-selected surveys were changed decreased to up to 2%

  3. The number of self check-ins per the total number of check-ins per a clinic was raised from 75% to 25%

  4. The number of check-ins done with the rules compared to the total number of check-ins increased by up 100%