Digital Health Data

Real-World Data

Information gaps often arise between visits. Symptoms experienced several weeks earlier may already have been forgotten by the time of the next appointment. Additional data points from routine care can make these trajectories easier to trace while also expanding the body of real-world data.

Their value extends beyond immediate patient care. Unlike clinical trials with predefined protocols, routine care does not capture this information in the same systematic way. Real-world data can therefore help further develop products, prepare additional studies, or reassess previous assumptions.

Relevance for Pharmaceutical Companies

The additional data available are of considerable value to pharmaceutical companies, even if they do not automatically create a standalone business model. Economic effects may arise, for example, when therapeutic products are combined with digital companion solutions and can thereby be differentiated from competing offerings. Improved adherence can also be economically relevant.

In chronic diseases, some providers have already built more comprehensive ecosystems—for example, in diabetes, with continuous glucose monitoring (CGM) and automated insulin delivery (AID) systems. This can create competitive pressure for pharmaceutical companies: Those seeking to remain competitive or catch up in such an indication also need to offer corresponding digital solutions.

The direct revenue potential of digital health applications (DiGA) is likely to be relatively limited for large pharmaceutical companies. They can nevertheless be relevant for reputation and credibility and as a complement to the existing offering.

Regulatory Considerations

Regulatory requirements already apply to digital data collection in clinical trials. Regulatory classification becomes particularly important when an exploratory approach is developed into a specific application or becomes part of a therapy or product.

If an application is classified as a medical device based on its intended purpose, regulatory requirements need to be considered during development. Otherwise, redevelopment and validation may result in duplicate effort. Technical functionality and regulatory compliance alone, however, do not demonstrate clinical benefit. It should therefore be established just as early what evidence is required for the intended purpose, the target population, and the claims to be made.

Medtech: Device, Software, and AI

Many Medtech companies have traditionally had a strong hardware focus. Software has long been part of many products, but traditionally hardware-focused providers now need stronger software capabilities and closer integration of software into product development. The same increasingly applies to AI.

This is particularly visible in medical imaging, where AI has been used for years for pattern recognition and the analysis of imaging data. Major providers in the hospital market have long offered more than hardware: Their products are connected through software to hospital information systems and other systems. Many of these capabilities are technically available but are not yet used as efficiently or as broadly in practice as they could be.

Implementing Digital Health Products

A fundamental uncertainty remains when developing such products: Even a plausible digital health approach can fail years later. A digital biomarker may deliver good results in an initial study with a relatively small patient population. If the approach is then expanded to a larger study, the data may nevertheless fail to confirm the expected relationship. Such risks cannot be eliminated. They should be identified early and reduced across each phase of the project. This also means repeatedly reassessing the architecture, data collection, and analysis as the project progresses.

Whether a product is used successfully also depends on its actual context of use. An application may work well for patients and be user-friendly, yet still fail in implementation if it creates additional work for other stakeholders or cannot be integrated effectively into existing workflows. Their work processes and requirements therefore become part of product development as well. Workflow, user interface, user experience, and the specific value for relevant stakeholders can materially shape product design — even to the point where a different solution is needed from the one originally planned.

Scaling Across Markets and Platforms

Which stakeholders matter and how a product is used also vary from market to market. Health systems and relevant stakeholders differ substantially across Europe, the United States, and Asian markets. What works in the United States therefore cannot simply be transferred to other markets. Depending on the market, a different product or at least a different approach may be required. In practice, development may take longer and cost more than expected, while revenues fall short of initial assumptions. Product strategy should therefore establish early which markets are realistically addressable and how much local adaptation is required.

In digital health, large pharmaceutical companies increasingly think in terms of platforms that can support multiple applications. This comes with the expectation of leveraging synergies across different applications and indications. How far those synergies can actually be realized should, however, be assessed early. Even with shared data models, the domain-specific requirements of different indications may diverge to such an extent that harmonization becomes considerably more difficult.

Regulated Development and Validation

Technological expertise alone is not enough when implementing such platforms. Technology providers may be highly capable in cloud, software, and integration architectures but have limited experience with regulated development processes in the pharmaceutical industry. Requirements for audit trails, documentation, testing, or validation may then become apparent only at a late stage. Many of these are process requirements. Regulatory expertise should therefore be involved in development and architecture from the outset. For platforms involving multiple devices, sensors, and data flows, end-to-end traceability should be ensured and, where applicable, the data should be validated end to end to maintain data integrity. For AI applications, the points at which model controls are performed should also be defined. Model performance and changes to the model should be monitored throughout the product lifecycle.

Using the Opportunities Deliberately

Digital health data provides the foundation for clinically relevant, usable, and scalable solutions in research, patient care, and product development. Building them is far from trivial: the medical concept has to fit the actual use, the relevant market, and the technical and regulatory implementation. But when these elements come together, digital health data can create substantial opportunities — from a better understanding of disease trajectories and earlier identification of changes to applications that are more closely aligned with actual care delivery.