IT Integration in Critical Access Hospitals

1
IT Integration in Critical Access Hospitals

• Lucas Kirkbride
• IT Coordinator
• Illinois Critical Access Hospital Network

2
IT Integration can be more of a challenge in CAHs

• Why
• Small staffs
• Small budgets
• Small Facilities

3
What makes Integration critical to the IT
department

• Time
• Money
• Buy-in

4
Time

• Any project takes time, the length of that time
  is often determined by three things
• Scope of the project number of apps, amount of
  equipment, number of users
• Preparations available space for equipment,
  additional security, bandwidth, planning
• Support troubleshooting problems, training,
  patchiness

5
Money

• Money as they say is always tied in with time and
  IT is no exception.
• We always budget for projects and integration is
  directly responsible for that budgets figures
  accuracy.
• The same three variables for Time affect money
• Scope
• generally speaking the scope of a project is easy
  to account for as costs are determined prior to
  purchase
• Preparations
• Often go unbudgeted
• Directly affect support
• Support
• Almost always unbudgeted
• Can become the most expensive variable in the
  project.
• Always recurring

6
Buy-in

• I am sure that CFOs will disagree here but to me
  this is the most important of the three areas
  that integration is critical.
• If no one uses the new systems or functionality
  then youve wasted your time and money.
• A smooth integration with proper motive and
  training will ensure a good buy-in by users.
• Testing is often the most crucial part of
  avoiding poor buy-in

7
Back to the question of how this relates to CAHs

• The same steps that are often applied to larger
  facilities in regards to proper integration
  techniques often cant be applied in the same way
  at CAHs.

8
So what are the steps?

• Concept
• Design
• Test
• Re-design
• Train
• Implement

9
What is different for CAHs?

• Lets look at the steps, what they mean, any
  pitfalls and then how they relate to CAHs.

10
Concept

• This step is the discovery phase of
  integration.
• Find out the requirements
• Find out the prerequisites
• Find the best fit
• Determine a provider

11
Pitfalls

• Overlooking the prerequisites is the most common
  pitfall associated with this step.
• These often present themselves as a problem
  during the testing and implementation steps.
• Not considering the user
• Process that is too complicated
• Interfaces that arent intuitive
• How the process or system is delivered and used
  by the user

12
What is different for CAHs

• IT isnt a part of this step always
• Department heads that need the new systems or
  functionality often decide what to use or who the
  provider will be.

13
How to fix this

• Policy
• The easiest step to fix this is policy
• No new systems get approvals until IT has been
  consulted, briefed and had a say.
• Structure
• IT is moving to the front office.
• Your IT department should be integral to all
  decisions made in regards to the direction your
  hospital is moving with Technology.
• You should have an administrative/executive
  position that either.
• Is wholly accountable for technology decisions
• Or at the very least knows what is going on day
  to day in the IT department and understands IT.
• CIO Chief Information Officer

14
Design

• Here we determine the whos, whats, wheres and
  hows.
• Who will be using the systems
• What equipment will be involved
• I say involved because not all will be new.
• Where the equipment will be housed
• How the application will be delivered

15
Pitfalls

• Overlooking the equipment outside of what is
  being purchased
• Will Active Directory be a requirementDNSexterna
  l access?
• Will this affect any current production systems?
• Will I need to upgrade any production equipment
  or systems?
• Purchasing equipment that doesnt fit in
• Dont forget to think about the network closet
• Dont forget to think about the users environment

16
Whats different for CAHs

• The only thing that makes CAHs unique is the
  where.
• Most CAHs do not have much room for housing all
  the growing equipment demands of IT.

17
How to fix this

• Designate more space
• Move offsite
• Go virtual

18
Test

• This really speaks for itself

19
Pitfalls

• Testing if the application or system works and
  not whether it works as the user will actually
  use it.
• Test all variables
• Test with a limited set of users to determine
  functionality

20
Whats different for CAHs

• This step is often not practiced in CAHs
• No budget for a testing environment
• No room for a testing environment

21
How to fix this

• If it aint broke dont fix it
• Does there really need to be a testing
  environment?
• Instead of using a testing environment create a
  test phase in the project where you have all
  pieces in place but have yet to introduce the
  full set of users.
• Use a Virtual environment
• Implementing a virtual server environment can
  allow you to create a testing environment with
  little additional costs.

22
Use your best judgement

• Will it disrupt current production processes
• Possible network disruption
• Replacing a current production system
• When you cant test use 3P0
• Prepare
• Plan
• Prevent
• Organize

23
3P0

• Prepare
• Spend extra time on Design
• Plan
• Having a Plan B becomes paramount
• Prevent
• Determine where you are likely to have issues
• Organize
• Work with everyone involved to make a smooth
  transition

24
Re-design

• This is the step where we fix those problems
  discovered in the testing phase

25
Pitfalls

• This phase relies entirely upon your testing
  phase.
• If all aspects of the integration were not tested
  then it is possible not all problems were
  detected.
• Re-designing the technical aspects and forgetting
  the user aspects
• Often engaged after Training has occurred.
• Leads to poor buy-in
• Leads to additional training sessions as users
  loose what they learn during the re-design

26
Whats different for CAHs

• Again we revisit the possibility of no testing
  environment

27
How to fix this

• Make sure this phase is always practiced prior to
  Training
• Again there may not be a wholly separate testing
  environment
• Determine if the re-design will interfere with
  production systems and processes.
• If it does remember 3P0
• Once the technical aspects of the re-design are
  proven make sure that again you use a limited set
  of users to determine if the re-design addresses
  usability.

28
Train

• Here we train all those who will be utilizing the
  system

29
Pitfalls

• Training prior to system being ready for
  implementation
• Training too early will lead to forgotten
  processes
• Dont forget to retrain
• Not every aspect of the system will be used on a
  daily basis
• After users have been using the system for 3 or 4
  months have a retraining session.
• Make sure your there
• IT is often asked questions regarding
  functionality or how to
• Get good manuals and reference material from the
  vendor
• Keep a copy

30
Whats different for CAHs

• Training users with more than one role in the
  facility.
• CAHs often have users who wear more than one hat
  and therefore it can be tough to fit in a proper
  training session or have the same retention
  levels as a user that only has to attend to the
  one system or process.

31
How to fix this

• Retraining becomes a necessity
• Use several retraining sessions instead of one
• Revisit the user sooner to retrain on all of the
  daily processes
• 1-2 weeks after implementation
• Revisit the user twice regarding processes that
  do not occur on a daily basis
• The time spent on retraining is often much less
  than time lost

32
Implementation

• The big roll-out

33
Pitfalls

• Training too early
• This will lead to an impromptu training session
  given by you (the IT person) when you really have
  other matters to attend to (like the roll out)
  and other information you want to impart to the
  users (username, password) which will undoubtedly
  have to now be repeated on a regular basis.
• No plan B
• Just because you have made it to the big day
  doesnt mean it will all still work.
• Make sure you have a plan of action when
  everything starts to blow up.
• Helps instill confidence with the users so that
  if things do tank you dont hurt your buy-in
  points
• Also eliminates down time for employees

34
Dont get ahead of yourself

• Make a roll-out plan and run through it before
  the actual roll-out
• Roll-outs no matter how smooth are still mini
  training sessions.
• Questions that users may have been uncomfortable
  asking are often presented during roll-out
• Making sure your roll-out steps are logical and
  flow from one step to the next will ensure that
  these questions can be asked as you move through
  the roll-out instead of having to go back or
  jump ahead

35
Whats different for CAHs

• Staff support is limited
• During a roll-out the IT person is general
  focused on the roll-out
• Still a whole hospital to attend to

36
How to fix this

• Ticketing systems
• Starting to see these widely used throughout CAHs
• Spiceworks
• Boss Assist
• OTRS (open source trouble request system)
• Short term staffing or project staffing
• Use those users that have been part of testing to
  help if you have to leave abruptly.
• Update your voice mail message
• Set an out of office message
• Setup breaking points during the roll-out

37
Whats the point?

• IT is moving to the front office of every
  healthcare facility
• Managing all Patient Data
• Ensuring Quality Care and Patient Safety
• Delivering healthcare to the Patient
• IT will be overwhelmed with project plans and
  roll-out dates
• Good Integration practices
• Quicker roll-out times
• Make tough multi-leveled integrations easier
• Allow your department to make the transition from
  Back end to Front end smoothly

38
Follow these steps, avoid the pitfalls and adapt
them to your environment

• Eliminate time and money wastes
• Ensure good buy-in when a system is rolled-out.