"But This Has Already Been Done!"
Last updated
Last updated
There are many commercial EMRs in the market. There are also several open source EMRs in existence. The open source ones are also being used, in the developed countries as well as in developing ones, by non-profit and private healthcare organizations, and even government ones. India too has multiple EMR systems, some created by government organizations and several others by commercial organizations.
So why do we propose to develop a new system, from scratch?
Most clinical information systems, even many that are created with inputs from clinicians, end up catering more to the administrative, business and financial functions. The open source systems, as well as the commercial systems, have proven to be a boon to the administrators and the bureaucracy of the healthcare organizations. Leaders love them, the clinicians don’t.
The dissatisfaction with the current systems, even with the best ones, remains high. The frustration with the EMR systems is cited as one of the main reasons for clinicians wanting to leave medicine.
For an EMR to be successful, including achieving satisfaction for all stakeholders in healthcare, especially the patient and the clinician, the clinical process must be treated as its core. All other features must be built inside out, starting from this core.
Because every healthcare administrative function is dependent on the data and events that emerge from the clinical process. The clinical process also often needs the data from administrative processes but this dependency is much less than the other way round.
If the administrative, non-clinical processes are implemented before the clinical one, they may function, but by creating indirect means of accessing the clinical data needed by them, in effect creating proxy clinical process for each such administrative function. Not only does this increase the duplication of work, it ends up creating multiple versions of the clinical processes, each of which needs to be updated every time the real world clinical process undergoes a change. This leads to system being fragile and difficult to maintain.
If the clinicians are to record the most critical part of the data, the data which will then be used by every other segment of the healthcare sector, does it not stand to reason that the system be built with the clinicians in mind, with the aim to make that the most important feature of the system?
A successful system that is clinician-oriented can be built with the participation of clinicians at every stage of its development including writing of pieces of code by them. Not only should the system be created in close cooperation with clinicians, it should be created to be completely modifiable by them, even after it is fully developed. Since not all clinicians will be in the position to write the code themselves, they must be provided a system and tools which allow them to customize every element of the system, or use pre-created components that perfectly meet their needs. The clinicians need not necessarily be the ones to build the system or to modify it, but if needed, they should be able to do so. They should be able to modify the system without having to learn programming or the intricacies of software engineering. They should be able to modify everything except the core data structure. This includes the data entry forms, the workflows, and the logic to derive inferences based on the data and to drive the intelligence underlying the workflows. (See how this may be achieved: ).
A system with such level of adaptability in the hands of the clinicians will lead to the clinicians having a sense of ownership, and will evolve continuously keeping pace with changes in medical knowledge and regulations, and become progressively better with clinicians contributing to the innovations that best address their needs.
The bottom line is, Clinical Information Systems belong to the clinicians. The sooner the Information Technology finds a way to hand them over to them the better it will be for the clinicians and for healthcare.
Most clinical information systems are still created with little consideration given to the collaborative nature of healthcare. Care for even the simplest of cases often involves multiple healthcare professionals working in tandem or together. Each case often winds through the hands of several clinicians before it is resolved.
All this entails great deal of collaboration, including simultaneous data entry by multiple providers, synchronous or asynchronous group discussion among them, and patient handovers. Many tools exist for facilitating similar collaborative tasks in other industries but in healthcare systems such tools are either clunky and patched in solutions, or very limited.
If a knowledge based system is to be built, the need for creating, modifying and keeping the knowledge in the systems up to date will require additional set of collaborative tools.
If a patient passes through the hands of several physicians and hospitals across different organizations or states, currently there is no way of tying together the disparate records created in different places to weave them into a reliable coherent narrative. None of the established EMR systems currently use the blockchain technology which is suitable for such features. Blockchains can also be an effective way to keep a record of the work done and the transactions involved by means of smart contracts. Additionally, blockchain technology ensures that no record of the patient can be tampered without being detected.
Just like the many other functions of EMR systems, Clinical Decision Support is often an add-on, not baked into its architecture. As a result, CDS is available only for purposes which some developers, somewhere, decided it will be of use to the clinicians. If a clinician wants to change how the data is to be interpreted or how a recommendation is to be made, it is not easy for her to get that change made in the system.
Additionally, CDS, as provided in systems relies on either rules-based inference making or rules that are hard coded by the programmers, to integrate a different technology, for example machine learning, is not possible.
Even in these rules-based systems, except for the very simple rules, the clinicians cannot modify them because the system is not designed for such control by non-experts; the modifications may be made only by informaticians specially trained to do so, or the programmers.
Systems that claim to have interoperability usually mean they can send or share documents based on some of the standards that allow such information to be shared. The codes embedded in the document may provide some sense to other systems about which disease it pertains to and what treatment was given etc., but the data doesn’t automatically go and get appended or inserted to the patient record in the host system. A clinician with the expertise to parse the document, who understands the medical domain and the host system’s data structure still must do this part. In most cases, the document is just kept in the text form, in an already voluminous record for the patient.
Interoperability in the modern web technology means something beyond just sharing of text documents. It means, a system should be able to use the data from another as if it is its own. It means, one system understands the data from the other system well enough to provide decision support based on it. It means, one system should be able to invoke functions in another to achieve tasks that it does not have the capability to perform.
There is no reason that a modern day EMR should not have the benefit of such interoperability.
With interoperability being available in many systems only in token form, the data collected by them becomes trapped in a silo. It cannot be accessed by independently created tools or by other major systems. As a result, neither the patient can benefit from her own data, if collected at multiple sites, nor can the data be used for larger secondary purposes, such as for policy making or biomedical research.
Many applications already exist, and each day a new application is announced, either by the central government, some state government, private developers or NGOs. Many of these have overlapping functionality, and worse, they created an isolated pool of data, which is only for use within that app, serving no larger purpose than the narrow focus of the application. So much of development resource is wasted by creating non-uniform functionality of the similar kind in all these apps.
Since there are many systems out there which already serve needs of many organizations. Any new system cannot simply supplant them. We plan to create mechanisms and tools to allow these systems to connect to the IndiMR backbone.
Once the core of the system has been created, and the APIs, the standards, the constraints and the developer guidelines have been published, the developers will be able to create systems that interact with IndiMR, or create adaptors to mediate the data between their system and IndiMR.
The aim is to make IndiMR the backbone of the national health information structure, in which all data of all Indians can be recorded, and if it is not directly recorded within IndiMR, it will be possible to port the data or allow the other IndiMR based tools to access the data of other systems based for specific purposes.
So, yes, there have been many systems built, but if we want to have an EMR with powerful real time collaborative tools, deep interoperability, cutting edge technologies like blockchain and machine learning, a common data pool, which the clinicians feel they own, and which can interoperate with existing set of applications, we better start from a scratch.