How physicians can contribute to improving healthcare IT products

By Naval Asija MD

A computer is a machine that works very fast and makes things easy. How fast, depends mostly on the hardware, and how easy mostly depends on the software.
Software or applications are fancy terms for the computer program. A computer program determines how well the computer is told to do things.
“Machines are excellent workers, but poor leaders”. It can’t be truer than the case of computer programs. If you don’t tell the computer to do its task in a proper manner, it will never do it properly.
Computer programs are based on stacks of information known as databases. And then, the written instructions tell the computer whether to run or not run elements of the database.
This process of giving instructions to the computer is based on logic statements using binary results in the form of TRUE or FALSE and the use of “Operators” like IF and THEN, AND-OR, GREATER THAN-LESS THAN.
The actual instructions to the computer are however provided through use of special programming languages like HTML, C++, and Python which are known by software engineers. They convert the above logic statements into “Code” and this process is called coding.

---

Can The Physician Intervene at The Level of Database?
Generally speaking, No! The physician can’t.
The databases for healthcare IT are normatively accepted as industry standards, sometimes even by law.  Some of the examples of databases that are universally used by different industries operating in the healthcare market are given below.

• SNOWMED CT and LOINC systems for developing Electronic Health Records.
• ICD 10, ICD 10 CM, DSM codes for reporting diagnosis.
• PCS and CPT for coding medical procedures and tests.
• ATC classification for classifying drugs.
• HL7 for interoperability of medical messages, and continuity of care documents.

Some in-built features common in all these master databases create a breeding ground for huge troubles in the software/application. The two most important problems are listed below. 

1. All these are huge in size, with some of them being enormously large. This poses the problem of lots of redundant and unnecessary information being fetched each time there is a transaction.
2. One patient can simultaneously have many diseases, prescriptions and investigations. These keep on changing over time. So the amount of information captured for each patient at a point of time can be huge. In contrast, the entities in these databases have little links and relationships defined with other parts of the database. So, while the practice of medicine is grey in nature; the databases mostly exist as black and white, often leading to misalignment.

Due to these structural difficulties, the applications formed using such databases result in products that are often hated by their users. The typical example of this phenomenon can be seen in United States’ EHR industry, where the handwritten to EHR conversion has led to the emerging problem of clinician’s burnout.
However, the physician can sometimes intervene at the level of database, especially in the cases of true innovation, when an entirely new application is being formed and a new futuristic industry is being created. The synthesis of an appropriate medical database should be the core responsibility of the physician in charge of the product. For example startups deploying techniques like AI, AR, and VR in healthcare processes mostly build their databases from scratch and try to avoid the above problems by keeping it lean and focusing on relationships of individual entities.   

What If The Physician Can’t Alter The Database? What Skills Does The Physician Require?
The physician can intervene at the workflow part of the application while also forming the logic rules for running the parts of database.
Programming rules that facilitate integration with the clinician’s workflow and enable quality information entry and increase usability of the application should be the physician’s top priority targets of intervention. The physician could use intelligence and clinical experience to make the user experience seamless, smooth and enjoyable.
Some of the examples in this regard could be:

• Use of modular approach to fetch only parts of databases that are highly relevant to the user in the first paint. The other modules should be available on request. For example, a cardiologist may be forced to always document “No history of anxiety or depression.”
• Use of biological control variables like age, gender, and past history to avoid data entry errors and provide text suggestions for data entry.
• Use of relationships to link variables like latest HbA1C levels being linked with diabetes status.
• Learning from client’s experience to improvise the software.   
• Helping the IT-development team in finding bugs, reporting issues and following up about their prompt resolution.*
• Working with IT-testing team to feel the user experience before the final release of the software.*

* The last two suggestions may require that the physician learn computer coding and work with specialized software that the physician could learn to use over time. These skills could develop in interdepartmental meetings or through formal training, similar to how the computer engineers who would be simultaneously learning the medical terminology.
About the author: Dr. Naval Asija is from India and has a postgraduate qualification in health administration. He has worked for four years in Synodex, Innodata as a Med-Tech Physician. He currently writes about various health issues. You may also like reading his blog post A Typical Workday Of The Physician In A Healthcare IT Company that was posted on his personal blog.