I agree that migrating an interface from test to production is a function that is not provided by Cloverleaf and left up to the integraiton engineer to administer.
That’s not all bad becuase it creates job security and a deeper understanding of Cloverleaf along with a great deal of control over what you are responsible for.
Many of the foo-bars I hear about from other hospitals are a result of not having a low risk mehtodology for migrating changes into production.
Here is a copy of my checklist that might give you an idea of what to consider when you get ready to create your checklist.
My checklist assumes the person using it has enough experience to understand it and is not meant to be able to give to just anyone and have them follow it.
Remeber it is a checklist whose purpose is to reduce the chance of overlooking some step(s) or getting them in the wrong order.
It is not intented to be a segue into a bunch of questions.
You will also notice I’m running scripts that you will not have since I wrote them, but you will see what steps I’m doing.
You may find it helpful and a good place to start.
If you find it confusing then just disregard it.
There is a basic concept that will be beneficial to understand when reading the attached word document.
We avoid modifying an existing production site.
We make a copy of the site and modify the copy and usually do some testing on the modified copy.
Our mock sites that pretend to be foriegn systems during down time are very useful in facilitating this type of testing.
When the modified copy of the site is ready to activate, we shut down the current production site and point the symbolic link to the new production site and start the site running.
If there is a problem and we have to back out, we reverse the process and point the link back to the original production site so we are able to back out with 100% confidence since that original site was never modified.
Russ Ross
RussRoss318@gmail.com
.
