Calle Hedberg wrote:
I have watched the Internet grow since the late 80's. I think the phenomena exhibited then and since is highly illuminating of successful open source infra-structure.
The approach described by David - to move towards a more integrated Health
Infostructure by linking up independent entities (hospitals, existing
networks) using open standards - is completely different and quite similar
to the "chaotic" but successful evolution of the Internet.
- Generalize a simple solution to problem (maybe not even the 80% level) and make it available as a service in two parts: client and server separated by the network (i.e the infra-structure).
- Make it easy for others to try your solution and then when you think it works, propose it as a standard.
- To become standardized the solution must have independent implementations that inter-operate.
- Once the first simple standard is adopted, an iterative process ensues that evolves towards more complexity, but always focused on the next small bit of functionality.
The tendancy these days is wait until a fairly complex product is nearly ready before releasing it as a proposed proposed open source project. Thus missing the very early phase of work and collaboration. This also misses the ingrained architecture of extensibility that the early IETF standards work encouraged, or rather I should say demanded in order to survive.
So in the case of linking independent health care entities the question arises as to what is the infra-structure? One idea is that it is once again network services (The Internet), over which a variety of simple, extensible network communications needs to be created. Or perhaps the open source project is more defined around a more complex set of code, an application, which delivers the information among entities.
In the former, if one were starting from scratch, I would be tempted to use an extensible (templates? archtypes?) MIME or XML (over HTTP and SMTP) to create the interchanges. I would start the interchanges based on a very real, but fairly small, extant need. A wide range of developers using a variety of user interfaces and application goals could use this.
In the latter, I would be less concerned about the message interchange and just re-use some existing means of making remote method invocations across the network and focus instead on an application architecture to integrate information at the user interface. A smaller range of developers sharing a common user interface or common application goals would use or re-use parts of this.
