1. Electronic Submission of Medical Documentation (esMD) eDoC eClinical Templates on FHIR using Structured Data Capture Use Case
May 6, 2015

2. Meeting Etiquette
Please announce your name each time prior to making comments or suggestions during the call
Remember: If you are not speaking keep your phone on mute
Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call
Hold = Elevator Music = very frustrated speakers and participants
This meeting, like all of our meetings, is being recorded
Another reason to keep your phone on mute when not speaking!
Feel free to use the “Chat” or “Q&A” feature for questions or comments
From S&I Framework to Participants:
Hi everyone: remember to keep your phone on mute 
NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting

3. Agenda Topic Presenter Announcements Sweta Ladwa
eDoC, Structured Data Capture, and FHIR Background
Bob D.
Begin Overview and Discussion on the eDoC eClinical Templates on FHIR using Structured Data Capture Use Case

4. Schedule- This Week Wednesday, 2-3 PM ET
HL7 CDP 1 IG Ballot Reconciliation Meeting
Friday, 2-3 PM ET
HL7 CDP 1 IG Ballot Reconciliation Discussion

5. eDoC eClinical Templates, SDC, and FHIR

6. eDoC Background
The purpose of eDoC Workgroup is to define data sets, templates and standards in providing guidance with decision support, enabling provider capture of required structured documentation, and securely exchanging for benefit determination based on Health Plan/Payer’s coverage and payment rules.
Goal: To achieve provider/supplier documentation required for the electronic determination of coverage by payer’s rules in an efficient manner for payers and providers
Outcome: Successful pilot of templates, decision support, and information exchange standards over standard secure transactions for the purpose of determining coverage

7. SDC Background
Key area of focus is enabling the collection of structured data within EHRs to supplement data collected for other purposes to include determination of coverage for CMS and other Payers
SDC Overview for the esMD eDoC Workgroup can be viewed here:

8. Transported to CMS via CDP1
DRAFT: Not for distribution

9. SDC Background SDC Solution Plan presented in terms of 3 Transactions:
Transaction 1A: Form/Template Request and Response without Patient data
EHR System sends request for blank form/template to Form/Template Repository
Form/template Repository sends requested blank form to EHR System
Transaction 1B: Form/Template Request and Response with Patient data
EHR System sends request for form/template with relevant patient data to Form/Template Repository
Form/Template Repository sends form/template with pre-populated patient data to EHR system
Transaction 1C: EHR System sends completed form/template to External Data Repository

10. FHIR Background
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a draft standard describing data formats and elements (known as "resources") and an Application Programming Interface (API) for exchanging Electronic health records. The standard was created by the Health Level Seven International (HL7) health-care standards organization.
FHIR builds on previous data format standards from HL7, like HL7 version 2.x and HL7 version 3.x. But it is easier to implement because it uses a modern web-based suite of API technology. One of its goals is to facilitate interoperation between legacy health care systems, to make it easy to provide health care information to health care providers and individuals on a wide variety of devices from computers to tablets to cell phones, and to allow third-party application developers to provide medical applications which can be easily integrated into existing systems.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs. FHIR was supported at an American Medical Informatics Association meeting by companies like Cerner which value its open and extensible nature.
FHIR Overview for esMD eDoC Workgroup can be viewed here:

11. Benefits of using SDC and FHIR for eDoC eClinical Templates
Collects comprehensive information at the time of a patient encounter
Saving time, money and resources for CMS/Payers and Providers
Increases the accuracy of the information requested and received
Improved timeliness results in improved accounts receivable cycle for provider, so payments are received sooner
Reduced error rate for highly-utilized services and devices by using templates to guide data generation
Increased efficiency in processing documentation sent by providers using eClinical Templates

12. eDoC SDC and FHIR Use Case Objective and Scope
Leverage the Structured Data Capture(SDC) IHE and HL7 standards, including the HL7 Fast Health Interoperability Resource (FHIR) standard, to define questions and responses used to support CMS eClinical Templates, establish pre-population of responses to pre-defined questions based on data within the EHR, and modify or expand upon pre-populated responses.
The HL7 Complete Documents for Payers Set 1 standard will be leveraged, in addition to the HL7 digital signature standard to verify authorship and delegation of rights, to exchange the contents generated using SDC standards.
This effort will include investigating and recommending solutions for:
Structured Data – Data Set requirements
Structured Data Capture Documentation Templates – Data Capture requirements

13. S&I Framework Lifecycle
Promotes a sustainable ecosystem that drives increasing interoperability and standards adoption
Creates a collaborative, coordinated, incremental standards process that is led by the industry in solving real world problems
Leverages “government as a platform” – provide tools, coordination, and harmonization that will support interested parties as they develop solutions to interoperability and standards adoption.

14. S&I Framework UC Development

15. S&I Framework Phases YOU ARE HERE Phase Planned Activities
Potential Output
Pre-Discovery
Development of Initiative Synopsis
Development of Initiative Charter
Definition of Goals & Initiative Outcomes
Environmental Scan
Project Charter
Discovery
Creation/Validation of Use Cases, User Stories & Functional Requirements
Identification of interoperability gaps, barriers, obstacles and costs
Review of Vocabulary
Use Case
Candidate Standards Inventory
Implementation
Evaluation of candidate standards
Development of Standards Solution Plan
Creation of Implementation Guidance
Implementation Guide
Companion Guide (‘how to guide’)
Exchange Profiles
Code Packages/Reference Implementation
Pilot
Validation of aligned specifications, testing tools, and reference implementation tools
Revision of documentation and tools
Development and presentation of Pilot Proposals
Pilot Demonstration Plan
Evaluation
Measurement of initiative success against goals and outcomes
Identification of best practices and lessons learned from pilots for wider scale deployment
Identification of hard and soft policy tools that could be considered for wider scale deployments
Pilot Evaluation
Pilot Lessons Learned/‘Open House’
YOU ARE HERE

16. Use Case Background
Foundation for identifying and specifying standards required to support data exchange, reference implementations and tools
Ensure consistent and reliable adoption of data exchange standards
Gives contextual background of why esMD standards are necessary
Explains benefits of standards
Describes detailed Scenarios and User Stories which serve as examples of how enhanced technical capabilities will improve task at hand
Scenarios are accompanied by diagrams which provide pictorial representations of the processes, actors involved and the sequence of the information exchange

17. Use Case Development Objectives
Engage Stakeholders as Committed Members, Invite Experts, or Interested Parties in the creation of a Use Case
Identify Scenarios and User Stories that address real-world problems
Keep it simple
Focus on the business and functional requirements: Focus on “what” the requirements should be rather than “how”
Create a finalized Use Case that demonstrates value and supports the proposed goals and success criteria for the Initiative
Publish a finalized Use Case that contains necessary content, supported by artifacts, to enable Harmonization and subsequent S&I Framework efforts to occur
Establish Use Case and supporting artifacts in a reusable fashion to support future health information interchange Initiatives

18. Use Case Development Approach
Incorporate Challenge Statement, Value Statement and Scope Statement from Project Charter
Foster discussion with the workgroup providing introductory context
Develop the Scenarios
Organizes the Use Case into logical components
Develop the User Stories
Provide real life application examples of the improved technology that the Use Case is meant to support
Define the Actors
Derived from User Stories
Identify the Assumptions, Pre-Conditions and Post Conditions
Lay the foundation for creating the Functional and Dataset Requirements
Act as inputs for the standards harmonization activities
Develop the Diagrams
Use Case, Context, Activity, Sequence diagrams represent the interaction between systems

19. Use Case Development Approach (cont’d)
Develop the Functional Requirements
Identify the capabilities a system in a role must have in order to enable interoperable exchange of the healthcare data of interest
Provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application
Includes System Requirements and Information Interchange Requirements
Develop Dataset Requirements
A table representing the data elements and data element sets that will be available within the message or document.
Finalize Issues, Risks and Obstacles
Compiled throughout the Use Case development process
Achieve consensus on the Use Case Package

20. Use Case Outline Tailored for each Initiative
1.0 Preface and Introduction**
2.0 Initiative Overview
2.1 Initiative Challenge Statement**
3.0 Use Case Scope
3.1 Background**
3.2 In Scope
3.2 Out of Scope
3.3 Communities of Interest**
4.0 Value Statement**
5.0 Use Case Assumptions
6.0 Pre-Conditions
7.0 Post Conditions
8.0 Actors and Roles
9.0 Use Case Diagram
10.0 Scenario: Generic Provider Workflow
10.1 User Story 1, 2, x, …
10.2 Activity Diagram
Base Flow
Alternate Flow
10.3 Functional Requirements
Information Interchange Requirements
System Requirements
10.4 Sequence Diagram
11.0 Risks, Issues and Obstacles
12.0 Dataset Requirements
Appendices
Related Use Cases
Previous Work Efforts
References
** Leverage content from Project Charter

21. Review of Key Use Case Sections Assumptions, Pre-Conditions, Post-Conditions
Outlines what needs to be in place to meet or realize Use Case requirements
Functional in nature and state broad overarching concepts related to the Initiative
Serve as a starting point for subsequent harmonization activities
Pre Conditions
Describes the state of the system, from a technical perspective, that must be true before an operation, process, activity or task can be executed
Lists what needs to be in place before executing information exchange as described by Functional Requirements and Dataset requirements
Post Conditions
Describes the state of the system, from a technical perspective, that will result after the execution of the operation, process activity or task

22. Review of Key Use Case Sections Defining the Actors
Outlines business actors who are participants in information exchange requirements for each scenario
A business actor is a person or organization that directly participates in a scenario
Business actor must use a system to perform functions and participate in the information interchange
The system or system actor has roles (send, receive, publish, subscribe or in some cases display) and actions which involve exchanging content.
Example
Actor
System
Role
PCP
EHR System
Sender
Specialist
Receiver
Patient
PHR System

23. Review of Key Use Case Sections Use Case Context Diagram
Conceptually represents business actors interacting with Use Case and User Stories
Provides a pictorial representation of environment where exchange takes place
Characterizes types of interactions that an actor has with a specific system
Shows the association and interaction between business actors and Use Case
Provides an overview of actors (users or external systems) and interactions between them
DRAFT EXAMPLE

24. Review of Key Use Case Sections Scenarios
A comprehensive description of actors, interactions, activities, and requirements associated with information exchange
Pertain to supporting the health information exchange and describing key flows
Scenarios are supplemented by User Stories
Example: Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)
Scenario 1
Scenario 2
User Story 1
User Story 2
User Story 1
User Story 2

25. Review of Key Use Case Sections User Story
Describes real world application as an example or instantiation of a Scenario
Summarizes interaction between Use Case actors, and specifies what information is exchanged from a contextual perspective
Interactions are further described in subsequent sections 
Historically, user stories have been utilized to provide clinical context
Example Scenario (from previous slide): Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)
Example User Story: A Specialist receives a referral and requires more information to treat the patient properly at the point of care. Using an EHR System, the Specialist sends a request to the PCP for the patient’s Clinical Care Summary. The PCP successfully receives the requests, understands the requests, and sends the patient’s Clinical Care Summary back to the Specialist via the EHR System. The Specialist successfully receives the patient information, understands it, and makes an informed decision that can provide better quality of care to the patient.

26. Review of Key Use Case Sections Activity Diagram
A form of a state transition diagram in which all or most of the states are activity states or action states
Illustrates Use Case flows graphically, and represents flow of events and information between actors
Displays the main events/actions required for data exchange and the role of each system in supporting the change

27. Review of Key Use Case Sections Functional Requirements
Identify capabilities a system in a role must have to enable interoperable exchange of healthcare data
Provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application
Functional Requirements include:
Information Interchange Requirements define the system’s name and role
Specify actions associated with actual transport of content from the sending system to the receiving system
System Requirements include requirements internal to the system necessary to participate successfully in the transaction
Detail workflow that is essential to the Use Case

28. Review of Key Use Case Sections Sequence Diagram
Show interactions between objects in sequential order of occurrence
Communicates how exchange works by displaying how different components interact
Primary use of diagram is the transition from requirements expressed as use cases to more formal level of refinement
NOTE: Horizontal lines identify specific activity between systems

29. Review of Key Use Case Sections Dataset Requirements & Issues, Risks & Obstacles
Include data elements and data element sets within message or document
Each data element included is necessary for some aspect of Use Case; however, requirements do not specify exactly how they may be used together
All data element sets may contain multiple data elements unless otherwise stated
Identification of data elements forms the foundation for harmonization activities
Data elements identified in Use Case set constrain the contents of documents and messages
Issues Risks and Obstacles
Concerns that might interfere with meeting requirements of Use Case
NOTE: Take into consideration risks outlined in Project Charter

30. eDoC SDC and FHIR Use Case TimelineWk
Target Date (2015)
All Hands WG Meeting Tasks
Review & Comments from Community via Wiki page
due following Monday by 8 P.M. Eastern 1
5/6
Use Case Kick-Off & UC Process Overview
Introduce: Preface, Introduction, Initiative Overview, Initiative Challenge Statement
Review Preface, Introduction, Initiative Overview, Initiative Challenge Statement 2
5/13
Finalize: Preface, Introduction, Initiative Overview, Initiative Challenge Statement
Introduce: Use Case Scope (Background, In Scope, Out of Scope, Communities of Interest), Value Statement
Review: Use Case Scope (Background, In Scope, Out of Scope, Communities of Interest), Value Statement 3
5/20
Finalize: Use Case Scope (Background, In Scope, Out of Scope, Communities of Interest), Value Statement
Introduce: Use Case Assumptions, Pre-Conditions, Post-Conditions, Actors and Roles
Review: Use Case Assumptions, Pre-Conditions, Post-Conditions, Actors and Roles 4
5/27
Finalize: Use Case Assumptions, Pre-Conditions, Post-Conditions, Actors and Roles
Introduce: Use Case Diagram, Scenario, User Story, Activity Diagram, Base Flow
Review: Use Case Diagram, Scenario, User Story, Activity Diagram, Base Flow 5
6/3
Introduce: Functional Requirements, Information Interchange Requirements, System Requirements, Risks/Issues/Obstacles
Review: Functional Requirements, Information Interchange Requirements, System Requirements, Risks/Issues/Obstacles 6
6/10
Finalize: Functional Requirements, Information Interchange Requirements, System Requirements, Risks/Issues/Obstacles
Introduce: Dataset Requirements 1
Review: Dataset Requirements 1 7
6/17
Finalize: Dataset Requirements Part 1
Introduce: Dataset Requirements 2
Review: Dataset Requirements 2 8
6/24
Finalize: Dataset Requirements 2
Introduce: Dataset Requirements 3
Review: Dataset Requirements 3 9
7/1
Finalize: Dataset Requirements 3
Introduce: Dataset Requirements 4
Review: Dataset Requirements 4 10
7/8
Finalize: Dataset Requirements 4
Begin End-to-End Review
End-to-End Review by Community 11
7/15
Review End-to-End Comments and Dispositions
Begin Consensus
Consensus Voting by Community 12
7/22
Continue Consensus 13
7/29
Review Consensus Comments and Dispositions
Conclude Consensus