I always pay attention to the reaction I receive from an audience at a talk or individual I encounter when I discuss the difference between a tool and a solution. Marketing a technology as a solution before it has been trialed, integrated into clinical workflow or even an EHR can even be met with legitimized skepticism by an educated purchaser.
I offer a few thoughts on the subject which are critical for the development, adoption, and success of digital health technologies. These have been discussed in various other pieces I have written, but are focused here on the issue of technology as a solution.
1. Solve a specific problem. The Merriam-Webster dictionary definition of solution is: “Something that is used or done to deal with and end a problem : something that solves a problem.” It might seem obvious that a technology touted as a solution would solve a problem. Addressing specific concerns, whether they are workflow-related, clinical should be the driving force behind a technology. The problem should be one which requires bidirectional input so that metrics can be tracked and evaluated. This will facilitate identifying potential pain points from technical or human perspectives requiring improvement.
2. Give as much importance to processes as to technology. Technologies do not operate in a vacuum. Many digital health technologies (if not most) involve staff education, restructuring workflows, and perhaps rethinking human resource requirements. All of these considerations translate into new processes within which the technology will operate. Certainly this has been illustrated in the area of electronic health records. Some processes built around the technology have had both negative impacts (decreased physician/nurse efficiency and time with patients) and positive ones (billing, scheduling, e-prescribing). Given time, both the technology and processes will likely arise to improve upon the negatives.
Many of the pain points experienced in the implementation and use of EHRs are borne out of the fact that they were not developed with provider-patient workflow in mind and therefore do not offer a good user experience. This is due to the development addressing needs to satisfy regulatory requirements, not clinical issues. Other technologies will not be strapped with as much regulatory restrictions and have the freedom to create friendly and effective processes. It is up to many of us to demonstrate to physicians that EHRs are not representative of the rest of the digital health technology sector which holds much promise for achieving positive and honorable goals from both the provider and patient perspective.
3. Demonstrate positive outcomes. Most digital health technologies need not undergo long clinical randomized trials to demonstrate outcome. However, prospective studies looking at time efficiencies, user satisfaction, and eventually clinical impact are what a purchaser of a technology would not only demand but expect. The development process must include small trials in order to result in quality cost-effective outcomes for the company itself.The best time to collect data is from the beginning of implementation, even if it is a minimal viable product trial. This will be the best way to identify weaknesses and strengths of the product and processes. Until data is collected and the ROI (whether it be clinical, financial, or other type) demonstrated, a technology should not be called a solution. Business impact can be measured on strategic, operational, and tactical levels. According to the excellent book Measuring ROI in Healthcare, effective measures are: important, complete, timely, visible, controllable, cost-effective, interpretable, simple to understand, specific, collectible, team-based, and credible.
4. Create partnerships (doing whatever it takes) to solve the problem. Sometimes this is the most difficult part of the vision and execution of the project. Budgeting resources, whether they be financial or human is best accomplished by partnering with other entities which can contribute to the solution in ways otherwise not achievable. The partnerships might be in technical, clinical, or business development areas. They sometimes might involve strange business bedfellows. The production of a more robust offering (whether it be from a technical or strategic standpoint) is going to make it easier to get into a C-Suite or perhaps result in better process or clinical outcomes.
David Lee Scher is a cardiac electrophysiologist and a consultant, DLS Healthcare Consulting, LLC. He blogs at his self-titled site, David Lee Scher, MD.
