A visual grid to digitally record an Ayurvedic Prakriti assessment; a first step toward integrated electronic health records.

Introduction

In recent years, factors including globalization and economic growth in India and Sri Lanka have driven an important modernization of Ayurvedic Medicine, characterized by increases in evidence-based research and initiatives to standardize remedies and procedures. Ramakrishna et al provide an important example of this trend with the standardization and validation of a questionnaire for the assessment of Prakriti. Prakriti represents an individual's unique personality, constitution or connection with the universe and is described on three dimensions or Dhosas; Kapha, Vata and Pitta. Ayurvedic clinicians assess a patient's Dhosa profile in order to customize diagnoses and customize treatments. Conventionally, a Dhosa profile is described using linguistic phrases such as Kapha-Vata, or Pitta-Vata Prakriti.

Ayurvedic clinicians typically record a patient's Prakriti along with the record of consultation in paper based files that are not normally exchanged or made accessible to other clinicians. Increased use, and interoperability with electronic health records, of digital Ayurvedic patient management systems is required. An electronic health record (EHR) is a longitudinal electronic record of patient health information of every event or encounter in a healthcare delivery environment. Smith and Kalra demonstrated that EHRs, when applying international standards, can be used to capture complementary and alternative medicine practice. Sud and Sud claim that patient management systems that digitally record clinical data are an important component for the modernization of Ayurveda and its interaction with Western medicine.

The benefits inherent in the establishment of digital Ayurvedic records, particularly for developing countries, has been identified.6, 7 However, authors also identified considerable obstacles including cost and professional change required for adoption: clinical patient management systems are very expensive and nationally linked electronic medical records represent integration projects that have cost more than $AUD1 billion in Australia. In a historical view of adoption of information technology (IT) within the United States of America medical sector, Berber, Detmer and Simborg cited the profession's reluctance to embrace new systems, a lack of government policies to encourage change and cost, to be significant factors in delaying transitions to digital healthcare. Venkatraman and Stranieri and Goldstein have noted that other challenges exist for widespread use of information systems in Ayurvedic medicine. These include the need to develop terminological standards for Ayurvedic concepts and the need to identify ways in which existing inter-operability standards, such as Health Level 7 (HL-7), can accommodate Ayurvedic concepts.

Experiences that delayed the adoption of EHR and information systems in allopathic medicine in economically advanced nations in recent decades can be analyzed to inform IT architectures for Ayurvedic medicine. Chapman lists recommendations for the design of eHealth technologies: the technology should be simple, it should be locally developed, built on existing technology already being used, end users should participate in the design and introduction of new technology and utilize resilient development strategies.

In the next section of this article, a user interface is presented that is designed for use on mobile devices by clinicians and patients. The interface enables the clinician to enter a patient's Dhosa in a finer grained manner than the linguistic terms currently used in practice, with a single touch/click of the mobile screen. The claim advanced in this article is that fully integrated EHRs that accommodate Ayurvedic medicine is possible without the expenditure of enormous resources if the architecture evolves somewhat organically driven by end user demand. A mobile device application (App) that enables an Ayurvedic clinician to enter and share a patient's Dhosa can act as the trigger for the organic evolution of an EHR and meets many of the recommendations advanced by Chapman.

The model for the transition to digital Ayurvedic records draws on Chapman's dictum that an IT architecture should build on technology being used by having its foundational software execute on mobile devices. Vatsalan et al have described the central role mobile health has to play in leap frogging developing nation healthcare into the 21st century. According to data from The World Bank, the use of mobile phones in India, where Ayurveda is widely used, is among the highest in the world.

Thyvalikakath et al draw on historical analyses in Western medicine to conclude that unless clinical systems are designed to be as intuitively useable as possible, clinician use will remain a barrier. Consequently, the interface for an Ayurvedic consultation tailored to be useable by clinicians and patients, is required to facilitate the entry of data from a patient consultation into a digital repository in as quick and easy a manner as possible. The design of a user interface for an Ayurvedic clinician to enter a patient's Dhosa in an easy and seamless a manner can be seen to be a critical success factor for the adoption of information systems in Ayurvedic medicine because the Dhosa assessment is an important element of every consultation.

In the next section, an interface for a one click entry of a Dhosa assessment by Ayurvedic clinicians is presented.

Representing TriDhosa on screen

Fig. 1, illustrates a plausible representation that includes a separate sliding data input for each of the Kapha, Vata and Pitta dimensions. This is cumbersome and deviates from core human–computer design principles elucidated by Johnson. An interface comprising three scales is minimally visual whereas a great deal of human cognition is visually driven. The three scales require the tedious entry of three pieces of data. Further, there is no correspondence between the relationship of Kapha, Vata and Pitta on screen to provide the clinician with a mental model.

Fig. 1

Three slider representation of TriDhosa.

Following exploration of the functionality required, it is proposed that a Maxwell Triangle, following the seminal work by Maxwell, can be used for the interface graphic. Fig. 2, depicts a triangle comprised of smaller colored triangles. The vertices represent Kapha, Vata and Pitta and are colored red, blue and green. The center of the triangle is colored white and represents a perfect balancing of the three Dhosas. The positioning of the three Dhosas on opposite vertices is consistent with the conceptualization of Prakriti in mainstream Ayurvedic medicine as described by Ref. 3. The triangle can readily be generated on any device using a conventional HTML 5.0 browser that implements the Maxwell equations, as described by Judd. A clinician enters the TriDhosa with a single finger press or mouse click.

Fig. 2

Vata, Kapha, Pita Grid.

The Vata, Kapha and Pita assessment is stored in a database on the clinician's device and can be readily transmitted to the patient's smartphone running the same application, or a Cloud based repository. This represents the first, albeit crude step that can evolve into an IT architecture for Ayurveda.

An IT architecture for Ayurveda

The model for the transition of Ayurvedic medicine to digitization and EHRs is based on the organic transitioning through four phases outlined below. Whilst barriers to adoption by health care professionals when using patient-generated data clearly exist in allopathic medicine, tailoring a system to be owned and managed by the consumer involves them in their health care process and empowers them to be part of their health care management.

For the model described below, the sustainability of eHealth technology is assumed to require three critical success factors in each of the four phases; the existence of appropriate technology, a demonstrable clinical benefit inherent in the eHealth technology and an economic case for sustainable deployment. A description of each phase and how each phase builds the technological, clinical and business case for the next phase is outlined.

Phase 1. Smartphone recording of Dhosas and sharing with patients

This phase is characterized by the availability of Mobile Apps such as the one described above that enable Ayurvedic clinicians to rapidly and accurately record the patient's Dhosa. The patient's birth Dhosa, detected by deep pressure pulse analysis can be stored in addition to the patient's Dhosa at points in time.

Technical case. Mobile infrastructure is already ubiquitous, relatively inexpensive and robust. The App should present no barriers to entry and should therefore be free or very inexpensive for clinicians and patients. Open source developments in health care have been identified to play a key and rising role. A community initiative to generate standards for the representation, storage and transmission of Dhosa should occur in this phase.

Business case. The initial development of the App does not require large resource outlays. App development companies can be expected to be interested in investing in the development of an App that could potentially be used by large numbers of Ayurvedic clinicians and patients. The need for the App to be available for free or at minimum cost needs to be explored to maximize opportunities for acquisition.

Clinical case. The App can be expected to be attractive for Ayurvedic clinicians to use because the Dhosa can be recorded more accurately in less time than existing paper based records. In addition the facility to retrieve the birth Dhosa grid for direct comparison with a current Dhosa is clinically useful.

Phase 2. Smartphone recording of additional patient data

This phase involves the expansion of the Dhosa App to include the facility for clinicians to record a broad range of data about patients and their treatment in addition to the Dhosa. The patient can also add to their own record. The App provides the functionality for the patient to transmit selected data to their clinician prior to a consultation. Similarly, the clinician can transmit their entry to the patient following a consultation.

Technical case. This phase is still heavily dependent on mobile technology. The App for this phase handles a great deal more data, so it needs to be more sophisticated. Standards become more important and access control and encryption becomes pressing. Processes to back-up the data, perhaps on Cloud repositories, also become more important.

Business case. Those companies who have developed successful phase 1 Apps can be expected to expend research and development funds to extend the Apps to include Phase 2 functionality. The business case can be expected to be sufficiently strong for this development as the number of users can be in many tens of thousands. Income can be expected to be generated from license fees paid by end users although governments can be expected to contribute towards fees for low income groups.

Clinical case. Ready access to more data about a patient can be clinically useful, particularly if mechanisms for the efficient display and retrieval of past data can be developed. Simply being able to retrieve treatments provided to patients in the past can help a clinician in treatment planning.

Phase 3. Emergence of entities to help patients store and manage their data

In this phase, organizations emerge to help patients store and manage their data. A model such as that advanced by the Health Record Bank Alliance (http://www.healthbanking.org/) where health bank organizations compete to store patient data and offer associated services, are particularly applicable for low resource economies. To sign up to health bank, a patient transfers their smartphone record to the bank. The bank can offer various services associated with the data including the facility to retrieve data from Ayurvedic hospitals and ultimately, to integrate data from allopathic and other complementary medicine clinicians.

Technical case. A health record bank trial reported by Yasnoff demonstrated that technology required for the operation of the health banks is currently stable and feasible. Integration with allopathic and other records requires a great deal of sophistication and will challenge existing terminological, messaging and inter-operability standards:

A back-end data repository is necessary to allow data capture and management, particularly where the system requires interoperability with other clinical systems. Where possible, data vocabularies should be in-built to standardize data capture.

The applicability of reporting tools also needs to be identified.

The architecture needs to support a standalone product that can integrate with existing electronic record and clinical systems. However this requires the identification of a suitable messaging standard. Whilst HL7 seems the most appropriate standard, it may be too clinical for the inter-operability needs across diverse medical system.

In terms of the location of data, the system should be a hybrid system, with both local storage on the device and remote duplication when the mobile device is tethered to wifi or intermittent internet connectivity. Considering the regions where this application will be used, the device needs to be able to function without being connected to the internet, but also allow the functionality of duplication to a web-based database when connected to the internet for data integrity and transfer to a health organizations' EHR. The application should also allow data transfer through either direct connectivity, for example through a USB connected to a computer, or using other technology, such as Bluetooth or a push service, to connect with desktop devices to allow the transfer of information with existing EHRs. Other data output methods should include encrypted email transactions to health organizations.

Business case. The record bank pilot struggled to find sufficient capitalization and customer uptake to maintain the development required. In this model, customer uptake can be expected to be substantial if Phase 1 and 2 have advanced sufficiently because these phases have created a need for patients to manage their data. A proportion will find the storage of their entire record solely on their smartphone to be sufficient but a large proportion will find the additional services that a health bank can provide to be attractive.

Clinical case. Ready access to data about patient's consultations with health care professionals across allopathic and complementary medical systems can be clinically very useful, particularly if mechanisms for the display of data across systems can be developed.

Phase 4. Semantic inter-operability across all medical systems

Comprehensive inter-operability across all medical systems requires many issues highlighted by Venkatraman and Stranieri to be addressed including the development and integration of terminological standards, standard representations of clinical practice, rigorous clinician registration, and a harmonization of security and privacy principles. Phase 4 describes a context where diverse medical systems are not necessarily integrated but co-exist.

It is proposed that key components of the architecture such as the Ayurvedic Dhosa App should be open-sourced. This system will be largely utilized in developing nations of Sri Lanka and India, where many consumers and healthcare organizations have limited funds available to invest in IT. An open-source system will allow clinicians to modify the system to meet both their own and their patient's needs. Whilst commercial competitors argue that open-source systems are at greater risk of bugs and security threats, Reynolds and Wyatt (reported in Webster) argue open-source systems are generally more secure than proprietary software because it allows users to more accurately assess the security of a system, fix problem areas quickly and remotely receive automatic upgrades to the software. Mobile based applications allow greater control over the EHRs security and privacy and an application that has security controls built in (for example, password protected) furthers these security controls. Further research is required to explore the economic sustainability for such App development and utilization especially amongst low socio-economic and low literacy users.

Conclusion

Over 400,000 practitioners world wide practice Ayurvedic medicine making it one of the most prevalent and significant systems of medicine. As such, information and communication technologies that are transforming the practice of Western medicine through the digitization of data about patients and consultations can be expected to also transform the practice of Ayurvedic medicine. Increasingly in Western medicine, digital records are being integrated across health care providers to result in a virtual record of health events from before birth to after death known as the EHR and accessible to future providers. This same trend is not occurring in Ayurvedic medicine despite calls for this to occur. A key obstacle remains the enormous cost of linking health care provider's records. This typically amounts to billions of dollars of expenditure and is borne by governments.

The development of an EHR in Sri Lanka and India where Ayurvedic medicine is widely practiced is challenging because currently, Ayurvedic records, when they exist, are paper based. Further, government funds to meet the huge expenses associated with the establishment of an EHR are unlikely to be expended in the foreseeable future. In addition, an Ayurvedic electronic record can be most useful if it is integrated into a Western medicine EHR so that providers from both disciplines can view the entire patient's healthcare context but this only adds to the cost and complexity.

The main contention advanced in this article is that Ayurvedic medicine can transition organically to be based on EHR if the demand for electronic records is created by patients and clinicians. A model for this involves the use of an application accessible on smartphones. The App uses a visual triangle that enables a Prakriti assessment to be readily entered and stored in the smartphone and shared with the patient. This first step has the potential to create demand for the Prakriti record to be expanded to include other health data, and expanded again to enable records to be shared by many health care providers. The model outlined presents an approach that facilitates the deployment of health record banks in a manner that may be affordable, sustainable.

Competing interests

The authors declare that they have no competing interests.

Authors' contributions

AS designed the Prakriti grid (the triangle). TS and AS conceptualized the dataflow and apply the concept to the TriDhosa assessments. AS and KBH detailed and described the architecture section. KP contributed to the Ayurvedic assessments. JS and DP develop the mobile version of the Prakriti application. SM and DR develop the database and web application. AS and TS carried out the primary Prakriti data analysis. AS, TS and KBH drafted the manuscript. All authors read and approved the final manuscript.