Skip to content Skip to navigation

What's in a Name?

March 1, 2007
by Cynthia Centerbar
| Reprints
Clarity and common sense can go a long way when setting up master data files.

Have you ever been frustrated by a system's lack of user friendliness or perplexed as to why the data in a report you are looking at does not accurately reflect operational reality? Have you not realized your return on investment? It's possible your master data files are the root cause. How? Lack of data design.Cynthia centerbar

When implementing a system, it is common practice to spend effort designing screens, interfaces, conversions, workflows, and functionality, but much less common to spend effort designing the supporting master data files. As a result, the system's data often lacks a common format, contextualization, and organization. This lack of data design can lead to end user confusion, incorrect decisions, and unrealized ROI.

To illustrate, compare the following appointment type selection lists. Both are from small family medicine practices with OB/GYN services, and both use the same practice management system. Organization B designed their appointment type master data file while organization A did not.

Let's test our comparative lists using a business case scenario to see how design impacts outcome. Assume the scheduler for these respective practices receives a patient phone call from one of the practice's diabetic patients. The patient communicates to the scheduler that she was seen in the ER the day before because she was in a car accident and suffered a minor neck injury. The patient communicates that the ER physician instructed her to schedule an office visit with her doctor. She also communicates that she is due for her diabetic check up and desires to make one appointment for both problems. Assume you are the scheduler: Which appointment type would you select for: organization A or organization B?

For organization B, the appropriate appointment type is "OV-Two problems." For organization A, the appropriate appointment type is "Office visit 30 minutes." Even though you are not a scheduler for organization B, and thus have not had training on its system, you still chose the appropriate appointment type. The reason you were able to do this is because the appointment types for this organization are contextualized, formatted, and organized.

They are contextualized: they tell you, the end user, when to use them. They do this through consistent use of the words "new," "ob," and "physical exam." The appointment types have a standard format; each item has a prefix and the prefix is followed by a hyphen. The description uses proper case, which gives them a common look and feel and enhances their presentation. The appointment types are organized by visit types: new patient, physical exams, and office visits. These design elements result in a naming convention that enhances the user's ability to assimilate and understand the intended usage of each appointment type.

It is no surprise then that the downstream work is positively impacted. Staff members are correctly informed as to why a patient is coming. They accurately prep charts, rooms, and equipment, enhancing the overall efficiency and effectiveness of the practice. The reporting dependent on this data reflects the real world of the practice. The decisions made based on the report data are more reliable.

Soon after implementing a popular charge suspense application used to detect billing errors, the end users and managers at a large academic medical center were so unhappy with it that they were considering cutting their losses and deactivating it. The end users complained that the system was not user friendly, that they did not understand what the rules meant, and could not be expected to know how to fix the errors.

This lack of understanding resulted in an inability to efficiently process the rules triggered, ultimately resulting in an increase in A/R days. The organization as a whole did not understand how other like institutions had seen an ROI when it functioned in their view so poorly. A fulltime system manager was hired to evaluate and determine the appropriate course of action.

The system manager's evaluation revealed that the rule data (master data file) built by the organization was the source of the problem. The system itself was functioning correctly. The data was the problem. The problems with the data were many. The rules lacked a common format, there was inconsistent use of abbreviations, some rules stated a problem while others told the user to change something, some rules used cryptic language, others were not specific enough while some were too specific. Refer to table one below for examples.

The data was negatively impacting the business operations of this organization and preventing it from realizing ROI. The intent of rule two is to inform the user that the location entered on the charge is incorrect for the patient's type. In practice, when users encountered this rule, they interpreted the rule to mean that the patient's type needed to be changed, and inappropriately spent unnecessary time contacting the registration department, trying to convince them to change the patient's type.

Rule six was intended to be specific for just one of the organization's payers. Unfortunately the rule did not specify this. The users interpreted this rule to be true for all payers and began adding the LT or RT modifier inappropriately to like services. Ironically, this action caused more denials instead of fewer. The lack of data design actually caused the very problems the system was intended to prevent. No wonder this organization was disappointed with its investment.