My research group, Children’s Hospital Informatics Program, just released a statement of principles in designing the next generation of Health IT, and folks are picking it up. The key concept is substitutability, or what software/Internet architects have called loose coupling. The idea is to build modular rather than monolithic systems, and ensure that the modules are connected in loose enough ways that innovation is possible within each component independently of the others. Sounds kinda obvious, right? Not so in Health IT, which is only just now starting to get the point of the Web.
So, for example, if you think your system fits the bill because anyone can write a Java module/extension, you’ve got it wrong. Loose coupling means you’re not forcing one programming language on everyone else, rather you’re embracing the open protocols of the Web.
The work we’re doing with Indivo X, our open-source/free Personally Controlled Health Record, is exactly along those lines. But it’s not just about PCHRs. Really, the entire Health IT ecosystem needs to adapt to the loosely coupled way.
Benlog 
Comments
2 responses to “Loosely Coupled Health IT”
I commented on the Chilmark Research group pointing out Eclipse RCP as another example of an “open” platform. So this sentence in your post caught my attention:
—
So, for example, if you think your system fits the bill because anyone can write a Java module/extension, you’ve got it wrong. Loose coupling means you’re not forcing one programming language on everyone else, rather you’re embracing the open protocols of the Web.
—
Maybe using the iPhone as an example of a platform could be a bit confusing and could lead to the sort of conclusion that you point out as being incorrect.
I think the iPhone analogy was used because it’s salient in the general public and it’s quick for non-techies to grasp: one platform, a bunch of apps, you get to pick which one you want, they all work.
The example of the Eclipse RCP is the same, but shows that you only need to adhere to the “standard” to plug into the system; you don’t need to get approval from an organization or have to go through a store to purchase it, though this may be a desirable feature of this system. Maybe have a rating organization, but if you want to roll your own and plug it in you can do so without having to pay a central org (apple in the iPhone’s case).
Anyway, I think this concept is key and bringing attention is timely and great. I hope it gains some legs because I’m completely surprised when evaluating HIT systems about how monolithic they are.
I commented on the Chilmark Research group pointing out Eclipse RCP as another example of an “open” platform. So this sentence in your post caught my attention:
—
So, for example, if you think your system fits the bill because anyone can write a Java module/extension, you’ve got it wrong. Loose coupling means you’re not forcing one programming language on everyone else, rather you’re embracing the open protocols of the Web.
—
Maybe using the iPhone as an example of a platform could be a bit confusing and could lead to the sort of conclusion that you point out as being incorrect.
I think the iPhone analogy was used because it’s salient in the general public and it’s quick for non-techies to grasp: one platform, a bunch of apps, you get to pick which one you want, they all work.
The example of the Eclipse RCP is the same, but shows that you only need to adhere to the “standard” to plug into the system; you don’t need to get approval from an organization or have to go through a store to purchase it, though this may be a desirable feature of this system. Maybe have a rating organization, but if you want to roll your own and plug it in you can do so without having to pay a central org (apple in the iPhone’s case).
Anyway, I think this concept is key and bringing attention is timely and great. I hope it gains some legs because I’m completely surprised when evaluating HIT systems about how monolithic they are.