EMR Epic, CAT in ServiceNow

[Punahele Tanne1]

Looking to discuss a solution for migrating Epic CAT to ServiceNow.  I have not been able to find any current discussions regarding a solution.

The TL;DR just wrote I'm now compressing down to high level thoughts.  I will happily run tangent with details upon request, but the following are solutions currently in place, tried, or proposed

• Service Catalog (in use now for small apps, not Epic)
  • Update and enhancement requests from clinicians and staff come through a generalized form. Selecting the software title from a pulldown designates the SME group that receives the first Catalog Task to Scope the request.  Basic Workflow cadence of "Scope » Develop » Test » Move to Production" is setup, with each phase being a Catalog Task with editable Variables.  If during Scope, it is determined that update/enhancement extends outside the software/platform bubble, a CHG is generated passing the aligned Variables to the CHG form fields to then be submitted through the large Change Management CAB process.  Otherwise, Assignment Group managers rubber stamp smaller requests at various stages until moved to production.  RITM is the record of audit.
  • CON: Metrics are Variable based.  Database views help but the more records there are the slower the metrics can be rendered.
• Change Request w/ Extended Table
  • Extended table from CHANGE_REQUEST, custom workflow, currently in development for HR app
  • PRO: Well documented methodology by ServiceNow to create a custom Change type and process to live alongside OOB Normal, Emergency, Standard.
  • PRO: Extended table allows delineation between large CAB and application-only CAB.  Type field allows workbench triggers, metrics, left navigation Change app links, etc. to be separated.
  • PRO: Conflicts still work the same allowing full visibility to overlapping changes.
  • PRO: Certain used/unused table column can replace Variables, lightening the overhead for rendering dashboard metrics or list views.
  • PRO: Single record for audit.
  • PRO/CON: Customer visibility in Service Portal required, including Customer Comment.  Easier to do with one record instead of REQ/RITM/SCTASK.  Extended table means differential numbering schema for easier visual delineation from proper CAB.
  • CON: Inheritance of UI actions, UI actions, data policies, etc. require removal of inherited and net new versions to allow desired functionality.  Also means that OOB BR may not work as expected due to the new Type, so those will all have to be customized/duplicated.
  • CON: the whole system is starting to become too custom and tedious to be replicated for other platforms.
• Change Request, no table extension
  • Well documented methodology by ServiceNow to create a custom Change type and process to live alongside OOB Normal, Emergency, Standard.
  • PRO: Workbench configuration is super easy to implement.
  • PRO: Epic Changes that need to go through larger CAB can be flagged to show up in the Authorize state in those workbenches, as appropriate.
  • PRO: Single record for audit.
  • CON: In order to use Variables section, CHG must be generated by Service Catalog record producer.  "itil" cannot just create a new record via the Change » Create New.
  • CON: No customer interaction OOB, but Customer Comment can be added and standard ticket can be updated
• Release Management
  • PRO: OOB is aligned with current and accepted development cadence.
  • PRO/CON: Agile-based development cycle, scrums and epics.  development/support teams are not using Agile, learning curve and management would be point of friction.
  • PRO: highly auditable.
  • UNKNOWN: Customer interaction capabilities via Portal.
  • CON: Requires a "manager" to understand and run individual "releases", "epics", etc.  Sheer volume may not make this feasible.
  • CON: ITBM requirement, cost and training.

If you've read this far, thank you.  All thoughts are welcome.  I'm leaning towards Change Request, no table extension as it is the most straightforward with the least amount of effort (relatively).

Thank you!

[tslogue]

A little late seeing this, but several years back our organization went with the 'Change Request, no table extension' route for our Epic Change Control process.

At a high level, to differentiate our Epic Change Requests, we added a new type choice for 'Epic Prod' and 'Epic Non Prod' Change Requests. To make the process work for our organization, at the time, we heavily modified the Change Request table allowing for multiple configuration items, multiple assignment groups, and multiple assigned tos to be entered in the same Change Request at a time. We then created a workflow that sends a change task to every Assignment group or Assigned to listed on the Change Request upon approval by the Epic CAB group. The only class of CIs that our change groups can submit a Change Request for on Epic Changes are 'Epic Master Files' which we store in our CMDB in a custom Epic Master File class, and those are what the changes are logged against.

I am not saying this is the best solution, its just how we are currently doing it.

If I were to go thru the process again today, I would probably have focused more on how our CMDB and the Common Service Data Model could be leveraged to stick to a more out of box process using the Change Request table, but this is serving our needs for now.

Happy to discuss more if you have any questions. Im interested to hear what direction you ended up going

[Ralph Hand]

We use ServiceNow for Epic changes but have not extended the change types.  I am unclear why you would want a new change type for epic change, cause you would still need to have epic change normal, epic change emergency, and probably epic change standard.

We have the epic modules set up as applications and one overall CI for Epic core.  Each of the modules is "owned" by the Service Owner for that area.   The pharmacy epic module is owned by the Pharmacy service owner along with all other Pharmacy applications.  

There is a group that reviews all changes related to epic but that is accomplished with a task and/or a flag as necessary.

If you want to add a "technical" or other approval you could just make it conditional on it being an Epic CI.

Epic changes should not need a different workflow than other changes.   What happens if there is another normal change that has an impact on your epic implementation.  It won't go to your Epic CAB.

Could you also clarify what your definition for customer is.  It is unit clerks, nurses, doctors?

If you want user approvals then add that to the flow and set up groups for them.   I'm pretty sure they'll need ITIL permissions if you want them to add comments beyond a change approval.  

I'm probably missing some nuances here.

[Punahele Tanne1]

Apologies for the long delay in response.  Here's an update, as well as the motivation behind what we built.

A team was gathered to discuss the existing process in the long-standing homegrown solution and compare it against the documentation requirements needed by a third-party auditor.  It was decided to plot the typical cadence of 90% of all customer-requested or Incident-sourced development requests, which lead to the following:

1. Pre-Scoping Approval (rare) [group approval]
2. Scoping [catalog task]
3. Development [catalog task]
4. Peer Review/Testing [catalog task]
5. Change Authorization/Implementation [change request]
6. Attestation [catalog task]

Due to the above cadence, it was decided to use the Service Catalog as the point of entry for customers and fulfillers to begin the process instead of a Change Request record producer and creating a "4th change type" to create Change Tasks and a custom process.  There are other factors like feedback from the customer that they were not aware of where something was at in the homegrown solution and the need for customer communication and status.  Since Change Management is not customer facing and I did not want to attempt to add Customer Comment to Change Request, Service Catalog seemed most appropriate as customers and fulfillers are already familiar with it.

The initiating Catalog Item form includes a pulldown to select different aspects of Epic, like "Beacon", "Hospital Billing", "Ambulatory" etc. that were familiar to both customer and fulfiller.  Choosing an aspect also dictated certain process paths when the form was submitted, including the group queue the initial Scoping Catalog Task would go to.

It was also decided that all developments, including break/fix, will need to go through this process for auditing.  A UI Action was added to allow certain fulfillers the ability to transfer Incident field information to the initiating form by simply clicking a menu item.  Clicking the menu item would refresh the content frame to the Catalog Item form.  The URI would include a back reference to the originating Incident, allowing an onLoad Client Script to detect the presence of the back reference in the URI and query a Script Include to pull and apply existing Incident field data to certain form fields, greatly reducing the effort a fulfiller required to get the process started.  There is additional functionality that carries that Incident Reference through to the RITM when the form is submitted, allowing the process to close the Incident and provide an email notification of that transfer to the customer.  That notification was sourced from the new RITM, so any reply would be to the RITM and not the now-closed Incident.

Pre-Scoping Approval would only be done for certain changes that needed to be reviewed by nursing boards, quality control and other operational boards before the level of effort could be scoped.  Quite a few requests have been squashed during this phase, preventing frivolous requests from reaching the development teams.

Scoping is a group queued Catalog Task and leans on a moderate number of fulfiller-editable Variables that are also used to guide the process along different paths post-scoping.  For example, if it was determined that trainers need to be engaged to update documentation, update Epic Dashboards, or provide staff training, selecting Yes to "Engage Epic Training Team" would generate a process-tied Catalog Task to the RITM that requires completion to close the request.  We also wanted to leave room to allow for speed-lane or operational day-to-day work that may not require CAB oversight.  To that end, a functionality was developed to allow the Scoping process to choose a "change path" of Normal, Emergency and Standard.  A pulldown with available Epic standard change templates would apply the template fields to matching RITM Variable fields that match some fields in a CHG record, Depending on the change scoped, those fields would apply to the CHG record generated from the RITM process, minimizing the data entry requirements to kick off that Change Request down the necessary approval and implementation path.

Peer Review/Testing is exactly how it reads: ask a peer to review your changes with fresh eyes.  Because we are utilizing Service Catalog, a Catalog Task can be closed cancelled noting that review/testing failed.  A failed review/test will reopen the above Development Task with the close notes of the review/test Catalog Task, allowing the developing fulfiller to do more development.  Closing that Development Task will reopen the Review/Testing Task which, when closed successfully, will trigger the creation of a Change Request as designated in the Variables section during the Scoping phase.

Change Authorization is just a CHG generated from the RITM process which has the added benefit of automatically adding the RITM as the parent of the CHG record.  This is lovely for dot-walking and filtering what change requests will show during the "Epic CAB" Change Workbench and also for metrics.  From here the change process is basically the same except the OOB process for Normal was updated slightly to add an if/switch checking explicitly for if the CHG has a parent that is the "change Epic" Catalog Item form, making the pending workbench approvals go to the Epic CAB board members instead of regular CAB.  If the Change needs to be rescheduled, the "back to draft" functionality was extended to work all the way into the Implementation stage.  If additional development is required, just like review/testing Catalog Task cancelling a CHG will reopen the Development Catalog Task so the process rolls all the back to the beginning,

Attestation is a Catalog Task that the fulfiller closes with any post implementation notes and is the document that says, "I have checked production and I have verified the update has been done to the specifications provided."  Closing this Task closes the request like any other Catalog Item process, unless the training team still has an open Catalog Task to provide documentation or staff training as required.  Once they close their Catalog Task, the request will be officially closed.

It's been 6 months and 1350 developments have been completed successfully, 220+ have been transferred from Incidents.  Fulfiller love the Incident transfer functionality and have already asked for it in other forms, but I'm trying to push that off.  I understand the need, but I would prefer to make sure address that scenario with customer and Service Desk training before expanding what should really be a backup solution.

Please ask questions and post comments.  It was a labor of love and I have many lessons learned.

Thank you.