presentation on HL7

1. Health Level 7 (HL7):
A Brief Overview of a
23-Year Trajectory
W3C Semantic Web
Health Care and
Life Sciences SIG
Charlie Mead MD, MSc
Chief Technology Officer,
National Cancer Institute (NCI)
Center for Biomedical Informatics
and Information Technology
(CBIIT)
Chair,
HL7 Architecture Board (ArB)

2. Overview
• HL7 Origins: Mission and Version 1.0
• HL7 Adoption: Version 2.x
• HL7 Maturation and Expansion: Version 3.0
• HL7 Evolution: Reorganization & Collaboration, Domain Analysis
Models, Service-Awareness, and Enterprise Architecture
• HL7 Interoperability Contexts: the Translational Continuum
• Pharma’s “next” business model: intersection with healthcare
• National Cancer Institute: from caBIG™ to BIG-Health™
Time flies like an arrow.
Fruit flies like a banana.

3. HL7 Origins:
Version 1.0

4. 1985-89: A (relatively) Simple Problem
• Collection of seven enterprise-related hospitals with ~30 ADT systems
needed to exchange data
• RS-232-like byte-stream approach
• Defined delimiters in message headers , fields/sub-fields, etc.
• Syntactic interoperability with agreed-upon semantics in a restricted/closed
domain-of-application
• An engineering solution that worked!
• Message paradigm (ACK/NACK)
• “the only game in town”
• Version 1.0 (< 10 messages) released circa 1987, 1.1 circa 1989
• Organization name chosen (Health Level 7) based on OSI stack
• Solid adoption trajectory in US hospital community  interest in
expansion of message repertoire beyond ADT

5. HL7 Adoption:
Version 2.x

6. 1989-95: The Problem Gets Bigger
• Increasing adoption drives interest in non-ADT domains
• Financial/Patient Accounting
• Orders management (e.g. labs, etc.)
• (gradually) Clinical Care (e.g. order sets, care plans, etc.)
• Organizational structure of HL7 established
• Technical Committees/SIGs (domain-specific)
• Bottom-up message development based on “business triggers driving
information exchange”
• Optionality allowed in all messages
• Complex relationships were hand-tooled on a per-message basis
• Z-segments (the equivalent of free text in an RDBMS) allowed
• Cross-TC sharing of semantics based on “good citizenship/awareness”
• Content expands
• Version 2.0, 2.1, and 2.2 released between 1989-92
• Version 2.3, 2.4, and 2.5 relesed between 1992-95

7. 1989-95: The Problem Gets Bigger
• Adoption increases
• 75% (1992)/95% (1995) of US hospitals utilized HL7 2.x in two or more
systems
• Initial interest from non-US entities
• Canada
• Australia
• Europe
• UK NHS
• HL7 becomes an ANSI SDO to facilitate interaction with ISO
• Slowly but surely, HL7 was becoming a victim of its own success
• “If you’ve seen one HL7 implementation, you’ve seen one HL7
implementation.”
• “HL7 isn’t a standard, it’s a style guide.”

8. HL7 Maturation and
Expansion:
Version 3.0

9. 1995-2006: Success Drives New Approaches
• HL7 BoD decided to embark on a new message-development strategy
• Adoption of emerging UML as a standard modeling language
• Adoption of a more formal abstract data type specification as underpinning
for computable semantic interoperability
• Decision to “stay out of the terminology business” and concentrate on the
structures that bind terminologies, i.e….
• Development of a common Reference Information Model that would
provide the “universe of semantics” for all HL7 domains-of-interest and
could be used to develop all HL7 message structures
• Emergence of a commitment to “more than just messaging in the HL7
2.x sense”
• Computable semantic interoperability
• Other related standards
• Arden Syntax
• CCOW
• Clinical Document Architecture (CDA)

10. Health Level Seven (HL7)
•“HL7 develops specifications that enable the semantically interoperable
exchange of healthcare data. ‘Data’ refers to any subject, patient, or
population data required to facilitate the management or integration of any
aspect healthcare including the management, delivery, evaluation of and
reimbursement for healthcare services, as well as data necessary to conduct
or support healthcare-related research. HL7 Specifications are created to
enable the semantically interoperable interchange of data between healthcare
information systems across the entire healthcare continuum.”
-- (Mead paraphrase of HL7 Mission Statement)
•Conceptually congruent with W3C Semantic Web HCLS SIG Mission
Statement

11. The Four Pillars of
Computable Semantic Interoperability
Necessary but not Sufficient
• #1 - Common model (or harmonized sibling models) across all
domains-of-interest
• Information model vs Data model
• The semantics of common structures – Domain Analysis Model
• Discovered (in part) through analysis of business processes
• #2- Model bound to robust data type specification
• HL7 V3 Abstract Data Type Specification (R2)
• ISO DT Specification

12. The Four Pillars of
Computable Semantic Interoperability
Necessary but not Sufficient
• #3 - Methodology for binding terms from concept-based
terminologies
• Domain-specific semantics
• #4 - A formally defined process for defining specific structures to
be exchanged between machines, i.e. a “data exchange standard”
• Static structures (as defined via Pillars 1-3) bound to explicit
data/information exchange constructs
• As of Version 3.0, these constructs were still defined as “messages” in
the traditional HL7 sense
• Documents (content RIM-derived) could also be defined by HL7 TCs
and be exchanged within or without accompanying message constructs
A single CSI statement is made by binding common, cross-domain
structures to domain-specific terminologies (semantics).

13. HL7 V3 Reference Information Model (RIM)
• Referral
• Transportation
• Supply
• Procedure
• Consent
• Observation
• Medication
• Administrative act
• Financial act
• Organization
• Place
• Person
• Living Subject
• Material
• Patient
• Member
• Healthcare facility
• Practitioner
• Practitioner assignment
• Specimen
• Location
Entity
0..*
1
Role
1
0..*
1
0..*
Act
Relationship
1..*
1
0..*
1
Participation Act
• Author
• Reviewer
• Verifier
• Subject
• Target
• Tracker
• Has component
• Is supported by
“An instance of an Entity may play zero or more
Roles. Each instance of a Role may, in turn, play
zero or more instances of a Participation in the
context of an instance of an Act. Each instance of a
Participation participates in a one and only one Act
for the ‘duration’ of that Act. Acts may be related to
each other through instances of Act Relationship.”

14. ROLE:
Patient
PARTICIPAT:
Author
• A diagnosis of pneumonia (observation Act) related to three other observations Acts.
Each Act is fully attributed with its own context of Entity-Role-Participation values.
OBS:
Temp 101F
OBS:
Abnormal
CXR
OBS:
Elevated
WBC
AR:
“is supported
by”
AR:
“is supported
by”
AR:
“is supported
by”
has target
has target
has target
OBS:
Dx Pneumonia
is source for
Collection, Context, and Attribution
Building Complex RIM-based structures
PARTICIPAT:
Subject
ROLE:
Clinician ENTITY:
Person
Attribution
Attribution
Attribution
Attribution

15. All the world’s a stage
And all men and women are merely players
One man, in his time, has many parts,
First the infant,
Mewling and puking
In the nurse’s arms.
Shakespeare in RIM-speak
(courtesy of David Markwell)
direct target
subject
subject
responsible party

16. Information vs Terminology Models:
Intersecting and interleaving semantic structures
Common Structures
for
Shared Semantics
Information Model
Domain-Specific Terms
specifying
Domain-Specific Semantics
Terminology Model
Binding/Interface
Common Structures
bound to
Domain-Specific Structures
specifying
Domain-Specific Semantics
Information Model
Terminology Model
Domain-Specific Terms
specifying
Domain-Specific Semantics
Example: Appropriately constructed semantic web structures should be
able to distinguish between “Grade IV allergic rxn to Penicillin” represented
in several ways using various combinations of RIM and SNOMED-CT codes.

17. HL7’s Clinical Document Architecture (CDA)
• Emerged coincident with development of XML
• Driven by “document-centricity” of much of healthcare practice
• Emphasized the importance of transmitting both text and structured data
• Identified “fundamental document characteristics”
• Persistence
• Authentication
• Stewardship
• Wholeness
• Global/Local Context
• Human Readability
• Nicholas Negroponte’s “bits and atoms” paradigm is particularly relevent
• Release 1 (circa 2001) was only partially RIM-derived
• Rapid uptake/adoption in European community (less in US)
• Release 2 (circa 2006) entirely RIM-derived
• Adopted by HITSP (Coordination of Care Document (CCD)

18. Incremental Computable
Semantic Interoperability
*HL7 Clinical Document Architecture: Single standard for
computer processable and computer manageable data
Less “Informational” Systems
Highly “Informational” Systems
1001 0100 0100
1011 1110 0101
1001 0100 0100
1011 1110 0101
*
(Wes Rishel, Gartner Group)
1001 0100 0100
1011 1110 0101
1001 0100 0100
1011 1110 0101
*

19. HL7 TCs and the Life Sciences
• Focus up until circa 1997 was “clinical care”
• However, international interest in HL7 led to new domains-of-interest
and new TCs
• Regulated Clinical Research Information Management (RCRIM)
• Pharma (CDISC), FDA
• Clinical Genomics
• Imaging
• Medical Devices
• Security
• Etc.
• Of particular interest to W3C SW HCLS SIG is the RCRIM TC

20. RCRIM TC
• The RCRIM TC … defines standards to improve or enhance information
management during research and regulatory evaluation of the safety and
efficacy of therapeutic products or procedures worldwide. The
committee defines messages, document structures, and terminologies
to support the interoperability of systems and processes used in the
collection, storage, distribution, integration and analysis of ‘clinical trial’
information. Specific areas of interest include:
• Structured Protocols
• Product Stability and Labeling
• Clinical Trial Reporting
• AEs (with CDC)
• SDTM (with CDISC)

21. A caBIG™ Example
(from Covitz et al, Bioinformatics, V19, N18, P2404)
• Patient has headache, focal weakness, history of seizures
• Workup reveals glioblastoma multiforma, subtype astrocytoma
• Is this tumor histology associated with gene expression abnormalities?
• Yes, in the p53 signaling pathway including BCL2, TIMP3, GADD45A,
CCND1
• Is there documented evidence of aberrant expression of (e.g. CCND1)?
• Yes, SAGE tags for cyclin D1 appear with 3x greater frequency in
cancerous vs normal brain tissue
• Are any gene products of the p53 signaling pathway known targets for
therapeutic agents?
• Yes, TP53, RB1, BCL2, CDK4, MDM2, CCNE1
• Are any of the agents known to target these genes being specifically
tested in glioblastoma patients?
• Yes, trials xxx and yyy are currently underway

22. HL7 Evolution:
Reorganization & Collaboration,
Domain Analysis Models,
Service-Awareness, and
Enterprise Architecture

23. Reorganization
• As HL7 has grew to have ~3000 members, 40+ TCs and SIGs, ~30
International Affiliates, and as several countries implementing (or
attempting to implement) its standards, it became increasingly obvious
that -- like a growing company -- it needed to reassess its organizational
structure and processes.
• Multi-dimensional effort began in 2005 and continuuing to present
• Reconstituted BoD
• CEO
• CTO
• Technical Steering Committee
• Architecture Board
• Decreased number of TCs/SIGs
• Emphasis on project management and common development
methodology
• Use of ANSI DSTU to encourage testing before final ballot

24. Collaboration
• HL7 actively seeks collaboration with other organizations developing
standards for healthcare, life sciences, clinical research internationally
• Goal is to avoid redundant efforts
• Examples include
• ISO
• CEN
• OMG
• CDISC
• CDISC (Clinical Data Interchange Standards Consortium)
• Established circa 2002
• Virtually entire pharma industry is represented
• Prototype collaboration relationship for HL7 via RCRIM TC
• Leading developer of a DAM for domain of “Protocol-driven research and
associated regulatory artifacts”  the BRIDG Model

25. Domain Analysis Models:
The Communication Pyramid
Communication
`
Free-text Documents
Structured Documents
ad hoc Drawings
Non-standard Graphics
Discussions
Standardized Models (UML) -- DAM
Abstraction

26. BRIDG circa 2004:
Separating Analysis from Design/Implementation
ODM
RIM / DMIM
Problem-Space Model
(a la HL7 Development Framework)
RMIM / HMD / XSD
Level
of
Abstraction

27. Lessons Learned:
Using a DAM
• DAMs need to be applied in the context of a larger development
(message, service, application) management process
• DAMs should be both domain-friendly and semantically robust
(technology useful)
• In order to be truly effective, standards development needs to
become less like the Waterfall and more ‘Agile,’ i.e. embedded in
an interactive, iterative, incremental process.
• Exemplar process has been successfully piloted at NCI and is now
ready for application to all projects
• A DAM that is ultimately used in message, application, or service
development needs to address
• Data Type bindings
• Terminology bindings for coded data types

28. Lessons Learned:
Working with BRIDG (1)
• BRIDG only makes sense ‘in context’
• e.g. message development, application development, service
specification, etc.
• Analysis Paralysis occurs otherwise
• Most effective use is in the context of an iterative/incremental
development process (e.g. RUP, SCRUM, Agile, ect.)
• NCI has integrated use of the BRIDG Model (and the use of analysis
models in general) into its development practices
• HL7 RCRIM appears to be ready to do the same
• The BRIDG domain-of-interest is stable after 4+ years of use
• Protocol-driven research involving human, animal, or device subjects
and associated regulatory artifacts
• Recently, questions have been raised as to whether the BRIDG domain-
of-interest should include post-marketing safety/adverse events
• Initial indications are that the answer is ‘Yes’ and that the effect on the
model’s structure will be minimal

29. Lessons Learned:
Working with BRIDG (2)
• Teams need to start with the existing BRIDG Model
• Subset as needed based on project focus
• Add new semantics (e.g. classes, attributes, relationships,
business rules, etc.) as needed
• All new editions must be rigorously defined
• Identify existing elements in the BRIDG model which are incorrect,
unclear, too restrictive, etc.

30. BRIDG circa 2008:
Separating Analysis from Design/Implementation
Requirements
From
Wish
to
Reality
Analysis
Messages Services Applications
Design
Messages Services Applications
Implementation
Messages Services Applications
Implementation-dependencies
Technology/platform bindings

31. The Current BRIDG Model
Varying levels of
abstraction, explicitness,
and ‘RIM-compliance’
Understandable to Domain Experts
Unambiguously mappable to HL7 RIM

32. The Revised, 2-layered (2-views)
BRIDG Model
Consistent levels of abstraction and explicitness in
multiple sub-domain ‘Requirements Models’
Consistent levels of RIM-compliance and
explicitness in a single ‘Analysis Model’
Sub-Domain 1 Sub-Domain 2 Sub-Domain 3 Sub-Domain 4 Sub-Domain 5
Understandable to Domain Experts
(DaM)
Unambiguously mappable to HL7 RIM
(DAM)
NOTE: Sub-domains may or may not intersect semantically

33. DAMs and Ontologies (1)
Domain-
of-
Interest
Visual
Conceptualization
(UML DAM)
Ontologic
Representation
(OWL-DL)
A UML picture is worth
a thousand
Requirements Documents words
An OWL-DL definition
is worth at least several
UML classes
described by

34. DAMs and Ontologies (2)
Domain-
of-
Interest
Visual
Conceptualization
(UML DAM)
Ontologic
Representation
(OWL-DL)
A UML picture is worth
a thousand
Requirements Documents words
An OWL-DL definition
is worth at least several
UML classes
Is described by /
facilitates computational in

35. Service Awareness within HL7
• Initial work began in 2006 with the development of the Health
Services Specification Project (HSSP), a joint effort with OMG
• By CTO directive, has evolved to a directive to the newly-
established ArB to develop a “Services-Aware Enterprise
Architecture Framework” (SAEAF) for HL7
• Requirements include
• Maximum utilization of existing static artifacts
• Development of computationally robust behavioral/interaction model
• Development of a scalable Conformance/Compliance framework

36. Enterprise Integration Strategies:
Objects vs Messages vs Services
• Objects
• Finely-granulated
• Difficult to trace to business functionality
• Encapsulation not a positive when crossing enterprise boundaries
• Messages
• Payloads based on standards support semantic interoperability
• Embedding dynamic/behavioral semantics within message causes run-
time context ambiguity or non-enforceable contract semantics
• Application Roles
• Receiver Responsibilities
• Services
• Traceable to business-level requirements
• Separation of static semantics (message payload) from dynamic
semantics (“integration points,” contracts)

37. Service Awareness within HL7
• Historically, HL7 as conceptualized the world as “communicating
clouds” but has not formally specified the semantics of the
interactions that occur
• HSSP began the specification process with its Service Functional
Model (basically a services “requirements document”)
• SAEAF extends the definitional space

38. HL7, MDA, CSI, SOA, and Distributed
Systems Architecture
• The intersection of HL7, MDA, Distributed Systems Architecture, SOA,
and CSI provide a goal, the artifacts, portions of a methodology, and
the framework for defining robust, durable business-oriented
constructs that provide extensibility, reuse, and governance.
You are here (Vous êtes ici)
Service Oriented
Architecture
Reference Model
For Open Distributed
Processing Model Driven
Architecture
Computable Semantic
Interoperability
Health Level 7

39. Choreography: an Analysis Perspective
NCI is using CDL as an
analysis tool (via pi4soa
open-source tool)

40. SAEAF Behavioral Framework
The HL7 Specification Stack - Overview
RM-ODP Viewpoint
Business
Information
Computation
Engineering
Technology
Reference
- + + / /
Blueprint
+ + - / /
Platform-
Independent + + + - /
Platform-Bound
/ - + + O
Typical + Rare - Never / Optional O

41. SAEAF Specification Pattern
Specification Enterprise /
Business Viewpoint
Information
Viewpoint
Computational
Viewpoint
Engineering
Viewpoint
Conformance Level
- EHR-FM,
Clinical
Statements
RIM, Structured
Vocab, ADTs
EHR-FM - Reference
Analysis Business
Context,
Reference
Context
DIM Dynamic
Blueprint,
Functional
Profile(s)
N/A Blueprint
Conceptual
Design
Business
Governance
CIM, LIM Dynamic Model,
Interface
Specification
N/A Platform
Independent
Implementable
Design
N/A Transforms,
Schema
Orchestration,
Interface
Realization
Execution
Context,
Specification
Bindings,
Deployment
Model
Platform Bound

42. An Exemplar Service:
Clinical Research Filtered Query (CRFQ)
P4
I/E criteria
P2
I/E criteria
P1
I/E criteria
I/E criteria
P3
List Qualified
Protocol
Interface
C
R
F
Q
CRFQ client
(clinician,
caregiver,
patient Clinical
data set
Qualified
protocols
P1
Pt data
P2
Pt data
P4
Pt data
P3
Pt data
Count
Qualified
Patients
Interface C
R
F
Q
CRFQ client
(trial sponsor,
CRO,
Pharma) Protocol
I/E criteria/
Safety criteria
Qualified
patients

43. HL7 Interoperability Contexts:
The Translational Continuum
-- Pharma’s “next” business model: intersection with
healthcare
-- National Cancer Institute: from caBIG™ to BIG-Health™

44. Pharma’s essential challenge:
Increased R&D expenditures, decreased NCEs to market
0
10
20
30
40
50
60
'90 '91 '92 '93 '94 '95 '96 '97 '98 '99 '00 '01 '02 '03
Approved
NCEs
0
5
10
15
20
25
30
35
R&D
Expenditure
($Bn)
NCEs R&D Expenditure
Source: PhRMA
Today’s R&D Infrastructure
Phase I
Phase II
Phase III
rejection
rejection
rejection
Approved NCE
Genomics Proteomics Combichem UHTS
Ian Ferrier, PhD

45. The Transformation:
Better early decisions, fewer late stage failures,
decreased time-to-market
Increased Early Drug
Development
Capabilities
Phase I
Phase II
Phase III
rejection
rejection
rejection
Increased Approved NCEs
Genomics Proteomics Combichem UHTS
Decreased Time in
Pipeline
Decreased
Cost
Fewer late
stage failures
Ian Ferrier, PhD

46. Sophisticated
Knowledge Creation
Tools
The Vision is simple, and well understood …it is based on
individualized data…and appropriate tools…
Clinical data
Collection
Pharma-supplied
Queries
Clinical Data
Repository
Genomics,
Proteomics,
Chemistry, etc.
… ‘Knowledge-creation’  CSI platform
Ian Ferrier, PhD

47. caBIG™ and BIG-Health™:
Addressing the Infrastructure of the
Current World of Biomedicine
• Isolated information
“islands”
• Information dissemination
uses models recognizable
to Gutenberg
• Pioneered by
British Royal Academy of
Science in the 17th century
• Write manuscripts
• “Publish”
• Exchange information
at meetings
Need to convert islands into an integrated system

48. The caBIG™ Initiative
caBIG™ Goal
A virtual network of interconnected data, individuals, and organizations that whose goal is to
redefine how research is conducted, care is provided, and patients/participants interact with
the biomedical research enterprise.
caBIG™ Vision
• Connect the cancer research community through a shareable, interoperable electronic
infrastructure
• Deploy and extend standard rules and a common language to more easily share information
• Build or adapt tools for collecting, analyzing, integrating and disseminating information
associated with cancer research and care

49. caBIG™ Strategy
• Connect the cancer research community
through a shareable, interoperable infrastructure
• Deploy and extend standard rules and a
common language to more easily share
information
• Build or adapt tools for collecting, analyzing,
integrating and disseminating information
associated with cancer research and care

50. Alabama
Birmingham:
UAB Comprehensive Cancer Center
Arizona
Phoenix:
Translational Genomics Research Institute
Tucson:
University of Arizona
California
Berkeley:
University of California Lawrence Berkeley National
Laboratory
University of California at Berkeley
Los Angeles:
AECOM
California Institute of Technology
University of Southern California Information Sciences
Institute
University of California at Irvine The Chao Family
Comprehensive Cancer Center
La Jolla:
The Burnham Institute
Sacramento:
University of California Davis Cancer Center
San Diego:
SAIC
San Francisco:
University of California San Francisco Comprehensive
Cancer Center
Colorado
Aurora:
University of Colorado Cancer Center
District of Columbia
Department of Veterans Affairs
Lombardi Cancer Research Center - Georgetown
University Medical Center
Florida
Tampa:
H. Lee Moffitt Cancer Center at the University of South
Florida
Hawaii
Manoa:
Cancer Research Center of Hawaii
Illinois
Argonne:
Argonne National Laboratory
Chicago:
Robert H. Lurie Comprehensive Cancer Center of
Northwestern University
University of Chicago Cancer Research Center
Urbana-Champaign:
University of Illinois at Urbana-Champaign
Indiana
Indianapolis:
Indiana University Cancer Center
Regenstrief Institute, Inc.
Iowa
Iowa City:
Holden Comprehensive Canter Center at the University
of Iowa
Louisiana
New Orleans:
Tulane University School of Medicine
Maine
Bar Harbor:
The Jackson Laboratory
Maryland
Baltimore:
The Sidney Kimmel Comprehensive Cancer Center at
Johns Hopkins University
Bethesda:
Consumer Advocates in Research and Related Activities
(CARRA)
NCI Cancer Therapy Evaluation Program
NCI Center for Bioinformatics
NCI Center for Cancer Research
NCI Center for Strategic Dissemination
NCI Division of Cancer Control and Population Sciences
NCI Division of Cancer Epidemiology and Genetics
NCI Division of Cancer Prevention
NCI Division of Cancer Treatment and Diagnosis
Terrapin Systems
Rockville:
Capital Technology Information Services
Emmes Corporation
Information Management Services, Inc.
Massachusetts
Cambridge:
Akaza Research
Massachusetts Institute of Technology
Somerville:
Panther Informatics
Michigan
Ann Arbor:
Internet2
University of Michigan Comprehensive Cancer Center
Detroit:
Meyer L. Prentis/Karmanos Comprehensive Cancer
Center
Minnesota
Minneapolis:
University of Minnesota Cancer Center
Rochester:
Mayo Clinic Cancer Center
Nebraska
Omaha:
University of Nebraska Medical Center/Eppley Cancer
Center
New Hampshire
Lebanon:
Dartmouth College
Dartmouth-Hitchcock Medical Center
New York
Buffalo:
Roswell Park Cancer Institute
Bronx:
Albert Einstein Cancer Center
Cold Spring Harbor:
Cold Spring Harbor Laboratory
New York:
Herbert Irving Comprehensive Cancer Center Columbia University
Memorial Sloan-Kettering Cancer Center
New York University Medical Center
White Plains:
IBM
North Carolina
Chapel Hill:
University of North Carolina Lineberger Comprehensive Cancer
Center
Raleigh-Durham:
Alpha-Gamma Technologies, Inc.
Constella Health Sciences
Duke Comprehensive Cancer Center
Ohio
Cleveland:
Case Comprehensive Cancer Center
Columbus:
Ohio State University Comprehensive Cancer Center
Oregon
Portland:
Oregon Health & Science University
Pennsylvania
Philadelphia:
Drexel University
Fox Chase Cancer Center
Kimmel Cancer Center at Thomas Jefferson University
Abramson Cancer Center of the University of Pennsylvania
Pittsburgh:
University of Pittsburgh Cancer Institute
Tennessee
Memphis:
St. Jude’s Children’s Research Hospital
Texas
Austin:
9 Star Research
Houston:
M.D. Anderson Cancer Center
Virginia
Fairfax:
SRA International
Reston:
Scenpro
Washington
Seattle:
DataWorks Development, Inc.
Fred Hutchinson Cancer Research Center
International
Paris, France:
Sanofi Aventis
caBIG™ is utilizing information
technology to join islands into a
community

51. caBIG™ Tools and Infrastructure
NCI-Designated Cancer Centers,
Community Cancer Centers, and
Community Oncology Programs
• caBIG™ adoption is unfolding in:
• 56 NCI-designated
Cancer Centers
• 16 NCI Community
Cancer Center Sites
• caBIG™ being integrated into federal
health architecture to connect Nationwide
Health Information Network
• Global Expansion
• United Kingdom
• China
• India
• Latin America

52. Molecular Medicine:
Pre-emptive, Preventive, Participatory,
Personalized

53. Molecular medicine
Trials outcomes
Practice outcomes
Extended participant access
A Bridge Between
Research and Care Delivery
Shared HIT
• Infrastructure
• Standards
• Development
caBIGTM is already linking clinical practice to clinical research
E Health
Record
Clinical Practice
• Medical centers
• Community hospitals
• Private practice
• Government
Clinical Research
• Academic centers
• Pharma/CROs
• Biotech
• Government
Molecular Medicine
• Molecular Profiling
• Family History
• Molecular Diagnostics

54. Scientific Literature / Research Community
Aggregated Data
(via standards)
Aggregated Data
(via standards)
Diagnostic Results
NCCCP Center - Patient and Physician
The BIG-Health™ Model…
• Genomic Health
• Genzyme
• Monogram
• Covance.
ROLE: Traditional and
molecular testing
• Navigenics
• 23andMe
ROLE: Genetic data
Sample and
medical info
Diagnostic
Labs
Sample
Genomic Results
Personal
Genomics
Firms
EHRs
PHRs
ROLE: Data integration
• Google
• Healthvault
Clinical Data
ROLE: Analysis
• Baylor
• Duke
• Lombardi
• UCSF
Association Results
Personalized Treatment
Research
Centers
Pharma
Industry

55. Scientific Literature / Research Community
Aggregated Data
(via standards)
Aggregated Data
(via standards)
Diagnostic Results
NCCCP Center - Patient and Physician
BIG-Health™ Value Propositions
Diagnostic
Labs
Genomic Results
Personal
Genomics
Firms
EHRs
PHRs
Clinical Data
Association Results
Personalized Treatment
Research
Centers
Pharma
Industry
Physician: Real-
time knowledge;
improved clinical
outcomes
Personal
Genomics
Firms: Broader
market; research
validation
PHR and EHR Providers:
Broader market
Research Centers:
Faster discovery;
improved productivity
Patient: Research
participation and
improved
treatments
Diagnostic Labs:
Broader market
Scientific Literature / Research Community : Enhanced Knowledge
Pharma Industry:
Discovery Engine +
Patient Cohorts
NCCCP Center: Unity
of research and care

56. Current Ecosystem Participation
Academic
• Baylor
• Duke
• Georgetown
• UCSF
Diagnostic
• Genzyme
Genetics
• Genomic Health
Platform
• Affymetrix
Pharmaceutical
• Genentech
• Novartis
IT
• Microsoft
Foundation
• Gates Foundation
• FasterCures
• Personalized Medicine Coalition
• Prostate Cancer Foundation
• Canyon Ranch Institute
Government
• ONC
• HHS Personalized Medicine
Initiative
Payer
• Kaiser Permanente
Venture Capital
• Kleiner Perkins
• MDV
• Health Evolution Partners
• 5am Ventures
Personal Genomics
• Navigenics
• 23 and Me

57. HL7’s Role in these two Contexts
• Key components
• RIM
• Data type specification
• Terminology binding infrastructure
• Document architecture
• Services-Aware Enterprise Architecture Framework
• Adoption of various components by
• Canada Infoway
• NCI
• UK NHS
• DoD/VA
• Collaboration with
• ISO, CEN, CDISC, IHE, HITSP, etc.

58. Q U E S T I O N S
A N S W E R S