Although we call this stage “Systems Analysis and Design“, sometimes it feels like ‘Systems Analysis, Select & Purchase’, or more appropriately ‘Organization Analysis, Select the Best System, & then Purchase‘.   Even still, if you do software development or heavy configuration changes in your organization, “Systems Analysis and Design” still fits.

[thim-heading main_title=”Where Did the Designers Go?” title_uppercase=”” clone_title=”” line=””]

In the USA, the “build or buy?” question was answered once and for all when the American Reinvestment & Recovery Act (ARRA) was enacted on February 17, 2009.  Among other things, the   HITECH Act within ARRA (yes, an Act within an Act)  required that virtually all EHRs be Certified to perform specific functions. Within five years,  Partners Healthcare  ditched its celebrated EHR for Epic, and Intermountain lasted about 10 years before abandoning their iconic EHR for Cerner.   It is not that these legendary  EHRs did not meet the requirements for certification, it is simply that the process of certification and re-certification adversely impacts provider organizations.

Because provider organizations of all sizes stopped designing their own major software products such as EHRs, needs assessment and design tools have been replaced by “how to choose your vendor” tools.  However, despite what  and regional extension centers would have you believe, documenting software requirements is still a necessary  (and common) activity in medium to large sized healthcare organizations.

[thim-heading main_title=”Systems Analysis and Design: In a Nutshell” title_uppercase=”” clone_title=”” line=””]
  1. Identify the stakeholders and decision makers
  2. Establish your goals and document your needs
  3. Prioritize what you need and what is nice to have
  4. If building in house
    • Document design and specifications
  5. If buying
    • Write an RFP or RFI
    • Compare systems
    • Check references, Do site visits, and demo
    • Make a selection
    • Negotiate contract
[thim-heading main_title=”The Team: Stakeholders and Decisionmakers” title_uppercase=”” clone_title=”” line=””]

Having the right people on the team is essential for success.  Starting with the project manager (or lead), who is responsible for the project’s operations and overall success. The project manager coordinates the rest of the team during the project. AMA’s Digital Health Implementation Playbook recommends the following team members:

  • Core Team (every meeting)- responsible and accountable for putting together the plan and driving the project forward day to day
    • Clinical Representative(s)
    • Administration Representative(s)
    • Information Technology and/or Information Security Representative
    • Any Priority Department Representatives
  • Leadership (some meetings)- High-level decisionmakers who authorize key decisions, provide budgetary approval, and whose alignment is important
    • Board of Directors
    • C-suite Executives
    • Practice Owners/Partners
  • Advisory Team (some meetings) – A group of advisors for the Core team to consult for perspective and guidance and ensure the team’s
    decisions and leadership proposal are sound

    • End Users
      • Practicing care team members
      • Patient Advisory Board/Patients/ Caregivers
    • Organizational Navigation:
      • A program sponsor
      • Retired Leadership
      • Benefactors
[thim-heading main_title=”Goals and Needs” title_uppercase=”” clone_title=”” line=””]

Presumably you would not have gotten this far if there wasn’t an initial reason to pursue new software or a system change.  This reason is your first need.  An need is articulated from the user or operations perspective.  The specific way that the software addresses the user’s need is called a feature ( or capability).  Any feature that is a must-have (i.e. you can’t do without it), is called a requirement.

So for example, if you wanted to talk like an IT person, you would say “I made a list of all of the needs that the nurses identified for their new documentation template.  Before I turn it on, I’m going to make sure all of their needs match up to the list of features supported by the documentation template and check off the requirements one-by-one to make sure they are all covered.”

Whether the project is small or large, start with needs that are concrete, uncontroversial,  and easy to define. For example,  issues where you lose efficiency, where staff encounter pain points, or where patients’ health or satisfaction suffers are good initial candidate needs. When appropriate, be sure that institutional (e.g. strategic or technical) needs are also included.  Anchoring on these universal needs can benefit your project by:

  1. Crystalizes purpose of the project
  2. Helps buy-in from key stakeholders
  3. Promotes long-term stability and commitment for the project

In smaller organizations you can identify your  needs and requirements from simply having semi-structured conversations with the key users and stakeholders.  However, larger organizations may require various other requirements gathering techniques such as surveys, focus groups, document reviews, observational studies, and patient town halls.  The better your requirements gathering, the better your buy-in from the users will be.  Some organizations have had success with posting a staffed question/answer table in the facility cafeteria, and dropping in on regular department level staff meetings.

For general needs assessment and requirements gathering, consider a brief survey or worksheet like this one from AMA.  You can simply ask:

What areas are most frustrating about your job?
What could we do to make your job easier?
Drawing from your experience with patients, what could we do to make patients’ lives better? 
How might you address one of these opportunity areas if given the resources to do so?
What’s the most important thing we should do this year?

[thim-heading main_title=”Documenting Requirements” title_uppercase=”” clone_title=”” line=””]

Depending on whether you are building or buying, the final product of your systems analysis and design may be design specifications or an RFP.

Design specifications explain your requirements to software developers who will make your software, while the RFP explains your requirements to potential vendors who have already made software. Both documents contain software requirements. RFPs also contain organizational attributes that vendors need to know such as existing IT systems and numbers of users.   On the other hand, design specifications contain user interface specifications, data model  and other information needed to make new software.

Design specifications documents contains the system requirements, use cases, and supplementary specifications that provide the basis for design and development of the system. The following information is provided for each requirement identified in the document:

  • Requirement ID, name, and title
  • Requirement description
  • Use case (a story driven explanation of requirement)

A text-based functional requirements document may be provided instead of a use case model, use case specifications, and supplementary specifications.

Click to see very detailed RFP example.

There are a number of recognized standards for producing  Software Design Documents and specifications, but stick to whatever conventions are dictated by your organization.   Thee Simple Software Design Document is a good start.

Simple Software Design Document
[thim-heading main_title=”Prioritizing Requirements and Comparing Vendors” title_uppercase=”” clone_title=”” line=””]

You will need to prioritize the requirements that you must have, and deprioritize the requirements that may be nice, but not necessary.  Best practice suggests that you first use your teams of subject matter experts and end users.   You may also want to engage your staff population at this point (using town halls or surveys).  A decision matrix can help you rank and sort the priorities.

Handy Vendor Comparison Document.

In addition to your user-generated requirements, there may be other factors to consider when choosing a vendor product.

  1. The IT vendors your organization already uses.
    Interoperability is still a major concern. If you’re already using a variety of health IT for managing patient information and medical care, such as e-prescribing software or a practice management system, choose new technology that can integrate with your existing systems.
  2. Health IT vendors and products that your network are using.
    Give consideration to systems used by other groups you often interact with to help ensure you choose a system that can integrate, or at least communicate, with these other systems.
  3. Systems used by local hospitals and health care systems that may partner with you in the future.
    Other local health care groups may prefer a certain type of EHR and may be willing to subsidize or assist with adoption. Partnering with these groups may help you negotiate a lower-cost option.
[thim-heading main_title=”Cloud Hosted or Not?” title_uppercase=”” clone_title=”” line=””]

[table id=5 /]

[thim-heading main_title=”Contract Negotiation” title_uppercase=”” clone_title=”” line=””]

Once you decide on a vendor (if you are buying), you need to negotiate your contract.  If you can afford one, find a lawyer experienced with Health IT contracts.  The contract is the tool that sets what risks you will bear moving forward, and which are the vendors responsibilities and expectations.  Many vendors will supply you “standard form” contracts, where the terms and conditions of the proposed  contract are prepared by the vendor in advance, and you may feel you have limited ability to negotiate more favorable terms.  Your ability to negotiate changes to an  vendor’s standard form contract  depends on: (i) the importance of your business to the  vendor; (ii) the size of your practice or provider organization; (iii) the amount being spent on the acquisition; and (iv) the market share of the vendor.

Important aspects of the contract include:

  • Shared responsibility for safety and security
  • Safe and Timely Adoption and Implementation
  • Security
  • Reporting and communicating issues (to each other and 3rd parties)
  • Warranties
  • Acceptance criteria
  • Service level Agreements (such as uptime)
  • Support and Maintenance
  • Rights to Data
  • Integrations and Interoperability
  • Intellectual Property
  • Indemnity and Risk Management

For more information, review ONCs  contract guide.