2 Requirements Analysis and Prioritization for EHR and HIE

Section 2.5 Plan Requirements Analysis and Prioritization for HIE and HIT

A critical step to acquiring health information exchange (HIE) technology, or other he alth information technology (HIT) for your social service agency is to perform a requir ements analysis.

Time needed: 40 - 60 hours Suggested other tools: Section 2.3 Workflow and Process Analysis and Redesign for HIE and other HIT

Introduction This step is performed after visioning and goal setting have laid the framework for you r technology acquisition and after you have mapped current workflows and processes a nd evaluated them for improvements you would like to make with HIT.

How to Use A requirements analysis may give you what you need to approach vendors, or may be i ncorporated into a formal request for proposal (RFP). Defining your agency’s specific requirements can be an important part of educating everyone about HIT and building i nterest in this potentially major change.

Requirements Analysis Process and Resources Most experts recommend a four-step process to identify requirements: 1. Gain an overview of the technology to be acquired. Ideally, this should also include some exposure to the marketplace to learn about the range of functionality in products. It can also include reviewing any standards, certification criteria, or published product reviews. 2. Conduct a visioning exercise, set SMART goals, and analyze current workflows and processes to identify opportunities for improvement through HIT. It can also be helpful to review use cases or even document your own uses cases. 3. List the functional, technical, operational, and transitional requirements you have for HIE or other HIT based upon your vision, goals, and opportunities for improvement. 4. Prioritize the requirements in case it is not feasible or practical to acquire technology to meet all your requirements at once. A list of resources to help you understand the scope of functional requirements to cons ider can be found at the end of this tool.

Functional, Technical, Operational, and Transitional Requirements Requirements are often characterized to help different stakeholders define them and ev aluate them in product offerings:

Section 2 Plan—Requirements Analysis and Prioritization for HIE and HIT- 1  Functional Requirements define the features that satisfy the end users’ needs. These may include the ability to send secure email using the Direct protocol, locate a client within an HIE organization (HIO), use a community directory to locate and arrange for available services, scan and archive paper documents received in the agency, manage workflow within the agency through calendars, document workflow, and other HIT tools.  Technical requirements are the conditions under which the system must perform. These requirements specify system performance, security access controls, audit logs, backup and recovery capabilities, etc.  Operational requirements are “behind the scenes” functions that keep the system running. Some of these will be of administrative concern, such as adherence to standards to support interfaces, support of workflow customization, and the vendor’s track record. Others may be more IT-focused, such as system reliability and strong help desk support.  Transitional requirements aid in implementation, such as a vendor-supported data model, in-person training, a template to pre-load key data, etc.

Key Differentiators Document your list of requirements on the form below, using the categories above. A f ew examples are provided in italics. Requirements Score Description/Notes Functional Requirements 1. Modifiable data collection to meet 5 state-specific requirements 2. Tasking reminders 4 Ideally this should be on the first screen when a client’s record is opened 3. Search narrative notes 2 4. Electronic feed from existing 4 transcription system to a new document management system

Technical Requirements 1. Supports Direct protocol for email 4 Other forms of email encryption are not acceptable 2. Supports Microsoft Office 3. Updates client consent information 2 based on push from HIO 4. Provide access to documents only by 5 Not all staff have access to all role documents Operational Requirements 1. Interfaces with existing client database 5 Replace? 2. Clinical summaries can be received in 3 (See 2.6 Exchange of Clinical C-CDA format Summaries via CCR, CCD, C-CDA)

Section 2 Plan—Requirements Analysis and Prioritization for HIE and HIT- 1 Transitional Requirements 1. Template for pre-load of key data 3 2. Vendor has been in business for at least 4 five years and has at least 5 clients in our state

Prioritization A final step in requirements analysis is to prioritize the requirements that are most imp ortant to you. Y must decide what is most important and what you can “live without.” You will probably find that no one product or service supports every possible requirem ent. Be as realistic as you can before you approach your vendor selection so you will n ot be disappointed. You will probably need to approach different vendors for different requirements. For e xample, a state-based HIO will provide a variety of services, but may not provide Dire ct email capability. You may need to hire a general IT person to link the Direct email t o Microsoft Outlook in order to set flags to alert you to receipt of documents. Lower- p riced products have fewer features. For example, a document scanning system may not also provide workflow support that enables you to electronically direct the processing of a document among different staff members. You might simply number the list of requirements within each category, with those at t he top of each category most important. Another approach is to score the requirements: 5 = Must have 4 = Highly desirable 3 = Desirable 2 = Nice to have 1 = Not necessary To ensure that your list and its priorities are complete, return to your vision statement and goals to make sure you have listed the requirements that will get you closest to ach ieving the vision and meeting your goals.

HIE Functional Requirements Resources To understand the scope of HIE requirements to consider, the following resources may be useful: Health Information Exchange Certification Criteria, Certification Commission for Hea lth Information Technology (CCHIT). Available at: https://www.cchit.org/c/document_library/get_file?uuid=cbb290e1-7531-431d-bdd7-0 e3881d01450&groupId=18 This is a comprehensive and technical set of criteria for certification of health informat ion exchange organizations (HIO). Certification Commission for Health Information Technology (CCHIT) announcement of new HIE interoperability testing at HIMSS12. Available at: https://www.cchit.org/press-releases/-/asset_publisher/l7V2/content/2013-03-04-cchit- unveils-new-hie-interoperability-testing-at-himss13;jsessionid=E2F1C4A74387903F5 7D09973C991BB8D

Section 2 Plan—Requirements Analysis and Prioritization for HIE and HIT- 1 This press release describes the pilot of a new HIE compliance testing program conduc ted at the Healthcare Information Management Systems Society (HIMSS) conference i n 2013. A Practical Guide to Understanding Health Information Exchange, Assessing Your Re adiness and Selecting Health Information Exchange Options in Minnesota, Minnesota Department of health, Office of Health Information Technology, 2013. http://www.health.state.mn.us/divs/hpsc/ohit/hieguidance/hieguide.pdf This resource clearly explains health information exchange, distinguishes between pus h and pull HIE technology, and describes HIE options and the information exchange p riorities and capabilities for HIE in Minnesota. Standards Recommended to Achieve Interoperability in Minnesota; Guide 2: Updated August 2011, Minnesota Department of Health, Office of Health Information Technol ogy http://www.health.state.mn.us/e-health/standards/g2standards2011.pdf This resource describes standards recommended for health information exchange and i ncludes a reference grid to navigate the meaningful use of EHR standards and criteria, highlighting the need for health information exchange functionality. It also provides th e specific standards required for Minnesota certification of HIO.

Section 2 Plan—Requirements Analysis and Prioritization for HIE and HIT- 1