Regulatory requirements get blamed for slow modernization more often than they actually deserve. In most of the programs we've seen stall, the regulation itself was clear and had been clear for some time. What was actually slow was the internal process for interpreting that requirement, getting agreement across legal, compliance, clinical, and operational stakeholders on what it meant in practice, and then translating that agreement into a system requirement someone could actually build against.
That internal translation process is where the real time goes, and it's largely invisible from the outside, which is why it gets misattributed to the regulation rather than to the organization's own process for interpreting it. Two organizations facing the identical regulatory requirement can move at completely different speeds, not because the rule was different, but because one of them had a faster, clearer internal path from 'what does this require' to 'what are we building.'
The organizations that move faster tend to invest specifically in that translation step: a small, empowered group with real authority to interpret a requirement and commit the organization to an interpretation, rather than a requirement that has to pass through every stakeholder sequentially before anyone is willing to commit to a reading of it. That group doesn't replace legal or compliance review. It gives that review something concrete and well-formed to react to, instead of an open question that invites everyone to weigh in from the start.
Worth saying plainly: this is a solvable organizational design problem, not an unavoidable cost of doing business in a regulated environment. The regulation sets a real constraint. It rarely sets the pace. The organization's own process for interpreting it does that.