Identification

Technical Specifications for the "Check-In" Module

Use

This module is designed to serve as a log of patients to be seen during a given clinic session. The module will display a list of all patients who have checked in, along with any “alerts” (indicating labs, procedures, or other notes to be further determined) relevant to that patient. This will serve as a sort of navigational “home-base” for many functions, such as

• determining the appropriate patient file if there is a conflict
• enrolling new patients
• printing Visit Planners
• entering Clinic Visit data.

User

Primarily used by Undergraduate Floor Manager (i.e. non-medical volunteer), who will be entering check-in and enrollment information as well as printing prepared visit planners?. Additional users include Medical students who will navigate to Patient History/Clinic Visit modules from this page.

Workflow

This module will be used primarily at the beginning of a clinic session or data entry session. Depending on the computer situation at each clinic, it is possible that the form will be used as patient’s check-in with clinic staff, or it may be used just after check-in has occurred. It is designed to be used before medical students start seeing patients, and to be the “home page” for workstations not in use.

Module Specs

The clinic location and date will be displayed at the top of the Check-In Screen. The date will be automatically generated; the clinic location will be selected at an earlier stage in the process. The top right corner of the page will feature a query field, but this will not be central to check-in procedure. Since this module is intended to be a “home page,” this search feature is available should a user need to look something up quickly.

Under the location/date header will be 2 free text fields labeled “Patient Name” and “Chief Complaint.” Users will input the name of the patient to be checked in into the “Patient Name” field in the style suggested by the text example below the field. As the user types in a name, an auto-completion script should run that compares what the user is typing with names already in the database and populates a dynamic drop-down that displays this information as the user types. The list should generate in the same way that the user has been instructed to type in the name; for instance, typing “Joh…” into the field should populate a list of patients with a first name of “John” not patients with a last name of “Johnson.” Pending live testing of the module, the entry style (first name last name) could potentially be reversed in further development, but this format will be suitable for the initial coding. If the name the user is attempting to type shows up in the generated drop-down list, the user may select the name from the list. The complete selected name would show up in the “Patient Name” field. Likewise, the user may type the complete name himself. Users may also enter the patient’s “Chief Complaint” if applicable, but only the “Patient Name” field is required to check-in a patient. To continue the check-in process, the user will select the “Check-In” button to the right of the 2 text fields.

When the user clicks this button, the system will add the patient of that name to the list for the night. The list should alternate colors for each patient entered to make divisions clear (shown above as gray and white). For a normal patient that is already entered into the system with no conflicts, the following information will be displayed (as seen above): Name, Birth Date, Unique ID, Chief Complaint (if entered), Alerts (if applicable), Actions, and the Visit Status.

The “Name” and “Birth Date” are entered into the system upon initial Enrollment; the “Unique ID” is also assigned at this time. The “Chief Complaint” field displays whatever was entered when adding the patient to the list that session.

“Alerts” will display any overdue procedures as determined by the client.

“Actions” are links available for the user pertaining to the patient. The default actions are: “Print Visit Planner,” which will link the patient’s personal Visit Planner (that includes alerts and updates to the patient’s history) for the session; “View Patient History,” which displays the information stored in the database regarding the patient’s medical history (as gathered from the Enrollment form and previous Clinic Visits); and “Enter Clinic Visit,” which provides a link to the Clinic Visit form where data from that day’s session will be entered and from which users can put in orders to pharmacy and make referrals.

The “Visit Status” will remain “Incomplete” until all data has been entered into the clinic visit form, at which point it will read “Data Entered.”

The above was for a patient with no conflicts. However, there are 2 cases of conflict in particular to be discussed here: 1) What happens when a patient is new and thus has not yet been entered into the system, and 2) What if there is a name conflict? (i.e. 2 different patients with the same name).

In the first case (New Patient), the patient’s name will be added to the log, but be highlighted in blue as shown above (color choice is of course flexible; the point is, these cases need to be marked somehow so that they stand out from the rest and bring attention to themselves). Additionally, the fields where “Birth Date” and “Unique ID” would be posted read “NEW” since there is no information to populate these fields with. A “Chief Complaint” may be displayed if given. The only “Action” displayed is “ENROLL,” which provides a link to the enrollment form where the patient can be entered in to the system. At a minimum, the patient’s name and birth date must be entered on the enrollment form before the patient can be added to the system. Once this information has been entered, the patient will show up just like a normal patient with the default “Actions,” and the entry will no longer be highlighted.

In the second case (Name Conflict), all entries in question will be displayed (i.e. all entries for the name queried). Again, the entry will be highlighted, but in a different color than the Enrollment conflict (the name conflict is shown above in red). All fields (except “Chief Complaint,” which will not be filled in until the appropriate patient has been selected) will appear for each conflicted entry. From this information, hopefully the conflict can be resolved. If not, the user may view the “Patient History” of each name in the conflict to resolve the dilemma. Once the appropriate patient has been identified, the user will select “Check-In” under “Visit Status” for that patient. At this time, the entry will again appear as normal, without any additional highlighting, with the default “Actions,” and with the “Chief Complaint” if applicable.

Last Note

There will need to be a “Log Off” or “Switch User” function on this page

Image