Why incremental efforts are a better approach than a top-down specification
InfoWorld: I suppose one subtext there is that if the policies were created for a different time and space, and don't fit the more integrated care model of today, maybe the policies need to be revisited, which of course is outside of your domain. But that may be a requirement.
Fridsma: No, but you're absolutely right. We talk about the interaction between the policy and technology pieces. Within ONC, we have both of those responsibilities. So, on the one hand we want to make sure that the technical infrastructure can support the policies that are out there. But we also have to recognize that sometimes a particular policy in a different world would have been easy to implement, but in the current world is really convoluted, and that maybe we need to go back and revisit that and say, "If there's a small refinement to our policy, we can actually simplify the technologic implementation of that in a really substantive way."
There is this interplay between the policy and the technology that's so critical. It's one of the reasons why, at least within ONC, we have both the HIT Policy Committee and the HIT Standards Committee, and they keep each other informed. Because the policy folks might say, "We would like to do X," the standards folks will say, "Well, you can do X, but it's going to be really complicated. If you wanted to just tweak this a little bit this would be easier." Then we feed that back and we can come to the right angle of repose, if you will, between policy and technology.
InfoWorld: It's funny, this sounds like the so-called agile development process where the stakeholders all are talking to each other throughout the development, because things do affect each other. If you specify, then dump it over to somebody to implement, those interactions aren't always apparent and they can lead to overly complicated approaches, approaches that don't work. Right?
Fridsma: Yeah. And I think our approach, although I wouldn't necessarily call interactions between the policy committee and the standards committee "agile," we have this notion that it shouldn't be waterfall. We should think about small incremental and iterative approaches to doing our development. Because we'll learn a whole lot more from actually getting stuff out there and taking a look at it.
This notion of being able to create small bites in incrementalism, I think makes it much easier. It's a much more robust system to be fault-tolerant; if you didn't get something quite right, you just iterate the next one and you have only a small piece that you have to fix. Whereas if you try to get all your requirements done first, then you throw them over to the implementers and you've got it all wrong, it becomes much harder.
Although we do internally a lot of agile development and things like that in our work, ultimately we're trying to create this incremental, iterative, risk-focused way of addressing the problems that is, I think, aligned with a lot of the Lean approaches and the agile approaches that are in software development.
InfoWorld: Right, and I get the point that agile is not the specific process. I was using it as a metaphor for the notion of interplay.
Fridsma: We totally get that. And it's just such an important piece of what we work on.