Our foundation is written in Java and runs inside an OSGi micro-kernel that supports versioning and hot-swapping of libraries and services at runtime. This gives maximum flexibility when needing guaranteed uptimes of 99.99% and supporting services that require different versions of libraries within the same enterprise environment. The OSGi micro-kernel lives on top of an infinitely expandable, distributed cloud computing grid that has enough computing power to service the entire planet.

Example
We have an existing VoIP service running on the platform and we’d like to install a newer version that both fixes some bugs and adds some new features. In a non-OSGi environment, we would have to stop the Java container and re-deploy the new version and any new third-party dependencies that it relied on. In an OSGi environment, we can deploy new libraries at runtime and upgrade our services without stopping the container.

This approach works and is a natural stage of software development. The evolution of this type of development is that the vendor finds himself writing the same program over and over again for different clients and soon realizes he should be creating a product with all the existing code he has written. The product gets new features every now and then and clients pay for license fees and support contracts.

The problem arises when these software applications start to multiply and it becomes costly for the hospital to manage multiple disparate applications that do not communicate with each other and require separate installations. At this point, a hospital wants to simplify and they will look for a vendor that can offer them everything they need in one big package. This comes at a cost and hospitals will pay a premium for these software solutions. The end result is that the hospital spends a lot of money on software infrastructure that gets passed on to the patient but the patient does not derive real benefit because the systems themselves are not interoperable with other external systems the patient is connected to, such as another hospital system across the street.

We could take the argument of the laissez-faire approach one step further to exaggerate the eventual outcome. Hypothetically, if we assume that technology vendors adopt the right standards and protocols and are able to interoperate, the result will be 100000+ installs of interoperable systems with no federated security or user base and no centralized intelligence that can delegate the flow of information. In other words, it is not a feasible solution.

The second approach is highly contested for being too risky a venture because of its likelihood of failure. It assumes a centralized system where data flows through to the consumers who are the hospitals, the patients, and the doctors. It moves healthcare IT out of hospitals and onto the “cloud” (massively parallel computing grid) that can cater to all hospitals instead of one. Software has to be written for the distributed enterprise where services are always available, to everyone, with a federated security system guarding all data points. This is a Health Information Exchange, a medical data aggregator.

I would venture to say that the latter is indeed in the realm of possibility and, with a little bit of planning, can be a strong candidate for managing our country’s health in the decades to come. We have built a software platform we believe can serve as the infrastructure for future e-health applications to build upon. The platform was built for that very purpose. To support our own e-health services!