Electronic Health Records for Clinical Research Executive Summary for deliverable D6.1: Definition of the PFS services (requirements, initial design) Project acronym: EHR4CR Project full title: Electronic Health Records for Clinical Research Grant agreement no.: 115189 Budget: 16 million EURO Start: 01.03.2011 - End: 28.02.2015 Website: www.ehr4cr.eu The EHR4CR project is partially funded by the IMI JU programme Coordinator: Managing Entity:
Document description Deliverable no: D6.1 (executive summary) Deliverable title: Initial EHR4CR architecture and interoperability framework specifications Description: First deliverable of Work Package 6 Status: Final Version: 0.2 Date: 30/07/2012 Deadline: Editors: Isabelle Stévant Document history Date Revision Author(s) Changes 29/06/2012 0.1 Isabelle Stévant Initial draft 30/07/2012 0.2 Isabelle Stévant Final version Table of Content 1. Recap of PFS scenario... 4 2. Recap of WP6 objectives for PFS scenario... 4 3. Interdependencies... 4 4. Service definition... 5 5. State of the art... 6 5.1. Project similar to the PFS scenario... 6 5.1.1 DEBUGIT... 6 5.1.2 I2B2/SHRINE... 6 5.1.3 FARSITE... 6 5.1.4 EPCRN... 7 5.1.5 STRIDE... 7 5.2. Formal representation of eligibility criteria... 7 6. PFS end user services : constraints to be considered... 8 7. Functional architecture of PFS end user services... 8 8. Graphical user interface of PFS end user services... 9 8.1. Authentication... 9 8.2. User home page... 9 8.1. Feasibility studies list page... 9 8.2. Feasibility study workbench... 9 8.3. Query management... 10 Executive Summary for deliverable D6.1 Page 2 of 12
8.4. Query builder... 10 9. Conclusion... 11 Executive Summary for deliverable D6.1 Page 3 of 12
1. Recap of PFS scenario One of the first steps in the design of any clinical study is determining the feasibility of the protocol to be executed. There are two main components to this feasibility a) optimize the inclusion and exclusion criteria to ensure that the underlying patient population from which the study will recruit is sufficiently large, and b) technical feasibility, ensure that each site can enroll patients and support a clinical study. There are often many iterations surrounding the choice of inclusion/exclusion criteria, and changes here not only affect the base population, but can also affect the scientific design of the study. Therefore, the overall goal of this task is to demonstrate that the EHR4CR platform can provide reliable answers to the following questions: Do the inclusion/exclusion criteria suggest that a site is a practical location to run a clinical study? What happens when inclusion/exclusion criteria are changed? Which are the most appropriate sites for pursuing a study within a disease area? 2. Recap of WP6 objectives for PFS scenario The objective of this WP is to design and implement end-to-end solutions (tools and services) that address the requirements of the different EHR4CR scenarios (clinical trial protocol feasibility, patient recruitment, clinical trial execution and drug safety monitoring). This Work Package is built on the semantic interoperability services (WP 4) and the data protection services (WP 5) and will comply with the EHR4CR architecture (WP 3). WP 6 specifies the technical process flows based on the detailed WP 1 scenarios and implement them based on generic components delivered by the other technical WPs on the EHR4CR architecture. The initial description of works for the PFS scenario contain the following tasks : Clinical Trial Protocol Feasibility Services (PFS) Eligibility Criteria Authoring and Management Services (CAMS) Data Presentation and Visualization 3. Interdependencies In this section we will describe what exactly we want to achieve in this document and how it relates to the other Work Packages. We can use the Figure 1 to clarify this and build some consistency with the Architecture Document (WP3 Deliverable D3.1). The Architecture Document is built around requirements, constraints and specifications provided by several Work Packages. WP1 provides the stakeholder analysis and functional requirements for the architecture WP2 describes the business environment in which the architecture has to be positioned. Executive Summary for deliverable D6.1 Page 4 of 12
WP4 provides the information view for the Architecture WP5 provides the information security and privacy requirements and constraints for the architecture WP7 identifies the set of clinical data elements (coming from the EHRs), the data elements to represent eligibility criteria. WP7 identifies the current status of local infrastructure WP6 will define the Service Specification based on the system architecture provided by WP3. 4. Service definition Figure 1 Work Package Relationships and Deliverables The approach for defining the EHR4CR PFS Service is as follows: 1. Define the service expectations from an End User perspective. These expectations should be derived from the EHR4CR User Requirements (WP1). Important though it is that we consider the trade-offs between quality and cost we need to be able to articulate how the service will be affected by changing any of the capability tolerance (e.g. instead of having a system available 24x7, what would be the impact of having it down during the weekend). 2. The Service Expectations have to be translated into Service Capabilities. Although the main interface between the End User and the system will be the GUI we need to look at more than purely the usability of the GUI. We will look at re-usability, reliability, performance and cost as well. 3. Next, the Service Capabilities will have to be translated into a service offering. This will be done through a Service Catalogue. The Service Catalogue will present the PFS service to the End User as a set of Billable Units. These billable units will have to be defined after the technical platform architecture has fully been developed. Only then we will be able to differentiate between one-time service units, recurring service units, and mandatory and optional service units. Executive Summary for deliverable D6.1 Page 5 of 12
4. Finally, for all service components we can define Service Levels. It will be important to define how we will deal with Service Level Agreements. 5. State of the art 5.1. Project similar to the PFS scenario 5.1.1 DEBUGIT The DebugIT (Detecting and Eliminating Bacteria Using Information Technology) project aims at providing a fully semantic compliant IT infrastructure to share antimicrobial resistance information from healthcare institutions spread across Europe. The ultimate goal of the project is to help in the fight against increasing antimicrobial resistance with innovative solutions derived from advanced information mining methods. The main end users of the DebugIT system are public health agents, infectiologists and physicians. 5.1.2 I2B2/SHRINE The Shared Health Research Information Network (SHRINE) helps researchers overcome one of the greatest problems in population-based research: Compiling large groups of well-characterized patients. Qualified investigators may use the SHRINE web-based query tool to determine the aggregate total number of patients at participating hospitals who meet a given set of inclusion and exclusion criteria (currently demographics, diagnoses, medications, and selected laboratory values). These functionalities relate primarily to EHR4CR scenario 1 (protocol feasibility), which requires only access to aggregated, de-identified data. 5.1.3 FARSITE FARSITE offers support for Protocol Feasibility and Patient Recruitment. It provides an interface for easily building up protocols to identify cohorts of patients within an anonymised dataset and integrates with a service for identification of patients for clinicians. It is able to query against primary and secondary care data sources. It does not currently include an API for federated querying of the type required for EHR4CR, however the Executive Summary for deliverable D6.1 Page 6 of 12
current restful design could be adapted easily to accommodate a wider service-oriented architecture. FARSITE is also not currently able to query against non-coded or free text information. 5.1.4 EPCRN epcrn is currently a solution for protocol feasibility AND recruitment. At present the trial data management functionality is incomplete (it will be taken forward via TRANSFoRm). The software also offers an example of how to incorporate a semantic and model-based bridge between heterogeneous data sources as both the terminology service and the data model requirements are modular and dynamically driven. The query builder is based on a criteria pattern approach. The user can instantiate a criteria and put constraints on values. The system automatically generates a human readable statement. 5.1.5 STRIDE STRIDE (Stanford Translational Research Integrated Database Environment) is a research and development project at Stanford University to create a standards-based informatics platform supporting clinical and translational research. Stanford researchers can search the CDW to identify potential research patient cohorts using a self-service visual query tool called the Anonymous Patient Cohort Discovery Tool. This Java application uses an intuitive drag and drop interface to create and execute queries in real time, answering the question does the STRIDE CDW contain a cohort of patients with these attributes? No individual patient data is exposed by this tool and binning is used to prevent identification of individual patients within small cohort sets. All research patient cohort searches are logged for audit purposes. Patient cohorts of interest can be saved within the central STRIDE system for later use in IRB- approved chart review or research data set extraction. 5.2. Formal representation of eligibility criteria Eligibility criteria are usually written in free text to be human-readable; therefore, they are not amenable for computational processing. One important contribution of the EHR4CR project, is to be able to query clinical data according a set of eligibility criteria originally described in free text. In the current process of clinical research, the interpretation of the free text representation is made by the PFS experts, or by the investigators who check with the patient data, if a population or individuals match or not match each criterion. Executive Summary for deliverable D6.1 Page 7 of 12
As the scope of the project is to reuse the data contained in the EHRs, a computable knowledge representation for eligibility criteria is needed to convey unambiguous logical statements to provide decision. Many formalisms exist. They are listed in the WP4 deliverable (D4.1), and among them, ERGO seems to be one of the best candidates. At the time of writing this deliverable, the WPG2-team had not made a final choice for EHR4CR. 6. PFS end user services : constraints to be considered The PFS end user services (PFSeus) have to take into account different types of constraints that are explored by the different work packages of the project. Prior to a final decision being made on the exact nature of these constraints the WP6 team has made some assumptions regarding the functionalities of the PFSeus. However, the core functionalities of PFSeus (the query workbench) is well identified and defined. Below, we summarize the different constraints and issues that PFSeus has to deal with. In the project, the global method of the software development is to deliver iterative versions of the services. We expect that these constraints (especially the business model) will be gradually refined during the project time. Requirements (WP1) Ethical aspects and business model constraints (WP2) Architecture (WP3) Security (WP5) Semantic interoperability (WP4) Pilot sites (WP7) 7. Functional architecture of PFS end user services The protocol feasibility tools are described as a workbench for studying distributed patient data, as a cohort selection tool. The Protocol feasibility scenario is divided in different phases (functional areas are shown in italic): 1. Protocol Feasibility Study Management: Creation of the protocol feasibility study 2. Query Management: Creation of study query 3. Query Builder: Definition of the query statement 4. Query Management: Launching the query 5. Query Visualization and Analysis: Display of results 6. Query Builder: Modifying the query and measuring impact on results 7. Protocol Feasibility Study Management: Save query and associated result sets to feasibility Study Executive Summary for deliverable D6.1 Page 8 of 12
8. Graphical user interface of PFS end user services The general structure of the EHR4CR services is mainly inspired from the structure of a project management and collaboration tool. A user whom belongs to a registered organization has his own account from where he can see all the PFS from his organization. According to his rights, he can manage FPS, queries, users, access rights as it was previously described. 8.1. Authentication To sign in, the user enters his unique user ID (email address or specific ID provided by the system during registration) and his password provided by the Organization manager. A link Forget your password? allows a user to recover an access in case of the loss of the password. The user is prompted to enter his ID and he submits the request. He will receive an e-mail with his password. 8.2. User home page On this page, the user can see news from his organization or from the EHR4CR platform such as new Clinical data warehouses or new service updates. The frames are presented here as examples of what we can have on the home page. On the right, the user can have a quick access to recent active feasibility studies. If he wants to see all the available PFS, he has to click on Feasibility Studies on the top menu. 8.1. Feasibility studies list page By clicking on the Feasibility Studies menu, the user access to the list of PFS from his organization. On this page, the users can browse and see the details of existing feasibility studies. They need authorization to have an access to the feasibility study itself. A user can also create a new feasibility study and allow other users to see and access to it. 8.2. Feasibility study workbench After choosing the PFS, the user enters in the PFS workbench. A second access menu appears to allow the user to navigate into the different PFS services. This menu gives an access to the Overview page, the documentation manager, the query manager, the query Executive Summary for deliverable D6.1 Page 9 of 12
builder, and for users who have edit rights, the study manager. 8.3. Query management The query management page is quite similar to the PFS management pages previously described. It lists the existing queries from the current PFS. The user can access to the query builder to edit the query by clicking on the title. The query in blue are these the user is allowed to access, the ones in black are these he does not have access rights. When a user clicks on the check box of a blue query, the Edit, Duplicate and Delete button become accessible. The user can select several queries to delete, or to clone (duplicate). When one query is selected the Edit button is active, whereas when several queries are selected, the edit button is deactivated. 8.4. Query builder Once the user has created the new query, he accesses to the query builder itself. The query builder is a graphical query editor that will guide the user to compose queries in an easy and ergonomic way. The query builder is divided in three parts: the terminology where the user will pick terms to compose his query, the query composer itself with the logical and temporal operators needed to compose complex queries and a contextual part where will be display the different options related to a specific term such as lab results or dosages. The composer supports the Boolean operators AND, OR, NOT and provides brackets to help the user composing complex criteria such as: { Term1 AND Term2 } OR Term3 The composer also supports Temporal Operators. The user click on the purple button Time Operator and then he has the possibility to choose which Allen s operator he wants to use and he defines the values using the Advanced Option frame under the Composer. The user can apply a temporal operator to one term or to several one using the brackets: { Term1 AND Term2 } After 01/01/2011 Executive Summary for deliverable D6.1 Page 10 of 12
The last operator is the Occurrence or Frequency operator. The user can apply to one or more terms this operator to express the number of occurrence of an event. This operator can be coupled with a temporal operator: After 01/01/2011 { Term1 > 2 } The operators are designed with contrasted colours to allow the user to easily recognize them. This will help to avoid confusion when looking at a complex query. Once the user has composed the query, he has the ability to save it and to run it. By running the query, the query builder will generate the query in a specific formalism accepted by the orchestrator. The query will be split into as many sub-queries as there are criteria in the initial query. Therefore, the result of the query will not only be the total number of patient whom fit the criteria but as well the number of patient whom fit the query for each criterion. This will allow the user to appreciate the impact of the criteria on the result and identify if a criteria is to constraining. The user will also be able to modify an existing query. Each version of a query will be saved and will be accessible to let the user the ability to retrieve any previous version of the query. The results will also be saved and linked to its query version. 9. Conclusion WP 6 aims to provide end user services that fit all the constraints defined by the other work packages such as the semantic interoperability (WP 4), pilot sites (WP7) or security (WP 5). Those services must provide a useful and efficient tool for the first step of a clinical research, the feasibility study. At month M12, some of the constraints are still not finalised, this led to the WP 6 team making some Executive Summary for deliverable D6.1 Page 11 of 12
assumptions about the functionalities. However, the core functionalities of the PFS (the query workbench) are well identified and defined. We focused on this part to propose an original graphical interface which can answer the needs. After validation of the mockups, the development will be split into different team depending of the resources. Executive Summary for deliverable D6.1 Page 12 of 12