1 / 22

Change Control – tell me again why I need this?

Change Control – tell me again why I need this?. Presented by: Alice Brubaker Tymn Neece Lancaster General Hospital, Lancaster PA. Why change control is needed???. Have you experienced the following… Missing reference ranges?

hhorne
Download Presentation

Change Control – tell me again why I need this?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Change Control – tell me again why I need this? Presented by: Alice Brubaker Tymn Neece Lancaster General Hospital, Lancaster PA

  2. Why change control is needed??? Have you experienced the following… • Missing reference ranges? • Charges that didn’t drop….since you first went live... a long time ago???? • Change control values for one test, but forget it affects another group test? [PT and MIXPT] • Make change on a test, but forget to do change for other sites, if applicable?

  3. Change Control Why? • Patient Safety • CAP – GEN.43022 and GEN.43044 • Enterprise policy for change management • Internal or external audit response

  4. CAP requirement • GEN.43022 LIS Testing There is documentation that programs are adequately tested for proper functioning when first installed and after any modifications, and that the laboratory director or designee has approved the use of all new programs and modifications. NOTE: Computer programs must be checked for proper performance when first installed and after any changes or modifications. Any changes or modifications to the system must be documented, and the laboratory director or designee must approve all changes, additions and deletions in programs, the test library, and major computer functions before they are released. Documentation must be retained for at least two years beyond the service life of the system.

  5. Change Control What • What is Change Control A process followed to reduce risk associated with change • What constitutes a change… Any update to hardware, software and the application database • Industry Standards – ITIL (IT Infrastructure Library)

  6. Defining Change Types ITIL standard - BAU(Business as Usual) - Minor - Major - Significant - Emergency

  7. Defining Change Types LGH distilled the ITIL standard to: Standard Change Non Standard Change **Emergency is still defined as a process,not a change type

  8. Change Control Who? • All users with access to make changes to your system • Chain of command for user requested changes • Administrators of the HIS or other connected systems • Your Vendor!!!!???? [=Our SCC ‘friends’]

  9. Change Control When? Every time……without fail! (repeat!)

  10. Change Control How? • Change request • Defining change types • Procedure/Form for making changes • Testing changes • Approval of change • Implementation • Documentation of changes • Post implementation review

  11. Change Request • Define how you or your team wants to receive a request: Paper form Electronic process – ticket system or SharePoint • Have request approved and initiated by an authorized party • Evaluate change before you start

  12. Procedures/Forms for Making Changes Standard and frequently performed changes have written procedures Build sheets based on written procedures that include build steps and validation plan Standardizes change - results in a repeatable process – ‘any trained monkey can do it’ [….just kidding...] ****Best Practice**** Make all changes in a non production environment FIRST

  13. Document the Changes Build Sheets: - Document build and which environment with dates of changes and by whom - Includes other ticket references, i.e. STAR and/or hospital ticketing system System Log: - Central location to document all changes to the system (GEN.43044 – Software Modification Tracking)

  14. Example of Generic Build and Validation Sheets

  15. Change Documentation

  16. Testing the Changes Follow validation plan as written! Plan includes: - Testing steps – be specific - Expected results – flags, reflexes? - Pass / Fail - Date (time, if needed) - Tested by ****Best practice**** Have someone not making the change, do the testing – i.e., end user or person requesting the change

  17. Change Approval Define what changes are standard and don’t need approval before implementation - i.e., Doctors build vs. new test procedure All others: - Define who needs to review and approve a change before implementing - End user approval of end product - CAB = Change Advisory Board

  18. Implementation of Change Occurs Monday through Thursday ONLY, except Maintenance changes that can occur any time, i.e. new doctors, new users Some changes involve workflow or downtime and are scheduled at off peak hours Change must be communicated to end users Planned Downtime must be communicated in advance

  19. Post Implementation Review Highly recommended for complex changes Check ALL Soft modules Check HIS or other connected systems **** Best Practice**** Perform documented verification of the production process with actual patient data.

  20. Notes • LIS TEAM of 1

  21. Share your Experience • Please share how you manage change. • Any lessons learned? • Questions?

  22. The End

More Related