Avoid common traps when developing technology for medical research

Most academic medical teams that we come in contact with are seeking technology to support a grant-funded project. While this funding can be key to furthering the field of medical research, it is not necessarily structured with technology design and development in mind. Grants are funded according to detailed applications from research teams which outline research objectives, methodology, and estimated budget required to complete a study. The problem is that in most cases, research teams do not have a dedicated in-house design or development resource to help scope the role of technology in a particular project. This means that researchers are often applying for funding without first validating technology budget estimates with a tech team.

The best partnerships between clients and technology partners arise when technology teams are given the flexibility to design an application from a human-centered, iterative perspective. Instead, bringing in external technology partners once a budget has been secured forces these partners to try to reactively find a solution to fit within the narrow scope and resources allotted. It may also lead researchers to select tech partners based primarily on their ability to deliver work at the lowest cost possible, which can result in a partnership with a less-specialized team that cannot anticipate some of the biggest issues that medical teams face. During a vetting process of possible technology providers, this creates an incentive for vendors to find ways to meet the predefined budget even at the expense of quality or implementation method. Software quality cannot be specified in the same way as traditionally procured goods and as a result, software buyers can sometimes be surprised by unspecified shortcomings associated with the software platform they have purchased.

Rather than beginning with a grant application and figuring out how the technology piece will fit within the budget later, it is best to consult a technical team as early as possible and conduct discovery user research work to understand the best way to leverage technology to meet a given research objective.

As described in the first challenge above, assigning a technology budget before speaking with a tech partner can result in a mismatch of resources and project needs. Typically, teams underestimate the cost of building custom technology, especially given all of the compliance and regulatory requirements for medical research that can add complexity to technical systems.

Another budget issue is that even if the upfront design and build costs are covered, there is rarely money set aside to cover the cost of ongoing maintenance and improvements throughout the course of a study. There is a common misconception that applications can be launched and then run for years without upkeep. But as participants or patients interact with a product, research teams will almost inevitably find ways to improve the application. There are also system updates that may be required based on new devices and technologies. Grant periods might run as long as five years: A typical cost of supporting a custom application or website over this time might be as much or more than the initial cost of actually building it.

Grant-funded research teams rarely have dedicated in-house designers or developers working on the project full-time. While this is not a blocker, it is important to keep in mind that a custom technology engagement requires a lot of close collaboration and detailed work. Principal researchers may find it challenging to dedicate the time needed throughout the design phase and may lack the technical expertise to sign-off on system architectures and third-party integration selections. While technology partners can fill this gap, a great deal of trust is required so that both sides feel comfortable that technology decisions will meet all project needs.

In many cases, there are also other stakeholders who must weigh in on the technology decisions in a given project including academic institution IT and security teams. These experts typically are not involved until late in the project, meaning that specific requirements or limitations may not be exposed until a substantial amount of work has been completed. Technology partners may not understand the full range of things they are responsible for (or will be asked to be responsible for) until meeting with these additional stakeholders and therefore scope and budget may be impacted.This can lead to significant unexpected scope addition late in the process after the technology team has largely concluded work.

Privacy of patient data is key in the design and development of any healthcare technology system. However, in the case of grant-funded research, there are often regulatory and compliance requirements beyond HIPAA. The Institutional Review Board (IRB) that reviews and monitors studies on human subjects in some cases has stricter requirements and levels of approval plus the grant itself may stipulate additional requirements.

In some cases, an academic medical center’s approach to technology may also pose limitations to system architecture. Health system IT resources are generally not like those typically used for modern product hosting (e.g. Windows servers are very different from Linux servers and modern platform-as-a-service providers). Products that must be hosted and regulated by health system IT teams may face additional unforeseen limitations or barriers.

The final—and perhaps largest—issue for research teams is the limited view of existing technology tools that can be used and modified for research purposes. Researchers who have a clear vision of what a piece of technology needs to do may think it’s simpler to build a tool based on those specifications rather than try to modify or cobble together existing tech platforms to suit the job. However, given all of the challenges described above, care should be taken to weigh whether bespoke technology is really the best solution for a particular study.

There are many ways to conduct research using existing low-code or no-code tools, which can dramatically reduce timelines, costs, and project risk. Using some combination of existing technology allows the research team to test their hypotheses in a nimble way. Study findings may inform a clearer vision of what’s really required to meet patient or provider needs, leaving the door open for custom technology at a later, more informed project phase.

In order to steer clear of common challenges or traps, researchers should spend time reflecting on the following questions before committing to a custom technology build:

1. What kind of analysis is required? In order to design a fitting system, teams need to first be clear and specific about the types of data required for analysis and how this data will be exported from a technology product.
2. What are the technology goals? Oftentimes, the goals of research data are different from—or even at odds with—application-level goals. For instance, the application itself may need to be as simple and streamlined as possible in order to increase usability and ensure adherence throughout a study. However, the level of data required for analysis may be incredibly detailed, requiring many time-consuming application tasks. Balancing these goals is key to the successful implementation of technology and the collection of good data. A database that is well-structured for application performance is not the same as a database that is well-structured for data analytics. This can lead to extensive data extraction work after the product build and release.
3. How much of the budget can actually be spent on product build? As discussed earlier in this guide, there is often little consideration for the ongoing costs of maintaining technology. Researchers should weigh the cost of the initial design and build, the ongoing maintenance, and all other project costs such as the time of research staff analyzing data or conducting research.
4. What other tools already exist to cut corners? Before deciding to move forward with a bespoke product, teams should complete due diligence to understand what other technologies already exist that may be much cheaper to use and maintain throughout a study. In many cases, a system can be stitched together using several third-party tools that meet research objectives at a fraction of the cost. CIAS, the Computerized Intervention Authoring System was developed exactly for this purpose. This saves resources for building a custom application later if research findings demonstrate a clear need. Technology partners can still be leveraged to help connect multiple third-party products, but the price tag will be much lower than building a similar system from scratch.
5. Who will serve as the technology partner for this project? It can be difficult for research teams to anticipate all of the costs and considerations associated with a technology system. If teams plan to outsource any technology work, it’s smart to find and select a trusted partner as early in the process as possible—ideally before even applying for a grant. This will allow both researchers and their technology partners to see around corners and more thoughtfully plan a system that meets their needs.

If you have remaining questions about how best to approach technology for research purposes, the HTD team is happy to weigh in. You can reach us at info@htdhealth.com.