The Service Environment, Implementation Method, and Operational Support

Implementing an electronic medical record (EMR) across multiple sites is often described as a technology project: select the platform, configure the system, migrate or reconcile information, train users, and go live.

In practice, the technology is only one part of the implementation.

A multi-site EMR has to operate within an existing environment of people, clinical services, organizational structures, workflows, governance, infrastructure, information, and community relationships. Those elements are not identical from one site to another. The challenge is therefore not simply to deploy the same technology everywhere, but to establish a common platform while accommodating the realities of the environments in which it will be used.

This article looks at an EMR implementation through three connected perspectives.

Section	Title	Description
1	Why the operating model matters as much as the technology	The service environment: the operating model, roles, services, governance, relationships, and dependencies that shape what the EMR needs to support.
2	From Readiness to Go-Live: A Practical Model for EMR Implementation	The implementation method: how readiness, engagement, workstreams, sequencing, and go-live decisions can be managed when different sites are not equally prepared or able to follow exactly the same path.
3	An EMR Doesn’t End at Go-Live: Architecture, Interoperability and Operational Support	The EMR as a living service: what happens after go-live, when the focus shifts toward access, support, interoperability, development, operational change, and continuous improvement.

The three perspectives also provide useful lenses for thinking about the work through the disciplines of enterprise architecture, project delivery, and IT service management. In particular, concepts from TOGAF and ITIL offer ways to interpret the relationships between the organization, the technology, the implementation process, and the ongoing service.

The objective here is not to suggest that the implementation was formally delivered according to either framework. Rather, these frameworks provide useful ways of understanding what happens in a complex EMR environment.

The progression is straightforward:

Understand the environment → implement the change → operate and evolve the service.

The following three sections follow that progression.

---

Section One: Why the operating model matters as much as the technology

---

When organizations talk about implementing an electronic medical record (EMR), the conversation can quickly become technology-focused.

Which platform? Which modules? What interfaces are required? How will data be migrated? What does the implementation timeline look like?

Those questions matter. But in a complex, multi-site environment, they are not necessarily the questions that should come first.

An EMR has to operate within an existing service environment. Different sites may have different teams, services, workflows, relationships, leadership structures, infrastructure, and levels of readiness. The implementation therefore has to create enough consistency to support a common platform while retaining enough flexibility to reflect those differences.

That was the starting point for a provincial EMR implementation spanning multiple regions and diverse site contexts.

1. Start With the Vision

The implementation vision was a provincial EMR platform that could support consistent but flexible implementations across different regions, operating models, and site contexts.

That distinction is important.

Consistency does not necessarily mean that every site operates identically. In fact, attempting to make every site identical can create unnecessary friction when the underlying services and teams are different.

The objective was instead to establish a common platform and a common patient record while allowing implementation and configuration to respond to local circumstances.

The model included one provincial chart per client, supporting clinical standardization while allowing the implementation to accommodate different environments.

2. Define the Implementation Scope Broadly

The implementation scope extended well beyond installing software.

The work included engagement, site readiness assessment, configuration, training and change management, development and testing, go-live support, and operational support and sustainability.

That scope illustrates an important distinction between technology implementation and organizational implementation.

Installing an application can be a technical task.

Implementing an EMR is a change to how information is accessed, documented, shared, managed, and used to deliver services.

3. The Hub-and-Spoke Model

One of the most useful concepts in the implementation was the hub-and-spoke model.

Each implementation was configured around existing relationships between a primary hub and surrounding communities or service sites.

That relationship matters because the EMR does not exist in isolation at each physical location.

Teams may work across sites. Providers may have responsibilities in multiple locations. Services may be shared. Patient information needs to remain accessible within the appropriate boundaries.

The implementation therefore had to reflect the relationship between sites, not simply treat each location as an independent deployment.

4. Service and Role Composition Drives Configuration

Another lesson from the implementation was that the configuration of the EMR needs to reflect who is actually delivering services.

Different sites can have different combinations of physicians, nurse practitioners, nurses, medical office assistants, midwives, dietitians, mental health professionals, social workers and navigators, occupational and physical therapists, dental providers, traditional wellness and other roles.

The configuration reflects these differences and can evolve as roles, services, and care needs change.

This is another architecture lesson: requirements are not determined solely by the application. They emerge from the interaction between people, processes, services, information, technology and organizational structures.

5. Implementation Requires a Team, Not a Single Project Function

The implementation was deliberately team-based.

Project management, planning and development, clinical adoption, and operations each had different responsibilities, with leadership providing governance, scope and budget oversight.

That division is significant.

A project manager cannot independently solve configuration, privacy, migration, training, clinical adoption, contracting, infrastructure, and operational-support issues.

Likewise, technical teams cannot independently determine whether a community is ready to change how it delivers services.

The implementation therefore required cross-functional coordination rather than a purely technology-led delivery model.

6. Governance Is Part of the Delivery Environment

The implementation was supported by multiple governance structures, including steering, architecture, change advisory and project-level groups.

Governance provided decision-making structures around an implementation that crossed organizational, technical and operational boundaries.

This is where governance and architecture intersect.

Architecture decisions can have implications for implementation sequencing. Implementation decisions can create architectural consequences. Operational decisions can expose requirements that were not obvious during initial planning.

A governance structure therefore needs to allow those perspectives to connect.

7. Dependencies Are Often Outside the EMR Project

Perhaps one of the most important lessons is visible at the bottom of Page 1.

The implementation depended on things such as community and leadership alignment, service planning, finance, legal, recruitment, procurement, infrastructure and IT, and facilities and construction.

Many of these dependencies are not controlled by the EMR project team.

That creates a fundamental implementation challenge.

You can have a configured application, trained implementation staff and a technically prepared environment—but still be unable to go live because the physical site is not ready, staff have not been recruited, devices have not arrived, or another dependency has not been completed.

The Architecture Lesson

Looking back at this implementation through an enterprise architecture lens, one of the clearest lessons is that the technology is only one component of the architecture.

The effective implementation environment includes:

People + Services + Processes + Information + Technology + Relationships + Governance

The EMR has to operate across all of them.

That is why starting with the operating model is so important.

Conclusion

A successful EMR implementation is not created by configuring software and then asking the organization to adapt around it.

The stronger approach is to understand the environment first and then configure the technology to support it—while maintaining enough standardization to operate as a common platform.

That balance between standardization and flexibility became one of the defining characteristics of the implementation.

And once that environment was understood, the next question became: How do you actually move sites and teams through implementation?

That is where the implementation approach, workstreams, roadmaps, engagement model and readiness assessment become critical.

---

Section Two: From Readiness to Go-Live: A Practical Model for EMR Implementation

---

There is a tendency to describe an implementation as a sequence:

Plan → Configure → Train → Go Live.

In practice, complex implementations rarely work that cleanly.

The implementation of an EMR across multiple sites involves relationships, readiness, dependencies, different team structures, different onboarding requirements and competing priorities.

The challenge is not simply defining the steps. It is determining when a site is ready to move through those steps.

1. One Project, Different Delivery Approaches

The implementation used a combination of delivery approaches.

Relationships and community engagement came first, creating the foundation for implementation. A waterfall approach was used for implementation, while agile practices were used for development work and release management.

This is a useful distinction.

“Waterfall versus agile” is often treated as an organizational choice where one methodology must dominate.

A more practical approach is to ask: What type of work are we doing, and what delivery approach best fits that work?

Implementation has relatively identifiable stages and dependencies. Development work, new requirements and releases benefit from iterative prioritization, testing and feedback. Those characteristics do not have to be forced into the same delivery methodology.

2. Three Workstreams Running Together

The implementation was organized around three concurrent workstreams: Implementation; Development; and Operational Support & Sustainability.

This structure recognizes that an EMR does not suddenly become an operational service on the day of go-live.

Implementation is preparing the next site. Development is responding to emerging requirements. Operations is supporting the people already using the system.

Those activities overlap.

3. The Roadmap Changes With the Type of Team

The implementation roadmap differed depending on the operating context.

For community-operated sites, the sequence included additional activities such as agreements and confidentiality documentation. Health-authority-operated teams did not require those same steps.

That is a good example of standardization without rigidity.

A roadmap can provide a standard implementation framework while allowing steps to vary where the organizational context requires it.

4. Onboarding Was Phased

Sites within a region were often onboarded in phases rather than simultaneously.

The hub was often onboarded before community sites, although this was not always the case. The sequencing depended on readiness.

That last point is the important one.

The sequence was not determined solely by geography or organizational preference. It was influenced by readiness.

5. Engagement Is an Implementation Activity

Engagement was not treated as a communications exercise that occurred around the project.

Community input informed implementation planning, workflow decisions, onboarding, training needs, timing, and ongoing support.

That makes engagement part of the delivery mechanism itself.

If engagement changes the implementation plan, then engagement is not simply stakeholder management. It is a source of requirements.

6. Readiness Has Multiple Dimensions

The assessment considered several domains: site profile, clinical workflow, EMR/application, technical site readiness, security, and legal.

This matters because technical readiness is only one part of implementation readiness.

A site might have a functioning network and appropriate devices but still not be ready because staffing, workflow, agreements or training requirements remain unresolved.

Conversely, an organization may be technically ready but operationally unable to transition from its current documentation practices.

7. Readiness Becomes a Prioritization Mechanism

The Readiness Register provided a way to rate sites on a 1–5 scale.

The scores reflected readiness gaps that needed to be addressed, and higher readiness scores were used to prioritize the next sites and teams for go-live.

This is where an assessment becomes more useful than a checklist.

A checklist tells you what is missing. A readiness register allows the project team to compare sites and make sequencing decisions.

That turns readiness into a portfolio-level prioritization mechanism.

8. Go-Live Dates Are Not Always Static

Go-live dates were sometimes accelerated based on practical considerations including service and hiring start dates, cutover from existing charting, the need to move from multiple documentation locations to a single patient chart, team familiarity with another EMR, confidence in moving to the new EMR, and training availability.

This illustrates why implementation schedules should be treated as decision frameworks rather than immutable calendars.

A date can change because the business environment changes.

A PM Lesson: Manage Readiness, Not Just Tasks

Traditional project tracking tends to emphasize: Is the task complete?

Implementation management often needs another question: Is the site actually ready?

Those are not the same thing.

A training session can be scheduled and completed while the team remains uncomfortable using the system. A device can be installed while the surrounding workflow remains unresolved. A configuration item can be completed while an external dependency remains outstanding.

Readiness therefore requires looking across the implementation rather than down a task list.

Conclusion

The implementation model demonstrates that complex EMR deployments benefit from structure—but not rigidity.

There was a defined implementation approach, standardized workstreams and roadmaps, structured assessment and prioritization.

At the same time, sequencing could respond to relationships, local context, readiness and changing operational circumstances.

That balance is particularly important in transformation projects.

The objective isn’t to eliminate variation. It is to manage variation deliberately.

And once a site is live, another challenge emerges: the implementation does not end.

The EMR becomes part of an ongoing technology, information and service ecosystem. That is the subject of the third post.

---

---

Section Three: An EMR Doesn’t End at Go-Live: Architecture, Interoperability and Operational Support

Go-live is often treated as the finish line for a technology implementation.

For an EMR, it is better understood as a transition point.

After go-live, people still need access. Issues still occur. New requirements emerge. Workflows change. Roles change. Integrations evolve. Data needs to move between systems.

The technology has moved from being a project deliverable to being an operational service.

That distinction became increasingly important as the implementation progressed.

1. One EMR Does Not Necessarily Mean One Identical Experience

The underlying data architecture supported a single EMR while allowing access to be associated with specific sites.

The appearance of separate EMRs was a result of the underlying data model, with patient charts linked to specific sites and users receiving access to the charts associated with their assigned sites.

That distinction is important.

From a user perspective, the environment may appear segmented. Architecturally, however, the underlying model can still support a common platform and shared information environment.

This is a useful example of why architecture matters. What users see is not necessarily the same thing as how the underlying information architecture is organized.

2. Readiness Does Not Stop at the Initial Assessment

The Readiness Register provided a structured mechanism for assessing sites before onboarding.

But readiness should not be interpreted as a permanent characteristic.

Teams change. Services change. Technology changes. Workflows change. Organizational requirements change.

An implementation therefore needs mechanisms for recognizing that the operating environment will continue to evolve.

3. Modules Reflect Different Workflows

The EMR included modules supporting different areas of work, including patient chart, workspace, scheduler, billing, administration, data exchange, and reporting.

Access was based on role, responsibilities and scope of practice so users could access the functions required for their work.

This is where configuration, architecture and service management meet.

A module is not simply a software feature. It supports a particular capability or workflow. Changing access to that module can therefore change what someone is able to do operationally.

4. Development Should Respond to Real Operational Requirements

One of the advantages of the platform was its ability to be developed further to address organizational and patient-population needs.

Development areas included enhancements to role-based access, clinic workspaces, data sharing, sensitive encounter access, reconciliation of EMR instances and charts, and analytics/reporting.

This creates an important feedback loop:

Implementation → Use → Requirements → Development → Testing → Release → Use

The system therefore continues to evolve after implementation.

That is much closer to product/service evolution than a traditional one-time project deliverable.

5. Integration Is Not the Same as Interoperability

One of the concepts that often creates confusion in health information technology is the difference between integration and interoperability.

Integration connects the EMR to other systems. Interoperability enables systems to exchange and use information.

The environment included tools such as CareConnect, PharmaNet, Excelleris, CDX, PLIS, CDI and Health Gateway, with different data-sharing approaches across the broader ecosystem.

This distinction matters because an EMR does not necessarily need a direct point-to-point integration with every system that contributes or consumes information.

An ecosystem can support interoperability through APIs, standards-based exchange and other mechanisms.

The implementation therefore had to consider not only what the EMR did internally, but also how it participated in the broader information ecosystem.

6. The Architecture Is Bigger Than the Application

This is where a TOGAF-style perspective becomes particularly useful.

An EMR implementation involves multiple architectural concerns: business and service capabilities, application functionality, information and data, technology infrastructure, security and access, and external systems and interfaces.

The infographic illustrates several of these without necessarily labeling them as formal architecture domains.

That is one of the things that is interesting about real-world implementation work. Organizations often perform architecture activities without necessarily describing every activity using architecture-framework terminology.

7. Go-Live Creates a Service

The most important transition may be the distinction between implementation and operational support.

Implementation activities included assessment, configuration, training and go-live.

Operational support included access and onboarding/offboarding, permissions, incidents and issues, training, requests, enhancements and continuous improvement.

This is very close to the way ITIL encourages organizations to think about technology: not merely as something that has been deployed, but as a service requiring ongoing management.

8. Operational Support Starts Before the Project Is Finished

Support was provided throughout implementation and continued through and after go-live. Its focus included access, issue resolution, training and ongoing changes to the EMR.

That is significant.

If operational support only begins after the implementation team leaves, the organization can create an artificial boundary between project delivery and service management.

In reality, the transition begins well before the project closes.

Users need support during onboarding. Access processes need to exist. Issues need to be managed. Changes need to be assessed. Release management needs to continue. The service needs to remain usable while the next implementation is still underway.

An ITIL Lesson: The Service Has a Lifecycle

Looking at the implementation through an ITIL lens, the interesting lesson is that go-live is not the end of service management.

It is one point in the lifecycle of the service.

The operational model needs to accommodate:

Access → Support → Incidents → Requests → Changes → Releases → Continuous Improvement

That operational capability has to be designed alongside implementation rather than treated as an afterthought.

The Bigger Lesson

The most interesting aspect of this implementation is perhaps not the EMR itself.

It is the interaction between:

Architecture + Implementation + Adoption + Development + Operations

Each depends on the others.

Architecture establishes constraints and possibilities. Implementation establishes the operational foundation. Adoption determines whether people can effectively use the service. Development responds to emerging requirements. Operations keeps the service functioning. And continuous improvement connects what happens in production back into future decisions.

Conclusion

An EMR implementation does not end when the software goes live.

At that point, the organization has created a service that must be managed, supported and continuously improved.

The project therefore needs to think beyond implementation from the beginning.

The question is not simply: How do we get this site live?

It is also: How will this service be accessed, supported, changed, developed and sustained once it is live?

That is the point where implementation practice, enterprise architecture and IT service management stop being separate disciplines and start becoming parts of the same operating model.

---

Source and Publishing Notes

The three articles were developed from the uploaded three-page EMR implementation case-study infographic. The infographic is the source of the implementation-specific facts and structure. TOGAF and ITIL references are interpretive framing rather than claims that the project was formally delivered under those frameworks.