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 ?
Ops1
Ops2
Ops3
Ops4
Standards Semantic signifiers)
Governance
Audit
Functional 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 condition
Use 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 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 / 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. List Qualified Patients Interface
OGS-DAI and CRFQ
Serv3 P1
Pt data P2 P4 P3
OGS-DAI
List Qualified Patients Interface P1
Pt data P2 P4 P3 C R F Q
Qualified patients
CRFQ client
(trial sponsor,
CRO,
Pharma) P1
Pt data P2 P4 P3
OGS-DAI
Protocol
I/E criteria/
Safety criteria
Serv2
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.