caCIS® and TRANSCEND: Complements and Continuity

1. caCIS® and TRANSCEND: Complements and Continuity A Roadmap for Value between the NCI and TRANSCEND

2. NCI Partnering with UCSF to support I-SPY2 • TRANSCEND is the facilitating infrastructure between a Clinical Trial and native systems • Fundamental – communications between EHRs and Clinical Trial Systems • A more sophisticated view is that you are using services to build an architecture to extend and refine the integrations between any number of systems that are involved in cancer treatment

3. TRANSCEND – Functions and Deployment • TRANSCEND – caCIS v 0.5 – integrating research and clinical care • Functional Requirements • Manage the patient registration lifecycle • Manage eligibility determination • Randomize patients • Track study participants • Manage bio-specimens • Capture clinical data at the point of care and render CRFs using automated methods • Provide traditional web-based CRFs • Manage patient and treatment planning calendars • Initiate the adverse event lifecycle • Storage and retrieval of trial data for each participant or in aggregate • All of these were done as SIDE-BY-SIDE or MIDDLE OUT solutions because of the nature of the vendor systems at UCSF • Shows a flexible strategy on the part of UCSF to adapt their native systems to meet changing science, clinical practice, and demands of research • Slides from www.hogarth.org

4. TRANSCEND and caCIS • caCIS was scoped as TRANSCEND v2 • The initial service portfolio was defined by TRANSCEND interoperability points • The initial scenarios (and now the current ones) were about the intersection between ambulatory oncology and a clinical trial like ISPY2 • Architecturally, caCIS has useful pieces for TRANSCEND v1 and v2 • Solve the short term pain points • Define the integration of other systems with clinical care • Define the longer term extensibility and flexibility • Support ISPY2 • Support other tumor-based clinical trials • Support non-tumor-based clinical trials

5. NCI Partnering with a Community of Systems

6. NCI and TRANSCEND • TRANSCEND shows us one way to put these things together • Points the way for a more comprehensive approach that allows real information and intelligence to be accessible to researchers and clinicians • Our architectural strategy started with an idealization of how these fit together • Build systems for vendors, developers, and organizations • Define behavior and information quality standards that allow a NATIVE, SIDE BY SIDE, or MIDDLE OUT strategy to be identified by the implementer, NOT by NCI • Of course, this is sometimes easier said than done • From our take on the vendor / site perspective, caCIS supports: • Long term increase in interoperability • Intermediate term reduction in cost of integration with other systems • Short term strategies to identify additional consumers of information and to provide a layered architecture that is pluggable to NCI’s

7. Summary: Architecture And Value • caCIS is defining levels of interoperability between systems • Providing integration points that enable interoperability • Groups must build up to those “high bars” • This is a central tenet of caCIS architecture … these points of interoperability allow for great extensibility and future usage • Vendors and Sites can pick their efficiencies, components, and differentiating factors • Barriers to entry are pretty low • It is a chance to build communities of systems that reduce the barriers to provision of care

8. Inventory - Services • Allergy • Chemotherapy Management • Document Builder • Document Exchange • Family History • History & Physical • Immunization • Lab Result • Location Registry • Medication • Natural Language Processing • Order Request Management • Organization Registry • Patient Registry • Problem List • Provider Registry • Referral • Security • Authentication • Authorization • Identification • Anonymization • Consent Registry • Security and Privacy • Non-Repudiation • Federation • Social History • Terminology • Vital Signs

9. Inventory – Interoperability Specs • Referral • Document Builder – CDA • Document Exchange • Planned • Lab Order • Planned Medication Order • Planned Treatment Planning

10. Inventory – Enabling • Referral Management • Chemotherapy Management • Outcomes

11. Architecture - Other • There are other pieces of the architecture, design, and development that are worth noting …. • RIM-based db • Exception Handling • Contract Binding • Choreography engines + Configurations • Document Exchange • Virtual E H R Scaffold • ISO 21090 localized data type specification • Service and Information Specifications, patterns and practices • HL7 + SOA • Identification • RLUS • Orders • Document Management

12. Scenario • Eve Everywoman is a 45 year old WF that presents to her family doctor with a breast lump she noticed on self exam. Dr. FP performs a general history and physical an exam. He notes a 3-4 cm right breast mass and orders a mammogram and breast ultrasound. • She learns that there is a Transcend I-SPY 2 clinical trial that she is eligible for at a nearby institution and she elects to join the study. Her initial referral data is updated with new information obtained by the breast clinic and Gynecologic Oncology Clinic and sent to the Transcend platform using another profile of the caCIS Referral Service. • Her existing pathology, tumor marker, cancer stage and demographic data is included.

13. TRANSCEND v1 Pain Points

14. Pain Point 1 - Timeline • By March 21, the caCIS Architecture Team will have prototype code and work: • Design Work • Information • Analysis • Behavioral • Services • Interoperability Specs • Development • Tolven • Services • Interoperability • Integration Work / Testing • Infrastructure work • After March 21, prototype should move to deployable code • ESB • Interoperability with Epic (?)

15. Pain Points and the Roadmap • Resolving all of the pain points does not resolve TRANSCEND v2 • How is TRANSCEND portable to other sites? • How is TRANSCEND portable to other tumor-based cancers? • How is TRANSCEND portable to non-tumor based cancers? • caCIS has architected or built many of those solutions • Pain Point #1 is resolved using • Document Builder, Document Exchange, QRL Clinical Services • Pain Point #4 is resolved using • QRL Services + interoperability components • Regardless of solution: • Infrastructure • Vocabulary • Exception Handling • Message Exchange Patterns

16. CDA Extraction • CDA’s can be extracted

17. Interoperability Specs form the Extensible Portions

18. Architecture And Value: Transcend v2

19. Conformance: Community

20. Conformance: Behavioral Model

21. ConformanceShared State