Additional Links and Guidance
Intake, Triage and Assignment (Steps 1-4)
All requests must come from approved Digital Health Governance Committee (CSI / Enterprise Committee) road mapped work.
Ticket or project is flagged.
Ticket reviewed for completeness (up to date information added with triage outcome).
Confirm it is within the Builder scope.
Content is either created or gathered based on project needs, with subject matter experts (SMEs), IT partners and Builders engaged to ensure quality and relevance.
Builder assigned by Managers via CSI process and updated on the “Assigned Clinician Builder” JIRA ticket field.
Primary IT owner assigned through the IT Managers with support from Clinical Application Leads.
JIRA ticketing system
Minimum Dataset for JIRA tickets (mid way on the page)
Using JIRA as a Builder
Builder Scope
A planning discussion is held to confirm the roles, expectations, and responsibilities of those involved, including the Builder, Primary IT Owner, Praxis Owner, SMEs, CORe Leads, requestor, and any additional support roles.
During this discussion, the Builder, Primary IT Owner, Analyst, and others as needed review the scope of work and agree on how the build will be supported within Connect Care teams.
This includes discussing, confirming, and documenting in the request ticket:
The purpose of build planning is to establish a shared understanding of the configuration approach, build readiness, risk level, downstream impacts, and timing. Experienced Builders may also identify hidden complexity, integration risks, and interdependencies early so they can be addressed before build begins. These insights should inform the shared build strategy.
Prototype, Build and Documentation (Steps 6-9)
Prototype record creation in a non-production environment, either MPE or SBX. Because these environments are refreshed on a regular schedule, the Builder must understand refresh timing, so work is not lost. MPE and SBX environments are appropriate for early design, exploration, and learning because they allow the Builder to assess impacts to existing build without affecting the POC environment. They also support iterative work, comparison of multiple options, and situations where the final design, implementation approach, or timing is still being defined. For new Builders, they provide a lower-risk space to develop skill and familiarity with the build. Once the prototype is ready, the Builder reviews it with the IT primary owner, requestor and, where needed, the appropriate governance group.
The Primary IT Owner and Builder then review the mock-up together. If the build is ready, the Primary IT Owner confirms that the builder may move to the next stage, and analysis of downstream impacts begins.
The Builder then continues to record build documentation to explain the design logic and rationale for the build, and creates a Content Management ticket. For approval purposes, the Content Management ticket should be submitted in the Analyst’s name. Additional internal IT team processes for build tracking may also apply. The Primary IT Owner leads execution, ensures alignment with technical requirements and timelines, and completes any work outside the Builder’s scope.
In general, only finalized and approved build should be built in POC. This helps reduce the risk of incomplete or unapproved items being migrated to other environments, avoids conflicts with items already planned for migration, and limits long-term maintenance issues caused by outdated or abandoned build left in the development environment.
*An exception may be made for experienced Builders who complete build directly in POC. Any exception should follow the same principles of risk reduction, environment stability, and readiness which is discussed in the initial roles and responsibilities discussion.
Connect Care Content Management Ticket Guide (2026)
Content Management SharePoint
CM as a Builder
AHS Change Management presentation
Testing and Validation (Step 10-15)
Builder reproduces build in the POC environment, with support from Primary IT Owner.
Primary IT Owner tests build in POC environment (if required).
Build review completed with Primary IT Owner (build accuracy confirmed, CM documentation validated).
Primary IT Owner moves build to TST (data courier).
Builder performs testing in TST. Builder documents any issues with testing and coordinates with the Primary IT owner as needed.
Bigger changes will need a higher scrutiny of testing and collaboration with the Primary IT Owner. Integrated Testing may be required if impacting multiple areas.
Technical validation completed collaboratively with Builder and Primary IT Owner (confirming build records).
Final validation with requestor and/or governance group and approval obtained.
Note: Prescriber Builders are exempt from completing the change ticket. The Primary IT Owner completes on their behalf.
Integrated Application Testing
Epic Testing Strategy Handbook
Change and Migration (Step 16 -18)
Requirements met and validation completed, final approvals received.
Service Now change ticket required (Normal change requires a minimum of 3 business days).
Builder to connect with Training teams to determine if communications are needed (Connect Care Updates, CMIO Editorial Board).
CCCR meeting must be attended by Builder and Primary IT Owner, and tickets reviewed (if needed).
Once ready for migration to Production, follow IT Application Team’s data courier process for a normal change request (minimum 3 business days).
Builder completes final validation in TST and record check in PRD, as part of migration process.
Support post implementation – Builders will be engaged during normal business hours as needed if break-fixes occur. For larger changes, a formal support plan may be created.
Close Out and Communications (Step 19)
Ticket close and documented as completed (JIRA, SN, GSR).
Final communication sent to stakeholders, CORe Leads, CILs, and training teams.
Ensure appropriate teams (Training, Solution Center, IT Application Teams, etc.) have been updated.
