System Recommendation - Health Care

IFSMWeek7.pdf

Home >Information Systems homework help >System Recommendation - Health Care

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial- ShareAlike 3.0 Unported license. © Johns Hopkins University. UMUC has modified this work and it is available under the original license.

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Welcome to Installation and Maintenance of Health IT Systems, System Selection-Functional and Technical

Requirements.

The objectives for this unit, System Selection – Functional and Technical Requirements are to:

• Identify 12 possible steps to choosing an EHR system

• Gather functional requirements from institutions and others

• And document use-cases and relate them to functional requirements

The purchase of an EHR system will have a profound effect on your practice or healthcare institution. It is important that you develop a plan for assessing your institution’s needs to facilitate vendor selection. Today we are going to discuss twelve steps in the decision-making process when choosing an EHR system. Though neither these steps, nor the order in which you choose to execute them are written in stone, we have chosen to present them in a logical progression to help you understand the importance of developing a plan that will work for your organization and to help ensure that you are capable of making a high quality decision when it comes to EHR selection.

The article “How to Select an Electronic Health Record System” lists 12 recommended steps to evaluating an EHR system:

1. Identify the decision makers

2. Clarify your goals

3. Determine functional requirements and write a request for proposal, or RFP

4. Determine RFP recipients

5. Review RFP responses

6. Attend vendor demonstrations

7. Check references

8. Rank vendors

9. Conduct site visits

10. Select a finalist

11. Solidify organizational “buy-in”

12. Negotiate the contract

Now, let’s discuss each of the steps in some detail.

People, as well as whole institutions, are often resistant to change. Despite the fact that many agree on the benefits of using

electronic records, resistance will certainly become evident when discussing conversion to an EHR system within your own

institution. Success or failure will often hinge on how well the EHR system is received by managers and practitioners alike, as

well as on ensuring staff and management are comfortable that their concerns have been adequately addressed during the

decision-making process.

Here are some tips to help ensure adequate buy in for your EHR selection process:

In many healthcare institutions, the selection of EHR systems has been led by committed physicians who devote much time and

energy into learning about EHR systems and promoting adoption to their peers. Consider this tactic when considering who will be

involved in the selection process. Also, remember to keep your committee as diverse as possible, being sure to invite influential

people from all elements of the institution, managers and staff alike, to assist with the selection efforts.

Before evaluating EHR systems, you must evaluate your institution. In this stage, you’ll want to examine what it is you want to

accomplish with your new EHR system. Define which inefficiencies and limitations you currently see in your environment today.

For instance, do lab reports take too long to be added to the patient chart? Are your billing codes consistently outdated?

Be sure to identify the overall business strategy for your organization and be sure that these goals are in alignment there as well.

A critical step to purchasing any health information technology is performing a requirements analysis of your environment. In the

past, performing a requirements analysis often involved asking stakeholders what they wanted in the application they were

seeking.

For clinical information systems, this process has not worked well, primarily because most stakeholders simply have not been

exposed to these systems adequately to understand their overall potential and possible limitations, often resulting in

assessments with minimal functionality or unrealistic expectations.

Today, most experts recommend a three-step process for identifying functional and non-functional requirements:

1. Understand existing standards

2. Understand the market place and

3. Apply “use cases”

Functional requirements can be defined as those processes that you want a system to perform. These can be discussed as an

overview or can be analyzed in great detail. The more granular you get with your requirements, the better overall understanding

you will have of how the systems will work and the impact implementation will have on workflow and processes. There are

copious examples of functional requirements, from results reporting, to remote access, and on and on.

Conducting a needs assessment will assist in these efforts.

Once you have identified the functionalities your system should have, rank them in order of importance. It may be helpful to

classify them as “must-haves”, “want-to-haves”, and “not-criticals”.

Perhaps results reporting is more important in your institution than electronic fax reports. Maybe remote access is critical

because of the number of satellite locations.

Next, map these needs you have identified to the specific system features and functionality which will address them.

Be sure to take time to learn what’s available from the many vendors providing EHR solutions. Browsing the internet for ideas, as

well as reading up on vendor specifications and trade publications, can give you an idea of what functionality requirements are

most often associated with your particular organization and thus can paint a picture of the “market norm.”

Now let’s discuss the HL7 EHR System Functional Model, which is a repository of standard EHR functions that could be very

helpful in your assessment.

HL7, which stands for Health Level Seven, is an all-volunteer, non-profit organization involved in the development of

international healthcare standards for storing & exchanging clinical and administrative data.

The February, 2007, version of the Functional Model contains more than 160 functions which form a superset of possible EHR

functions – more than any one system is likely to need. Subsets of these functions, called “functional profiles”, are then created

and described for use in specific healthcare settings, such as behavioral health, child health, and emergency department.

Each functional statement has corresponding “conformance criteria” which provide more detail about how the system can carry

out the task.

Healthcare organizations can use this model to help generate their EHR requirements.

The following steps provide a good start in taking advantage of the functional model as a tool.

Learn the key words used in developing criteria:

• Shall is used to indicate a mandatory requirement for an EHR system to achieve conformance with the standard.

• Should indicates an optional or recommended action for an EHR system.

• May indicates an optional or permissible action for an EHR system.

Learn to read the model. Understand that there are over 160 functions divided into three sections:

1. Direct care

2. Supportive

3. Information infrastructure

and that it is represented as a hierarchical list.

Lastly, review the model (particularly a relevant Functional Profile, if available) and select sections relevant to your particular

healthcare setting, then evaluate each of these functions to determine relevance to your organization.

Let’s look at an example of an HL7 functional statement and its related conformance criteria.

The functional statement says the system “provide[s] patient data in a manner that meets local requirements for de-

identification”.

To meet the standard for this function, four conformance criteria are given:

1. “The system shall provide de-identified data according to realm-specific law or custom when requested by an authorized

internal or external party.

2. The system should comply with I.2.4, Extraction of health record information (conformance criteria 2). (The system should

provide de-identification functionality for extracted information.)

3. The system may provide the ability to export deidentified data to authorized recipients.

4. The system may provide a key with de-identified data to enable re-identification of the data or the contact of primary care

provider.”

Non-functional requirements refer to attributes of the system as a whole or its environment rather than to specific tasks that the

user needs to accomplish (like writing an electronic prescription).

Nonfunctional requirements include:

• Usability is the ease with which a system can be learned and used. An example of a nonfunctional requirement for usability

would be that the end user can navigate to any page in the EHR in five clicks or fewer.

• Reliability is the degree of uptime the system must perform for the users. An example of a nonfunctional requirement for

reliability would be that the EHR system will have redundant back ups allowing for 99.5% uptime.

• Performance usually refers to how well the system works for the user in measurable degrees. Examples of performance

would be response time and capacity.

• Supportability is the application’s ability to be easily modified or maintained to accommodate typical usage or change

scenarios.

• Scalability is the ability to increase the number of users or applications associated with the product.

• System requirements would include minimum and recommended required operating systems, commercial-grade software

development tools, specific hardware or platform requirements, and any environmental requirements such as redundant

environmental controls.

• Legal and regulatory requirements would include telecommunication requirements, compliance, etc.

• Security is the ability to provide confidentiality, data integrity, and data availability, for example as mandated by HIPAA. An

example of a nonfunctional requirement for security would be the capability to log all patient access by any user in the system

and retaining such logging for one year.

A use case is a technique for documenting the potential requirements of a new system or any type of system change. Each use

case provides one or more scenarios that explain how the system should interact with the end user or another system

component to achieve a specific goal or function. Use cases are usually written in simple terms and focus on how workflow

processes correspond with system or application processes to accomplish the goal.

As an example, here is a use case scenario for writing a prescription for a patient before an EHR is available. The analyst

gathers this information from interviews, observations, or any combination of the two.

• First, Joe pulls out his prescription pad and pen.

• Next, Joe consults with a pocket drug reference to check the usual dosage.

• Then, Joe glances at Jane's allergy list to make sure she is not allergic to the new medication.

• Next, Joe handwrites the drug name and the "sig" - in other words, the dose, route, frequency, quantity, and number of refills.

• Finally, Joe hands the handwritten prescription paper to Jane for her to bring to the pharmacy.

Now this use case describes the same task with an EHR, also known as “e-prescribing”:

• First, Joe activates the e-prescribing module within the EHR.

• Next, Joe searches for and selects the drug he wants to prescribe, and he sees the usual dosage, frequency, etc., presented

as options on-screen

• Next, the e-prescribing system checks behind the scenes to see whether Jane is allergic to the selected medication or

whether it has any significant interactions with her other current prescriptions.

• Then Joe fills in the required data to complete the prescription. If it is a commonly prescribed medication, he quickly selects a

complete prescription (i.e. drug, dose, route, quantity, refills, etc.) from a list of common options for that drug.

• Finally, Joe asks Jane from which pharmacy she would prefer to pick up the medication, selects that pharmacy in the system,

transmits the e-prescription, and tells Jane it should be available for pickup shortly.

As you can see from comparing the tables, the analyst expects to see significant improvement in this process once the EHR

system has been installed. The analyst will use this scenario to compare performance ratios with each of the EHR vendors.

There could be dozens of use cases to consider when choosing a new EHR system before it is all said and done. The case study

analyst will look at each of the various components including needed software, hardware, data transmission, change in work

flow, etc…that would provide the best fit for seeing each of these scenarios to completion.

Now let’s discuss how you would create a Request For Proposal, or RFP, following a specific outline to tell prospective vendors

what they need to know about your practice in order to provide you with useful information about their products. This will help

ensure that the responses you receive can be easily compared.

A typical outline for an RFP includes:

Cover letter

Introduction and selection process

Background information, including organization size and specialty and current systems and hardware in place

Desired EHR functionality

Vendor information you should receive should (at the very least) include:

Product description

Hardware and network components needed

Customer maintenance and support and warranties

Training available

System implementation plan

Proposed costs

Sample contract and

Applicable references

There are more than 200 different EHR systems currently available on the market. How can you narrow the list to only those EHR systems most relevant for your organization?

Start with these four questions:

1. Does the software have a history of interfacing with your practice management system, or PMS? To work effectively, your PMS (which generally performs operational functions such as patient scheduling, billing, and reporting) and the EHR must be able to share data. This is typically done through a software interface. Building, maintaining, and updating an interface requires the cooperation of personnel from both companies. Be sure that these two systems can talk to each other with a minimal amount of customization.

2. Is the EHR typically marketed to practices of your size? EHR vendors typically market their systems to one of three scales: small practices, with 1 to 15 providers; medium-sized practices, with 10 to 99 providers; or large practices, with 100 or more providers.

3. Does the EHR have favorable published ratings? Several excellent sources for EHR ratings are available. In 2003, for example, the American College of Rheumatology, in conjunction with the Aurora Consulting Group, evaluated EHRs in small practices. Also, trade shows such as Healthcare Information and Management Systems Society, or HIMSS, or Towards an Electronic Patient Record, or TEPR, can provide opportunities to see vendors’ wares and glean knowledge from show-goers.

4. Does the EHR meet your organization’s functionality needs? Will the EHR adequately address all or most of the goals and functionality requirements you are looking to address with your new EHR system? Compare each system to your checklist and rankings and determine which ones should receive an RFP.

Now that you have received responses to your RFP, take one or two sessions as a committee to review the proposals and select

the best candidates based on your criteria.

Next, set up vendor demonstrations with each of your contenders. Prepare a couple of patient scenarios for them to document,

and use a standardized rating form. Use the same approach with each vendor to ensure consistent ratings.

Check at least three references for every vendor that is still in the running. Ideally, references should include one or more

physician users, an information technology (IT) person, and a senior management person. The vendor will provide you with a list

of references – note that these are likely the vendor's happiest customers, and they may even be financially rewarded for talking

to you (e.g., discounts on service fees or individual rewards), so be skeptical. Nonetheless, these folks can be very informative

and honest, in our experience. If you know a person or group not on the vendor's reference list who has used their product, call

them too. Have a prepared list of questions for these phone calls.

Consider asking questions from each reference centered around these areas:

•Background

•Provider usage

•Training and support

•Implementation & hardware and

•Satisfaction

Now that you've reviewed the RFPs, seen the vendor demos, and done all the reference checks for each vendor you are

considering, it's time to rank the vendors and narrow the field to two or three vendors for whom you should set up site visits to

view the software in action. Site visits can take up lots of time and can require the organizational efforts of a master to get your

team together at a common time, making more than three visits pretty much impractical.

Before you rank the vendors, you should formally weigh your priorities in the following areas:

• Functionality. How well does the product perform to your specifications?

• Total cost. How much will the product cost, including all the needed hardware, software, technical support, etc.?

• Vendor Services. Will the vendor provide the expected service, training, and initial implementation support, and will they be

there for the long haul?

Once you've selected your final contenders, plan site visits to see how the systems perform. Go to practices that are similar in

size and configuration to yours. If possible, go to one that is using the same practice management system, or PMS, that you are

using. Bring at least one physician and the most senior management person that will be responsible for the EHR purchase. Plan

to visit with physicians and observe them with patients. Also talk to their back-office personnel, relevant management, and key IT

personnel. Take notes.

Finally, after each site visit, go back to your vendor rankings and see if they still agree with your latest findings. Select your top contender

and a runner-up. If negotiations don't go well with your number one choice, you may want to fall back on your runner up instead of

wasting more time reevaluating the vendor pool again.

Earlier, as part of the RFP, you asked each vendor to list the minimum and recommended hardware and software requirements

for installing their version of the EHR in your institution’s environment. Choosing the right hardware is important to ensure that

your EHR’s performance potential is fully realized and to minimize installation and performance issues down the road.

Hopefully, your institution, as part of the decision-making process, your institution has already come to terms that at least some

technology will need to be acquired or upgraded to accommodate the integration of a new EHR system.

Prior to solidifying a deal with a particular vendor, take a hard look at these requirements, being sure to address these issues:

Take an inventory of your current server, workstation, and mobile technology hardware (such as laptops and PDAs) as well as

the current operating systems and applications being deployed and used in your computing environments. Do the vendor’s

specifications align well with your current technologies?

If the vendor recommendations exceed your current hardware and software requirements, is your organization prepared to

dedicate the financial and organizational resources needed to meet these recommendations?

Your organization is likely already using different patient management software. Your EHR will need to be able to communicate

with this pre-existing system. Does the EHR you’re considering integrate well with these existing packages, or will you need to

budget for customized interface engines or even new PM software applications? We will discuss interfaces and interface engines

in more detail in a later unit.

Purchasing an EHR is usually a long-term commitment. EHR software life cycles can often span decades. Your organization will

want to have the flexibility to integrate new computing technologies as they become available. Is the vendor up to date on these

emerging technology trends, and are they committed to ensuring that their software will be scalable for the foreseeable future?

Hopefully, if you are choosing an EHR system for a smaller practice, you have already included all the relevant decision-makers

in the selection process. Larger organizations may require additional “selling.” Consider inviting the vendor to do a public

demonstration or a presentation to the stakeholders group to help solidify commitment.

As noted before, typical EHR contracts span from 10 years to lifetime. If the contract is to terminate in 10 years, be sure you

know what happens after that. Current and future costs should be spelled out, as should the role the vendor will play and the

amount of time the vendor will commit to the implementation process. Be sure to consider the possibility that the vendor could go

out of business before you do. Request that the vendor's source code be put into escrow, and clarify the circumstances under

which you could get access to it. Have a lawyer experienced in software contracts help with this step.

Now that we’ve walked through those steps on evaluation and selection of EHRs, let’s look briefly at the process as

recommended by HealthIT.gov, a website launched in September, 2011, by ONC, the Office of the National Coordinator for

Health Information Technology. They list 9 steps, which should sound very familiar after our prior discussion:

1. “Site visits for EHR solution

2. Develop and distribute request for proposals (RFPs)

3. Review vendor proposals

4. Conduct vendor demonstrations

5. Review specialty specific functionality and general usability

6. Identify hardware and IT support requirements

7. Rank EHRs and compare functionality, usability, and pricing

8. Negotiate contract and licensing agreements

9. Purchase an EHR solution”

This concludes Unit 3, System Selection – Functional and Technical Requirements.

In summary, it is important to follow a step-wise method carefully in evaluating and selecting an EHR, and we have walked

through 12 such steps from the informatics literature and looked at the 9 similar steps recommended by the federal government.

You should determine and prioritize your functional requirements using various sources, including the HL7 Functional Model, and

create use cases to help determine and illustrate those requirements. And do not forget to pay close attention to the software and

hardware requirements of the systems you consider.

No audio

http://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Welcome to Installation and Maintenance of Health IT Systems, This is System Selection – Software and Certification

This component covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR)

systems.

This unit, System Selection - Software and Certification, will discuss the differences in COTS (Commercial Off-The-Shelf) and

in-house/homegrown systems and how to select the system to meet the needs of the end users

There are many important steps to choosing the correct system for your institution and ensuring that it will be quickly adopted by your users.

Discussion will begin with COTS (Commercial Off-the-Shelf) and MOTS (Modifiable Off-the-Shelf) versus in-house software products; their advantages and disadvantages, along with costs associated with them.

We’ll also discuss EHR certification and ARRA’s meaningful use criteria with regard to EHR systems.

Finally, we will touch on some typical costs associated with selection and implementation of EHR systems.

COTS, or Commercial Off-the-Shelf, is a term used to describe a product that is implemented "as-is" while MOTS, or

Modifiable Off-the-Shelf, refers to a commercially available software product which can be, to some extent, modified

by the purchaser, vendor, or contractor to better suit the purchaser’s specific needs. For the purposes of this

discussion we will refer to both variants as COTS products.

COTS systems are designed by a software vendor to address the needs of many different purchasers. The services

provided are those most popular and often most generic, that are desired by the majority of the customer base.

Most software can be considered COTS; operating systems, office productivity software, and Internet communication

programs are examples. Because it can be sold to a larger market, COTS software may be available at relatively low

cost.

At present, well over 200 software companies offer some sort of off-the-shelf EHR solution. Some of these solutions

include “freeware” solutions, which are open-source products freely available for use, with commercial support.

There are several advantages to buying complete off-the-shelf products.

For starters, vendor companies have already put up the up-front costs associated with developing and testing the product. This is

especially advantageous for smaller healthcare settings that cannot afford an extensive IT development team. As part of the roll-

out process, vendors often will work with the clinical IT teams to ensure the product is successfully integrated within the

healthcare setting and plays well with preexisting software components. When things do go wrong, the vendor provides

additional troubleshooting and support and usually works with the IT staff to resolve software glitches and bugs. The COTS

products also generally have previously developed training documentation. This can mean that difficulties in learning the new

system have been addressed in previous installations at other institutions.

Because the vendor generally has already created training programs and materials to help ensure a successful adoption of the

product into the workplace, users and administrators can often be brought up to speed faster than with an in-house product.

Because many EHR systems are proprietary, access to the source code is often limited or nonexistent. This reduces the

flexibility of the program and makes the institution dependent on the vendor to make enhancements to the system, which are

often costly.

Compatibility is also a concern as EHR vendors must contend with an ever-increasing variety of hardware and software

combinations. Add in the staggering number of drivers, peripherals, testing devices, and so on, and it becomes obvious that

there is no way the vendor can test compatibility for all possible combinations. The issue is compounded with every new

upgrade, which holds the potential to “break” something that was working perfectly in the earlier version. If a COTS product is in

your institution’s future, you will need a plan that adequately addresses which users will receive upgrades and when, as well as

contingency plans for use in the event that the upgrade is not successful. Be sure that an adequate test environment exists in

your institution and that upgrades are thoroughly tested before deployment.

Each vendor is different with regard to frequency of upgrades. Reputable vendors theoretically are motivated to maintain a high

level of product quality; however, this is not a guarantee. Keep open lines of communication with your vendor and stay abreast of

product issues and pending upgrades. Never assume the vendor will meet upgrade release dates and never assume a certain

level of quality until you have tested the product in your own institution's environments.

Another disadvantage to purchasing a COTS product is the inability to find a product that fits your institution “just perfectly,” often

requiring workflow changes on an institutional level for successful adoption of the product.

Some institutions decide to build their own in-house EHR solution. In-house software is developed by the operating institution

and installed and managed by an existing IT team.

This kind of development is only undertaken by larger organizations with their own IT departments.

Development of the EHR system will often start through extension of existing In-House systems. Alternatively, the institution may

elect to use an open-source or otherwise modifiable system and (depending on the software license) adapt it solely for its own

use, or participate in further public development by contributing changes back to the source.

More often than not, the decision to build an EHR in-house is driven by the desire to make a product that can fully integrate with

existing software and/or closely match institutional processes and objectives.

The existing IT infrastructure and personnel will guide development of the system to ensure maximum compatibility with existing

processes.

There are several obstacles to creating your own in-house EHR solution.

First of all, you need to have the right team in place. If you decide to build an in-house solution, you will be spending a lot of

time, money, and energy in recruiting and retaining quality IT developers capable of implementing such a large-scale project. Not

many people take into consideration the costs involved in recruiting and hiring the right software development team along with

the associated hardware and software needed to develop, compile and test coding components. You should expect to expend

years of effort and dedicated resources toward the development and implementation process of an in-house EHR solution.

Secondly, you should have a person capable of monitoring and assessing the quality of the work, the output, and the productivity

of the team hired. This consultant or project manager represents another added expense.

Likewise, your IT team will need to stand on its own when testing, troubleshooting, debugging, or adding enhancements to the

EHR system throughout the product's entire lifecycle. This takes lots of time and resources. Products developed by vendors

have the advantage of multiple clients providing feedback and bug reporting.

Lastly, before the product can be successfully rolled out to your users, planning programs and materials must be created,

generally from scratch.

Given these obstacles, it's not surprising that many healthcare institutions – especially those that are not large institutions with adequate

resources – choose to go with a COTS or MOTS software solution.

The Office of the National Coordinator for Health Information Technology (ONC), as empowered by the US Department of Health

and Human Services, provides for a certification program for Health Information Technology providers and systems.

According to ONC, “Certification of Health IT will provide assurance to purchasers and other users that an EHR system, or other

relevant technology, offers the necessary technological capability, functionality, and security to help them meet the meaningful

use criteria established for a given phase. Providers and patients must also be confident that the electronic health IT products

and systems they use are secure, can maintain data confidentially, and can work with other systems to share information”

Given that use of a certified system means eligibility for payments from Medicare and Medicaid incentive programs – up to

$44,000 for individual practitioners, and over $2 million for participating hospitals – there is strong incentive for any EHR system

or module to become certified by an ATCB.

A Final Rule on an initial set of standards, implementation specifications, and certification criteria for adoption by the HHS

Secretary was issued on July 13, 2010. This Final Rule represents the first step in an incremental approach to adopting

standards, implementation specifications, and certification criteria to enhance the interoperability, functionality, utility, and

security of health IT and to support its meaningful use. The certification criteria adopted in this initial set establish the required

capabilities and related standards and implementation specifications that certified electronic health record (EHR) technology will

need to include in order to, at a minimum, support the achievement of meaningful use Stage 1 (beginning in 2011) by eligible

professionals and eligible hospitals under the Medicare and Medicaid EHR incentive programs.

Certification of EHR systems accomplishes four major goals:

It reduces the risks to investment in EHR systems, which represent a sizable business investment, by providing additional

assurance that the system is worthwhile.

It may facilitate interoperability between EHR systems, as multiple systems would adhere to the same set of standards.

As mentioned previously, certification is a prerequisite for Medicare and Medicaid incentive payments, among other stimulus

incentives.

Finally, certification requires that EHR systems and networks protect the privacy of personal health information.

Choosing to narrow your search to certified EHR products also allows you, as the evaluator, to be assured that each of the

certified software products will meet similar standards for basic functionality, interoperability, and security. This will allow you to

focus your evaluation more on any special or unusual needs of your institution. It’s important to note that interoperability is at an

early stage and requirements for interoperability are still being established.

Note: Certification examines only the system itself, and does not evaluate the company’s service aspects or financial solvency.

You should perform this type of due diligence yourself. It is important to know that your vendor has a good reputation and plans

to provide continuous support for your software throughout the product’s lifecycle.

ARRA (American Recovery and Reinvestment Act of 2009), commonly referred to as the “stimulus bill”, is the economic package passed by the U.S. Congress in February 2009. Of the $787 billon in expenditures, $22 billion were allocated to facilitate modernization of health information technology systems.

The HITECH Act, part of the stimulus package, aims to induce more physicians to adopt EHRs with potential payments of more than $40,000/yr via Medicare or more than $60,000/yr via Medicaid during the initial years of the program.

Starting in 2015, failure to meaningfully use health IT will lead to financial penalties, starting with 1% reduction in Medicare reimbursement and growing over time.

The meaningful use of EHRs, promoted by US government incentives, can be broken into five categories:

1. Improve Quality, Safety, Efficiency, and Reduce Health Disparities

2. Engage Patients and Families in Their Health Care

3. Improve Care Coordination

4. Improve Population and Public Health

5. Ensure Adequate Privacy and Security Protections for Personal Health Information

Let’s take a look at each of these five categories in better detail, starting with number one: Improve Quality, Safety, and Efficiency, and Reduce

Health Disparities.

In order to meet this criteria, EHR systems are expected to:

• Use Computerized Provider Order Entry, or CPOE, which allows the authorizing provider to enter the order directly, for at

least 10% of all orders, of any type

• Implement drug-drug, drug-allergy, & drug-formulary checks

• Maintain an up-to-date problem list of current and active diagnoses, based on ICD-9 or SNOMED

• Maintain active medication list

• Maintain active medication allergy list

Furthermore the government requires EHR systems to:

• Record demographics (preferred language, insurance type, gender, race, ethnicity, date of birth, date and cause of death in

the event of mortality)

• Record and chart changes in vital signs: height, weight, blood pressure; calculate and display BMI; plot and display growth

chart, including BMI, for children from 2-20 years old.

Compliance also means providers must use technology to:

• Record smoking status for patients 13 years old or older

• Incorporate clinical laboratory test results in the EHR as structured data

• Generate lists of patients by specific conditions

• Report hospital quality measures to CMS or to the states

• Implement five clinical decision support rules relevant to specialty or high clinical priority, including for diagnostic test

ordering, along with the ability to track compliance with those rules

• Submit claims electronically to public and private payers

In order for EHR systems to meet the specifications laid out for category two, Engage Patients and Families in Their Health Care, EHR systems are expected to:

• Provide patients with an electronic copy of their health information (including diagnostic test results, problem list, medication lists, allergies, discharge summary, procedures) upon request

• Provide patients with an electronic copy of their discharge instructions at the time of discharge, upon request.

In order for EHR systems to meet the specifications laid out for category three, Improve Care Coordination, EHR systems are expected to:

• Electronically exchange key clinical information (problem list, medication list, allergies, and diagnostic test results) among

care providers and patient-authorized entities

• Perform medication reconciliation at relevant encounters and each transition of care

• Provide summary of care record for each transition of care and referral

In order for EHR systems to meet the specifications laid out for category four, Improve Population and Public Health, EHR systems are

expected to have the capability to:

• Submit electronic data to immunization registries

• Provide electronic submission of reportable lab results (as required by state or local law) to public health agencies.

• Provide electronic syndromic surveillance data to public health agencies.

In order for EHR systems to meet the specifications laid out for category five, Ensure Adequate Privacy and Security Protections for Personal

Health Information, EHR systems are expected to protect electronic health information created or maintained by the certified

EHR technology through the implementation of appropriate technical capabilities.

The Stage 2 and Stage 3 Meaningful Use requirements are not officially defined as of 2011. However, according to the

Department of Health & Human Services, “we [can] expect that stage two meaningful use requirements will include rigorous

expectations for health information exchange, including more demanding requirements for e-prescribing and incorporating

structured laboratory results and the expectation that providers will electronically transmit patient care summaries to support

transitions in care across unaffiliated providers, settings and EHR systems.”

Startup costs include:

• New hardware and network components, including servers, switches, cabling, racks

• Software components, including purchasing and licensing the EHR product, along with any customization and support

contracts

and

• Interfaces, including laptops, workstations, PDAs, etc.

Bear in mind that licensing options vary and different licensing options may be available for each product. As an example, a

single user license or tiered pricing (where the fees are different depending on the level of access the user has to the system)

may be quite viable for a small practice. On the other hand, site licensing (a single fee covering all potential employees for an

entity) may be a more viable option for larger entities but far too costly for the smaller practice settings.

Maintenance costs include all costs associated with the continued upkeep, maintenance, and upgrades to the system. This

would include routine hardware replacement, software support fees, licensing renewals, and major upgrades.

Training costs include fees incurred by the vendor to train new system users and administrators during startup, as well as

training materials, simulators, etc., throughout the lifecycle of the product.

What are the anticipated productivity costs associated with the implementation of this product? Are the users going to have to

make significant changes in workflow resulting in substantial loss in productivity?

Lastly, what consultants will you need to bring in to implement the installation? Wireless and network upgrades may require

consultation to ensure optimal results. Will you be bringing in an implementation specialist at $125/hour?

Be sure to consider these costs when selecting an EHR system.

This concludes System Selection – Software and Certification.

In summary, when choosing a system, be aware of broad categories of systems available for selection. Weigh the advantages

and disadvantages of them, paying special attention to the required resources for development and maintenance. Certification of

systems should be strongly considered. Finally, any system that is considered and implemented should address the meaningful

use priorities.

No audio

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.

https://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

This is component 14, unit 3. We will be discussing how organizations select an Electronic Health Record (EHR), Lessons from the Frontlines. A tremendous amount of work is involved in selecting an EHR. We can't cover all the topics today but we will be discussing four of the principle tasks involved in selecting an EHR.

This unit will prepare students to be able to: 1. Demonstrate concept knowledge of the request for proposal (RFP) process 2. We will talk about stakeholders’ involvement, and their roles in selecting an EHR 3. Then we will review the costs that needed to be calculated when selecting an EHR, the capital, the maintenance and staffing costs. 4. Lastly, we will discuss the importance of evaluating the financial strength of each vendor being evaluated.

A request for a proposal, or RFP, is a document that is sent to suppliers. It invites them to submit a proposal to provide goods and services. Remember that it's only to be used for complex projects that require the vendor or supplier to be creative. Very importantly it assists with internal alignment. It's one of the best means to force an organization to describe its needs before involving a vendor. Assembling the responses to the RFP helps an organization compare vendors and understand potential project risks.

However, you need to remember that the RFP process is very time consuming for both the purchaser and the vendor. And it is always difficult to accurately describe all the requirements and, and even when you get all of the results in. Additionally, it's hard to make the comparisons and score responses.

What does an RFP include? It will include an overview of the business issues, what are you trying to accomplish? It will include a description of the product or the services that you require. It needs to detail all the business requirements. It requires specific instructions on how the proposal will be formatted, when it will be returned by the vendor, detailed instructions on how to select the vendors, what is the required timeline and many, many questions and must include who to contact for the vendor if they have any questions.

In addition to RFP's, there are other request formats that could be useful during your search for an Electronic Medical Record (EMR). There's a request for quotation, when you actually know exactly what you want and you're looking to find out what the prices are when price is the main factor.

You can issue a request for information, which is used to find out who's a potential seller of products and knowing the capabilities of those sellers in the market.

Before a request for proposal goes out, a request for qualifications (RFQ), an RFQ could be issued to find out who you would send the RFP to.

HIMSS is an excellent source for sample RFP documents. They're meant to act as tools used by health organizations and other healthcare providers in developing it’s own RFP. Remember they're meant to be starting points for your RFP. The questions and requirements are meant to be illustrative and not exhaustive. You cannot take an RFP from the HIMSS site and simply issue it. It's meant to help you get started in developing your own after extensive meetings with stakeholders and detailed determination of your own specifications.

And remember that access to the sample RFP documents requires active HIMSS membership.

As an example, I was able to find, on the HIMSS website, an ambulatory EHR sample RFP. Remember, it's provided as a tool for your organization to use and develop its own RFP. It's a structured approach to listing the various criteria that may be relevant in the RFP process. It's part of the series of documents that list the common features and questions that need to be answered for enterprise systems that are normally evaluated by an RFP but require extensive editing by you and your organization. Now that we've discussed the RFP process, let's move on to stakeholders, another important aspect of selecting an EHR.

Involving stakeholders is a crucial aspect of the project. The notion of stakeholder dates back to a 1963 internal memorandum at Stanford, which defined stakeholders as quote, those groups without whose support the organization would cease to exist, close quotes. It was later championed by Edward Freeman in the 80's and gained wide acceptance in business practice.

Stakeholder theory is a theory of organizational management in business ethics that talks about morals and values and managing an organization. Management needs to give due regard to the interest of groups. Stakeholder theory addresses the principle of who or what really counts.

Every organization and every type of organization has its own set of stakeholders. In addition, every project will have its own stakeholders. In selecting an EHR, the project won't involve everyone in the organization but it will involve many of the principal stakeholders. Here we list a set of stakeholders who may be involved in an EHR selection process: physicians, nurses, clerical staff, lab staff, management, and you also need to remember your product suppliers and even patients and the community as you research your needs to select an EHR. All of these groups should be involved, at least at some level, in your discussions and in developing your detailed selection specifications. Knowing who to involve is the first step. It’s important to know exactly how to engage your stakeholders.

One of the most important roles that stakeholders can play is to help develop communication plans, which are targeted to the specific stakeholders involved. Using stakeholders to review all communication is very important. They also know how to develop the benefit discussions and plans and track the benefits for their specific groups. A stakeholder will also know the business processes involved and assist in developing a gap analysis between the current situation and the desired outcome, which then is described as a gap and which will be filled by the new system. They will also help develop policy and procedure changes. As business processes change, policy and procedures need to be adapted and specific stakeholders will assist. Most importantly is their assistance in developing targeted lesson and learning plans for the specific groups. Physicians will be trained differently than nurses, will be trained differently than clerical staff.

An important aspect of selecting an EHR is the determination of the total project costs. I cannot understate how important it is to do a good job of determining project costs. Many projects fail due to inadequate funding. There are several types of costs involved in a project. The first that will be dealt with is the capital costs. These are onetime costs to set up the system, to purchase products and materials, and to hire consultants. It involves software, hardware and labor. These can all be capitalized because they're onetime costs. Capitalized costs are amortized such that the recorded cost of that asset is distributed over the estimated useful life of the system. Another aspect of the project cost is that of license. A license is an official legal permission to use or own a specific thing. It principally applies to software projects and involves application software and also the operating systems for the hardware on which the software products run.

After a project goes live, maintenance costs kick in. These are the recurring operational or running costs of a system. It includes labor costs, license costs and various OTPS, other than personnel costs. Maintenance costs for licenses typically incur about 15 to 20 percent costs annually. A very, very critical component of a project is the staffing costs. You need to also remember to include all the costs of staff, including fringe benefits and other administrative overhead costs such as desktop computers, laptops, administrative overhead, cell phones, travel costs, and training. Remember adequate funding can make or break a project.

On this screen is a very detailed list of staffing costs and OTPS costs that come from an actual ambulatory EHR project. This project was an enterprise scaled project with costs estimated to be 65 million dollars over 10 years. On the staff costs, at the top is, physician champion, application, coordinators, database administrators, network support, trainers, go live support, help desk support and at the bottom, it includes the very important calculation of fringe benefit for all the staff.

From the same project, on the OTPS side, is a full range of costs from software license, and notice that it includes the maintenance cost. This was a 10-year cost projection for the project. Implementation fees are estimated because it depends on the actual number of incurred hours. Contingencies are listed here and are a very important component of project costing and include, contingencies for software, hardware, network, data center, consulting fees and even desktop scanners.

An often-overlooked aspect of selecting an EHR is the performance of a financial strength analysis of the involved vendors. Many companies supply credit information on businesses corporations but Dunn & Bradstreet may be one of the most famous and in fact a colloquial term is to do a Dunn & Bradstreet on a company. But available are other companies such as Experian, Equifax, MarketWatch, InfoUSA and even Yahoo! Financial. On this page is listed their websites. For a fee these companies perform financial strength analyses. It's an important aspect and should be remembered that it needs to be done before signing a contract with the vendor. It’s not a onetime purchase of a product from a company. Instead a very long relationship will be developed with these companies. You need to know how strong the financials are since you don’t want to be purchasing an EHR system from a company that will go out of business.

In addition to hiring a company to do a financial strength analysis, there are other steps that can be performed. Vendors should be willing to share an audited financial statement. This is a lot easier with publicly traded companies because they're available on their website by law. But even a non public company should be willing to share audited financials. It’s essential to review the management team. What is their tenure? What is their industry experience? And importantly, what is the turnover in the company? How long has the management team been with the company? Does the company turnover senior management almost annually? Does the company generate cash? This is known as liquidity. Cash is important in all companies and helps during economic downturns so that they are able to continue to develop software and deliver services. In addition it’s crucial to check references on companies. It will be useful to call on the phone and most importantly visit customer sites. Talk directly with current users of the system and check references carefully. An often-overlooked step is to talk directly with the CFO of any company before signing a contract. You can ask very direct and pointed questions about the company’s financial strength and a CFO will answer those questions. We've gone through several aspects of selecting an EHR but by no means has this been an exhaustive list of steps involved in selecting an EHR. These are just some of the most important steps and unfortunately too often overlooked.

In this lecture, we have covered just a few of the most important steps that an organization carries out when selecting an EHR. First and foremost, we talked about the value of the RFP. We covered the importance of involving the key stakeholders. Finances are always critical so we discussed cost considerations, both capital and operating. And finally, we reviewed the importance of ascertaining the financial health of vendors involved in the project.

No audio.

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.

https://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Welcome to Installation and Maintenance of Health IT Systems. Unit 4: Structured Systems Analysis and Design.

This component covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR) systems.

This unit will discuss generalities about project management along with the role of the project manager. It will also cover in some detail the various components of a typical project plan and how to design a project plan for a typical EHR system.

The selection, installation, and adoption of a new health IT system is a major undertaking, requiring the talents and coordination of many people in order to ensure success. Today’s lecture will outline steps used in successfully managing such an undertaking from start to finish.

Objectives for this unit are to:

• Identify the 8 basic components to a project plan • Define the role of a project manager • Equate the basic project plan components to a typical EHR implementation plan • Create a project plan for system design and implementation

Project management can be defined as a carefully planned and organized effort to accomplish a specific, and usually one-time, objective.

There are several facets to successfully managing any project, including: • developing the plan and managing its implementation, along with the various controls put into place to ensure that performance is

sustained and that objective timelines can be adequately met; • being able to adjust the plan for any errors or unforeseen circumstances while ensuring the overall success of the project; • and lastly, once the project implementation is complete, being able to measure the success outcomes in relation to the project

expectations in some sort of quantifiable way.

A project is usually defined in phases. The number and types of phases are solely dependent on the project at hand; however, some of the more common phases include:

• Determining feasibility: the process of determining if undertaking the project will net beneficial outcomes for the organization as a whole?

• Definition, and determining the scope of the project: Who is affected by this project…both directly or indirectly? Who will be involved with the project? What other factors are relevant to the success of the project?

• The project planning phase: Developing a roadmap for project success as well as tools for measuring that success when completed.

• The project implementation phase: Actually DOING the work. • Evaluation; and • Support and maintenance: Determining the project’s net benefit to the organization and putting in place processes to ensure

longevity.

As this picture suggests, successful project management means effectively balancing the components of time, cost, scope, quality, and expectations, each having a symbiotic relationship as represented by the diamond shape in the center. This is referred to in project management circles as the “Project Diamond.” The concept is quite simple: When a user requests an additional report not originally agreed on in the project specifications, the project's scope and quality change, resulting in an imbalance and skewing the shape of the diamond unless changes in the remaining components are made to bring the project back on track. We refer to this relationship as the “Project Diamond.”

Every project needs a someone who can lead the project from start to finish: someone who is able to understand, relate to, and coordinate between the project’s many facets.

This project manager is responsible for everything required to ensure the project’s success, whether directly or indirectly.

It’s important to note that a project manager is NOT like a typical hierarchical line management role. Rather, they can best be viewed as the center of everything relating to the project. Let’s look at an illustration.

As you can see from this illustration, the project manager acts a focal point where different aspects of the project come together. The project manager is responsible for coordinating project activities as well as developing and maintaining the scope and time table of the project.

The four arrows represent the relationships between the project manager and various groups typically associated with project completion. It is not uncommon for the project manager to be in both a supervisory position and at the same time subordinate to stakeholders or upper management affiliated with the project. The project manager must also be able to forge productive relationships with any internal and external elements such as other departments and outside vendors or contractors of over which he or she may have no direct authority.

A project plan is basically a blueprint charting the entire project’s expected progress from start to finish. A project plan can contain as little as a framework for the project or spell out every minute detail– in other words, it can be either detailed or summarized – as needed to successfully manage the project itself.

A good project plan effectively balances all of the components of scope, time, cost, quality, and outcome expectations while minimizing costly errors, by adequately anticipating and addressing problems early on which could negatively impact the project’s success.

A typical project plan formalizes the following: • Agreements between the employer, the project team, contractors and anyone else affiliated with the project • The project’s primary purpose • Organizational, institutional and project goals and objectives as to their relationship to the project’s outcomes • Scope and expectations • Roles and responsibilities of Project staff/affiliates • Assumptions and constraints • Quality management approach • Project management approach

and • Policies and procedures that must be adhered to for the project’s success.

Before beginning to write your final project plan, consider performing a factor analysis. Factor analysis is “a disciplined technique used for investigating, analyzing, and understanding a project prior to making any formal commitments.” A factor analysis allows you to consider all of the relevant system requirements and environmental conditions necessary to ensure the project’s success before finalizing any commitments.

In other words, by examining where a project’s many variables are interdependent upon one another, you will gain a better understanding of the project’s importance as well as which variables are most likely to hinder or help complete the project.

An example of one such factor to consider would be looking at the client’s commitment level toward seeing the project to its completion.

Another would be taking a look at your organization’s current level of technology and determining its capabilities in relation to the project’s expected specifications.

When performing a factor analysis, there are at least ten areas you should consider 1. Definition/Scope: Understanding the project’s primary purpose as well as listing all of the major functions and deliverables expected to complete the project is

very important. Likewise, by determining why the project was created and what mission it fulfills within the organization is crucial for determining the project’s overall relevance and what support the project has.

2. Resources: A factor analysis attempts to identify all of the necessary resources needed for the project’s success. This includes monetary, technical, personnel, or special materials needed.

3. Time: You should calculate the actual work time needed to complete the project as well as the overall timeline. 4. Procedures: Most projects are subject to special polices and procedures to ensure proper outcomes are realized. Here you should catalog all of the relevant

organizational requirements as well as any regulatory policies or mandates, financial reviews, special methodologies, or any other requirements. 5. Environment: Explain the project's environmental factors that may have spurred the project or could hinder its completion. This could include geography,

culture, political environment, available technology, and so on. 6. Change: The factor analysis should take into account all changes (procedural, policy, etc) that will be necessitated and implemented because of the project and

any potential issues or risks associated with these changes. An effective change management plan should then be developed to adequately address these issues.

7. Communications: A good communication strategy is key to the success of a project. However, there are many factors such as geographical location for instance, that can inhibit this process. Determine the best communication strategy for the project, considering any routine meetings, reports, presentations, and such needed to keep the project on track. Be sure to catalog any foreseeable obsticles that will affect communication efforts and plan accordingly.

8. Commitment: For a project to succeed it must gather momentum and maintain a level of support from key proponents capable of driving the project to completion. Analyze and determine the degree of support for the project from sponsors, users, and stakeholders. Are they willing to commit to seeing the project through to completion? What factors are currently driving support for this project? Will those factors still be in play as the project moves forward? What’s at stake if the project is NOT completed?

9. Expectations: What positive outcomes can you expect from completion of this project? What goal or objective will completion of the project satisfy? To what measurable degree?

10. Risk: Summarize any potential obstacles that will hinder project completion. Additionally, take time to analyze the risks associated with not completing the project or portions of the project.

Completing the factor analysis will help you gain further insight into the many different facets needing consideration and will go a long way toward completing a thorough project plan.

A typical project plan should have at least eight components, each of which is essentially a work product resulting from subtasks.

Introduction The Introduction of the project plan should state the overall purpose of the project. Ask yourself to define the mission you are trying to accomplish. The project description typically provides a short statement about what the plan hopes to accomplish, as well as a brief background synopsis of how the project was originally derived. What motivated, or demonstrated the need for, the project? What background history led up to this project being created?

Goals & Objectives: A goal is a specific and desirable achievement that the organization chooses as a focus in support of its overall mission. Goals tend to be long term while objectives, on the other hand, tend to be short-term targets (typically 12-24 months or less) of defined, measurable achievement.

The expected project goals and objectives should be clearly defined within the project plan. Reaffirm project objectives by establishing the motives driving the project and determine how completing the project will achieve specific aims for the organization or institution and its mission as a whole. Essentially you should be able to identify the specific results to be realized and the benefits to be achieved, and establish a desirable and realistic time frame for meeting the project objectives. A visible and reliable method for monitoring and measuring progress toward meeting these objectives will also need to be devised.

Before we begin discussing scope, it’s important to note that, in project management, there are two distinct definitions for scope: 1. Project scope refers to the work needing to be accomplished to deliver a product, service, or result with the specified features and

functions as outlined. 2. Product scope can be defined as the features and functions which characterize a product, service, or result.

Note that project scope defines a more work-oriented approach, while product scope focuses on the functional requirements of a deliverable. Defining the scope of a project is often neglected; however, properly defining the scope in detail is critical to properly planning a schedule, budget and the needed resources to ensure successful completion.

With that said, having clearly and concisely defined the scope of a project is key to its success. The project scope should describe, from a quantitative perspective, what is to be accomplished. Defining the scope aids in establishing realistic work plans, budgets, schedules, and expectations. Should identified work arise that falls outside of the defined scope, it becomes the project manager’s responsibility to determine whether the additional work falls out of the project’s scope and should be deferred, or whether the scope of the project should be expanded to include the work. Expanding the project scope would mean making formal changes to the work plan, resource allocation, budget, and/or schedule.

Scope Definition You will want to detail what work will be done and what resources will be included in the project; we call this Scope Definition. If the project is part of a phased approach, it may include deliverables from the previous stage and the scope may be characterized by which objects will be further defined and developed. Focus on the components identified within the project plan scope definition. Define the scope of the project by determining which criteria constitute maintenance of the product. This will help prevent the occurrence of “scope creep”, a term that refers to the incremental expansion of the scope of a project, as when requirements are introduced that were not part of the initial planning. Scope creep is often due to inadequate planning or a failure to consult all of the stakeholder parties during the project’s initial stages, and it can result in costly financial and scheduling overruns.

The deliverable scope of the project is a complete listing of the products and/or other “deliverables” expected. These could include tangible items as well as specific results resulting from the project’s completion. Every project plan should have a deliverable scope. It should Include a list of these deliverables often times with more detailed explanations of each deliverable which may be contained within the project plan’s Appendix. When writing a deliverable scope for a project plan be sure to contain the following, for each deliverable: • Name and a description • Purpose behind creating the deliverable • Major task(s) producing/updating the deliverable • Expected audience • Sign-off participants Remember to include any project management deliverables, including the project plan itself.

Milestones represent the timeline, or temporal scope, of the project. Here you describe significant project accomplishments that will act as primary checkpoints marking the project’s progress. These are generally points marking the completion of a specific activity or group of activities and resulting in a significant product or result, such as equipment delivery, material delivery, review meeting, or approval checkpoint. Not every task completion date in the project will be a milestone, but every milestone should be tied to a deliverable.

Include the estimated time of completion for each milestone. Milestones are targets that should be met. If they are not met, it is likely that the project will not finish on time. Ensure that milestones are clearly identified in the timeline and project plan.

Assumptions Assumptions are necessary if we are going to make decisions about the future. They help us fill the gaps where facts are lacking but are not always proven to be true. Use this section to describe any assumptions made about the project or its completion related to items such as available resources, scope, expectations, schedules, etc. Assumptions should be specific and measurable. Be sure to differentiate between assumptions made about the project and real facts that can be proven.

For instance, when determining the project’s hiring budget you can assume from the facts you are currently given whether or not you will be able to fully staff the project throughout it’s duration or perhaps whether cut backs will be needed at a later phase of the project due to projected budgetary constraints.

Constraints Describe and plan for any limitations under which the project will need to be conducted, This could include any operational or environmental parameters such as projected timeframes, deadlines, available funding, staff skill levels, or resource availability that may or may not impede the project’s progress.

Related Projects Other projects can be potentially impacted by your project as well. Other projects may be dependent on deliverables associated with your project or your project may affect the parameters of other projects. You should address these issues and ensure managers of these related projects should be kept in the communication loop on all matters related to your project.

Critical Dependencies Likewise, it is also essential that the critical dependencies between related tasks and subtasks whether internal or external to the project be understood to ensure that tasks are sequenced correctly so you can maximize efficiency and so that the project can run smoothly, minimalizing unwanted downtime. Determine the relationship between work performed in a given task or subtask with the work performed in other tasks or subtasks. Identify the predecessor and successor activities. Identify any tasks within a related project on which this project is dependent, and describe each relationship.

Quality management is the process of ensuring that the project’s objectives, adequately meet expectations. Your project plan should identify and list the methods you plan to use to ensure your deliverables are up to snuff and how that methodology aligns appropriately with any industry standards or regulations which must be followed. This would include any project reviews or inspections you plan to conduct, along with any testing or test scripts and where in the process each should occur to ensure quality guidelines are met. You should also define the specific and measurable standards used in determining acceptable results.

Also list and describe any special tools, skills, and techniques that will be needed on the project to perform the testing and ensure positive outcomes, including any specific hardware or software packages. Some such packages would include project management software, measuring devices or testing software.

Lastly, define the specific quality management roles and accompanying responsibilities that individuals will be assigned to ensure quality is adequately met on the project.

Project Management Effective project administration is key to success. Ground rules need to be set into place outlining acceptable standards for providing effective administration, communication, and project oversight.

Identify the administration policies agreed to by the project team that govern the way in which the project will be conducted. Such standards include status reporting, staff meetings, product review acceptance criteria, and celebration criteria. Describe which standards, if any, already exist within the organization and are appropriate for the project. Such standards typically include project model management, technology, documentation management and training techniques, naming conventions, quality assurance, and testing and validation. These may be standards that are recognized and embraced as an industry standard or that are specific to your organization.

Define & describe the roles and responsibilities of each team member, along with the overall communication plan to ensure that team members understand what is expected of them. Describe the mechanism for communicating responsibilities across the project team and within the organization at large. Be sure to develop a strategy that promotes communication among team members; consider using a directory of all team members and liaisons.

Identify how progress on the project will be determined and how it will be communicated to those involved in or impacted by the project. Identify how often status reports will be distributed and to whom. Determine how often progress meetings will be held and who is expected to attend.

Approvals Unexpected situations and setbacks are bound to occur. Likewise, project tasks need some sort of approval process to ensure quality checks have been sufficiently completed to move to the next phase It’s important to develop an efficient approval strategy for monitoring and moving the process forward and can also anticipate and adequately address any unexpected variations and modifications that become necessary during the project’s life cycle.

We have already discussed in detail the steps involved in selecting an EHR system that’s right for your practice or institution. Now let’s review the steps for implementation as a whole.

Stage 1: Assessment Your project team, represented by a variety of physicians, staff, and stakeholders with the appropriate skills, is formed, and regular team meetings are conducted. These team meetings continue throughout the six stages. The assessment stage helps prepare for the implementation by completing a “practice readiness assessment”; this includes a profile of the organization in terms of goals and priorities, and an assessment of IT, healthcare, and business and office personnel. A “hardware requirement analysis” is also carried out at this stage.

Step 2: Planning The practice data collected from the previous stage is carefully reviewed. Based on this, the electronic health records implementation goals are defined, and improvement opportunities are identified and targeted.

Step 3: Selection The EHR system's requirements are defined, including configuration needs, and a selection process and details of the goals that are archieved based on the selection. The EHR system is also selected in this stage.

Step 4: Implementation Once the EHR selection has been made, a system implementation plan is developed with the vendor, along with timelines. The implementation plan includes details on installing and configuring hardware and EHR software. A plan for migrating any old data over to the new system must also be devised, including any necessary database conversions in a manner that ensures data integrity. A staff training program is initiated and system testing follows. Then the staff begin to use the EHR system. Throughout the process, a journal of experience and processes is maintained.

Step 5: Evaluation A post-implementation review is conducted and the journal of experience and processes is updated. The performance measures created during the planning phase are validated and an improvement plan is prepared.

Step 6: Improvement The EHR is then modified to resolve issues encountered during the evaluation phase. Improvements are carried out as defined in the improvement plan.

Reference: http://www.binaryspectrum.com/HealthcareSolutions/ElectronicMedicalRecords/Roadmap-for-implementation-of-EHRsystem-at-a- practice.html

There are special concerns for implementing an EHR project in smaller settings. First, it’s important to understand that implementing an EHR is a time consuming process that cannot be rushed. Smaller practices are more often than not limited in their resources, creating additional pressures which can hinder EHR adoption rates. Consider using a step by step approach for implementation, particularly after the EHR rollout begins; allowing time for staff to become familiar with the new technology at their own pace. For a single physician practice you should expect the project to span from 12-18 months at least from start to rollout; or longer for practices with multiple physicians.

Implementation of your EHR should be driven by the long term goals you wish to achieve. You should begin by evaluating your practice and looking for deficiencies or areas where improvement can improve quality of care and efficiency. Special areas to consider could include coding, medication management, quality improvement, patient satisfaction, and so on. There are many goal setting tools and resources available. MedQIC, an online goal-setting tool hosted by the Centers for Medicare and Medicaid Services is just one such tool which may prove valuable but there are many more.

Just like large practices, you should take care to include a thorough workflow analysis, in your project plan, particularly when it comes to scheduling, triaging, patient registration, referral management, visit documentation, orders, result management, protocols, treatment plans, clinical decision support, copayment capture, claims processing, and billing. Other areas should be considered as well. Special consideration should also be given in office environments where the transition to an EHR coincides with a transition from a paper tracking system to a paperless tracking system.

In a smaller practice, you will probably need to focus more on up front and long term costs associated with choosing an EHR. Establishing a budget early on will help guide you toward selecting an appropriate EHR vendor. For instance, many smaller practices opt for a hosted EHR solution over an in-house solution, which may help offset costs for maintenance and support of the EHR infrastructure.

In smaller practices, building a PARTNERSHIP between your practice and the EHR vendor is just as important if not more so. You will be more dependent on the vendor providing technical expertise and even on-site support during and after the implementation process has begun. Choose a vendor that’s a good fit for your practice and understands your goals and will work with you to develop a project plan that not only focuses on the technical requirements and deliverables but also encompasses the project plan as a whole including time for analysis, staff training, and testing. Choosing a vendor should not rest on cost analysis alone.

We’ve covered a lot of concepts in today’s lecture. Lets summarize the important points:

Project management is the process of carefully planning and organizing efforts for accomplishing a specific, and usually one-time, objective.

A project manager is directly responsible for activities of all participants, tasks, & deliverables however, the project manager may not necessarily be the top level of the hierarchical management structure.

Projects have major phases designed to move the project along in a logical and timely progression

A factor analysis is often done before the project begins to help determine scope resources and time needed to be successful.

A project plan is then developed and typically should have at least eight components, each of which is essentially a work product resulting from subtasks. The project plan helps identify specific details including workflow, teams, communication and approvals needed to ensure project success.

EHR project implementations follow similar patterns as many other projects including six typical stages:

Assessment Planning Selection Implementation Evaluation Improvement

Special considerations such as limited staffing and financial resources should be considered when developing EHRs project plans for smaller practices.

That concludes today’s material. A lot of concepts were covered, here so take additional time to digest these concepts before moving

on to the next unit.

No audio.

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.

https://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

This is Component 14 Unit 8: EHR go-live strategies.

At the end of this lecture, you will be able to evaluate training and go-live strategies in terms of impact on cost and workflow.

More specifically, by the end of this unit, you will be able to Describe characteristics of training and go-live strategies that would facilitate implementation of a new Electronic Health Record (EHR) system. Compare the advantages and disadvantages of a big-bang roll-out versus a phased roll-out and vice-versa. Identify staffing, command center and consultant considerations Compare strategies for monitoring systems and change management during the immediate post go-live period.

One of the first project decisions that have to be made is whether to rollout the system in a big bang or a phased approach. When referring to big bang or phased, we are mostly referring to the software modules or main application functions. However, with the big bang approach, you still have implementation choices. You could rollout all modules in selected locations or all modules in all locations. This big bang approach is usually used when replacing a legacy system. It would be difficult to have two systems running at the same time. In the phased or incremental rollout, selected modules are implemented. Again, you have the choice of selected modules in all locations, selected modules in some locations or a combination of both.

There are pros and cons to both the big bang and the phased rollout approaches. Let's talk about big bang. The pros for doing the big bang rollout are a short-term disruption and there will be no need to link the old and the new system. Since the old legacy system will not be running during the go-live, it will not require support. On the other hand, the rollout will demand much more organization. It absolutely requires comprehensive planning and all the users will need to be trained and ready to go at the same time. This can be a massive undertaking.

So, what are the pros and cons of the phased or incremental rollout? The benefit of this approach is that it allows you to progressively adjust your strategy during implementation. Your planning can be more focused. Any disruptions will be isolated to only those locations and those modules involved. As a result, smaller groups of users are affected during the rollout. Against this approach is the need to maintain two systems: both the new and the old or legacy systems. There is a danger that the project will stall or stagnate. In addition, obstacles will be found which may cause groups to think about not continuing with the implementation. It will be necessary to correlate information from both systems for management reporting. Furthermore, detailed business operations will have to be extracted from both systems simultaneously.

The staffing required for implementing and maintaining an EHR depend on many factors. For example, you need to consider the product being implemented, the location (whether hospital, inpatient or physician office), whether the implementation will be formed by the vendor or consultants and if it is a big bang or a phased rollout. All of these factors will greatly determine the required staffing. From a technical standpoint, if the application is hosted locally, that would require a much larger team versus hosted remotely by a vendor. In addition, you will have to determine temporary staffing during implementation, actual go-live support, and the permanent staffing once the project is fully functioning.

In Unit 3, we reviewed an example EHR implementation cost profile including staffing requirements. Here, we have the same list of personnel including physician champion, application coordinators, database designers, third party reporting, two administrators, programmers, security analysts, work station management staff, trainers, go-live support, and chief privacy officer, just to name a few.

An important component of an EHR go-live is the command center. This is a special location set up during implementation. While command centers can exist in the phased or incremental rollout, they are more typical of big bang rollouts. All project communications go through the command center. It serves as the project's help desk and all user calls are routed to the command center. Field staff meets at the command center usually at the beginning and end of each day to report and get project updates. Moreover, project executives meet together at the command center to take the pulse of the project and to make immediate necessary decisions.

Onsite consultants can play many important roles in an EHR project. Staff is needed during implementation and during the go-live period; but not needed during the maintenance phase. For example, consultants can assist with EHR selection; develop processes during implementation, work on meaningful use criteria, assist in EHR review of existing projects and direct training and certification processes.

A very important task to be formed during the rollout is monitoring system usage. As the system gains users, increases functionality and takes on heavier loads, it is critically important to watch all system health indicators. The operating system, disk space and application usage need to be monitored. Each day requires a tally of the number of documents created, orders written, orders completed and prescriptions written. It is also important to monitor the count of calls coming into the help desk. Some concerns could be: Are there system issues? Are there logon issues? Are there application questions? Monitoring all of this will help detect early on whether the system has some issues. A lot will be learned from performing these tasks.

A lot goes on during the implementation of an EHR. There is a significant amount of change that occurs. While organizational change is a fascinating topic, where organizations evolved to different levels in their lifecycle, here we will be specifically talking about system change. This typically refers to information systems or other process changes in an organization.

An important aspect to the system change is the management of changes. If a formal change management system is typically instituted immediately post go-live, a structured approach to transition individuals, teams and organizations from a current state to a desired future state is needed. Changes are implemented in a controlled manner by following a very well defined framework managing all modifications.

During implementation and go-live, changes are usually made on the fly and that is okay. However, during post go-live, when the system is stable, it is very important to follow the formal processes of change control. This ensures that changes are introduced in a controlled and coordinated manner. This is done to reduce the possibility that an unnecessary and harmful change is introduced; thereby, creating defects in the system. The goals are to minimize disruption, to reduce having to back out changes, and to utilize resources in a very cost effective manner.

Change control management consists of the following steps: recording and classifying each requested change, assessing all aspects of the change, planning for the change, building and testing every aspect of the system including the parts that no one thinks will be affected by the change, implementing the change, closing it out and gaining acceptance from all users.

In this lecture, we have covered just a few of the most important go-live strategies. We talked about big bang versus phased rollout. We talked about staffing, command centers, use of consultants and change management. These are just a few of the very important aspects of go-live strategies that have to be considered during the implementation of an EHR in both the inpatient and ambulatory settings.

No audio

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.

https://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Welcome to Installation and Maintenance of Health IT Systems, Software Development Life Cycle. This component Installation and Maintenance of Health IT Systems covers fundamentals of selection, installation, and maintenance of typical Electronic Health Records (EHR) systems.

This unit, Software Development Lifecycle, will discuss methods for planning for the creation, development, implementation, and eventual phase-out of software packages using various Software Development Life Cycle Models.

The Objectives for this unit are to: 1. Define the steps of the Software Development Life Cycle, or SDLC, and the purpose and importance of each. 2. Describe different models of the SDLC and their key differences. 3. Describe how and why an HIT software application would go through the SDLC.

The SDLC is a well-developed concept from the IT world that promotes an organized, long-term view of the software you’re working with, from its “birth” to its “death” (hence the term “lifecycle”).

It’s important for those who work in healthcare IT to understand this model and apply it when appropriate. This will be crucial if you work in an institution that chooses to build its own EHR components. But even if your institution lets a commercial vendor make all the changes to the software, it will be helpful to understand the conceptual phases they are using … particularly since your institution’s success will be dependent on the outcome.

We’ll start by describing the SDLC and its importance, then we’ll discuss the conceptual phases of the lifecycle. Then we’ll look at three different models – the waterfall, iterative, and spiral models – that illustrate different views of the relationships between the phases. Then we’ll go through an example of the SDLC in practice. Finally, we’ll close with more remarks about the role of the SDLC in EHR systems.

The SDLC is a term used for modeling a detailed plan for the creation, development, implementation and eventual phase-out of a software or software system package. It’s a complete plan outlining how the software will be born, raised, and eventually retired from its function.

Many different SDLC models exist. Each of these models was designed to fit a specific business needs model, to accommodate available resources and skills, or to take advantage of a specific programming language or toolset that would be used.

Usually, these models can be divided into two categories - the waterfall model and the iterative model - each employing a different workflow philosophy.

So why is SDLC important, anyway? Well, as computers and software became integrated into the business environment and businesses became more dependent on computers not only to manage their business data, but also to assist or track every aspect of the workflow process, it became increasingly apparent that poor design, or failure, of software can be quite costly in terms of lost productivity. Additionally, poorly designed software can increase security risks and decrease data integrity. Replacement of outdated or inadequate software can cost many thousands of dollars.

Therefore SDLC was designed to control the development environment to help ensure that developers produce a high quality system that meets or exceeds their customer expectations, is completed within time and cost estimates, works effectively within the designed infrastructure, and is inexpensive to maintain and cost-effective.

Factors for developing a successful SDLC are not unlike those already discussed in previous units for developing your successful project plan or for selecting your EHR system. Again, these factors are not steps in your SDLC; rather, they are elements that will dictate whether the SDLC will be followed, which in turn assures the success of the program being developed.

1. Management support - Developers need to have the support of the management as much as possible, since management will dictate the business need, budgeting, and top-level buy-in for the product.

2. Technical and business expertise – As in any field, there are experts (in this case, programmers) who just know what needs to be accomplished even when the objective is originally presented. These programmers know which SDLC model is most appropriate for the programming language or toolkits that need to be utilized to ensure the software project will be successful. Likewise, business experts are also critical in the software development cycle, since they understand the overall demand and needed functionality for a particular software. Additionally, business experts can help determine whether the software will eventually show any cost savings over other products or processes.

3. Determining the product focal points - Some parts of the program should be rated a higher priority than other parts. Choosing which elements are most important will allow developers to make decisions when issues arise which may compromise the software’s overall functionality, ensuring that there will always be some strong selling points in the developed software compared to a product that provides only mediocre service.

4. Follow well-defined procedures - Developers should have a clear understanding of goals at each phase, along with the methods and accepted tolerances for evaluating each of the goals.

5. Develop proper documentation for maintenance – Developing good documentation will help with the implementation and continued success of the product throughout its entire life cycle.

Now let’s take a brief look at how these phases can relate to each other, initially using the so-called “Waterfall” model.

The initial assessment of feasibility is followed by an analysis phase, which is followed by the design phase, which is followed by the implementation phase, then the testing phase, then the maintenance phase.

Contrast that with this “iterative” or “incremental” model, which starts with initial planning and research. Then begins a cycle -- consisting of planning, requirements, analysis and design, implementation, testing, and evaluation -- which repeats as needed until the decision is made to do deployment.

We’ll discuss the models in more detail at the end of this Unit. Now let’s discuss what each phase generally entails.

Initiation In the software vendor world, where profits are realized by fulfilling consumer market needs with new software products, initiation is where a need is identified for a new software system. Software development companies use this stage to determine the needs of the present market. The software vendor’s management is often involved in this stage as they want to determine what the developers have to do and how it will impact the market.

In a clinic or other healthcare institution, this need is usually identified by clinicians or staff such as a flawed workflow process or other issue.

For instance, a healthcare clinic currently uses three different programs to record patient data, dispense online prescriptions, and run the business office, requiring a lot of work overlap and generation of paper documentation between systems. Both the physicians and the billing department are looking for a more efficient way to communicate and improve efficiency. They would like a system that can communicate seamlessly between the various business components and streamline operations.

A Project Manager typically would be assigned and would eventually generate a Concept Proposal – a document which identifies the problem and why the new system needs to be pursued. Upper management would then review the proposal and approve it, and the project moves on to the next phase.

The Concept Development phase begins when the Concept Proposal has been formally approved but when additional study and analysis are required prior to system development activities.

We begin to analyze what will be necessary to complete the project. Here all relevant factors are analyzed to develop the project scope.

Several reports can be created here: • Feasibility Study; in other words, will it work? • Cost/Benefit Analysis; in other words, is the cost really worth it? • System Boundary; in other words, how far should the project go? • Risk Management; in other words, what will happen if we don’t do it?

These reports are then presented to the powers that be, and a decision is made whether or not to go ahead. They approve the funding. If they give their approval, it’s on to the next phase.

During the Planning phase, we determine who is doing what, when, and how, along with the personnel and other resources that will be needed to complete the project. For instance, should we use existing personnel or hire consultants? During this phase we determine what developmental resources will be required to create the specific software.

Other questions are also contemplated during this phase: • Should we develop in-house software, or buy it off the shelf? • What are the “deliverables” – such as completed software programming and documentation, user manual, training, testing plans,

etc.?

Finally, a planning document is submitted to management for approval.

The Requirements Analysis Phase focuses on what the system will do, in an effort that considers all stakeholders, including sponsors and potential users, as important sources of information.

During this phase you will determine what Operating System, or OS, and interfaces are required; e.g., will it run with Windows or LINUX? Here you will answer a number of other questions as well: What functionality will be required? Should it be run with the mouse, keyboard, or touchscreen input? How much training will be required of the user? Will a new room be needed for the hardware that runs the system?

There are a variety of techniques that can be used to gather the requirements, but some key points to remember are that the requirements must be systematic, verifiable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Once the requirements documentation is approved, the project moves on to the design phase.

The Design Phase takes those requirements and develops a detailed blueprint outlining the software specifications. Here, the program architecture, which defines the various software components, along with their interfaces and behaviors, is established.

The design phase is also where much of the program documentation begins to take shape, including the Maintenance Manual, Operations Manual, and Training Manual.

Flaws in the original planning, which require some adjustment, are often revealed during the design phase.

The system is built during the development phase. This includes source-code files, header files, make files, and binaries.

This is where everything is coded and assembled, and the actual design of the system is realized as “living, breathing” software. This process is usually a team effort with its own set of sub-goals and milestones, involving many software developers who coordinate their efforts to realize a final product.

Integration and testing of the entire system is a formal, documented testing procedure, which ensures that the system performs as designed.

Testing the roll-out of the system also begins, including migration of existing data into the new system, as well as usability.

Usually, the system is rolled-out over a weekend so that if anything goes wrong, the old system is still active and available.

Integration and testing is a critical step. If the software fails testing, it cannot be trusted to work.

Approval of testing and test results is necessary before the project moves into the next phase: implementation.

Now that the software has been formally tested and passed, it is time for distribution to the production environment. In this implementation phase, user training takes place, previous data is migrated, and the system is brought online.

After the system “goes live”, it is once again tested and data is collected to determine if it is working to specifications. This process is often referred to as a “debriefing”. It is also where any problems that were not crucial to the implementation can be addressed and any necessary changes to the system documented for future versions.

The Operations & Maintenance Phase is the day-to-day operation of the software after deployment. The software must be maintained, patched, and regularly updated to ensure long, reliable life. Upgrades can be tested and deployed to improve functionality.

Every software application eventually becomes obsolete. Perhaps a new system is being developed, or this system cannot keep up.

Whatever the reason, disposition involves more than just shutting off the server. Often, the system may be kept going due to regulatory requirements or because there are still projects using it. Sometimes there is data on board that must be kept safe and secure even after its useful life is over.

Software disposition needs to be planned to ensure that you meet all regulatory requirements and ensure a smooth transition to whatever the replacement product will be. A disposition plan must be developed which may outline everything from the dismantling of the software itself, to the safe and secure disposal of old hardware and data, to archiving of documentation.

As briefly shown and discussed earlier in this presentation, many different SDLC models exist. Each of these models was designed to fit specific business needs, to accommodate available resources and skills, or to work with a specific programming language or toolkit.

Usually, these models are divided into two categories, the Waterfall Model and the Iterative model, each of which employs a different workflow philosophy.

The waterfall model uses more traditional planning, testing and implementation techniques to design and implement new software products. This model promotes strong documentation of each step of the development process.

The waterfall SDLC model represents a sequential development process, where progress is seen as flowing steadily downwards through each of the phases of development.

Winston W. Royce has been given credit for formalizing the waterfall model in an article around 1970, where he presented this modeling concept as flawed from a software development standpoint.

The waterfall development model is actually a product of the manufacturing and development industries where making after-the-fact changes is often prohibitively costly. Therefore progression to the next phase of development does not typically commence until the previous phase has been perfected and ”locked down.”

Many have criticized the waterfall model, citing that it is difficult, if not impossible, to finish a phase of a software product’s lifecycle perfectly before progressing forward to the next stage. To that end, several variations of the waterfall model have been created to help address some of these issues.

This diagram, which I described on an earlier slide, depicts just one of the many variations of the waterfall model employed by developers. As this variation of the waterfall model suggests, the waterfall model can best be described as a sequential software development process whose workflow progresses in a linear, downward fashion, just like a waterfall flows.

Using a waterfall methodology is most likely to be successful when the complexity of the system is low and requirements are static, but there is little room for mistakes and no process for correcting errors after the final requirements are released.

Feedback can be quite limited when using this approach. And, as I mentioned previously, most believe it is nearly impossible to finish a phase of a software product’s lifecycle perfectly before progressing forward to the next stage.

Iterative and Incremental model: These models were developed in response to identified weaknesses of the waterfall model and often considered cyclical in nature. One variation of the iterative model is the Spiral model, which we will look at after we see a more basic Iterative model.

This approach works well in environments where perceived requirements are subject to change as the project progresses or where more feedback is warranted.

Let’s take another look at the illustration.

As you can see from this diagram, which I described earlier in the presentation, in iterative models, the phases of software development take on a more cyclical nature.

It starts with an initial planning phase and ends with deployment, with the cyclic interactions in between, or even after the initial deployment occurs. With this model, several deployment cycles of the product are possible as the software becomes further refined, analyzed, and tested, and as new enhancements are added.

Another variation of the cyclical model is the spiral lifecycle (or spiral development) model used in IT. This model combines the features of another model, called the prototyping model, with those of the waterfall model. The spiral model is intended for large, expensive, and complicated projects where client responsiveness is a significant issue.

In this model, one or several prototypes may be created throughout the lifecycle. At each iteration, the prototype is tested and further input is gathered until all concerns have been adequately addressed.

Let’s walk through the diagram. The action begins in the center of the spiral, with initiation, and then cycles repeatedly through four conceptual quadrants: Identify, Design, Construct, and Evaluate. The first cycle contains the phases Concept and Risk Analysis. Later cycles contain the phases Implementation, Testing, and Delivery.

As you can see, the SDLC is very similar to a project plan, but it integrates several software-specific aspects into the planning infrastructure to specifically address the concerns associated with developing and deploying a new software system. However, you should consider an SDLC as augmenting your overall EHR project plan, not replacing it.

Employing SDLC in your environment, when developing a new EHR system or designing changes to an existing system, is crucial to ensuring that your new software, whether developed in-house or purchased off the shelf, adequately meets expectations while mitigating overall risk to the organization.

Now let’s discuss a scenario in which EHR installation utilizes SDLC principles.

Sunny Happy Care (SHC) Clinic, a small primary care practice, wants to upgrade their paper records to an EHR system. Before purchasing and deploying, they do extensive planning, including evaluation of their requirements and analysis of market options. They ultimately select and implement a commercial EHR.

You’ll have recognized those actions by the clinic staff as several of the general steps in the SDLC. The fact that they are specifically following an iterative SDLC model in their deployment soon becomes clear. According to the project plan, the business manager has been assigned to test and evaluate the EHR after go-live. In her analysis, she determines that the SHC clinic staff is spending excessive time manually entering laboratory data, since a laboratory integration module was not part of the initial purchase. Thus the staff enters a new cycle of planning, requirement-gathering, & analysis of vendor options, leading to purchase & deployment of a laboratory module. Subsequent re-testing & re-evaluation of the EHR now shows satisfactory improvement in staff effort & availability of lab data.

This concludes our unit on the Software Development Life Cycle.

In summary, the SDLC is a set of steps that were codified by the software development industry but are useful in executing many types of projects. Common steps include concept development, planning, requirements analysis, design, development, integration & testing, implementation, and operations & maintenance.

The relationships between these steps have been formulated into different models based on different needs. The waterfall is one such prominent model, and it emphasizes steady progress through the steps and careful completion of each before moving on. The iterative, or incremental, is another prominent model, and it emphasizes iterations, in which the steps are repeated in a cycle of improvement. It has variations such as the spiral.

The SDLC is useful for EHRs, and its steps should be carefully considered whether one is creating a new EHR or deploying a purchased EHR, in order to maximize the success of the project.

No audio.

IT Project Management

In this course, we only introduce project management, but the main concepts are covered. In order to be a good project manager, you

should specialize in this area. Project management certificates are offered by universities such as UMUC, and there is at least one

recognized certification authority—the Project Management Institute (PMI). PMI evaluates both your experience as well as your knowledge

before a certification is awarded. So, you can see that project management cannot really be learned from a book or a class, but from those combined with experience in the "real world."

A couple of definitions with which you should be familiar are:

 Project: temporary endeavor undertaken to create a unique

product, service, or result  Project management: the application of knowledge, skills,

tools, and techniques to project activities to meet project requirements.

What is the role of a project manager? Is it different for an IT project manager? A project manager must control the four key variables

associated with any project: time (schedule), resources (human and financial), scope of work, and quality. The project manager leads the

development of a project plan that takes all of these into consideration. Frequently, trade-offs are required. For instance, the

budget may be limited, which restricts the scope of the work and perhaps how many people can work on the project. Or, the project is

needed within a certain time frame, which may drive the costs up,

since more people would have to be hired to complete the project on time. When any one of the four variables changes, there is an impact

on at least one (and often more than one) other variable. A strong project manager pays close attention to the project plan and the

progress of the project against the plan, and manages the variables appropriately to ensure successful completion of the project.

Successful completion is accomplished if the project is delivered on time, stays within the allocated budget, performs the required

functions, and does so correctly. This role is the same for any project manager, including an IT project manager.

The four variables are interdependent. You cannot change one

without affecting the others. For example,

 Decreasing a project's time frame means either increasing the

cost of the project or decreasing the scope of the project to meet

the new deadline.  Increasing a project's scope means either increasing the

project's time frame or increasing the project's cost—or both— to meet the increased scope changes.

 Decreasing a project's resources (either people or money) will necessitate a reevaluation of the scope and/or the quality. The

scope may need to be reduced to avoid decreasing the quality, or if the scope must remain unchanged, quality will suffer.

 Increasing a project's quality requirements will require more time and money to incorporate more perfection and test all possible outcomes for correctness.

Project management is the science of making intelligent trade-offs

among time, cost, scope, and quality. This is the job of the project manager. As things change, the project manager must adjust the four variables to keep them in balance.

The first step is the selection of strategic projects. Now, the project manager does not select the projects alone; usually that is done by

senior management after the presentation of a "business case" that

outlines the project plan, stating the objectives (how the project supports the corporate strategy), cost, schedule, functionality, and risk

associated with the proposed project. Once senior management allocates resources, the project manager ensures the project plan is

executed according to plan. A smart project manager makes sure that his or her plan has "SMART" criteria – useful reminders on how to

ensure that the project has created understandable and measurable objectives:

 Specific

 Measurable

 Agreed upon  Realistic  Time framed

These objectives are documented in the project plan, used throughout the project's life to help keep the project on track to a successful

completion. The project manager monitors progress against the plan and manages any changes and mitigates risks as they become known.

Project risk management involves identifying potential events or conditions that could have a negative effect on the project, estimating

the impact if the risk occurs, determining a mitigation strategy to

reduce the likelihood of the risk occurring, and identifying what will be done if the event or condition actually arises.

Since almost no project goes exactly according to the plan, the project

manager needs a tool to detect and manage the changes. The process of change management is this tool. The project manager documents

all approved changes, revises the project plan accordingly, and then continues managing and monitoring the project.

Keep in mind that the job of the project manager is to stay on top of all the variables and manage the cost, schedule (time), scope and

quality. He or she must seek additional resources (money or people) or a schedule change (time) when the scope increases, and must be

able to articulate the effect on quality if additional resources or a schedule change are not authorized. The project manager is

responsible to senior leaders to monitor the variables, keep leadership informed, and propose solutions for changes as they occur.

Working with Health IT Systems is available under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported license.

https://knowledge.amia.org/onc-ntdc/working-with-health-it-systems-1.379705

https://creativecommons.org/licenses/by-nc-sa/3.0/us/

Welcome to Introduction to Project Management: An Overview of Health IT Projects. This is Lecture a.

The Objectives for An Overview of Health IT Projects are to:

•Review the history of project management.

•Define what a project is.

•Define project management.

•Identify reasons that more organizations are implementing HIT projects.

•Identify key characteristics for project success and failure.

•Describe the range and characteristics of health IT projects.

For Lecture a we will focus on all of the objectives.

This unit will provide you with a high-level overview of health IT projects. Here is a brief history of project management. Project management can be traced to early civilizations, including the Egyptian pyramids and the Great Wall of China. The year 1910 brought the Gantt chart, a project management tool still in use today. Project management was first considered an isolated concept in 1954. The latter part of the 1950s saw great strides in the development of project management concepts and techniques. After the Soviet Union launched Sputnik in 1957 and with it, the Space Race of the Cold War between the United States and the Soviet Union, the US Department of Defense focused greater resources toward strengthening its space and defense project procedures. In the same year, the U.S. Navy created the Program Evaluation and Review Technique, or PERT, to help manage its Polaris missile submarine program. Around the same time, the DuPont corporation developed its Critical Path Method, usually referred to as CPM, as a project management tool for scheduling various processes or activities. Eventually, PERT was adapted to employ a work breakdown structure, or WBS), which we discuss in other units of this course. Private enterprises began to adapt some of these methods. One of the most important guiding techniques to specify how a project should be managed is the Project Management Body of Knowledge or PMBOK, created by PMI in the late 1980s. The techniques outlined in the PMBOK standardize the practices of the development team, which makes it easier to predict, manage, and track projects. The 2000s brought the development of the agile alliance, along with an update of the PMBOK into its fourth edition. The multi-project company environment of today requires more flexible and cyclical models than the critical chain models used in the past. Many of the critical chain-oriented project management techniques, which focus on the resources required to complete project tasks, are aimed at very large scale, one-time, non-routine projects, and are unnecessarily complex and costly for smaller projects. Modern project management, however, includes all kinds of projects and all kinds of management models and techniques.

The PMI PMBOK defines a project as, “a temporary endeavor undertaken to create a unique product or service.” You can consider a project complete when its goals have been reached, and you can consider a project terminated when its goals can no longer be reached for any reason or the project is no longer necessary.

As a professional area of knowledge, project management provides a methodology for preparing, coordinating, and supervising people, supplies, and processes, from project initiation to closure, to achieve definite targets. While its scope is broad enough to apply to complicated, multifaceted concerns such as software development, the techniques of project management are appropriate to for any project.

Project management helps organizations achieve specific goals, use resources effectively and efficiently, and typically provides feedback or information that will impact future decision making. It helps an organization build a culture of execution and collaboration and achieve desired results reliably. Project management can also provide timely and accurate data that informs business decisions to maintain a competitive edge. Finally, project management ultimately increases productivity and enthusiasm among employees by developing and implementing effective communication processes.

Because project management has such a broad scope, the literature on the topic is equally vast. We can study it in general terms as it is applied across domains, or we can drill down as our projects become more narrowly focused on such areas as IT projects, or even more specialized, IT projects in health care.

Each of these professional arenas foster communities of practice that include professional associations, publications, and meetings. Many are broad and/or influential enough to cultivate their own special interest groups or sponsor industry standards and guidelines.

The IT field offers such professional organizations as the Association for Computing Machinery and the Institute of Electrical and Electronic Engineers, better known as IEEE. Professional resources for the specific area of health IT can be found at associations like Health Information Management Systems Society, the American Health Information Management Association, and the American Medical Informatics Association.

The Project Management Institute, or PMI, is also a great source of information on project management. Along with its PMBOK guide, it offers a PMI health care special interest group.

Like any professional area of knowledge, project management comes with its own vocabulary and concepts. The first term you will need to understand is scope. Scope defines the boundaries of a project, such as schedule, financial resources, objectives, and staff. “Scope creep,” refers to the tendency of most projects to shift boundaries as the project moves forward, and professionals often use the term, “gold plating,” when they speak of adding needless details to a project. Keeping a watchful eye and a firm hand on your project scope will help you avoid such project roadblocks as scope creep and gold plating. Scope is considered one of the recognized project constraints, which also include schedule and funding. Project risk refers to those factors that may delay or obstruct a project’s completion. Part of a project manager’s job is to plan for and reduce the amount of risk to a project. Another primary part of your job focuses on communications. No project can run smoothly if expectations, responsibilities, objectives, and timelines are not clearly understood by all stakeholders, or those who are invested in your project. Stakeholders can include team staff, clients, or consultants. As a project manager, you may find yourself communicating with these stakeholders though a number of different media, including hardcopy documents, email, or project websites. Finally, the term, “deliverables,” refers to the project’s final product or results – the outcome that you “deliver” upon completion of the project.

The five process stages of project management include the following:

•Initiation,

•Planning,

•Implementation,

•Monitoring and Controlling, and

•Closing.

The initiation stage covers all the processes that define the project’s scope, objectives, and environment. Once the manager develops a comprehensive grasp of these details, he or she can begin the planning stage. This stage focuses on developing a schedule and budget, identifying necessary staff, resources, and supplies, and preparing for potential risks – all of this work is captured in the project plan. During the implementation stage, the manager will target the project’s staff, process, activities, and resources toward the project objectives. The monitoring and controlling stage includes supervising this entire execution, while constantly reviewing the current outcomes against the project plan and defined baselines, and controlling for risk. Finally, the manager presents the final deliverable for client acceptance or approval during the closing stage, while finalizing the project processes and activities.

Why use process? A defined process technique is not an assembly line of automated steps. Rather, it provides structure, consistency, clear communication, and efficiency controls that improve the way you and your team work. It also minimizes risk and eliminates problems.

The literature on project management offers many approaches, or project life cycles, to the work. Based on certain project details, such as project scope, complexity, outcomes, and timelines, the project manager decides which life cycle best suits a project.

This unit provides a basic overview of project life cycles, but you will receive more in-depth information on various project approaches in later units. For now, briefly, project life cycles include a linear method, which is typically best applied to large, complex projects, while iterative and adaptive methods are more appropriate for rapid application development or projects that occur over short periods of time and require high levels of prototype development, feedback, modification, and redelivery. Agile techniques are best used in small-scale projects or on elements of a broader project that require a quick turnaround.

•This slide identifies several common reasons for initiating a project.

•First, opportunity.

•Market demands often call for a project.

•Technological advances or challenges often inspire new projects.

•Challenges include customer-requested tools or social needs.

•The last category of drivers is business requirements.

•In the field of health IT projects, these include legal requirements, clinical advances, and regulatory requirements.

Over the next five years, Meaningful Use (MU) will become a major driver of health IT projects. Meaningful use is a new term that has come into the health care market in recent years. The American Recovery and Reinvestment Act of 2009 outlined the government’s expectations for meaningful use of health care technology. Implementing meaningful use initiatives nationwide improves quality, safety, and efficiency of patient care, engages patients and families in their own health care, improves care coordination, ensures adequate privacy and security for personal health information, and improves population and public health.

Let’s take a look at the state of health IT implementation across the nation. The 2011 HIMSS survey of health care information technology noted that 51 percent of hospital respondents have an IT strategic plan for health IT conformance to meaningful use; 36 percent have health IT strategic plans that are separate from, but aligned with their IT strategic plan; and the rest have no plan at present.

This slide shows the survey respondents’ plans for future projects: 64 percent plan to increase their IT staffs in the next 12 months, and 76 percent will definitely and/or probably increase their budgets for health IT initiatives. Clearly, we are on the edge of a big reform in health IT.

Achieving meaningful use requires necessary changes in the health industry. It demands changes to the way the entire information system in this industry is managed, distributed, and exchanged, by whom, how, and for what purpose.

It requires a realistic approach to the technological landscape that can capture the knowledge and skill sets necessary to achieve meaningful use. These include the current and future workflow of health information, the appropriate health IT infrastructure, and the ability to drive projects effectively.

This is where project management comes in. Meaningful use affects everyone in the health care strata. A small doctor’s office can receive tens of thousands of dollars in incentive payments from the government for implementing a health care IT system, while a large academic hospital could get millions of dollars for increasing its meaningful use of health care IT.

All of these organizations need someone who can understand and manage the demands, resources, processes, challenges, and benefits of these complex projects.

As a project manager, you will be driving the health IT initiatives. Although these projects can have specific and complex details, the basic lessons of project management apply: You are responsible for realizing the project’s vision by following the typical processes for project management: planning, execution, monitoring, and closure. And you will also provide a level of subject matter expertise. Since so many IT projects are supervised by committees unfamiliar with the specific issues and challenges of these jobs, the committees often hire project management professionals to oversee operations and achieve their objectives. You will function as that subject matter expert.

Your first job will be to understand this new landscape, so that you can define your scope and lead your team authoritatively. Project managers who come from a business or IT framework will need to learn the medical terminology so that they can discuss projects with health care professionals. At the same time, those who come from the medical side of project management will need to acquaint themselves with the technical requirements so they can have productive conversations with the technical groups. Project managers need to be able to work on both sides of the tracks.

According to the HIMSS survey, hospitals’ health IT priorities include achieving meaningful use by focusing on such clinical systems as computerized practitioner order entry, electronic health records, and e-prescribing, and by optimizing current systems. Nearly half of all respondents noted that their health IT projects will focus on implementing the International Statistical Classification of Diseases and Related Health Problems, 10th Revision, better known as the ICD-10. The ICD-10 includes the medical classification list for the coding of diseases as maintained by the World Health Organization.

The HIMSS website is a great resource for information on health IT.

You will need to gather details about the organization’s current information systems and how they perform on the meaningful use intended outcomes of quality, safety, and efficiency. This information will provide your baseline to track your new system’s improvement. As you begin developing your new system, the choices you make will impact future information systems, so it is important to employ staff with the appropriate skill sets who can design with an eye to future use.

What kind of information does health IT share? It breaks down as 94 percent clinical information, 89 percent patient demographics, and 49 percent billing code information. These kinds of details will help your IT staff tailor the system appropriately.

Once you’ve done the legwork in developing your scope, the rest of the process should be very similar to other project management work. During your planning stage, you’ll assemble a team of skilled, creative professionals and develop a time line and resource allocation. It is important to know that because health IT projects are so complex, they tend to become unwieldy. One way to tackle an overwhelming project is by reducing it to a number of simpler goals. So, you might take a complex project, such as digitizing a medical office’s paperwork, and break it down into manageable parts. These might include one project for converting records to digital format, another for training personnel to use the digital database, and then a final project to post the database online. This process allows you to step up to meeting the overall objectives of the project by reaching achievable goals and charting your progress. A major part of your job requires a constant vigilance regarding your project boundaries, so don’t let a project grow in complexity beyond its scope. Your stakeholders, especially those on the client side, often propose “improvements” to your project that would ultimately tax your budget and resources without offering truly beneficial functionality. You will need to weigh these requests against your project constraints and objectives, and thoughtfully consider only those that bring true value to your project. A large part of project management is personnel management, so you must communicate time lines, deliverables, and expectations to your staff. Be willing to implement motivation or negotiation techniques, and maintain a respectful awareness of others’ politics and cultures.

Project success factors include the following: •Executive support can make or break a project, particularly in regard to resource allocation. •From the very beginning of a project, user investment and participation is essential to your success. If you don’t have a comprehensive understanding of your user’s requirements or how they hope to use the product, your project will fall short. •A profitable undertaking often depends on an experienced project manager, especially in a highly specialized field like health IT. Their background and familiarity with the demands of the specific environment and its users can help a project reach successful completion. For instance, an experience project manager will take a clinical provider’s hectic schedule into account when planning meetings or requesting feedback. Unlike the fairly predictable schedule of a business environment, the demands on a clinician’s time can be irregular and urgent. To accommodate the changing schedules of these stakeholders, meetings must be short, efficient, goal-oriented, and above all, flexible. •Using a clear set of business objectives to frame and focus your project are critical elements in your success. Why are you undertaking this project? What do you hope to achieve? How will it help the organization’s business? These are all questions that can help you define your business objectives for this project.

Factors contributing to failure include lack of planning, lack of resources, and an unwieldy scope—but if you have planned correctly in your early stages, these should not become major issues.

This concludes Lecture a of An Overview of Health IT Projects. In summary, health IT projects and the approaches to those projects vary widely in terms of scope, critical need, and risk factors, but they all have one aim: to produce a needed product or service.

Understanding that certain factors are common across all projects can help you manage those differences to achieve success in any kind of project. The project management process is not magic: it is built on a sure combination of technique and experience, and if you educate yourself on the details of the health IT scope of your institution, it will lead you to a successful outcome.

No audio.

comp8_unit3_lecture_slides
comp8_unit2_lecture_slides
comp14_unit3_lecture_slides
comp8_unit4_lecture_slides
comp14_unit8_lecture_slides
comp8_unit5_lecture_slides
IT_Project_Management
comp19_unit1a_lecture_slides