1. Xerox & Faxton St. Luke’s
Healthcare System
A Partnership in Clinical
Documentation
Anil A. Bapat, M.S. PMP

2. Our Journey
 Patient Education Log (Oct – Dec 2012)
 KBC/Clinical Documentation (Jan – June 2013)
 Staff Augmentation & Support (July – Dec 2013)
 Knowledge Transfer (Jan – June 2014)

3. Patient Education Log
Oct – Dec 2012

4. Patient Education Log
Our Challenge:
Patient Education is scattered in multiple areas of the chart.
We need a central location where all clinicians can go to see
what education has been given to the patient and when.
Solution:
Implement the Patient Education Log in Allscripts.

5. Our Approach:
 Load Core Modules into the system
 Design Meetings with Project Sponsor
 Rapid Prototyping (Build)
 Stakeholder Meetings to Review Prototypes
 User Training/Education
 Go Live/Activation Support
Patient Education Log

6. Load Core Modules into the system:
 Loaded by Allscripts System Engineer (SE)
 Validation of load by Xerox/Faxton.
 Confirmation of Patient Education Log licensure.
 Webex Q&A session with Allscripts Subject Matter Expert.
Patient Education Log

7. Design Meetings with Project Sponsor:
 Initial Design Template created and reviewed with Faxton Project
Sponsor
 Key Design Decisions included:
 Integration with Exit Care module?
 Names of Document Categories
 Names of Documents
 Mappings of Documents to Categories
Patient Education Log

8. Rapid Prototyping (Build):
 Iterative Development
 Reviewed with the Faxton Project Sponsor at regular intervals prior
to presenting to the Stakeholders (Clinicians)
Patient Education Log

9. Stakeholder Meetings to Review Prototypes:
 System Wide Meetings were scheduled with the Clinicians to present
the content developed by our teams:
 Meeting #1: Review Initial Prototype
 Meeting #2: Make Revisions from Initial Meeting & Demo the
Final Build for Signoff
Patient Education Log

10. User Training/Education:
 Education Packets created for ‘Train the Trainer’ sessions.
 Workflow Diagrams
 Live Classroom Training Sessions with the Clinicians.
Patient Education Log

11. Go Live/Activation Support:
 Load Patient Education Log content to Production environment
 Post Load Manual Build work
 Activation – Dec 18th
 Post Go Live Support/Chart Audits
Patient Education Log

12. Accomplishments:
 Establishment of a clear Project Plan w/timelines and milestones for
implementation.
 Development of a Prototype Signoff Process to validate requirements.
 A savings of 80 hours of manual build work through use of
automation tools to move content between environments.
Patient Education Log

13. Knowledge Based
Charting (KBC/Clin Doc)
Jan – June 2013

14. Knowledge Based Charting
Our Challenge:
Clinical Documentation is scattered and fragmented within
the system. Clinicians seem to work in silos and there are no
guidelines or standards for documentation within the
Electronic Health Record.
Solution:
Implement Knowledge Based Charting (KBC) to establish
best practices in documentation.

15. Our Approach:
 GAP Analysis
 Design/Configuration
 *BUILD FREEZE – Load content to TEST/TRAIN
 Document Testing/End User Training
 Load content to PROD/Activation
 Post Go Live Support/Chart Audits
Knowledge Based Charting

16. GAP Analysis:
 Compared site’s current build to KBC content.
 Analysis was done by document and discipline (Nursing, Rehab, ….)
 Goal was to adopt as much of KBC as possible with minimal
customization.
Knowledge Based Charting

17. Design/Configuration:
 Reviewed GAP Analysis with Clinicians
 Built necessary customizations into KBC documents
 Validation/Signoff of each document
Knowledge Based Charting

18. BUILD FREEZE – Load content to TEST/TRAIN:
 BUILD FREEZE – May 10th
 KBC content was unloaded from DEV and loaded to the TEST and
TRAIN environments.
 Validation of loads was performed by Xerox and Faxton teams.
Knowledge Based Charting

19. Document Testing/End User Training:
 Testing/Training activities were performed for next 3 weeks
 Issue Log was used to record defects uncovered in testing
 Tip sheets were created to help resolve training/workflow questions.
 “Mock” Go Live test runs were staged to simulate downtime process.
Knowledge Based Charting

20. Go Live/Activation Support:
 Downtime/Cutover – June 10 – 11th 6PM – 7AM
 KBC content loaded to Production environment
 Post Load Manual Build work
 System Release – June 11th @7AM
 Post Go Live Support/Chart Audits
Knowledge Based Charting

21. Accomplishments:
 Establishment of a clear Project Plan w/timelines and milestones for
implementation.
 Development of a Prototype Signoff Process to validate requirements.
 Enforcement of a BUILD FREEZE date ensured delivery of stable
documentation at Go Live.
 Creation of new Interdisciplinary Flowsheets promoted standardized
documentation
Knowledge Based Charting

22. Accomplishments:
 Clinical Summaries allowed for “1-stop shopping” view of patient chart
 A 50% increase in documentation consistency was reported as an
Initial Improvement post go live
 Creation of “Pull Sets” allowed for Nursing Documentation to be pulled
into Ancillary Department notes (Nutrition, Rehab)
 Automation of Clinical Practice Guidelines (CPGs)
 Greater sense of Participation and Ownership felt by departments in
the Patient Care process.
Knowledge Based Charting

23. Staff Augmentation &
Support
July – Dec 2013

24. Staff Augmentation & Support
Our Challenge:
Now that the site is live on Knowledge Based Charting, we
need to be able to sustain the momentum we’ve created with
Interdisciplinary documentation.
We also need to be able to control requests for future
changes to documents in the system.
Solution:
Establish a formalized Change Control Process.

25. Approach:
 Identify key components of a Formalized Change Control Process
 Establish process for progressing builds through the environments in
the system
Staff Augmentation & Support

26. Change Control Process Components:
 Change Request form
 Change Control Spreadsheet
 Weekly Change Control Review Meetings
 Evaluate change for impact to other areas of the system
 Develop Initial Prototype
 Review Prototype with End User & Obtain Signoff
Staff Augmentation & Support

27. Environment Progression of Builds:
 Change Request does not leave DEV environment until signed off by
end user.
 Once approved, move to TEST and TRAIN environments.
 Extensive testing performed on Change Request in TEST environment
to ensure accurate outcomes.
 Conduct End User Training on changes, if necessary.
 Coordinate time with the end user to move Change Request into the
PRODUCTION environment
 Move the Change Request into PRODUCTION.
 Notify End User that request is complete.
Staff Augmentation & Support

28. Accomplishments:
 Better accounting of Change Requests
 Easier Status Reporting on Change Requests
 Improved focus on Higher Priority Change Requests
 More accurate, reliable testing
 Consistent Training
 Easier Troubleshooting for Production Issues
Staff Augmentation & Support

29. Knowledge Transfer
Jan – June 2014

30. Knowledge Transfer
Our Challenge:
We need to enable the site to support their Clinical
Documentation after we roll off the Project.
Solution:
Facilitate Knowledge Transfer and create a Formalized
Training Program for new Faxton employees so they may
support the system going forward.

31. Phase 1 – Foundation Concepts:
 Environment Overview
 Introduction to Change Control Process
 “Pre-Build” Work:
 Create a “build spec” for each change request on paper before
doing anything in the system.
Knowledge Transfer

32. Phase 2 – Basic Clinical Documentation Concepts:
 Introduction to lists, observations, sets
 Build Simple Change Requests:
 List item additions
 Spelling corrections
 Add new observations
 Moving (positioning) items within a document and/or set
Knowledge Transfer

33. Phase 3 – Advanced Clinical Documentation Concepts:
 Introduction to Discriminants, Flowsheets, Structured Notes, MLMs, etc
 Build Advanced Change Requests:
 Create a new Flowsheet or Structured Note
 Build Discriminants
 Calculations/Advanced Calculations
 Develop Clinical Summary Tiles/Views
 Pull sets
 Multi-Part/Faceted Change Requests (Ex/ Clinical Documentation
interfacing with Order Items, MLMs, Reports)
Knowledge Transfer

34. Phase 4 – Transition of Ownership:
Faxton Resource now:
 Leads Weekly Change Control Meetings
 Builds Prototypes
 Develops plan for moving changes between environments.
Knowledge Transfer

35. Accomplishments:
 Instilled a good working knowledge of Clinical Documentation to
Faxton resource
 Faxton resource is now able to conduct effective meetings and calls
 Faxton resource is now able to effectively complete any build
assignment asked of him or know where to go to get support
Knowledge Transfer

36. Questions?