It is imperative that IT Administrators, CTOs, CIOs and Representatives from Clinical users make an informed choice while selecting a software product for EMR. However, amidst talk of difficulties in implementation, lack of standards, mindsets, challenges of change management etc. product design aspects of EMRs often take a back seat when it comes to informed decision making for a hospital automation committee. eHEALTH tried to explore the technology perspective of Clinical Reporting and Analysis systems with Director and Solution Architect of 21st Century Health Management Solutions, Ravi Mani.

Q. How do you compare IT systems for clinical areas with other relatively mature business areas?

A. To design and deliver a clinical reporting system that will cater to the needs of the healthcare market is a challenge.

Unlike business applications where the processes and entities are fairly standard across the world, software products for clinical reporting face different challenges. If one has accurate insight into real challenges, explores the existing approaches and applies technology that best suits the particular challenge one can always arrive at a solution. Since we believe that technology is not a limiting factor. Of course implementing correct technology to convert a solution it into a widely adopted system by the users is also an equally important ingredient but my focus would be on the choice of technology.

Q. Correct me if I am wrong, but I think that any system can be automated if the logic is known. Why should medical science be an exception? It may be vast but I am sure it is well documented.

A. Yes the clinical flow is well documented, but it is not followed in practice the same way. It is as much an art as it is science. Doctors have to take split-second decisions when a patient is fighting death. Doctors do not have adequate infrastructure available all the time to meticulously follow documented process and they have more reasons to justify why the process cannot apply rigidly in care.

Let’s dig it a bit deeper by focusing on the data clinicians need to capture. Various specialties of medical science require different information to be captured. There are no universal standards that are followed by all doctors, especially in countries like India. In fact, the problem is so severe that even within one specialty of a hospital, the doctors find it difficult to come to an agreement on the clinical data that needs to be captured.

The granularity of data depends on the extent of specialisation of the hospital. That is to say that the data requirements of a Cardiac Department in a multi-specialty hospital would be lesser than a Cardiac Speciality hospital. This is because a Cardiac Specialty hospital would in all probability be involved in research and hence, the data requirements would be far greater.

Regional data requirements also vary depending on the disease profiles of the region.

Q. That’s true but software can always be tailored to any specific data requirement.

A. Specialists have designed and developed intricate systems for various medical disciplines. However, because of the above-mentioned challenges, such a system would inherently need extensive customisation and the system would fail to remain a product but will become a project leading to consume huge time and cost.

If you notice Enterprise Resource Planning (ERP) systems that have covered verticals such as banking, finance, manufacturing and many more, you’ll realize that this could be achieved because the extent of standardisation of the process is very high in these business areas. So the challenge of customisation seemed surmountable. So a single, all-encompassing product developed with conventional design methods is fine. But this has not worked so far for clinical systems and will not work in future either.

If we forgo the product concept for clinical systems and try to develop a system as a development project from scratch we will only be jumping from the frying pan into fire! This approach also suffers from the fact that the users of the system have to depend on the vendor for any change that they might need from time to time or any analysis that they wish to perform on the data if it is not already available in the system.

Q. So what could be a solution that would allow vendors to create a product, while allowing the hospital to customize as required?

A. What is needed is to give the user community a system that they themselves can configure the way they want. The product should be a tool rather than a tailored solution, something that can be referred to as a ‘framework’. A framework can give standard templates, which the users can change. They may even create completely new templates for clinical data capture.

Q. We have a direction of the solution. Can you elaborate on the technical aspects of the framework?

A. The framework should allow IT Administrators and doctors to define the fields that they wish to capture. The fields could be simple like text, numbers, selection from a list, dates etc. Such entries are typically required for OP consultation. The fields could also be complex like a table, the columns of which could again be either text, numbers, selection from a list, dates etc. Nursing charts that require periodic measurements can find this suitable.

They should be able to present hierarchical data structures by relating multiple tables that they have defined in the data capture form. Clinical data is typically hierarchical. Each visit is grouped under the patient’s name, and main aspect of data collection, such as patient history, family history, symptoms, signs, diagnostic findings and so forth are grouped under visit.

The data can be an object attached at any level in the hierarchy. It could be a scanned image, drawing by e-pen or also a pdf file downloaded from the Internet. All these inputs need to be accepted by the framework.

In other words, the users should be able to build a complete data capture form without having to code and compile programs, while at the same time be able to define simple rules like specifying mandatory fields, conditional data capture etc. And this is the principal differentiating factor from conventional systems that address all challenges imposed by clinical systems effectively.

Of course there are other critical technical aspects of the framework even after doing away with data capture issue. These are:

• To link to any conventionally developed system like Hospital Information System where the Patient Master Index would be residing because all the clinical data that is being captured has to be recorded against a patient.
• It is not enough to only link all the data to the right patient but all points of Care need the data whenever and where ever needed by the service providers. These requirements will be specific and not all the data captured. Patient-desktop for OP, Nursing, ICCU, Treatment planning. Unless this is easy and effectively implemented, users can never be expected to capture data regularly.
• Textual summary of the data captured is equally important as the users can have the ‘feel of’ case sheet in a single document for each encounter. It should be possible to print encounter summaries using the user-defined fields in the output document.
• Lastly, the system should provide very flexible tools for analysis on any of the fields defined by the user for academic / research purposes, statutory reports etc.

Q. We agree that customisation needed by other systems such as ERP is not as extensive as clinical systems but every system needs some customisation. Many of the ERPs provide extra fields in their databases that are preserved for future customisation. Is it not the same as what you mean by the framework?

A. This is a typical response after the first look at framework. But the limitations with ‘predefined-extra-fields’ approach are that:

• The number of fields is limited by the designer and clinical systems need much larger flexibility than this.
• Incorporation of such fields may not require change in data base structure till one exhausts all extra fields, but it still needs compilation and re-deployment of the software.
• Some vendors may allow users to define fields on the fly and create the fields in the database. But this approach fails since the vendor can never send a product upgrade as the original data structure that the vendor had made would remain the same.
• Pre-allocation of fields until they are actually used is highly inefficient.
• Hierarchies of data cannot be created by the user.
• User defined lists are generally not possible with this approach.

Q. That really makes a big differentiation. But how can all this be achieved?

A. We at 21st Century have come up with a completely new approach using the XML technology. XML lends itself for unstructured data organisation while providing fast querying techniques. XML has been adopted by the major relational database vendors like Oracle and Microsoft and has become a universal standard.

The main advantage of using XML approach is that our database structure does not change even if users add new fields in the system. This is because such user-defined fields are not stored as separate fields in the table but as part of a single XML field in the table. This is where the challenge of customisation gets solved with innovative technology.

And the best part is that the data which appears unstructured and dynamic to the end user, is actually well organised, analysable and efficiently stored in the database with XML.

Hence, we can send new product updates and upgrades to our customers without affecting their data definitions.

Once we decided the approach, we built an engine that allows the users to define complete new forms with simple and complex fields and having any number of hierarchies. The engine provides all the necessary options to save a record, retrieve an existing record, navigate, define an output document (using Word template) as well as provide Excel based analysis of the data that is entered. The engine is tightly integrated with Microsoft Office as MS Office supports XML data. Also, because MS Office is extremely popular, users find it easy to change the outputs from the system without depending on us. The engine also provides a Patient File screen where all the encounters of consultation, investigations and procedures are chronologically listed and the details of which can be drilled through from the screen.

Using this engine, our in-house panel of doctors create standard templates as part of the product for various specialties and this is distributed with our product. But, because of the features provided, users can use existing templates and change them as per their needs or create new templates of their own. Figure 1 and 2 are some examples of the forms developed by our customers using the engine.

The main philosophy behind the XML based engine is to empower end-users to get what they want without depending on the software or the solution provider. That will ensure a sustainable mechanism through a ‘product’ that addresses EMR for fast scalability.

For more information visit – www.21chms.com

Like

Dislike

Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter , Instagram.