Transcript Day 2 - P4 CRFQ and Services -ProblemStatement

“Service Framework”
workgroup
1
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”
2
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 !
3
Problem Statement
What do we mean by services ?
Ops4
Ops3
Ops2
Ops1
Standards
Semantic signifiers)
Services
Governance Audit
Functional Profile
(use case –
see example from CRFQ)
4
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. ….
5
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)
6
Problem Statement – what do we want to
achieve
Clinical
Research
1. Genetic
Association and
Linkage Analysis
2. Clinical
Validation –
Target,
Biomarker, and
Diagnostic
Clinical
Development
Regulatory /
Safety
3. Clinical Trial Execution
10. Post-Marketing
a. Connect Patients to Trials
b. Data Collection & Mgmt
c. Investigator Services
d. Compliance
e. Placebo Populations
a. Safety /
Adverse Event
Monitoring
b. Pharmacovigilance
c. P-Epi & Data
Mining
Prioritized High-Level Use Cases
Commercial
12. Pharmacoeconomics
13. Marketing
Comparative
Studies
14. Pharmaceutical/
Disease
Management
Programs
4. Clinical Trial Simulation
5. New Indication
Identification
15. e-Prescribing
11. Manufacturer’s
Recall
6. Interim analyses
7. Personalized Medicine – Pharmacogenomics
8. Outcomes Studies
9. Disease and Care Management Modeling
7
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
8
Key Milestones
 2008 / 2009 Piloting CRFQ – and other services
9
BACKUP
10
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
11
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 deidentification 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
12
OGS-DAI and CRFQ
Serv3
OGS-DAI
List Qualified
Patients
Interface
Pt data
P3
P1
Pt data
Pt data
P4
C
R
F
Q
Protocol
Pt data
P3
P1
Pt data
Pt data
Pt data
Serv2
OGS-DAI
I/E criteria/
Safety criteria
Pt data
P2
OGS-DAI
CRFQ client
(trial sponsor,
CRO,
Pharma)
Qualified
patients
Pt data
Pt data
P4
P3
P2
P1
Pt data
Pt data
P4
P2
13
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.
14