530 likes | 689 Views
caEHR Domain SME F2F Meeting #3. Day 1 Houston, TX February 2, 2010. Welcome. Introduction of New Members Project Status Update Agenda Review and Session Objectives. Day 1 Agenda. Welcome and Introductions Project Status <Kevin Hurley> Meeting Objectives Agenda Review
E N D
caEHR Domain SME F2F Meeting #3 Day 1 Houston, TX February 2, 2010
Welcome Introduction of New Members Project Status Update Agenda Review and Session Objectives
Day 1 Agenda • Welcome and Introductions • Project Status <Kevin Hurley> • Meeting Objectives • Agenda Review • Use Case Levelling Walk Through and Use Case Map Review & Status Check • Storyboard Review and Development <lunch> • Storyboard Review and Development • Use Case Development • Referral Order & Billing Related Use Cases • Wrap Up
NCI caEHRProject Updateas ofFriday January 29, 2010Project SponsorCaterina Lasome, PhD, RN, CPHIMSChief Operating OfficerNational Cancer Institute
Overview • NCI CBIIT Strategic Position • Project Introduction • Purpose • Goals • Background • Overview • Project Team • Team Members • Leadership & Governance Structure • Notional Project Approach • Phases • Key Milestones/Activities • Completed or Underway • Project Documentation, References & Artifacts
NCI CBIIT Strategic Position • CBIIT consumes and developsconformant standards-based specifications to resolve business problems • CBIIT validates the viability of specifications through reference implementations • CBIIT deploys and hands off both its specifications and reference implementations to the Commercial and Open-Source vendor communities. Conform Validate Deploy
Project Introduction and Goals Introduction
caEHR Project Purpose “To support the ambulatory oncology clinical care community in the coordination and delivery of improved patient care through the development of consensus-based health IT standards and solutions that meets this sector’s unique EHR needs.”
caEHR Project Goals • We have a series of established caEHR Goals • Over the next 6-to-18 months • Define, design, develop, and deploy a series of prioritized “business capability services” to participating ambulatory oncology sites • Incremental release of service specifications and service code-base suitable for integration with existing systems • The iterative/incremental process, using one-month iterations and 3-month release cycles to stakeholders, will ultimately result in a fully functional reference implementation of an ambulatory oncology EHR (caEHR) • Utilize all relevant content from HL7 EHR FM Release 1.1 and Interoperability Specification validated by caEHR stakeholders • 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)
Steering Committee TEAM MEMBERS & Governance
caEHR Inception Phase Approach & Progress *Information displayed in this graphic is notional pending contract awards, team engagement, and project transition activities.
Continuous Integration Project Approach (Elaboration thru Transition Phases)
Key Milestones & Activities • Stakeholder Engagement Start • HL7 Engagement Underway • caEHR Engagement Plan Approved • CCHIT Engagement Underway • Functional Profile Ballot Process • Presented to HL7 Organization • Infrastructure Engagement Start • Determining team tooling and development environment needs
caEHR Wiki Artifacts Posted Regularly for Stakeholder and Interested Parties Consumption and Comments https://wiki.nci.nih.gov/x/zSJyAQ
Next Steps • Award ARRA contract to support the caEHR project • ESC to approve project charter • ESC to validate and approve the caEHR leadership and governance structure • Project kickoff meeting with new team members • Stakeholder engagement for caEHR software and services • Scope & Vision document approval • Scope sign-off • Infrastructure Engagement Started
Welcome • Introduction of New Members • Caterina Lansome Project Sponsor • Marc Koehn Stakeholder Manager • Robbin Gosa SAIC-F Deputy Program Manager • Agenda Review and Session Objectives • Agenda Review • <add> • Other changes? • Session Objectives • Use Case Leveling Walk Through and Use Case Map Review & Status Check • Continue Development Use Cases • Review Use Cases in New Format • Develop Storyboards • Continue Glossary Development • Review and Answer Questions from Analysis
Welcome • Conference calls and upcoming meetings • February 10, 17, 24 Weekly Teleconference 12 – 2:00 pm ET Meeting Request to be emailed will contains phone in details and Web Ex links • Administration procedures • Travel guidelines • Expense reports • Meeting feedback
Brain Teasers! Which word is the odd one out: • First Second Third Forth Fifth Sixth Seventh Eighth Can you name three consecutive days without using the words: • Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, or Sunday? This riddle must be done IN YOUR HEAD and NOT using paper and a pen. Try it! • Take 1000 and add 40 to it. Now add another 1000.Now add 30. And another 1000.Now add 20. Now add another 1000. Now add 10.What is the total?
Use Case Leveling Walk Through and Use Case Map Review & Status Check Christine Bester, Bill Dumais and Patrick Loyd
Use Case Leveling Criteria • Use case Level ‘(the unstated assumption) • Global statement • Example: manage patient’s health • 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 Leveling Criteria • 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 • 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.) • 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
Use Case Leveling Criteria • Use case Level – 3 • Reflects architecture paradigm. One aspect of this is whether messaging or service based architecture (or both) is deployed in the use case • 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…
Leveled Use Case Walk-thru • Laboratory Use Case Set • Level 1 – Create Electronic Lab Order • Level 2 – Create Electronic Lab Order – CBC • Level 3 – Create Electronic Lab Order – CBC - MSG
Wrap Up Day 1 • Agenda Changes or Additions for tomorrow • < > • Comments/Questions? • Dinner Plans!
caEHR Domain SME F2F Meeting #3 Day 2 Houston, TX February 2, 2010
Day 2 Agenda • Welcome and Introductions • Caterina Lasome, Project Sponsor • Marc Koehn, Stakeholder Manager • Robbin Gosa, SAIC-F Deputy Program Manager • John Koisch, caEHR Architect • Paul Boyes, caEHR Architect • Brief Recap of Day 1 • Domain Analysis Model Review • Use Case Development • Treatment-Related Use Cases <lunch> • Use Case Development Continued • Glossary • Wrap Up
Recap Day One • Project Status Update provide by Kevin Hurley • Use Case Leveling and Use Case Mapping Review • Create Lab Order Set (Levels 1 – 3) • Storyboard and Use Case Development • Referral vs. Consult Discussion • Create Referral Order • Create Consultation Order
Consult and Referral • Consult - A request to another provider to interact with a patient to provide an opinion or advice for the purpose of enabling or confirming a diagnosis. Unlike a referral, this does not include authorization for treatment activities concerning the potential diagnosis. The request shall include the reason for the referral, history of present illness, physical examination and objective data such as laboratory and diagnostic imaging. • Referral - A request to another provider to treat a patient for a presumed diagnosis. The request shall include the reason for the referral, history of present illness, physical examination and objective data such as laboratory and diagnostic imaging. • Transfer of Care - A request to another provider to assume full responsibility for treatment of a patient.
Domain Analysis Model Review Jean Duteau
Domain Analysis Model Review Review Model Components for: • Treatment Plan Template • Treatment Plan
Brain Teasers Part Deux! Brain Bats Warm up… • Le g • Vacation cccccc What is represented by the following: • RUE • habirdnd = butwosh • William MarchWilliam JuneWilliam SeptemberWilliam January
Use Cases Continue with the development of the following use cases: • Coordinate Co-Management • External Data/Document Receipt • Insurance Eligibility Check