Technical Level:  Easy

The following article contains steps which can only be configured in Team Admin by Clockwise support staff.  It is provided here for informational purposes.  If your clinic desires to have these settings enabled, please contact Clockwise Support for assistance.


ClockwiseMD can be configured to integrate with other electronic medical record systems.  One such system is Athena by AthenaHealth.  However, one of the challenges of allowing patients to self-register in any record system is the possibility of duplicate records, i.e., creating a new record when a record already exists in the current system.  This duplicate can come about for several different reasons:  a patient marries and changes her last name, moves and changes her ZIP code, decides to forego a landline and changes to a mobile phone, or uses a nickname instead of a legal first name.  However the duplicate occurs, it is in everyone's best interest to reduce or eliminate duplicates.  Not only can the duplicates cause extra work for back office staff to merge the duplicate records, but it can cause billing errors or non-payment if the patient receives bills under two names, and it may lead to providers mistreating or mis-prescribing if history is known for one patient record but not the other.

Clockwise has implemented several configurations designed to mitigate duplicates.  Each feature will be listed below and explained as to why it is important in the process.

Athena Best Match

In an attempt to mitigate these duplications, Athena uses a 'best match' API call (an API, or application program interface, is a set of routines, protocols, and tools for building software applications.  The API specifies how software components should interact - webopedia.com) to try and match the Clockwise patient to an existing Athena record if possible.  The best match API will attempt to match on four data elements outlined as follows:

•  last name
•  date-of-birth (DOB)

These first two are non-negotiable; they must be included in the match and, if they do not match, the match attempt will fail.

The third match, the first name match, can match on any one of three possibles, but must match on one of the three:

•  legal first name
•  preferred first name, i.e., a nickname, or
•  any first name (but this must have first been collected and entered into this field by the clinic/health system

The fourth match point can come from a pool of seven identifiers:

•  home phone
•  work phone
•  cell phone
•  any phone (but this must have first been collected and entered into this field by the clinic/health system)
•  e-mail address
•  Social Security number (SSN), or
•  ZIP code

It is required that the patient match on four data points...    but the data points must come from their respective pools:  last name, date-of-birth, one from the first name pool, and one from the other identifiers pool.  Having two from the other identifiers will not satisfy the lack of a match from, say, the first name pool.  However, in order to give the greatest chance for a match, a clinic may elect to capture more than one data element from the other identifiers pool, e.g., collecting a home phone number, a cell phone number, an e-mail address, AND a ZIP code might allow an overall match if one of those elements matched and another did not. 

EXAMPLE:  a patient's last name, date-of-birth, and first name match...   but they have moved and their ZIP code no longer is a match.  However, their cell phone number remained the same despite the move and if it is a match, it will provide the fourth data point and satisfy the overall match criteria.


This best-match API can be enabled in two different locations within Team Admin > Hospitals:

The first is for walk-in patients and is enabled by checking the box for 'Enable check for best match'.

Be sure and scroll to the bottom of the Hospitals page and click Save to preserve your changes.

The second configuration is for online patients and is enabled by checking the box for 'Enable check for online best match'.  Once this box is checked, you will also need to supply verbiage for the 'online duplicate message'.


Be sure and scroll to the bottom of the Hospitals page and click Save to preserve your changes.


Enabling Additional Name Fields (Middle Initial, Suffix)

Another common reason for duplicates is because patients will attempt to enter additional name elements, such as a middle initial or a suffix, into the first or last name fields, invalidating the name (since the Athena fields do not contain those elements).  To help guide patients in placing those elements outside the first and last name fields, it is helpful for Clockwise to provide fields for the middle initial and suffix so as not to have them invalidate the name fields.  But these fields are not enabled by default:  they must be turned on in Team Admin before they will be visible in the form.

The additional name fields are enabled in Team Admin > Hospitals by checking the box 'Enable extra name fields'.

Be sure and scroll to the bottom of the Hospitals page and click Save to preserve your changes.

NOTE:  these fields are NOT included in any best match effort nor used in any other validation attempt.  They are merely used to try and prevent patients from inappropriately entering the elements in the incorrect location.


Enabling Date-of-Birth Validation

If a patient misinterprets the date-of-birth field, perhaps mistaking it for 'today's date', he/she might enter in an incorrect date-of-birth which appears to be different from the original Athena record, thus creating a duplicate.  In order to help prevent this, Clockwise has the ability to prevent patients from entering a date that is less than a year past the current date.

The setting in Team Admin > Hospitals is called 'Validate DOB'.  Once this setting is enabled, one must also configure the 'minimum age' (in years).  Setting the value to '0' is the same as not enabling the validation, however, the setting may be set to a higher number of years if desired.

NOTE:  this validation setting may pose some issue if the clinic routinely sees infants who are less than one year old.  The clinic should weigh which is likely to pose more of any issue - invalid date-of-births or manually registering infants under one year in age - and configure the setting accordingly.


New/Existing Patient Status

One final consideration:  clinics which do not use Athena may freely elect whether to collect/use the 'new' vs 'existing' patient status.  It is sometimes helpful for clinics (and their marketing departments) to be able to ascertain whether they are driving new patients to the clinic via marketing campaigns and online registration.  However, if a clinic is using Athena integration, the clinic must use the new/existing status as there is considerable logic tied to the status which helps to determine whether the patient is a duplicate.


Should you have any comments or questions regarding this article, please e-mail Clockwise Support at support@clockwisemd.com or call 1-800-729-1363.