Electronic Submission of Medical Documentation (esMD) Electronic Determination of Coverage (eDoC) Home Health User Story January 28, 2015

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 NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute 2

Agenda 3 TopicPresenter AnnouncementsSweta Ladwa Begin Home Health User Story DiscussionSweta Ladwa/Vaishnavi Rao

Wednesday, 1-2PM ET - eDoC Home Health User Story Discussion Wednesday, 2-3 PM ET - HL7 CDP 1 IG Ballot Reconciliation Discussion is CANCELLED Friday, 2-3 PM ET - HL7 CDP 1 IG Ballot Reconciliation Discussion Schedule – This Week

esMD eDoC OCPO User Story Consensus Period The esMD eDoC OCPO User Story Consensus Review period has been extended to Monday, 2/2/15 COB. The Consensus form can be accessed here: *IMPORTANT* - Only Committed Members may vote on the User Story. - Each Organization, no matter the number of Committed Members only receives 1 Vote. If there are multiple committed members from your organization please coordinate your collective vote with them.

esMD eDoC OCPO User Story Consensus *Voting Options : Yes- A Yes vote does not necessarily mean that the deliverable is the ideal one from the perspective of the Initiative Member, but that it is better to move forward than to block the deliverable Yes with Comments- If a consensus process attracts significant comments (through Yes with comment votes), it is expected that the comments be addressed in a future revision of the deliverable. No- Vote with comments indicating a path to address the objection in a way that meets the known concerns of other members of the Community of Interest. “No" vote without such comments will be considered Abstain votes. Abstain- Decline to vote

1.Is the current Home Health Electronic Clinical Template too long? If so, what can we take out? What can be combined/streamlined? 2.Should the Home Health Electronic Clinical Template list include only questions? Or both questions and possible responses? 3.Take a look at what is lacking in documentation other than homebound status (what does Medicare find improper or lacking most often?) Home Health User Story Discussion Topics for CMS Open Door Forum

Should we change the term "electronic clinical template?" If so, to what? -structured documentation tool -documentation capture reminders -Checklist -other ideas? Generation of two different workflows: 1 for Physician F2Fand 1 for NPP F2F Followed by Physician review and co-signature Home Health User Story Discussion Topics for S&I eDoC Workgroup

S&I Framework Phases 9 PhasePlanned ActivitiesPotential 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 EvaluationMeasurement 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 User Story Development

esMD eDoC Use Case The eDoC Use Case has already been developed and is consensus approved. The eDoC Use Case is available here: 0Sections_ docx/ /SIFramework_esMD_eDoC_UseCase_All%20Sections_ docxhttp://wiki.siframework.org/file/view/SIFramework_esMD_eDoC_UseCase_All%2 0Sections_ docx/ /SIFramework_esMD_eDoC_UseCase_All%20Sections_ docx The eDoC Use Case addresses: Defining coverage determination documentation requirements as a combination of structured data sets, unstructured data and exchange templates Determining standards to enable providers to capture of documentation based on payer requirements Defining decision support rules to facilitate provider decision making and preferred order management in light of payer standards Determining standards for privacy and secure exchange of documentation between payers, providers, and suppliers Determining standards for digital signatures on transactions and documents

Describes the real world application as an example or instantiation of the scenario Summarizes the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective Historically, user stories have been utilized to provide clinical context Example Scenario: 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. User Story Development

A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that they occur –This representation can make it easy to communicate how the exchange works by displaying how the different components interact –The primary use of the diagram is in the transition from requirements expressed as use cases to the next and more formal level of refinement Note: Horizontal lines are used to identify the specific activity between the systems Review of Key Use Case Sections Sequence Diagram 12 User Story Development- Sequence Diagram

Dataset Requirements: Include the data elements and data element sets that will be available within the message or document. Each data element included is necessary for some aspect of the Use Case; however, the requirements do not specify exactly how they may be used together. All data element sets may contain multiple data elements unless otherwise stated. The identification of data elements forms the foundation for harmonization activities. The data elements identified in the Use Case set constrains the contents of documents and messages. Issues Risks and Obstacles: Lists the concerns that might interfere with meeting the requirements of the Use Case Note: This list takes into consideration risks outlined in the Charter Review of Key Use Case Sections Dataset Requirements & Issues, Risks & Obstacles 13 User Story Development- Dataset Requirements