Section 2.10 Plan
Requirements Analysis and Prioritization for
EHR and HIE
A critical step to acquiring an electronic health record (EHR), health information exchange (HIE)
technology, or other health information technology (HIT) for your local public health (LPH)
department is to perform a requirements analysis.
Time needed: 40 – 60 hours
Suggested other tools: Section 2.3 Visioning, Goal Setting, and Strategic Planning for EHR and
HIE, Section 2.7 Workflow and Process Analysis and 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. 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 requirement 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:

Functional Requirements define the features that satisfy the end users’ needs. For example, a
nurse is very interested in: having a problem list; being able to perform medication
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 1
reconciliation at a transition of care; using a portal or secure email to exchange client
information with the referring provider, primary care provider, and/or patient-centered
medical home so the current status of the client is known at all times; and access community
resources through one centralized resource.

Technical requirements are the conditions under which the system must perform. IT is
concerned with system performance, assurance that authentication requirements for HIE are
met, 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, 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.
Document your list of requirements, such as on the form below, using the categories above. A few
examples are provided in italics.
Requirements
Functional Requirements
1. Modifiable data collection to meet
state-specific requirements
2. Tasking reminders for care
coordination
3. Search narrative notes
4. Health risk behaviors in family
5. Omaha System charting
6. Create flow sheets
7. Time tracking
Technical Requirements
1. Supports DIRECT protocol for email
2. Supports Microsoft Office
3. Updates client consent information
based on push from HIO
4. Provide access to documents only by
role
Operational Requirements
1. Interfaces with existing client database
2. Clinical summaries can be received in
C-CDA format
Transitional Requirements
1. Template for pre-load of key data from
paper records
2. Customizable care plans
3. Vendor has been in business for at least
five years and has at least 5 clients in
our state
Score
Description/Notes
5
4
2
3
4
5
5
4
Ideally this should be on the first screen
when a client’s record is opened
Should be on dashboard when record is
opened
Should link directly to billing system
Other forms of email encryption are not
acceptable
2
5
Not all staff have access to all documents
5
3
Replace?
(See 2.11 Exchange of Clinical
Summaries via CCR, CCD, C-CDA)
3
4
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 2
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.
Now you must decide what is most important to you and what you can “live without.” You will
probably find that no one product or service supports every possible requirement.
Be as realistic as you can before you approach your vendor selection. You will probably need to
approach different vendors for different requirements. For example, a state-based HIE organization
(HIO) may not provide Direct email capability. You may need to hire an IT professional to link
Direct email to Microsoft Outlook in order to set flags to alert you to receipt of documents. Also
appreciate that lower priced products have fewer features. For example, a document scanning system
may not 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 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:
Public Health Informatics Institute (www.phii.org)
There is no specific list of requirements or vendor list for LPH EHR systems. However, the
Public Health Informatics Institute provides a wide range of tools to assist in discovering
requirements and documenting them.
HL7 EHR-System Public Health Functional Profile, Release 1.1, January 2013
(http://www.hl7.org/implement/standards/product_brief.cfm?product_id=278)
Health Level Seven (HL7) is the predominant standards development organization for EHR
systems. Over the years, various domain groups have developed functional profiles for EHRs
for specific domains. This work is the closest to a set of standard functional requirements for
LPH EHRs.
Adoption and Use of Electronic Health Records and Mobile Technology by Home Health and
Hospice Care Agencies, U.S. 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 a key functionality desired in home health EHRs and the national
picture on rates of adoption. While not focused on LPH, it may be useful from the
perspective of the public health nurse.
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 3
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. This resource is also not focused on LPH, but maybe useful from
the perspective of the public health nurse.
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-post-acute-care-ehr//asset_publisher/kHK2/document/id/158547?redirect=https%3a%2f%2fwww.cchit.org%2flongterm-and-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. As with the above two references, it may be useful from the public health nurse
perspective.
Public Health – EHR Vendors Collaboration Initiative (http://www.phconnect.org/group/publichealth-ehr-vendors-collaboration-initiative)
The Office of the National Coordinator for Health Information Technology (ONC) in
collaboration with the Centers for Disease Control and Prevention (CDC) launched a Public
Health – EHR Vendors Collaboration Initiative. While the initial focus is on meeting Stage 1
and 2 Meaningful Use public health objectives, there are plans to expand the focus to fullblown EHRs for public health.
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 HIOs. The
categorization of the criteria can help you determine what to look for as an LPH department
begins to evaluate HIE options.
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
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 4
This resource clearly explains HIE, 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/ehealth/ehrplan.html
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 HIE functionality. It also provides the specific standards required
for Minnesota certification of HIO.
Copyright © 2014 Stratis Health.
Section 2 Plan—Requirements Analysis and Prioritization for EHR and HIE - 5
Updated 03-10-14