1. Clinical Research Filtered Queries (CRFQ) from pilot to a service framework Introduction to break out sessions Isabelle de Zegher – Johan van der Lei 11 th March 2001

2. - 2 - EFPIA EMR Task Force - I. de Zegher Overview What is CRFQ? –Definition –Benefit & concerns Towards a “service-oriented architecture” (SOA) –What is it ? Benefits –How should we proceed

3. - 3 - EFPIA EMR Task Force - I. de Zegher What is CRFQ? Problem Statement: –From Pharma side: matching patient to trial Evaluation of protocol feasibility against patient population, patient recruitment and monitoring patient population with specific safety conditions are difficult to achieve Access to patient information is fragmented; there are some centralized databases which allows to check specific patient criteria but this is not sufficient to cover a wider population. EHR offers new possibilities that need to be clarified and piloted. –From patient side: matching trial to patient Identification of protocol that match specific conditions is difficult -> need to look at the different side of the different company Some central repository (Clintrial.gov, WHO..) are built – but information contained in these repository is not always sufficient or structured enough Project Scope: –Pilot implementation of a standard service (CRFQ) –Evaluate needed changes (processes, organization, legal, financial…) –Definition project proposal for full implementation Not a lot of progress done Workload – time pressure !

4. - 4 - EFPIA EMR Task Force - I. de Zegher What is CRFQ – details (1/2) P4 I/E criteria P2 I/E criteria P1 I/E criteria P3 List Qualified Protocol Interface CRFQCRFQ CRFQ client (clinician, caregiver, patient Clinical data set Qualified protocols P1 Pt data P2 Pt data P4 Pt data P3 Pt data List Qualified Patients Interface CRFQCRFQ CRFQ client (trial sponsor, CRO, Pharma) Protocol I/E criteria/ Safety criteria Qualified patients Source Charlie Mead – October 2007

5. - 5 - EFPIA EMR Task Force - I. de Zegher What is CRFQ – details (2/2) Protocol Feasibility CRFQCRFQ CRFQ client (clinician, caregiver, patient CRFQ client ( trial sponsor, CRO, Pharma) How many patients meet the I/E criteria in my study design ? Count of patient/ per site Total Count of patient Checking trials for patient CRFQCRFQ CRFQ client (clinician, caregiver, patient CRFQ client (trial sponsor, CRO, Pharma) Which trial/company could I go to, to have an advanced treatment ? Name of trial & company Patient Recruitment CRFQCRFQ CRFQ client (clinician, caregiver, patient CRFQ client ( trial sponsor, CRO, Pharma) Which sites do have most patients with i/e/ criteria of my study ? Count of patient/ per site Total Count of patient with sites (and investigator ?) Patient safety condition monitoring CRFQCRFQ CRFQ client (clinician, caregiver, patient CRFQ client ( trial sponsor, CRO, Pharma) How many patients meet the specified safety criteria ? Count of patient/ per site Total Count of patient with sites (and responsible physician)

6. - 6 - EFPIA EMR Task Force - I. de Zegher What is CRFQ? A single service within a bigger initiative: Health Service Specification Project Joint effort by HL7 EHR Technical Committee (EHR TC) and the Object Management Group (OMG) –HL7 responsibility: produce semantically robust service specifications Driven by business cases Manifest as Interface specifications (implementation-independent) bound to “semantic signifiers” (e.g. BRIDG Model, terminologies, etc.) –OMG responsibility: manage an RFP process that results in the implementation of the specified service Overall goal is to produce a set of standardized services that can be deployed by multiple vendors across the life sciences/clinical research/clinical care continuum Source Charlie Mead – October 2007

7. - 7 - EFPIA EMR Task Force - I. de Zegher Benefits and Concerns of CRFQ/HSSP Benefits On-going pilot Business specifications being completed by technical specifications Included within a broader standardization framework for services (HSSP) –today focus is still very much on “data” standardization (static component) –Not yet on “services” (dynamic component) Concerns One service => requires other (e.g. security, identification, …) for deployment in production –Some services exist –Many still need to be specified and checked against legal requirements How to develop a Framework of services which is consistent from a business process point of view Semantic interoperability: how do we ensure matching of I/E criteria or patient conditions criteria across the HC continuum

8. - 8 - EFPIA EMR Task Force - I. de Zegher Overview What is CRFQ –Definition –Benefit & concerns Towards a “services-oriented architecture” (SOA) –What is it ? Benefits –How should we proceed

9. - 9 - EFPIA EMR Task Force - I. de Zegher What is a SOA?: An architecture which is based on business use cases and designed for agility and change

10. - 10 - EFPIA EMR Task Force - I. de Zegher What is a SOA: The Architecture of the future What about cross-organizational architecture ? –We focus on target “normative” data layer is (static component e.g. RIM and Domain Analysis Models (DAM) such a BRIDG in clinical research) –There is NO business process layer - common service => the dynamic component of a DAM is not aimed at becoming normative (it simply support disambiguation of semantic) Should we define a common process/services layer when we want to exchange data ? Benefits –Ensure correct usage of underlying data –Facilitate communication – decrease cost It is “easy’ to set up communication when pharma has to communicate with limited well regulated actors (authorities) It is complex/costly when we need to communicate with Health care (many organization, no structure)

11. - 11 - EFPIA EMR Task Force - I. de Zegher How should we proceed ? Definition of “services” HSSP (HL7/OMG) has a methodology develop “standards services” –Few ones already developed – but no overall framework ? –We would need to develop all services of interest for clinical research as a start – should be extended to public health) eClinical Forum/Pharma EDC developed a set of functional requirements/conformance criteria –that EHRs should have to support clinical research –Can these be the basis of “standard” a service framework? How do we leverage on-going/existing projects/registries (see next slide) – rather than to start from scratch again. –E.g. Patient disease specific registries and safety, Pooling patient through large data and hospital, Disease based registries, EORTC –In the ideal world each of on-going project would have to add a work package to include dedicated services from the “service architecture” – like CRFQ

12. - 12 - EFPIA EMR Task Force - I. de Zegher How should we proceed ? Definition of “common data sets for patient condition criteria” What defines unambiguously i/e criteria of patient conditions ? How to ensure mapping across different organisations –Different companies define patient conditions differently (MedDRA, internal) –Health Care is using different terminologies (ICD, SNOMED, National terminologies, ….) Possibility to build a common repository of data elements definition –starting from a specific disease ? –How to relate this to existing terminologies & regulatory requirements (safety) Should we build/maintain registries with “clean/common” data –Geographic registries or disease specific registries or ???? –How to relate this to existing/ongoing initiatives

13. - 13 - EFPIA EMR Task Force - I. de Zegher Conclusion: what is innovative (for an IMI/FP7 strategic research item) Technology is there but not widely use –innovation is more in the way we use the technology than in technology development –it is the way people collaborate and work together => organizational, legal, semantic issues (Safety) Requirements placed on Pharma companies are increasing and authorities/pharma struggle to be ready within current model Push the notion of what is possible to a different dimension – not only what is feasible today

14. - 14 - EFPIA EMR Task Force - I. de Zegher 14 BACKUPs Material for Breakout Session

15. - 15 - EFPIA EMR Task Force - I. de Zegher Chair :J. van der Lei Rapporteur :I. de Zegher Location :Room Ensor Daniel (Le Bozec)Christel APHP / INSERM UMRS872 Christel.Lebozec@spim.jussieu.fr de ZegherIsabelleNovartis isabelle.dezegher@novartis.com IakovidisIliasDG INFSO, ICT Health Ilias.Iakovidis@ec.europa.eu LovisChristianCHU Geneva christian.Lovis@sim.hcuge.ch MeadCharlieBooz Allen Ham./NCI mead_charlie@bah.com PerkinsRichardeClinical Forum Richard.Perkins@con7.com RouaultStephaneHoffmann La Roche Stephane.rouault@roche.com StroetmannVeliEmpirica veli.stroetmann@empirica.com TardiffBarbaraParexel barbara.tardiff@parexel.com TiffeSvenAGFA sven.tiffe@agfa.com TwaitesRobGSK rob.m.thwaites@gsk.com van der LeiJohanErasmus U Rotterdam j.vanderlei@erasmusmc.nl WilsonPetraCisco petrwils@cisco.com

16. - 16 - EFPIA EMR Task Force - I. de Zegher TimeTitle 11:00Agreement on agenda 11:10Status of CRFQ – possibility for pilots 11.40 Round table Brainstormi ng + conclusion Services “architecture” (security, patient matching, data access, …) - What do we mean by services How can we define a “business” framework for different services needed to “connect” the health care continuum while keeping flexibility/freedom need to be practical and start from specific process (e.g. safety) more focus could be on routine patient care for research purpose / safety issue - context of primary care or secondary/tertiary care – may be related to conformance criteria start from a specific disease How can we leverage eClinical Forum/ conformance criteria ? 12:30LUNCH BREAK 13:30 Post-it Brainstormi ng Key challenges for building a service “architecture”, possibilities for accelerators Challenges (Organizational, technical/semantic, legal) Accelerators (use registries – what for, which scope), mapping of ICD 11 and SNOMED …..) Debriefing 14:30Conclusion: shaping recommendations for IMI and FP7 in the direction of “service architecture” What Why Key milestones 15:00End of breakout session

17. - 17 - EFPIA EMR Task Force - I. de Zegher Some thoughts …. “services-oriented architecture” (SOA) Brainstorming on potential direction for a project –Services “architecture” (security, patient matching, data access, …) - description of the different type of services that would be needed to “connect” the health care continuum while keeping flexibility/freedom need to be practical and start from specific process (e.g. safety) – otherwise more focus could be on routine patient care for research purpose / safety issue - context of primary care or secondary/tertiary care => may be related to conformance criteria from eClinical Forum start from a specific disease –Roadmap and priorities – which type of services, when –Governance to put in place for implementation at European level –Implementation map –Practical pilot/implementation to test overall concept

18. - 18 - EFPIA EMR Task Force - I. de Zegher Some thoughts…. Registries as “accelerators” How do we leverage existing activities, rather than start from scratch. –Activities Patient disease specific registries and safety Pooling patient through large data and hospital - Disease based registries EORTC – European society conducting cancer trials – only able to function because they have a pool of collaborating partners (many lessons learned could come from them) –Issues More and more such registries Many exist within one country – this is not a technological challenges but organization => best to start small based on a good understanding of what is required. Many of the registries we see are coming from chronic disease (e.g. leukemia) –Positive: allowing to fine tuning treatment –Negative: by fragmenting to a specific disease we are missing some aspects. E.g. Diabetic patients have as well cardiac issues => many aspects are related at the combination => we could use services collecting information from these different registries (if they share the same patient id) to re-combine information