How & why to design for CLIA waiver

New technology platforms. Expanded test menus. Extended use settings. All of these have contributed to the robust growth of the Point of Care (POC) diagnostic market segment. Globally, this segment (including blood glucose monitoring) was valued at approximately $23 billion in 2016. Strong POC testing growth is projected to continue, with an estimated CAGR of 8 to 10 percent driving revenues to over $43 billion by 2021-2022.1,2

Demand will increase for POC offerings targeted at the needs of retail and urgent care clinics, primary care physician offices, assisted living facilities and patients at home. Key drivers include the need for rapid results in certain medical situations, the ability to test and treat patients at the time of care and expanded patient population reach. As testing situations move closer to the patient, achieving CLIA waiver is becoming increasingly necessary for instruments to successfully address the expanding POC market. With this drive to CLIA waiver, IVD manufacturers are faced with the challenge of addressing the associated product design and development requirements for simple and error-free use.

The question becomes “How should manufacturers approach product development for CLIA waiver?”

Demonstrating simplicity

The first step in achieving CLIA waiver is to demonstrate that the test is “simple,” described by the FDA as meeting certain criteria, including:

  • Analysis on a fully automated or self-contained device
  • Using a direct, unprocessed specimen
  • Requiring “basic, non-technique-dependent” specimen and reagent handling
  • No need for operator intervention during sample analysis
  • No special training necessary for troubleshooting or understanding error codes
  • No maintenance demands beyond changing a battery or power cord
  • A result that is easy to determine and requires no interpretation

A key component of a device being simple to use is a design where there is an insignificant risk of an erroneous result in the hands of the intended user at the intended use sites. The need to design for this level of simplicity calls for simultaneously considering both the user and the context of use. This entire product use case should be considered from the very start of the product development process. Development should focus not just on the main operational mode (e.g., how a user inserts a microfluidic cartridge and reads the result on a screen), but also on how the device ensures an accurate and error-free result.

Designing for simplicity

Below are some key considerations for successfully developing a CLIA-waived POC device based on our experiences.

1. Consider the user beyond how they will interact with the device.

The scope of potential user capabilities and limitations needs to be addressed as a key design input, along with demographics and physical characteristics. Taking the vision and manual dexterity of anticipated users into account, for example, will have implications for the selection and positioning of a touchscreen, as well as its overall dimensions and ability to display the necessary data. Thought needs to be given to make sure any instructions or results are in resolutions and font sizes that are legible and easy to execute. Colorblindness is another factor affecting how results are depicted; red-green readouts call for an additional differentiator. Any symbols or icons should be clear in their meaning in light of user demographics as well as cultural or regional differences. Sample collection and handling consumables should be designed for use by either right-handed or left-handed operators.

2. Evaluate the entire test workflow, from the user handling the packaging to the number of consumable components.

Starting with the test cartridge or consumables in their packaging, examine each testing step and how it would be implemented. For example, how does a user wearing gloves open the protective packaging and remove the consumables without putting them down on a table or counter and risking potential contamination? When and how is the sample introduced? Each step should require little to no training to be performed correctly. In arriving at what would make a test simple, it is best to start with a range of options, then narrow these down to the optimal solution. A very good starting point is to use tools and mechanisms that are familiar to non-medical professionals, such as pistol or pen grips, as the basis for design. In the case of packaging, different ways to design for ease of use might include a consumer-like plastic tray with a foil pouch inside or a peel-off sticker.

3. Minimize sample handling.

One area of the assay workflow where this can be achieved is at the sample collection stage. An option is to design a single sample collection component that also is used for sample transfer. It might take the form of a finger stick lancet modified to include a capillary tube for wicking up the sample, followed by direct insertion into the assay cartridge or reader device. Using one consumable for multiple tasks in the workflow both simplifies the operation and helps reduce the risk for contamination.

4. Reduce or eliminate the need for introduction of reagents.

Along with reducing the total number of moving parts, building these mechanisms directly into the assay cartridge gives users one less step to manage. Automated introduction of reagents within the cartridge itself removes any need for the user to manage correct sample processing.

5. Start with a blank slate for the user functionality.

Then ask the question “What operations does an untrained user need to perform that cannot be automated?” There can be a natural tendency to begin with full functionality and decide what to remove. Progressively adding user functionality helps keep the device simple to use.

6. Allow users to choose what to do, but not how to do it.

Limit users to a choice of which high-level action to take, such as “Run a patient sample.” From that point, use guided user workflows to walk the user through a fixed set of steps, requiring no further decision making on the part of the operator; the device program will take over and prompt any user actions (e.g. “Insert the cartridge”), ending with assay results. The step-by-step instructions and anything that a trained user would know is embedded in the instrument’s operational programming. In doing so, workflow rules are enforced, and judgement calls typically allowed with trained users are not required. A key development step is to first work out in a laboratory setting each of the workflow steps and what a user would minimally need to do under a CLIA waiver scenario.

7. Strive for clear communication.

Labeling and test instructions should be pitched at a seventh-grade reading comprehension level, with visuals and words clearly and unambiguously conveying what needs to be done. In developing user interface screen messages, the following questions need to be answered:

  • What sequence of steps should the user be taken through to ensure a simple and consistent operation?
  • How should the user be prompted?
  • What should those prompts be?

Instructions should be in a “show and tell” format, making sure that the visuals such as photos or embedded video support the text; local language should also be taken into account. The system also needs to confirm that the action step has been completed and was successful. Process confirmation is a key part of the technical design to guarantee simplicity and insignificant risk of error.

8. Less is more with result reports.

Similar to the principles behind guided user workflows, keeping the report to a minimum, irrespective of how easy that information is to understand, helps control testing outcomes. Doing so provides the user with only the needed output and avoids any effects from data “clutter.” Result readouts can be tailored to the context of use. For example, in a physician’s office the informational output might be a physical printout along with electronic data transfer. In a situation like this, no results would be displayed on the operator’s instrument screen other than the test has been completed, or there was an error and no result. At that point, the tester would be instructed what to do next such as “Alert the ordering physician.” In the case of home use, results would be displayed in some form of a clear “yes” or “no.”

Conclusion

A CLIA waiver requires that a device is simple to use and carries an insignificant risk of an erroneous result in the hands of the user at the site of use. Successfully achieving this calls for incorporating that user perspective throughout the entire Point of Care product development process. The optimal approach to gain those insights and feedback is by engaging in experience design, observing and interacting with users in the actual settings where the device will be used. This provides objective, real world assessments of user needs, skill sets and work flows to inform initial product designs.

Continued testing of iterative designs with representative users allows for observing what users might do and using those findings to uncover best solutions. Trial work should span the entire workflow and include both patients and operators handling mock ups of consumables including any packaging. Refinements can continue to be made throughout development to arrive at a device that is as simple as possible to use. The result will be a POC test that aligns with CLIA waiver requirements, but also provides a positive user interaction through ease of use and elegant design.

White Paper: User-focused Product Definition for IVD Market Success

In this white paper, we explore how a user-focused product definition approach can help IVD manufacturers deliver winning product solutions that earn the approval of users by addressing the real problems they face.