Critical Success Factors
The factors that must be present to make the iotaMed project work are:
Open source, open specs
The specifications of applications and interfaces must be open. This does not mean that individual developers must open source their products. See below for details. But it does mean that if an interface to a product is to be accepted as part of the iotaMed design, it must be openly documented and come without strings attached.
The iotaMed mark
The iota and iotaMed labels are reserved by MITM AB in the sense that we do want to maintain control of what specifications and products call themselves iota or iotaMed compliant. We do expect that this kind of decision should be taken by the community, but since that community hasn't formed yet, we do assert our right to control the terms in the meanwhile.
The best IT designers and developers have always been found in the smallest companies, often creating startups. There's an abundancy of literature that explains why this is so, so I'll not argue the how and the why of it. Currently, these highly capable entrepreneurs are largely locked out of the health-care IT market by inappropriate purchasing rules and organizations. The only places where they do have a chance to apply their unique knowledge are limited skunk-works. Any solution to the health-care IT dilemma must involve having these entrepreneurs participate on at least equal footing with the major all-in-one systems vendors.
Entrepreneurs must be guaranteed that anything they produce will be independent of the intellectual properties of any of their competitors, small and large. They must also have the assurance that their participation does not limit them in any way from any future development they may want to do in the same or other areas.
This implies that all specifications they use from the community must be free of patents, or at a minimum guaranteed to be free to use by anyone and free of obligations of any kind. Even though it will usually be in their own interest to produce equally open products themselves, there should be no obligation to do so. In other words, the iotaMed specifications and community is also available to entrepreneurs who wish to keep both their products and distribution entirely proprietary and closed. Developers are entirely free to select which licenses they wish to use with their products, and just as free to decide who will be able to use or reuse their products, specifically allowing open source developers to require a commercial license from other developers or customers who do not subscribe to the open source model.
To succeed in the marketplace, iotaMed compliant products need to fill real medical needs and to do that, they need to be optimized for the actual medical situation. This is the downfall of all-in-one systems and the opportunity of the iotaMed developer. This also means that the plug-in modularity is absolutely essential and all iotaMed compliant products must respect the opportunity of other developers to hook in to and enrich the funtionality as far as practically possible.
Any attempts to centralize all data to a single type of data store will work against our objectives. Data stores, in particular relational data stores, severly limit the customization of modules and make changes and improvements extremely costly. A solution that claims to be iotaMed compliant should in no way force other iotaMed compliant products to use a particular data store in such a way that inventions and improvements are unduly limited. All iotaMed compliant products, however, should present themselves to users as if no such division of data stores existed. They should also take care to not make the data in any single data storage inconsistent, even if they cannot guarantee that every store is complete, since not every store will be capable of storing all kinds of data. Similarly, no design that adds a data store for increased richness of data, should by doing so impoverish the data content in a pre-existing store.
Bottle neck interfaces
No iotaMed project should force any other iotaMed module to pass data or functionality through a narrow interface that limits the functionality to a lower level than otherwise possible. Examples would be a single data store (as described above) or a web service interface mandated by an organization as the single point of communication, unless the individual iotaMed projects can add their own APIs to that interface.
Minimal reliance on standards
The iotaMed projects should always strive to reduce the reliance on standards to an absolute minimum. We all know that if a project depends on an extensive standards effort, that it is severely handicapped from the start. There is an ever increasing number of techniques to allow full interoperability of IT systems with very lightweight standards, and utilizing these methods to the fullest is essential to the iotaMed project.