about IT application and it's value in the healthcare industry
This is a set of technical principles describing how the HIT systems fulfilling the Manifesto Goals can be built. It is the very essence of the openHIT reference architecture and a powerful tool for checking the compliance of logical and technical architecture with the motivation part of the openHIT and the end-user expectations.
Principle In the systems design there should be one-and-only obvious and straightforward way to carry the things out.
Motivation Regarding design of the system, if there is any possibility to screw up, one will definitely do. Lots of alternatives is the way to make things complicated and unclear. All of the internal components in the system would support as simple API as it is possible. In that case the information for processing of the message is stored in the message and processed by each node independently. This dramatically reduce costs and complexity of the message routing and helped to maintain the consistency of the applications and infrastructure APIs despite the large number of changes and special use-cases in the process of the messages processing.
Principle User application should be adaptive to a certain use case, process or situation.
Motivation In the majority of cases interaction of the users with the applications and information systems are too complex. Tools for the healthcare professionals are too complex, hard to learn and modify. Use of such tools steals a lot of working time of highly payed healthcare professionals and leads to poor results. That should help to simplify user interactions with the system. Dynamic applications allow user to adjust the application in the process of its use. It assumes that user or a semantic router tool on the fly can adjust the application. This is very useful for the situations with the rare diagnosis, special check-ups and observations and other use cases.
Principle Applications should become means of healthcare professionals’ personal experience sharing and representation.
Motivation Without the specialists who use their tools in everyday work it is not possible to build valuable applications. On the other hand, if developers will follow directly the instructions of the healthcare specialist there will be no product as a result. Every healthcare specialist has his own view and comprehension of what is important and what is not. As can be seen from the above, the only meaningful way to achieve excellence with the healthcare applications is merely to unify the passion of the healthcare specialists and software developers. This is only possible if every healthcare specialist has an opportunity to build (with the help of professional developers) his own application and present it to the community as a result of his vision and experience. Ideally such applications should become parts of scientific researches and publications - as a practical realization of methods of diagnostics and treatment.
Principle Use of applications should become a real pleasure for end-users.
Motivation Nowadays all of us enjoy superb and easy-to-use applications at our personal devices. We fancy using them every day, try it out with them. They have become our tools, toys and means to create and produce. On the contrary enterprise applications are still ugly, they are stealing away our working time and making working process complex and inconvenient.
Principle: HIT should have security means built-in the design of the systems and sufficient for effective data and system protection. Motivation: Security is one of the major issues for the HIT. Low coupled security system (including SSO mechanisms, session keys, cryptography and special design of the deployment scheme) allows to incorporate special security tools and means combined with built-in security measures. That will allow to protect user data and system at every stage of system deployment, adoption and usage. Implications:
Principle The design of the system should provide clear definition and description of means used to support required level of compliance.
Motivation For sure there are some constraints and liabilities connected with the use of HIT. These are regulatory, business and personal security concerns, commercial confidentiality and etc. Those should be dealt with the two major means. First one is a principal design of the system which could help to avoid the problems with the adoption at all levels of implementation. Second one is the set of tools which could support the level of compliance needed for the certain judicial field or stakeholder.
Principle The system should have well controlled, based on implicit rules, secure unified capability of data sharing across internal and external system components.
Principle HIT should have tools for fast on-demand extension of the capabilities.
Motivation Implementation of this principle will give the stakeholders and end-users greater agility in their work. Ad-hoc capabilities will allow stakeholders quickly adopt to the certain situation and specifics. Besides, it will allow changing the approach for business processes and their optimization, gaining more control and agility in both internal and external interactions. It will significantly reduce time needed for adoption of business process to the particular needs or for launching a new one.
Principle HIT systems should be platform and technology independent.
Motivation Only platform and technology independent solutions will allow to establish large-scale HIT systems that suit requirements and all needs of various stakeholders. Use of the open source SBBs linked with minimal requirements for the system deployment allowed to adjust the price of the solution and support for the clinics and low budget healthcare organizations.
Principle Changes in standards of data should have minimum possible effect on systems capabilities or interactions.
Motivation Implications of this principle will allow to avoid strong metadata coupling between services and domains and will help to achieve flexibility while processing redundant messages.
Principle Processing of the message should depend on its context and content.
Motivation There are lots of processes in the healthcare and dozens of variations of these processes. It is very hard to implement and maintain all these processes in the current HIT systems implementation. As most of the modern approaches and technologies suppose that all the processes in the organization should be unified, but regarding various healthcare cases (especially for large regional or global client-oriented networks) it is almost impossible, due to high complexity:
Semantic-based message routing allowed to take into consideration the most parts of clinics and other healthcare organizations specific, besides the use of semantic-based routing allowed to adopt the applications UI, data and processes to the use cases of each clinic and even specialist in cases it was actual.
Principle Processing of messages should be independent in different parts of the system.
Motivation Various organizations in their domains could have different rules, conditions and constraints of data processing. Every clinic or clinical system could support its own process for the request of every type but with respect to the results quality and consistency in order to maintain unified processes. This principle was implemented as a distributed integration platform and high-level transport system.
Principle Processes should be as simple as possible.
Motivation The process in healthcare are too complex - the only thing to handle it is to simplify it as well as it possible. Pipeline style processes help to implement a number of restrictions on the business processes and functions implementation which in one turn helped to simplify the processes and to order the badly (due to the bad regulatory) structured functions and processes in clinics.
Principle The message always contains all the information needed for its processing.
Motivation The following approach will allow when it is necessary different types of message processing with external domains, applications and even manual processing master data (without worrying a lot about metadata), as well as comply formally with data standards in large distributed systems of undefined scale. Supports the same format and standard implementation for the store, process and exchange of the messages in the system. The implementation of this principle led to the usage of non-relational databases with REST services and JSON message format as well as to implementation of special data control and clearing processes.