TL;DR
- Healthcare IT modernization means upgrading the systems that run patient care: registration, clinical documentation, orders, and the interfaces connecting hospitals to labs and payers. Most of it happens on systems already in daily clinical use.
- The defining constraint is that the system cannot stop. A hospital cannot pause admissions while engineers refactor code, which rules out the rewrite-and-switch approach that works in other industries.
- Rewrites fail here for a specific reason: a decade of clinical rules lives inside the existing code, much of it undocumented. Rebuilding from a specification loses the rules nobody wrote down.
- We assessed OpenMRS Core, an open-source medical record platform used by health systems worldwide. It scored 67/100, with one dimension far below the rest.
- The weak spot was structural coupling, scoring 44/100 with a dependency balance of 0.32. In plain terms, a handful of components carry so much of the system that changing any one of them risks breaking things far away.
- The approach that works is behavior-preserving change: write tests that capture what the system does today, improve the internals underneath those tests, and prove clinical behavior did not shift.
Hospitals run on software that has been accumulating since before most of the current staff arrived. The registration system knows which identifier formats are valid because someone encoded that rule in 2009. The lab interface handles a particular message quirk because a specific analyzer once sent malformed data, and the fix stuck.
None of this is bad engineering. It is what happens when software serves real clinical work for long enough. The difficulty comes when that system needs to change, because nobody can fully describe what it currently does. This post explains how healthcare IT modernization works under that constraint, using a real assessment of an open-source medical record platform as the worked example.
Understanding what healthcare IT modernization involves
Healthcare IT modernization is the work of improving clinical systems already in production use, without changing what those systems do for the people using them. It covers the core platforms that hospitals and payer organizations depend on daily.
The systems in scope typically include:
- Electronic medical records, holding patient identity, encounters, diagnoses, and clinical notes.
- Order management, covering medication orders, lab requests, and their approval and fulfillment lifecycle.
- Terminology services, mapping local codes to standards such as SNOMED and LOINC so data means the same thing across systems.
- Integration interfaces, exchanging messages with labs, pharmacies, imaging systems, and payers, usually over HL7 or increasingly FHIR.
- Administrative tooling, managing users, roles, privileges, and configuration.
Modernization is not the same as replacement. Replacement means buying a new system and migrating to it, a multi-year program with its own substantial risk. Modernization means keeping the system and improving how it is built: reducing coupling, clarifying boundaries, hardening security, and making future change cheaper.
The distinction matters because the two carry very different risk profiles. Replacement risks a discontinuity at cutover. Modernization spreads risk across many small changes, each individually verifiable.
Why clinical systems resist the usual modernization playbook
Software teams outside healthcare have a well-worn approach: build the replacement alongside the original, gradually migrate traffic, and retire the old system. That approach runs into three obstacles in clinical settings.
Downtime carries clinical consequences: When a retail site goes down, sales pause. When a medical record system goes down, clinicians lose access to allergy lists and medication histories while patients are in front of them. Hospitals maintain paper fallback procedures precisely because this happens, and every hour on paper creates reconciliation work afterward.
The rules live in the code, not in documents: A patient identifier validation routine may encode a dozen institutional policies accumulated over years. A rewrite built from a written specification will implement the documented rules and silently drop the rest. The failure surfaces later as rejected registrations for patients whose identifiers were previously fine.
Extensions depend on internal structure: Platforms like OpenMRS support modules that health systems install to add local functionality. Those modules reach into the platform’s internals. Changing internal structure can break modules that a hospital depends on, and the platform team often has no visibility into which modules are deployed where.
| Constraint | What it rules out | What it permits |
| Continuous clinical availability | Big-bang cutover, extended maintenance windows | Incremental change, phased rollout, per-site opt-in |
| Undocumented business rules | Rewrite from specification | Characterization tests capturing current behavior |
| Third-party module dependencies | Freely changing internal structure | Stable public contracts with internals refactored beneath |
| Regulatory audit requirements | Untracked changes to privileged operations | Immutable audit records for administrative actions |
Reading the assessment of a real clinical platform
To ground this, we ran OpenMRS Core through Forge, which scans a codebase and scores it across eight dimensions of how difficult it is to change the system safely.
OpenMRS is a mature open-source medical record platform, widely used by health systems in many countries, particularly in low-resource settings. It is genuinely used for patient care, and it is large: 345 files analyzed, built in Java on Spring and Hibernate.
The composite score was 67 out of 100, rated “Established.” The individual dimensions tell a more useful story than the composite.
| Dimension | Score | Rating | What it measures |
| Hidden Gems | 82 | Advanced | Reusable patterns worth extracting |
| Logic Narrative | 76 | Advanced | How readably the code tells its story |
| Semantic Clarity | 72 | Established | Whether names match domain concepts |
| Future Proofing | 69 | Established | Resilience to future change |
| Trust Boundaries | 68 | Established | Where untrusted input crosses into the system |
| Data Weight | 64 | Established | How efficiently data moves |
| Cognitive Load | 57 | Developing | Mental effort a change requires |
| System Gravity | 44 | Foundation | How concentrated the structural mass is |
System Gravity at 44 stands well below everything else, and it is the finding that shaped the entire remediation plan.
What a low structural score reveals about change risk
System Gravity measures how evenly responsibility is distributed across a codebase. The scan reported a dependency balance of 0.32, where an even distribution would approach 1.0.
A useful analogy: imagine a hospital where every department routes requests through one coordinator. The arrangement works, and that person becomes extremely knowledgeable. But changing their process affects every department at once, and their absence halts everything.
The scan found this pattern concretely. One method, getCurrentSession, has a fan-in of 348, meaning 348 places in the code depend on it. Change how it behaves and the effect reaches into hundreds of call paths, many of them touching clinical data.
Two related findings compound this:
Circular dependencies exist when component A depends on B and B depends on A. Cycles make independent change difficult because the two components must be understood, tested, and often modified together.
2,434 layer violations were detected, meaning code at one architectural level reaches directly into another rather than going through the intended path. Some are benign inherited calls. Collectively, they signal that the intended boundaries are not enforced, so a developer cannot trust the architecture diagram to predict which changes will be affected.
A dependency balance of 0.32 against an even distribution near 1.0. The hub works, but every change to it reaches hundreds of call paths.
Cognitive Load at 57 follows from the same root. The scan noted that a meaningful change can require holding Maven module inheritance, Spring XML wiring, transaction proxies, AOP advice, Hibernate sessions, servlet configuration, and module classloading in mind simultaneously. Each is a reasonable choice. Together they impose a real tax on every contributor.
Turning findings into work that preserves clinical behavior
The assessment produced 72 work orders across 8 epics. Their ordering encodes the central discipline of clinical modernization: prove current behavior before changing anything.
The first epic establishes a baseline. WO-001 captures a dependency-gravity map so improvement can be measured rather than asserted. WO-002 adds characterization tests, which record what the system does today rather than what the documentation claims. If an undocumented rule exists in the code, the characterization test captures it and fails loudly when a refactor breaks it.
The second epic builds parity fixtures for six clinical areas before touching any of them:
| Work order | Clinical area | What it protects |
| WO-004 | Patient identity | Registration and identifier validation rules |
| WO-015 | Encounter documentation | How clinical visits are recorded |
| WO-016 | Observation versioning | Amendment history for clinical readings |
| WO-017 | Order lifecycle | Medication and lab order state transitions |
| WO-018 | Visit lifecycle | Admission through discharge |
| WO-019 | Terminology dictionary | Local-to-standard code mappings |
| WO-020 | HL7 result processing | Inbound lab result handling |
Only after those exist does WO-036 turn them into a CI gate, so any change breaking clinical parity fails the build automatically.
The order is the safeguard. Nothing gets refactored until the tests that would catch a regression are already passing.
The decomposition work comes later and stays deliberately constrained. WO-042, for instance, breaks apart the encounter save pipeline, but it depends on WO-016’s observation parity suite already passing. Public service interfaces stay stable throughout so installed modules keep working; only internals move.
Seventy-two work orders across eight epics. The parity fixtures come first, and the decomposition work depends on them.
Hardening administrative access without blocking operators
Two findings concerned security, and both illustrate a tension specific to platforms that hospitals self-administer.
Administrative SQL execution: OpenMRS exposes an executeSQL operation letting administrators run database statements directly. This is genuinely useful, because operators need it for data corrections and troubleshooting that no user interface anticipates. It is also a powerful capability crossing a sensitive trust boundary.
Removing it would break legitimate operational work. The plan instead constrains and records it: require an explicit privilege, separate select-only from mutating modes, emit an immutable audit record capturing actor, timestamp, operation, outcome, and affected resource, and redact sensitive values from failure messages. Operators keep the capability; compliance reviewers gain a trail.
Development credentials: The docker-compose.yml file includes default passwords for openmrs and Admin123, making local setup effortless for new contributors. The risk is reuse: compose files get copied into shared or staging environments, and the defaults travel with them.
The fix keeps local onboarding simple. Default credentials work in the local development profile, and the application refuses to start in any non-local environment unless credentials are explicitly overridden. Convenience where it is safe, failure where it is not.
A third area covers modules. Because modules are trusted extension code rather than sandboxed plugins, the plan makes visibility and provenance rules explicit and adds a certification harness, ensuring module authors receive documented rules rather than discovering behavior at runtime.
Sequencing a rollout that clinical operators can accept
The rollout runs through six phases from August 2026 to April 2027, and its structure reflects who must approve each step.
| Phase | Window | Focus |
| 0. Baseline and governance | Aug 18 – Sep 14 | Agree scope, critical workflows, rollback policy |
| 1. Quality gates | Sep 15 – Oct 12 | Security scanning, audit criteria, credential guardrails |
| 2. Core modernization build | Oct 13 – Jan 19 | Decompose service internals, clarify persistence contracts |
| 3. Parallel beta and certification | Jan 20 – Feb 16 | Beta sites, module certification, parity validation |
| 4. GA readiness | Feb 17 – Mar 16 | Evidence review, compliance sign-off, controlled release |
| 5. Post-GA monitoring | Mar 17 – Apr 14 | Incident tracking, burn-down of remaining findings |
Phase 2 is the longest, at roughly three months, during which the actual refactoring happens. Phases 0 and 1 build the safety apparatus first, and phases 3 through 5 are almost entirely verification.
That ratio is the point. Most of the calendar goes to establishing and checking safety rather than to changing code.
Where the eight months actually go. A plan weighted the other way is usually underestimating clinical risk.
The gates are stated in terms operators recognize rather than engineering metrics: zero severity-one clinical regressions during beta, at least 95% of certified modules passing compatibility tests, every participating operator signing off before general availability, and a rehearsed rollback procedure. Engineering completion alone does not authorize release.
Roughly three months of refactoring inside eight months of plan. The rest establishes safety and verifies results.
Applying this to your own clinical systems
The specifics come from one open-source platform, but the method transfers to hospital and payer modernization generally.
- Measure structural risk before scoping work. System Gravity at 44 against a 67 composite told us where change was dangerous. A task list written from intuition would likely have started elsewhere.
- Write characterization tests before refactoring. They capture the undocumented rules that a specification-driven rewrite loses. In clinical software, those rules are frequently the ones that matter most.
- Keep public contracts stable and move internals underneath. This is what allows a platform to improve without breaking the extensions that health systems have built on top of it.
- Constrain privileged operations rather than removing them. Operators need administrative capability. Audit records and mode restrictions satisfy compliance without taking away the tools people use to keep systems running.
- Define gates in operational terms. “Zero severity-one clinical regressions” and “operator sign-off” are conditions a hospital can evaluate. Code coverage percentages are not.
Healthcare IT modernization rarely produces a dramatic before-and-after. When done properly, clinicians notice nothing at all, and the engineering team can make the next change safely. That is the actual deliverable.
FAQs
How is modernization different from replacing a hospital system?
Replacement means selecting a new platform and migrating to it, typically a multi-year program with a cutover event that carries concentrated risk. Modernization preserves the existing system while improving its internal structure, security posture, and testability. Risk spreads across many small verifiable changes rather than concentrating at a single switchover. For systems that work clinically but are expensive to change, modernization usually offers a better return.
What are characterization tests and why do they matter clinically?
Characterization tests record what a system currently does, rather than what it is supposed to do. You run the existing code, capture its outputs, and assert that future versions produce the same results. This matters in healthcare because clinical systems accumulate rules that were never documented, encoded by developers responding to real institutional needs years ago. A test suite built from documentation would miss them; characterization tests catch them because they capture actual behavior.
How long should a healthcare modernization program take?
The plan for OpenMRS Core runs roughly eight months across six phases, for a single platform with a defined scope. Programs touching multiple integrated systems typically run longer. A useful signal is the ratio: in this plan, roughly three months go to refactoring and five to establishing safety measures and verifying results. A plan weighted heavily toward code changes, with little time for verification, usually underestimates clinical risk.
Will modernization break the modules and extensions we depend on?
It can, which is why module compatibility is treated as a release gate rather than an afterthought. The approach keeps public service interfaces stable so modules continue to compile and run, refactoring only the internals beneath them. A certification harness tests modules against the modernized platform and produces pass, warning, or fail results with remediation guidance. General availability requires at least 95% of certified modules passing.
How do we satisfy compliance requirements during modernization?
Through controls the system enforces rather than documents written afterward. For privileged administrative actions, that means immutable audit records capturing who did what, when, to which resource, with what outcome. For patient data, it means classification, masking identifiers in logs, and defined retention with enforced purge. Making these release gates means that compliance evidence exists for every version shipped, rather than being assembled retrospectively before an audit.
