KNOWLEDGENT WHITE PAPER. Microservice Architectures for Building Real World Evidence Applications

Transcription

1 Microservice Architectures for Building Real World Evidence Applications

2 The term real-world evidence (RWE) refers to information on health care that is derived from multiple sources outside typical clinical research settings, including electronic health records (EHRs), claims and billing data, product and disease registries, and data gathered through personal devices and health applications. RWE can inform product development, health economics and outcomes research (HEOR), patient care and quality improvement as well as monitor drug safety and adverse events. Use of the real-world data is increasingly important in both clinical and commercial context, as is evident from the increasing spend in HEOR studies, developing and adopting new models for clinical trials (e.g. adaptive, pragmatic randomized clinical trials), care delivery (e.g. pay for performance) and market access (e.g. value-based contracts). So how can current RWE application infrastructure support the onboarding of new business models? How RWE applications have been built traditionally RWE applications have been traditionally developed as a one-stop-shop, composed of a: user interface relational database with a number of tables in a central location, and a backend application responsible for the heavy lifting from handling HTPP requests to executing domain logic to populating views for the client-side component to render to the user interface all in very classic, monolithic application. In many respects, this is an entirely natural approach to software design as the monolith strategy keeps all of an application s code in one place letting developers take full advantage of the implementation language s tools for organizing large codebases (namespaces, classes, etc.), thereby allowing horizontal scale to be achieved fairly easily. This is attractive from a software engineering standpoint, as well as the fact that team members can reasonably run the entire application locally on their own respective machines. However, a monolithic application is not without its set of challenges: For one, the difficulty of maintaining a codebase in which developers can rapidly add new features in one part of the application without causing unintended side effects elsewhere grows with time The constraint of adding scale is an all-or-nothing proposition i.e. individual components can t be scaled independently The continued need to deploy the entire application each time a change is made Consider all of the above, and the monolith s downsides become obvious.

3 Furthermore, combining these tendencies with the heightened expectations placed on modern enterprise applications, particularly in this era of Big Data, even the most talented and experienced teams struggle to develop enterprise applications that meet stakeholders expectations without incurring significant technical debt along the way. This poses a roadblock for allowing engineering organizations to realize the full potential of RWE across a diverse array of teams and applications, both commercial and clinical. So, is there an alternative, better way? A functional approach to building RWE applications We propose the Microservices Architecture (MSA) as the best method for developing Real World Evidence applications in the Pharmaceutical, Life Sciences, and Healthcare industries. However, before examining the advantages of the MSA, we recommend examining its composite parts and their interactions. While there exists a number of different implementations of the MSA, each shares a common building block: the microservice that inherently has the following three properties that are consistently present across the majority of variances of the MSA implementations: It is a bare bones, lightweight implementation of a service that runs in its own process, It is built around a specific business capability, and, It is capable of being deployed independently from the broader architecture. A complete application is comprised of a number of these microservices, communicating with a central orchestration tool as well as with one another via lightweight, technology-agnostic protocols, such as REST APIs interacting over HTTP. To give a brief RWE example of such architecture, imagine a clinical team using a web app for cohort building that communicates with a separate service providing geographic analysis of patient populations via a REST API, and a commercial team using the same service s API to leverage geographic analysis for marketing purposes. So, why is choosing a MSA a better approach over choosing a monolithic architecture for building enterprise RWE applications? Rest API Geographic Analysis Clinical Team Web Cohort Building WebApp Rest API EMR, EHR Analysis

4 K N O W L E D G E N T W H I T E PA P E R Use of real-world data is increasingly important in both clinical and commercial context, as is evident in the increasing spend in HEOR studies, developing and adopting new models for clinical trials, care delivery, and market access.

5 Why microservices and how does it benefit RWE applications? We will examine the four primary benefits of the Microservices Architecture, identifying that the upside is the direct result of a particular difference between the two approaches. These four primary sources of upside are: 1. Simplified feature development and deployment 2. Scalability 3. Fault tolerance and isolation 4. Increased developer productivity Simplified feature development and deployment The modular behavior of the microservices reduces the complexity associated with making a given change to the application codebase. Rather than having to manage a potentially large collection of disparate pieces of functionality, a developer working with an MSA benefits from having to manage a smaller amount of code. This simplification, coupled with the complete independence of each microservice from its peers in the broader architecture, means that developers are insulated from causing unintended effects to other components of the application when they are considering making changes to their microservice. Also stemming from the MSA s inherent independence of components is the ease with which teams can deploy new microservices or make changes to existing ones, eliminating the lag between development and deployment that is often found on monolithic projects. The final factor driving simplified feature development tasks is that the latitude developers are able to choose the best tool, language, or framework for implementing their designated MSA. This property of the MSA is one which will likely not have much impact on most teams day to day operations, but when the standard methods are not applicable, one cannot overestimate the importance of being able to easily switch to an entirely different language, framework, or development pattern. For an RWE application, this is especially important, as typically the RWE requirements apply within a wide problem space with the possibility of leveraging multiple different analysis capabilities say across HEOR, EHR/EMR, OMOP standardization, etc. potentially developed by different vendors using varying technology stacks. The MSA reduces the likelihood of any kind of a vendor lock-in and increases the ease with which development teams can stitch together these multiple RWE products. This is meaningful because burgeoning challenges like RWE demand the ability to move quickly, leaving little chance to wait for vendors to update an entire traditional monolith application, to satisfy business needs.

6 K N O W L E D G E N T W H I T E PA P E R Unlike a monolithic application, the individual components of the Microservices Architecture can be scaled individually and independently as required owing to the decentralized nature and the fact that the components can be deployed and redeployed without affecting the integrity of the application. This fundamental shift in application scaling strategy provides a huge upside keeping in view the changing business and resource needs.

7 Scalability In addition to simplifying the development of new features, the MSA based application can be easily scaled up and down. Unlike a monolithic application, the individual components of the MSA can be scaled individually and independently as required owing to the decentralized nature and the fact that the components can be deployed and redeployed without affecting the integrity of the application. This fundamental shift in application scaling strategy provides a huge upside keeping in view the changing business and resource needs. Clinical and commercial teams could require different functionality from an RWE application, given the different objectives, and in order to adequately meet both group s demands, high quality RWE applications must be built with versatility in mind. While preparing for a brand launch, an RWE application would be able to meet the analysis needs by being able to scale effectively to better understand the market and patient landscape, and benchmarks for say patient adherence and therapy abandonment, patient cost sharing distribution through analyzing the product analogues in the market. This translates to building not just a wide array of features for each group s respective functional and scaling needs, but also the ability to reuse, recycle, and compose significant parts of the underlying codebase. The MSA inherently satisfies both of these requirements, while the independent microservices allow for the versatility to meet each stakeholder s business and analysis needs. Fault tolerance and isolation The next major source of upside offered by the MSA lies in how the architecture s composition of several different independent microservices naturally lends itself to facilitating the development of highly resilient, fault tolerant applications. In the monolithic style of software architecture, should one part of the system fail, then it brings the entire application down along with it. The MSA does not have this pitfall. Assuming proper implementation, the complete failure of one microservice will have no impact on the remaining components of the architecture. One or more microservices may fail, but the remainder will continue to remain available and fully functional. Additionally, this lends to simplifying the security monitoring, given the various components are isolated. A security issue could happen within one microservice; however, this will have no impact on the other functionality of the application. This benefit greatly reduces the risks associated with making significant investment in developing a cutting-edge, greenfield technology for an RWE application. Here the MSA compliments its numerous sources for significant potential benefit with the promise of hedge against some of that risk: if monoliths are slow to improve, they are even slower to fail, but the MSA, with its small teams, rapid development cycles, and characteristics facilitating rapid prototyping lets teams fail as fast as they can succeed.

8 Assuming proper implementation, the complete failure of one microservice will have no impact on the remaining components of the architecture. One or more microservices may fail, but the remainder will continue to remain available and fully functional.

9 Consider a hospital that typically would have an IT system that is outdated, but needs to support mission critical technology infrastructure to support patient care. An MSA based approach allows the IT systems to be updated without a single large big bang change, and new capabilities brought in a piecemeal approach. This also works well with the set of buyers who do not have an appetite for large changes or enabling deeper technology integration, and are not looking to invest as much in IT. An MSA approach would be easier to build, deploy, and to integrate with the outdated systems. Increased developer productivity The final upside is the increase in developer productivity that results from the sizable difference in magnitude between monolithic applications and an MSA based application a microservice will always be a smaller component than an entire monolith. Additionally, with an MSA, each microservice is developed and run as a unique process, usually managed with its own database. This decentralized approach to software building inherently provides several benefits such as the ability to: Easily execute on parallel workstreams where each team is separately responsible to build, test, deploy and manage the service independently Iterate faster on the overall software design Get new developers up to speed much more quickly In addition to the clear contrast in size, developer productivity is also boosted by the nature of the composition of development teams typically working on an MSA-based project. Rather than having individual team members dedicated to UX, backend, and database development respectively, MSA teams are cross-functional, self-sufficient units, closely in-line with Agile teams. How can Knowledgent help? The bespoke nature of a Microservices Architecture based software poses new opportunities for new entrants to enter this space and develop microservices as a product or a service for customers needing RWE applications built up. In both the technology and retail sectors, there are numerous examples where players like Netflix, Twitter, Amazon, Walmart, and other websites and applications evolved from monolithic to Microservices Architecture. This has allowed them to scale and meet the fast evolving business and consumer needs. We are currently engaged with a top biopharma manufacturer to help evolve their RWE infrastructure leveraging microservices, and set them up for the next level of growth within this space. Given

10 the functional application of microservices, the decentralized approach that reduces complexity and risk, both from a security and implementation perspective, as well as allowing to grow with scale, we strongly advocate for the use of the Microservices Architecture in RWE applications to help realize the value of the Real World Data for both clinical and commercial use. Sources 1. Food and Drug Administration. Use of real-world evidence to support regulatory decision-making for medical devices: draft guidance for industry and Food and Drug Administration staff. July 27, 2016 ( DeviceRegulationandGuidance/GuidanceDocuments/UCM pdf ) ga= ABOUT KNOWLEDGENT Knowledgent is a data intelligence company that innovates IN and THROUGH data. We eat, sleep, and breathe data to enable advanced and agile analytics, digital enterprise, and robotics. We combine our data and analytics expertise with business specific domain knowledge. We are Informationists that are passionate about data. New York, New York Warren, New Jersey Boston, Massachusetts Toronto, Canada For more information contact marketing@.com Knowledgent Group Inc. All rights reserved.