2 Requirements Analysis and Prioritization for E-Health

Section 2.9 Plan

Requirements Analysis and Prioritization for EHR and HIE

A critical step to acquiring health information technology (HIT) is to perform a requirements analysis. Although this step is typically aligned with preparing a request for proposal (RFP), the exercise to define the requirements specific to your organization needs can be a very important part of your education about HIT and electronic health record (EHR).

Time needed: 80 – 160 hours Suggested other tools: Section 0.2 Laws and Mandates for e-Health, Section 2.4 Visioning, Goal Setting, and Strategic Planning for EHR and HIE, Section 2.6 Workflow and Process Redesign for EHR and HIE

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

2. How to Use A documented requirements analysis may give you what you need to approach vendors, or may be incorporated into a formal request for proposal (RFP) (see Section 3.4 Soliciting Bids for EHR and HIE: RFI, RFB, RFP). Defining your organization’s specific requirements can be an important part of your facility’s education about HIT.

3. 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 being offered. It can also include reviewal of any existing standards, certification criteria, or published product reviews. 2. Conduct a visioning exercise, set SMART goals, and analyze current workflow and processes to identify opportunities for improvement through HIT. It can also be helpful to review use cases or even document your own use cases. 3. List the functional, technical, operational, and transitional requirements you have for EHR and/or HIE 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 consider can be found at the end of this tool.

4. Functional, Technical, Operational, and Transitional Requirements

Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 1 Requirements are often characterized to help different stakeholders define them and evaluate them in product offerings:  Functional Requirements are those that define the features that satisfy the end users’ needs. These may include the ability to document an assessment, treatment plan, notes, and ease of use, among many other things.  Technical requirements are the conditions under which the system must perform. IT is concerned with system performance, security access controls, audit logs, backup and recovery, 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 between systems, supports 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, etc.

5. Key Differentiators Requirements that are unique to your needs or not prevalent in the marketplace are considered key differentiators. Document your list of requirements on the form below, using the categories above. As you document, bear in mind that while all requirements are important, many of the functional capabilities, much of the technology, and some of the operational elements and transitional support are available in virtually every product offering of the same type. You should decide whether you want to:  List all requirements because the behavioral health EHR marketplace includes many small, local vendors which may not have published lists and generally do not seek certification. You may find that listing all requirements is a safeguard to make sure that all vendors you consider truly do meet the requirements that you would think would be the norm. You can still highlight the key differentiators. A comprehensive list of all requirements you might want to consider is supplied in Section 3.5 EHR – Request for Proposal from Behavioral Health Facility.  List only the key differentiating requirements. A list of all requirements can become very long and distracting as you are trying to evaluate products based on factors that are most important and unique in your environment. You may choose to make the long list, but then transfer the differentiators to a separate list. Below is an example of a list of key differentiators.

6. Example of Key Differentiators Requirements Score Description/Notes Functional Requirements 1. Modifiable assessment to state-specific 5 requirements 2. Reminders of data on the assessment 4 Ideally this should be on the first screen that are incomplete when a client’s record is opened 3. Search narrative notes 2 4. Prohibit e-prescribing by role 5 Only MD may enter prescriptions 5. Lab results from all external sources 4 6. Exchange of treatment plan with referring 3 primary care provider

Technical Requirements

2 1. Supports DIRECT protocol for email 4 Other forms of email encryption are not acceptable 2. Interface with ABC billing system 5 Replace billing system?

Operational Requirements 1. Updates client consent information based 2 on push from HIE

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

7. Prioritization A final step in requirements analysis is to prioritize the requirements that are most important to you. Your list of key differentiators probably will include requirements that not every vendor will offer. Now you must decide what is most important to you and what you can “live without.” You will probably find that no one product supports every possible requirement. Be as realistic as you can before you approach your vendor selection so you will not be disappointed. You might simply number the list of requirements within each category, with those at the 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 your top-priority requirements that will get you closest to achieving the vision and meeting your goals.

8. Functional Requirements Resources To understand the scope of requirements to consider, the following resources may be useful:

9. For a Review of MN Mandates There are a number of requirements and mandates you will need to keep in mind as you determine requirements for your e-health needs. Review document 0- State Mandates for e-Health in the Overview Section of this toolkit.

10. For EHR requirements: 2013 Information Technology Vendor Survey, Behavioral Healthcare, provides a matrix of approximately 40 EHR vendors evaluated on a short list of clinical and administrative/financial features

Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 1 and functions. Also includes a list of 12-15 vendors that supply other behavioral health IT software and solutions. Available at: http://www.behavioral.net/article/2013-information-technology-vendor-survey 2011 Behavioral Health EHR Certification Criteria, Certification Commission for Health Information Technology (CCHIT) provides a comprehensive set of functional statements used as the criteria for certifying products. It can provide a good idea of what is possible. Available at: http://tinyurl.com/lmndofm

11. For HIE requirements: A Practical Guide to Understanding Health Information Exchange, Assessing Your Readiness and Selecting Health Information Exchange Options in Minnesota, Minnesota Department of Health, Office of Health Information Technology, 2013. This resource clearly explains health information exchange, distinguishes between push and pull HIE technology, and describes HIE options and the information exchange priorities and capabilities for HIE in Minnesota. Available at: http://www.health.state.mn.us/divs/hpsc/ohit/hieguidance/hieguide.pdf

The State of Minnesota certifies businesses that provides health information exchange services. You can find a list of certified businesses at this link: http://www.health.state.mn.us/divs/hpsc/ohit/certified.html Certification Commission for Health Information Technology (CCHIT) announcement of new HIE interoperability testing at HIMSS12. This press release describes the pilot of a new HIE compliance testing program conducted at the Healthcare Information Management Systems Society (HIMSS) conference in 2013. Available at: http://tinyurl.com/jwup2lb