“Service Framework” workgroup

1. “Service Framework” workgroup

2. Problem Statement • Seamless integration between clinical research requires 2 pillars • “Data”: Computer semantic interoperability, based on unambiguous semantic on data shared across the HC continuum • “Functions”: Standards services supporting harmonization of interactions across a very heterogeneous community of stakeholders (hospitals, GPs, nursing homes, pharmacists, companies, authorities) • Today most effort focus on standardization of data; we need as well to address standardization of services through a “service framework”

3. Problem Statement What do we mean by services ? • Definition of Services • Something – based on a use case - provided by one organization to another one – and that the consumer is ‘ready to pay for”; the consumer does not see the underlying operations supporting a service • Services support seamless information flow across (heterogeneous & disperse) organizations; they are available through “Yellow pages” • They assume computation semantic interoperability across organizations (data are not the same in local system but when exchange they can be mapped to a common semantic) • There are different level of services • “low” level supporting data access, security integration services • “high level” supporting business services (decision support, CRFQ, data mining, ….) and building on top of “low” level, re-usable services • Services must be testable and certified !

4. Problem Statement What do we mean by services ? Services Ops1 Ops3 Ops4 Ops2 StandardsSemantic signifiers) Audit Governance Functional Profile(use case – see example from CRFQ)

5. Problem Statement What do we mean by services ? Use case: patient monitoring condition • Use case: check how many patient – in January 2000 - met a specific set of condition (diabetic, above 50 years, within a certain time frame….) in the accessible DBs • Functional Profile = “count of qualified patients” • Issues: no possibility to identify double count, need to have total population • Operations: • Check authorization • Patient selection • Patient count • Service = a set of operations exposed via an interface answering needs for a specific functional profile • CRFQ – match patient criteria to EHR • Need additional services – security, consent, anonymization, etc. ….

6. Problem Statement – what do we want to achieve • “Service framework”=> taxonomy of standard services • Services will support business specific use cases at the interface between clinical care and clinical research (like patient safety monitoring, trial set up, trial execution, …see complete list) • Services will be organized in a taxonomy of integrable, re-usable components in a stepped approach • Starting with some piloting of which ones would fit with each other • Understanding maturity of organization (organization need be ready for using/working with services => evolution to more complex service will be related to maturity of organization to be able to use services and data => • Services specification must have • narrative description • performance indicators, • linkage to organization information model and • know downstream consumers (in context of overall interaction)

7. Problem Statement – what do we want to achieve

8. Benefit – why do we believe this would bring value • Manage complexity of business problems we want to solve by decomposing it into sub-components (i.e. patient safety monitoring decomposed in many different services) • Cost savings • Flexibility/agility/adaptability of the solution • Re-usability of functionalities • “low” level services across different “high” level services • services across organizations • Complexity of interactions more scaleable & manageable • stepped approach – required adaptation for each organization at the beginning) • Set up clear “contract’ with each organization (e.g. access, …) => no need to redo each time

9. Key Milestones • 2008 / 2009 Piloting CRFQ – and other services

10. BACKUP

11. Going from some examples • ALERT IT • How to specify queries across the different DBs • Possibility to use CRFQ – to have a more “architecture” oriented approach

12. OGSA-DAI project • On-going Project from IBM and Manchester University , included in DebugIT • Complete environment – GRID storage and GRID queries • Many type of data stored + layer to manage firewall and de-identification to expose various set of standardized services • User queries can be propagated and you get data back (field data mapping, quality…) • Semantic mapping is relatively weak but nice in propagating queries • Tools to be configured to be adapted to each EHR • => underlying building block needed for service like CRFQ

13. P2 P4 P1 P4 P1 P2 P4 P1 P2 Serv3 Serv2 Pt data Pt data Pt data Pt data Pt data Pt data P3 P3 P3 Pt data Pt data Pt data Pt data Pt data Pt data OGS-DAI and CRFQ OGS-DAI List Qualified Patients Interface C R F Q Qualified patients CRFQ client (trial sponsor, CRO, Pharma) OGS-DAI Protocol I/E criteria/ Safety criteria OGS-DAI

14. Definition of Services from Wikipedia • A “Service” has a description or specification. This description consists of: • 1. An explicit and detailed narrative definition supported by a low (but not detailed [not implementation specific]) level process model. The narrative definition is in some cases augmented by machine-readable semantic information about the service which facilitates service mediation and consistency checking of an Enterprise Architecture. • 2. A set of performance indicators that address measures/performance parameters such as availability (when should members of the organization be able to perform the function), duration (how long should it take to perform the function), rate (how often will the function be performed over a period of time), etc. • 3. A linkage to the organization’s information model showing what information the “Service” owns (creates, reads, updates, and deletes) and which information it references and is owned by other “Services”. • 4. A listing of known downstream consumers (other “Services” that depend upon its function or information) and the documentation of their requirements.