Denmark’s Sundhedsplatformen: The Epic Rollout That Became a National Warning
Denmark's Sundhedsplatformen rollout became a warning about large EHR transformations when testing, training, workflow change, coding, and user satisfaction lagged behind deployment.
Sundhedsplatformen was designed as a common digital backbone for two Danish regions
The Capital Region of Denmark and Region Zealand selected Epic for a shared electronic health record intended to replace many fragmented hospital systems. The original vision promised a modern, integrated platform that would give clinicians a unified patient view and let patients participate more directly in care.[1] The programme’s scale was extraordinary: it touched hospitals, clinicians, billing, documentation, scheduling, and patient communication across regions. That made the rollout less like buying software and more like changing the operating model of a health system.
Standardization creates both benefits and concentrated risk
One common platform can eliminate fragmentation, but a design or workflow problem can also affect many hospitals at once.
The first hospitals went live in May 2016 despite expected disruption
Herlev and Gentofte Hospital were the first major sites to adopt the platform in May 2016. The region publicly acknowledged that staff and patients would experience inconvenience while issues were corrected.[2] Later waves proceeded on schedule. This illustrates a recurring implementation tension: once a large rollout calendar, training plan, and contractual ecosystem are in motion, delaying deployment can be expensive, yet proceeding transfers unresolved risks into live clinical work.
Denmark’s national auditors later judged preparation unsatisfactory
Rigsrevisionen examined the initial rollout and concluded that the Capital Region had not adequately understood how the system would affect hospital activity. It also found that testing and staff training related to tracking activity were inadequate.[3] This is a crucial distinction. An EHR can pass technical tests while the organization remains unprepared to use it correctly at production scale. Readiness must include workflows, staff competence, reporting, and operational recovery.
Testing the application is not the same as testing the hospital
A technically functioning screen can still create failure if users cannot complete real clinical tasks quickly, consistently, and with correct downstream coding.
Coding and activity-registration problems created financial and management consequences
Regional reports described persistent issues with coding and incorrect activity records that interfered with billing and reporting.[4] Healthcare organizations depend on clinical documentation for reimbursement, planning, quality metrics, and national reporting. A new EHR therefore changes the institution’s data-production machinery. When coding workflows are unstable, the organization can lose both revenue and visibility into what care it is delivering.
High availability did not eliminate usability and workflow problems
Regional status updates reported uptime close to 100 percent while still tracking thousands of open issues.[4] This is an important software-reliability lesson. Availability measures whether a service responds; usability measures whether people can accomplish work safely and efficiently. A system can be technically “up” while clinicians struggle with navigation, documentation burden, configuration, or unfamiliar workflows.
Operational reliability has more dimensions than uptime
For clinical software, success also includes task time, cognitive load, correct ordering, information retrieval, and the ability to recover from mistakes.
Long-term studies found dissatisfaction persisted well after deployment
Research on the Danish Epic implementation found substantial ongoing dissatisfaction among clinicians years after the first rollout. One study reported that many physicians did not believe the platform facilitated their work, despite continuing optimization efforts.[5] That persistence matters because organizations often assume resistance will fade automatically as users become familiar with the system. Some friction is temporary; other friction reflects workflow or interface design that must be redesigned rather than merely tolerated.
The rollout demonstrates why local adaptation and standardization conflict
Large EHRs promise standardized data and workflows, but hospitals contain specialized practices built over decades. Excessive customization can make a shared platform expensive and difficult to upgrade; insufficient customization can force clinicians into awkward processes. Sundhedsplatformen became a visible example of this tension. The implementation had to replace dozens of older systems while still accommodating real differences among hospitals and specialties.[1][5]
The hardest configuration decisions are organizational decisions
Choosing which workflow becomes the standard can redistribute work between doctors, nurses, secretaries, coders, and administrators.
Why Sundhedsplatformen became a national warning
The Danish experience shows that an EHR can succeed as infrastructure while still impose large human and organizational costs. The national audit did not say a common patient record was inherently a bad goal; it criticized preparation, testing, training, and understanding of operational effects.[3]
The enduring software lesson is that large platforms should be evaluated through clinical outcomes and work practices, not only deployment milestones. A rollout can be on schedule, highly available, and technically integrated while still leaving users dissatisfied and organizations struggling with workflow and data quality. That broader definition of failure is essential when software becomes the working environment for healthcare itself.
The Danish case also demonstrates the importance of measuring work before and after a digital transformation. If leaders capture baseline task times, error rates, documentation burden, coding accuracy, and user satisfaction before deployment, they can distinguish temporary learning effects from persistent design problems. Without those baselines, every debate about whether the new system is improving becomes vulnerable to anecdote, selective metrics, and institutional defensiveness.
Works Cited
- 01
- 02
- 03Rigsrevisionen — Report on Sundhedsplatformen uk.rigsrevisionen.dk
- 04
- 05PubMed — Implementing Large-Scale Electronic Health Records: Denmark and Finland pubmed.ncbi.nlm.nih.gov
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.