NCI caEHR Analysis Stream Project Update as of Friday February 19, 2010

1. NCI caEHRAnalysis Stream Project Updateas ofFriday February 19, 2010

2. Overview • Analyst Team • Project Team Members • Domain Subject Matter Experts • Work Streams and Core Deliverables • caEHR Ambulatory Oncology Functional Profile • ANSI/HL7 EHR-S Functional Model and Oncology EHR Gap Analysis Document • Master Functional Requirements Document for an Ambulatory Oncology extended EHR • Domain Analysis Model • Gap analysis between BRIDG 2.1 and 3.0 and Oncology EHR Requirements Document from ASCO and NCCCP. • Oncology extended EHR Domain Analysis Model with Associated Terminology Bindings • Use Case Development • Overarching Narrative “Journey of a Cancer Patient” • Storyboards • Leveled Use Cases

3. Analysis and Domain SME TEAM MEMBERS

4. Team Members • Helen Stevens Love – Project Analyst • Functional Profile Development • HL7 EHR WG Engagement • HL7 Ambulatory Oncology Task Group • Jean Duteau – Information Analyst • Domain Analysis Modeler • Bill Dumais – Project Analyst • Use Case Development • Patrick Loyd – Project Analyst • Use Case Development • Analyst Architecture Team Liaison • Christine Bester – Project Analyst • Domain SME Team Facilitator • Functional Profile Development • Use Case Development • HL7 Engagement Support for EHR WG, AO Task Group and Interoperability WG

5. Domain Subject Matter Experts • John Ellerton MD, CM FACP • Principal Investigator, Southern Nevada Community Clinical Oncology Program • Adjunct Professor Community Medicine-Oncology, Touro Nevada College of Osteopathic Medicine • Member, Board of Directors CALGB • Member, BOLD (Breast Oncology Local Disease) Task Force, NCI Breast Cancer Steering Committee • Raymond Lord MD Medical Oncologist • Clinical Trials Physician • West Michigan Cancer Center • Kalamazoo, Michigan • Anna Schorer MD Medical Oncologist • Associate Professor of Medicine • Division of Hematology, Oncology and Transplantation • University of Minnesota Ann Setser Oncology Nurse for Clinical Products and Programs, Center for Biomedical Informatics and Information Technology, National Cancer Institute Dianne Reeves Associate Director for Biomedical Data Standards, Center for Biomedical Informatics and Information Technology, National Cancer Institute Gene Kraus BS, MS Cancer Center CIO and Bioinformatics Fellow

6. caEHR Ambulatory Oncology Functional Profile

7. Functional Profile Development Work Stream

8. Functional Profile Objectives At a High Level… • Review and Validate Functional Requirements inputs from ASCO and NCCCP sources • Perform a Gap Analysis between ASCO, NCCCP and HL7/ANSI EHR-S Functional Model R1.1 • Create a Specification that is a valid constraint of the HL7/ANSI EHR-S Functional Model R1.1 • Utilizing all relevant content from HL7 EHR-S FM Release 1.1 with additional consideration given to the HL7 Interoperability and Lifecycle Model

9. Functional Profile Development Process

10. Functional Profile Development Process • Validation of NCCCP St. Joseph’s of Orange and ASCO Core Functional Requirements as the basis to perform Gap Analysis • A number of sources including the St. Joseph’s of Orange EHR requirements, the ASCO/NCI CORE work and the HL7 EHR-S Functional Model R1.1 were reconciled to not only identify gaps but to inform specific perspective on EHR-S Functional Model requirements statements • Reviewed and vetted EHR-S FM functionality requirements resulting in draft caEHR Ambulatory Oncology Functional Profile • Iterative reviews with the Domain SME team to ensure soundness of requirements and additionally prioritize the identified functional requirements

11. Functional Profile Development Outcomes • Contribute additional requirements to HL7 EHR WG for consideration in HL7 EHR FM Release2 (including abstraction from ambulatory oncology context to more general EHR context) • Provide HL7 EHR WG with a robust localization/constraint of all caEHR requirements for consideration as an ambulatory oncology Functional Profile (based on EHR FM R1.1 and/or FM R2) • As per project direction this has taken the form of the Ambulatory Oncology Functional Profile which has been completed and • aggregates CORE, St. Josephs of Orange and EHR-S FM R1 requirements.

12. HL7 EHR Working Group EHR-S Functional Model Release 2 Ambulatory Oncology Functional Profile

13. Functional Profile Status • Baseline Ambulatory Oncology Functional Profile has been completed and submitted – as a starting point – to the HL7 EHR Work Group and the process to seek “Draft Standard for Trial Use (DSTU)” status initiated • HL7 Oncology FP Project has been initiated and HL7 volunteer members are being guided through the profile with a goal to approve it for ballot in the Jan-May 2010 cycle • In addition to HL7 Functional Model Release 1.1 alignment, certain expected Release 2 requirements have also been identified to help maintain alignment with the emerging R2 model.   Also, alignment is being sought with the HL7 EHR Interoperability and the EHR Lifecycle Models as appropriate.

14. Functional Profile Status • HL7 FM Release 2 development is significantly behind schedule impacting our ability to align with it. Consequently we are supporting an accelerated development approach with the HL7 WG with a goal of starting balloting in May-Sept 2010 cycle • A portfolio of use cases and associated discussion documents have been devised to further elaborate the requirements in various priority areas

15. caEHR Domain Analysis model

16. caEHR Domain Analysis Model • A consistent and logical representation of key business concepts. It also provides information on key semantics about these concepts, their use, and their relationships • Draws on concepts from the NCI Life Sciences DAM and the HL7 Consent Directives DAM (which was imported into Enterprise Architect (EA) format and can be found on the NCI SVN servers) • The current version is aligned with and based on BRIDG V3 and hence aligned with the normative HL7 Reference Information Model (RIM)

17. Gap Analysis Inputs… • Biomedical Research Integrated Domain Group (BRIDG) Model 2.1, 3.0 and Oncology EHR Functional Requirements from both ASCO Core and NCCCP St. Joseph’s of Orange Outcome… • Focused on establishing an oncology extended EHR Domain Analysis Model (DAM) which incorporates oncology driven concepts that are not reflected in existing BRIDG models and omits concepts and attributes not required

18. DAM Development • The Oncology DAM reflects the gap as understood at this time • It should be noted that reverse harmonization (i.e. seeking the introduction of caEHR driven requirements back into the BRIDG models) should be deferred until a later stage of the project • caEHR-BRIDG-Gap identifies the linkages between the caEHR DAM and the BRIDG 3.0 model

19. DAM Development • It highlights (by way of a ‘BRIDG’ tag) the specific BRIDG concept where applicable • Based on this, the tagged items that indicate derivation become future harmonization candidates while non-tagged items become candidates for potential addition to BRIDG

20. DAM Lifecycle Status • The model is complete at a conceptual level • By this it is meant that it has strong coverage of the anticipated entities / concepts and reasonable stability at this level • In addition it has attribute level information for those entities from BRIDG and HL7 Reference Information Model (RIM) • Further attribution on those entities unique to caEHR and/or surfaced through the caEHR process will be required going forward

21. DAM Lifecycle Status cont. • It is anticipated that the identified entities will be extended with attribute information in the Elaboration phase of the project. • Also, further harmonization work with existing HL7 artifacts and with the Cancer Data Standards Registry & Repository (caDSR work) – to establish appropriate terminology bindings – is required. • This work would result not only in the addition of further attributes but would also ensure that naming is clear and correct (i.e. aligned). • Some examples of work that will affect the model are patient outcomes reporting, chemotherapy ordering, insurance coverage requests, and consent and privacy concerns.

22. caEHR USE CaSES

23. Narratives, Storyboards and Use Cases • Based on initial inputs from St. Joseph’s of Orange, and NCI Biomedical Research Business Architecture Model (BAM) • Draft Use Case Diagram was crafted based on ambulatory oncology business processes identified to date • Subsequently reviewed and vetted with Domain SME for additional input and later content • Team identified need to level Use Cases as they were created at varying degree’s of abstraction and needed to support all consumers from clinicians to architects and developers

24. Narratives and Storyboards • Overarching Narrative • Intend to chronicle the journey of a cancer patient • Ties the “storyboards” within the use cases back to the narrative where applicable • Vetted with Domain SME team and HL7 Ambulatory Oncology Task Group • Additional Storyboards • Where the narrative does not reflect a specific business process these storyboards provide that context • Developed with the Domain SME input

25. Leveling Process Rationale • Traceability • The leveled use cases allow us to make very high-level statements which are traceable to the business capabilities and • Use cases are easily followed through increasing detail mapping to the specific services that they support • Engagement • Allows us to engage the appropriate audience for the different levels to confirm the details at that level • The Domain SME's confirm top-level, analysts manage transitional level, architects confirm bottom-level. • Allows efficient utilization of limited (scarce) resources

26. Leveling Process Rationale • Organization of Work • has assisted with organizing the multitude of process information being gathered with domain experts • Decomposition of Processes • Allows for introduction of alternative sub-processes • Identifying and managing different methods of arriving at a clinical business process outcome • Focus • the leveling allows us to focus on the relevant details, information, process, and accountability

27. Use Case Leveling Criteria • 4 Levels identified to date to support project outcomes for both analysis and architecture • Use case Level – 0 • Most general; high level business processes • Authored and/or Reviewed by: DEs, Analysts • Example: treat this patient for cancer • Use case Level – 1 • Diagnostic or treatment specific, but only down to department level for business process flow reasons • Authored and/or Reviewed by: DEs, Analysts • Example: treat this patient for cancer by using diagnostics, education, treatments, etc

28. Use Case Leveling Criteria • Use case Level – 2 • Department detail level – test codes included, but still platform independent • Level 2 use cases must drive out the major model dimensions (static/information model, behavioral model, governance model, etc.). Can include some exception conditions. • Authored and/or Reviewed by: DEs, Analysts, Architects • Example: treat this patient for cancer by ordering these lab tests, evaluating the results, customizing a treatment or treatment plan to specifically address concerns

29. Use Case Leveling Criteria • Use case Level – 3 • Add detail of each exchange of information. Includes assumptions about system boundaries. • Authored and/or Reviewed by: Analysts and Architects • Example: treat this patient for cancer by ordering these lab tests in the caEHR system • find the patient, if new add patient, if not check for update • create request(s) for testing for patient, • then evaluate the results, • read the faxed copy of the result or • receive notification in Provider email that a result is ready for viewing, etc…

30. Use Case Leveling Criteria • Use case Level – 4 • Project-specific solution for exchanges detailed in use case level-3 (could be MSG, SOA, or both) • Authored and/or Reviewed by: Architects • Not kept in separate Use Case documents; found in the service specifications themselves • Traceable to originating use case path

31. Use Case Development Process • To ensure a collaborative process between the Analyst and Architecture groups a six step process has been established to ensure a standardized approach • To manage consistency of content, each Use Case follows this development pattern 1. Patient’s primary provider refers patient to oncologist for cancer treatment 2. Provider and Patient have an encounter 3. Provider evaluates Patient’s condition, treatment plan, current statistics, requests diagnostics 4. Provider updates treatment plan 5. Patient is treated, outcomes documented 6. Flow returns to #2, #3, #4, #5, or patient is no longer being treated

32. Use Case Development Process • As the details are driven out they are captured in subsequent levels between the established process steps

33. Use Case Status • Approximately 75 Use Cases identified to date • While some support same business processes, they satisfy the different levels of detail required • 22 assigned ‘Team Draft’ status, meaning they are being consumed by external parties such as the architecture team, analysis team and/or HL7 AO Task Group • Others at various states between Planned (to be defined with the Domain SME team) and Analyst Review (in process of abstracting into various levels) • Managed via the Analytical Artifact Log.xls which is shared between the analyst and architecture teams