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 hoursSuggested 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 ResourcesMost 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 RequirementsRequirements 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 reconciliation at a transition of care; using a portal or secure email to exchange client information with the

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

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, in-person 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 Score Description/NotesFunctional Requirements

1. Modifiable data collection to meet state-specific requirements

5

2. Tasking reminders for care coordination

4 Ideally this should be on the first screen when a client’s record is opened

3. Search narrative notes 24. Health risk behaviors in family 3 Should be on dashboard when record is

opened5. Omaha System charting 46. Create flow sheets 57. Time tracking 5 Should link directly to billing system

Technical Requirements1. Supports DIRECT protocol for email 4 Other forms of email encryption are not

acceptable2. Supports Microsoft Office3. Updates client consent information

based on push from HIO2

4. Provide access to documents only by role

5 Not all staff have access to all documents

Operational Requirements1. Interfaces with existing client database 5 Replace?2. Clinical summaries can be received in

C-CDA format3 (See 2.11 Exchange of Clinical

Summaries via CCR, CCD, C-CDA)Transitional Requirements

1. Template for pre-load of key data from paper records

3

2. Customizable care plans3. Vendor has been in business for at least

five years and has at least 5 clients in our state

4

Copyright © 2014, Margret\A Consulting, LLC. Used with permission of author.

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

PrioritizationA 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 have4 = Highly desirable3 = Desirable2 = Nice to have1 = 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.

EHR for LTPAC: A Primer on Planning and Vendor Selection, Leading Age Center for Aging Services Technologies, 2013. Available at:

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

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%2flong-term-and-post-acute-care-ehr%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/public-health-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 full- blown 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-bdd7-0e3881d01450&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-new-hie-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 HIE, distinguishes between push and pull HIE technology, and describes HIE options and the information exchange priorities and capabilities for HIE in Minnesota.

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

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. Updated 03-10-14

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