Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Change Management for Epic EHR

Samantha Hoschek
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 30, 2026

We are looking to use Jira's Service Managment Change Management module to track new requests as we move to using Epic's electronic health record.  I am looking to see if anyone is currently doing the same and if you are willing to share what your setup looks like.  Thanks in advance!  

1 answer

0 votes
Himanshu Tiwary
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Champions.
March 30, 2026

Hi @Samantha Hoschek ,

Welcome to the Community!!

My recommendation would be to Use one JSM project for change requests, with change types such as
  • Standard for low-risk, repeatable changes
  • Normal for planned Epic build or workflow updates
  • Emergency for urgent production fixes
 
You can follow this flow for the required use case
Draft -> Initial Review -> Clinical Review -> CAB Approval -> Build/Configuration -> Testing/Validation -> Scheduled for Release -> Implemented -> Closed
 
For Epic-related work, useful custom fields would be
Epic module/application, Request type / change category, Clinical impact, Patient safety risk, Environment (TEST/PROD), Implementation date, Rollback plan, Business owner / clinical owner
If your team is also using Jira Software, a common model is to track the governance and approvals in JSM Change Management
link each change to related Epic/build tasks, stories, or epics in Jira Software. That way, JSM handles the formal change process, while Jira Software handles delivery work.
 
For the approval model for healthcare
 Application/technical review, Clinical/business approval, CAB approval for higher-risk changes
 
Also Include dashboards that would add a plus for you lke
pending approvals, changes scheduled for go-live, high-risk changes, failed or rolled-back changes, changes by Epic module or team
 
My recommendation would be to keep the first version simple and only add complexity once your process is stable. For Epic, the biggest value usually comes from having clear approvals, risk visibility, and release tracking rather than building a very complicated workflow on day one.
 
If it helps you can follow this structure
  • Project: Epic Change Management
  • Issue type: Change
  • Request types: New build, workflow update, interface change, security change, urgent fix
  • Approvers: IT owner, clinical owner, CAB
  • Linked items: testing ticket, implementation task, rollback task
This gives you traceability without making the process too heavy.
I hope this adds value for your use case :)

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events