1. ‘CORRAL’ Your New Instrument Build
OR... How to be sure to rope and tie all the ‘little doggies’ using a Project Plan!!
Alice F Brubaker, MT (ASCP)
Applications Analyst – Clinical Lab
Lancaster General – Lancaster, PA

2. Located in south central Pennsylvania
631 Beds
37,000 Inpatient Discharges
107,000 ED Visits
989,000 Ambulatory Visits
7,000 Employees
1200 Physicians
Soft Modules
2.5.1
HL7
SoftLab
SoftMic
SoftBank
SoftDonor
SoftID
SoftPath
SoftReports
SoftMedia
3 Hospitals, 3 Urgent Cares, 1 Health Express, 12 OP sites with another under construction in neighboring county.
Can see our IT Awards on this screen….

3. GOALS for this presentation:
Understand Basic Project Plan Principles
with Importance of Workflow Design and
End User Acceptance
Understand Basic Autoposting/Autoverification Tools:
Instrument Interface Control by Translation Table and Flags
RBS Use
Be Aware of the Gopher Holes on the Trail to Success (trials?)

4. Simple: new test on existing interface
ALWAYS a Project!
Simple: new test on existing interface
Complex: new instrument, tests and interfaces
Using MS Project software vs. using Excel Spreadsheets  Template on next pages….
Microsoft Project vs others available online: Basecamp, Huddle, Soho Projects 2 and MANY others.
Don’t have to use MS Project as seen on examples on next pages…what I use.

5. Scope Tab on Excel Template
Scope statements can be much more stringent or defined – always specify what ISN’T included, too.
ALWAYS get documented sign off on the Inclusions and Exclusions.
Scope Tab on Excel Template

6. Plan Tab on Excel Template
Add or remove steps as needed to each category – notice main steps of project: Planning, Build/Configuration, Testing, Approvals.
Must designate owners of each step and dates.
Plan Tab on Excel Template

7. Issues/Risks Tab on Excel Template
All issues and risks, no matter how small they seem or if easily resolved.
Issues/Risks Tab on Excel Template

8. We have change control forms we use for ‘simple’ changes, but making a spreadsheet to track all changes and including screenshots of the ‘before and after’ are often very helpful in the end stages.
Changes Tab on Project Template – if it is an involved build/project, using a spreadsheet and screenshots to track all the TEST changes can help when moving to LIVE – so nothing is missed.

9. Clear Authority (one Trail Boss) to:
Determine scope
Determine who is final authority for any change discussions
Hold regular meetings with ALL stakeholders for status updates, issue logging, problem resolution
Ensure adherence/accountability to jointly agreed upon time frames for each step of project
Initiates scope change discussion: 1st ? = feasibility
Involve administration as needed for attaining successful completion
Responsibilities/duties of the one in charge.

10. Project Plan Template: using one  fewer missing pieces  fewer surprises
Scope – Define what IS included as the ‘end product’ for the project. Stick to your guns and don’t allow wolves to be added to the herd of cattle.
Scope Changes – can be the result of changes to Resources, Timeline, or Cost
2) Include all stakeholders/customers:
End Users – lab, providers, hospital depts, etc.
IT – LIS, HIS, hardware, connectivity, etc.
Instrument Vendor
SCC
Others?
Scope statements to be used can be defined or designated by your organization and be very specific.
Be very careful to get input from all departments affected by the project or end product of the project. Get documented sign off.

11. Template (con’t): Workflow design:
All stakeholders/customers must be represented
Design it from start to finish (order result view/print and billing – LIS and HIS, if applicable)
Look for all possible ‘winding trails’ and ‘box canyons’ that herd may be driven into – misdirection will happen!
Face-to-face meeting are often the MOST productive way for workflow completion and agreement
Create a hardcopy map of the workflow
Get end user sign off, every time – helps to keep the scope from stampeding in other directions
Workflow is KEY – Having it defined and approved by all users helps ensure no scope changes down the line of implementation and that all potential tasks are accounted for at the beginning of the project.

12. Template (con’t):
4) Separate tasks should be developed for each step to
complete defined Scope(s):
What key decisions are going to be needed for scope completion – and get the decision made!
Workflows with end user approval/sign off
Time estimate/end date for each step
Staffing needs for completion of each step
Clearly designate responsible person(s) for each step
Issues and Risks encountered – use logs to track them
Testing: Functional, Application, Integrated
Documentation of all changes and testing
Main components are Planning, Build/Configuration, Testing, and Approvals, as were denoted on pg 2 of Excel spreadsheet examples.

13. Template (con’t): 5) Instrument/Interface Considerations:
Autoposting Use
Use of Autoverification, if Autoposted?
Flag Use on Interfaces
Translation Table Capabilities – value conversion and pipe rules with Error Translation Table
Values Tab on Test Maintenance
Use RBS to stop Autoposting in specific situations
Middleware Use
Post and Post Without Verification with Result Check Flags, Collection and Receive status, Partial Posting
Summary vs. Flags tabs; Actions with Error codes – stopping Posting, etc.
Test Maintenance and Value tab use; RBS – S type rules – UCOLR for Green urines
Middleware – using it can reduce use of trans table functions and RBS – simpler or not? What functions of middleware do you want to take advantage of and which ones you don’t? Testing – no easy ‘test environment’

14. Interface Tools: Summary & Flags
Double Negative “Without Verification”

15. Interface Tools: Translation & Errors
Translation Table with Actions on Error Translation Actions…. ^ (stop Post), ! (cancel), | (replace result)
P column – ‘partial post’ - posted when all other tests posted, but not verified. Flag 48!! Flag 39 important too (next slide)

16. Test Maintenance: Value Tab in Test Maintenance:
STOPL test and used on Values tab in Test Maintenance – it stops because of being a reflexed test with Flag 39 on the instrument interface being checked

17. RBS Use: ‘S’ rule (stop autopost): ‘H’ rule (stop autoverify):
S and H rules in RBS – looking for values or error codes, etc.

18. Tangled Lassos (Gotcha’s)
Instrument Vendor Misinformation (not OUR first roundup!)
No Interface needed – or you’re the first to build one!
Incomplete test build information
Proprietary calculations
Network/Organizational Security Issues:
Server access – vendor and users
Remote viewing - providers
Physical Network Issues – the trail splits:
PC connections
Network line drops
XP remediation!!
Security can be a real show stopper depending upon your organization’s constraints.

19. Tangled Lassos (Gotcha’s):
Server/Software Updates: mandatory ‘gopher hole’ that you discover at the end of the project
Equipment supplied by Vendor vs. your organization:
PC’s
Servers
Other hardware
Staffing woes:
Account for time off ‘the cattle drive’
Anticipate ‘river crossings’ with other projects or staff pulled
for production issues
Do you have the right ‘cooks and wranglers’ on the drive and around the campfire?
Coagucheck software
TEG interface build - examples

20. Tangled Lassos (Gotcha’s):
FINALLY:
Project a Go-Live date: based on realistic &
anticipated completed step dates ONLY –
don’t let them ‘bulldog’ you into an
over-aggressive timeline, but be mindful of
their needs, too.
Tasks  Milestones Go-Live date.
Go-Live dates should be firm enough to ensure all the steps are completed on time, but flexible enough to accommodate major and unforeseen impacts to the scope.

21. ROUNDUP: