Section2.9 Plan

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

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:

  • 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, in-person 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 / Score / Description/Notes
Functional Requirements
  1. Health risk behaviors in family
/ 3 / Should be on dashboard when record is opened
  1. Search narrative notes
/ 2
  1. Prohibit order entry by role
/ 3 / Only MD and NP may enter orders
  1. Enforces use of Omaha System
/ 3
  1. Lab results from all external sources
/ 4
  1. Exchange of home health plan of care
/ 5
Technical Requirements
  1. Supports DIRECT protocol for email
/ 4 / Other forms of email encryption are not acceptable
  1. Interface with ABC billing system
/ 5 / Replace billing system?
Operational Requirements
  1. Updates patient consent information based on push from HIE
/ 2
Transitional Requirements
  1. Template for pre-load of key data
/ 3
  1. Vendor has been in business for at least five years
/ 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 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:

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, LeadingAge Center for Aging Services Technologies, 2013. Available at:

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:

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.

For HIE requirements:

Health Information Exchange Certification Criteria, Certification Commission for Health Information Technology (CCHIT). Available at:

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:

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.

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

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 Updated 03-06-14

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