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
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.
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.
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.
Functional, Technical, Operational, and Transitional Requirements
Requirements are often characterized to help different stakeholders define them and evaluate them in
product offerings:
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 1

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, inperson training, etc.
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.
Example of Key Differentiators
Requirements
Functional Requirements
1. Modifiable assessment to state-specific
requirements
2. Reminders of data on the assessment
that are incomplete
3. Search narrative notes
4. Prohibit e-prescribing by role
5. Lab results from all external sources
6. Exchange of treatment plan with referring
primary care provider
Score
Description/Notes
5
4
2
5
4
3
Ideally this should be on the first screen
when a client’s record is opened
Only MD may enter prescriptions
Technical Requirements
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 2
1. Supports DIRECT protocol for email
4
2. Interface with ABC billing system
5
Operational Requirements
1. Updates client consent information based
on push from HIE
Transitional Requirements
1. Template for pre-load of key data
2. Vendor has been in business for at least
five years and has at least 5 clients in our
state
Other forms of email encryption are not
acceptable
Replace billing system?
2
3
4
Copyright © 2014, Margret\A Consulting, LLC. Used with permission of author.
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.
Functional Requirements Resources
To understand the scope of requirements to consider, the following resources may be useful:
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.
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 and functions. Also includes a list of 12-15 vendors that supply other behavioral health IT
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 3
software and solutions. Available at: http://www.behavioral.net/article/2013-information-technologyvendor-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
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
Copyright © 2014 Stratis Health.
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 4
Updated 03-12-14