2 Problem StatementSeamless 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 ServicesSomething – 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 serviceServices 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 servicesServices must be testable and certified !
4 Problem Statement What do we mean by services ? Ops1Ops2Ops3Ops4Standards Semantic signifiers)GovernanceAuditFunctional Profile (use case – see example from CRFQ)
5 Problem Statement What do we mean by services Problem Statement What do we mean by services ? Use case: patient monitoring conditionUse case: check how many patient – in January met a specific set of condition (diabetic, above 50 years, within a certain time frame….) in the accessible DBsFunctional Profile = “count of qualified patients”Issues: no possibility to identify double count, need to have total populationOperations:Check authorizationPatient selectionPatient countService = a set of operations exposed via an interface answering needs for a specific functional profileCRFQ – match patient criteria to EHRNeed additional services – security, consent, anonymization, etc. ….
6 Problem Statement – what do we want to achieve “Service framework”=> taxonomy of standard servicesServices 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 approachStarting with some piloting of which ones would fit with each otherUnderstanding 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 havenarrative descriptionperformance indicators,linkage to organization information model andknow downstream consumers (in context of overall interaction)
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 savingsFlexibility/agility/adaptability of the solutionRe-usability of functionalities“low” level services across different “high” level servicesservices across organizationsComplexity of interactions more scaleable & manageablestepped 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 Milestones2008 / Piloting CRFQ – and other services
11 Going from some examples ALERT ITHow to specify queries across the different DBsPossibility to use CRFQ – to have a more “architecture” oriented approach
12 OGSA-DAI projectOn-going Project from IBM and Manchester University , included in DebugITComplete environment – GRID storage and GRID queriesMany type of data stored + layer to manage firewall and de-identification to expose various set of standardized servicesUser queries can be propagated and you get data back (field data mapping, quality…)Semantic mapping is relatively weak but nice in propagating queriesTools to be configured to be adapted to each EHR=> underlying building block needed for service like CRFQ
13 List Qualified Patients Interface OGS-DAI and CRFQServ3P1Pt dataP2P4P3OGS-DAIList Qualified Patients InterfaceP1Pt dataP2P4P3CRFQQualified patientsCRFQ client(trial sponsor,CRO,Pharma)P1Pt dataP2P4P3OGS-DAIProtocolI/E criteria/Safety criteriaServ2OGS-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.