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 an important part of
your education about HIT and electronic health record (EHR).
Time needed: 80 - 160 hours
Suggested other tools: 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 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). If you are not selecting a vendor yourself because you are part of a corporate structure,
you may still be asked to participate in a requirements analysis. You may also have special needs that
you want to convey to corporate leaders. Defining your organization’s specific requirements can be
an important part of your agency’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 include some
exposure to the marketplace to learn about the range of functionality in products. It can also
include reviewing any existing 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 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 define the features that satisfy the end users’needs . For example, a
nurse may be very interested in these features: a problem list, the ability for Outcome and
Assessment Information Set (OASIS) data to be generated automatically from an assessment,
and ease of use.
Technical requirements are the conditions under which the system must perform. IT is
concerned with system performance, 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, 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, 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 for each of the categories
described above. It is not necessary to list these universally available requirements.
List only the requirements that are unique to your agency. Functions may be performed with slight
variation, but users can adjust to these variations. For instance, virtually every home health EHR will
support OASIS documentation. However, some products may not have the ability to support secure
messaging to send alerts to nurses in the field. Not all EHR systems support a patient report card. The
vendor may not currently have the technical capability to support HIE or certain aspects of HIE. List
all desired interfaces. These will be unique to your organization.
You might want to add a description to help you remember what is unique about the requirements, or
notes to explore further. Some examples are illustrated in the requirements list below. Your list may
be one to two pages long. If you find it is getting longer, further marketplace analysis may help you
pare your list down to requirements that are truly unique.
Key Differentiating Requirements with Examples
Requirements
Functional Requirements
1. Health risk behaviors in family
Score
3
2. Search narrative notes
3. Prohibit order entry by role
4. Enforces use of Omaha System
5. Lab results from all external sources
6. Exchange of home health plan of care
Technical Requirements
1. Supports DIRECT protocol for email
2
3
3
4
5
2. Interface with ABC billing system
Operational Requirements
1. Updates patient 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
5
4
Description/Notes
Should be on dashboard when record is
opened
Only MD and NP may enter orders
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.
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 2
Prioritization
A final step in requirements analysis is to prioritize the requirements that are most important to you.
Your list of key differentiators generally 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 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 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 EHR requirements:
Adoption and Use of Electronic Health Records and Mobile Technology by Home Health and
Hospice Care Agencies, US Dept. of Health and Human Services, Center for Disease Control and
Prevention, National Center for Health Statistics, May 20, 2013. Available at:
http://www.cdc.gov/nchs/data/nhsr/nhsr066.pdf
This resource highlights key functionality desired in home health EHRs and the national
picture on rates of adoption.
EHR for LTPAC: A Primer on Planning and Vendor Selection, Leading Age Center for Aging
Services Technologies, 2013. Available at:
http://www.leadingage.org/uploadedFiles/Content/About/CAST/Resources/2013_CAST_EHR_For_
LTPAC_A_Primer_on_Planning_and_Vendor_Selection.pdf
This resource provides a matrix of Long-Term and Post-Acute Care (LTPAC) vendors and
the functionality they provide.
2011 Long Term and Post Acute Care Certified 2011 LTPAC Criteria, Certification Commission for
Health Information Technology (CCHIT). Available at:https://www.cchit.org/long-term-and-postacute-care-ehr/asset_publisher/kHK2/document/id/158547?redirect=https%3a%2f%2fwww.cchit.org%2flong-termand-post-acute-careehr%3fp_p_id%3d101_INSTANCE_kHK2%26p_p_lifecycle%3d0%26p_p_state%3dnormal%26p_
p_mode%3dview%26p_p_col_id%3dcolumn-2%26p_p_col_pos%3d2%26p_p_col_count%3d3
This is a comprehensive set of functional statements used as the criteria for certifying
products and can provide a good idea of all of what is possible.
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 3
For HIE requirements:
Health Information Exchange Certification Criteria, Certification Commission for Health
Information Technology (CCHIT). Available at:
https://www.cchit.org/c/document_library/get_file?uuid=cbb290e1-7531-431d-bdd70e3881d01450&groupId=18
This is a comprehensive and technical set of criteria for certification of health information
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-newhie-interoperability-testing-at-himss13;jsessionid=E2F1C4A74387903F57D09973C991BB8D
This press release describes the pilot of a new HIE compliance testing program conducted at
the Healthcare Information Management Systems Society conference in 2013.
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.
http://www.health.state.mn.us/divs/hpsc/ohit/hieguidance/hieguide.pdf
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.
Standards Recommended to Achieve Interoperability in Minnesota; Guide 2: Updated August 2011,
Minnesota Department of health, Office of Health Information Technology
http://www.health.state.mn.us/e-health/standards/g2standards2011.pdf
This resource describes standards recommended for health information exchange and
includes a reference grid to navigate the meaningful use of EHR standards and criteria,
highlighting the need for health information exchange functionality. It also provides the
specific standards required for Minnesota certification of HIO.
Copyright © 2013
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 4
Updated 03-06-14