Some perceived shortfalls in the proposed Indian National Health Stack by Dr. Pramod Jacob

There is ongoing work in India for a Nationwide Information Technology platform, that will support and facilitate the deployment of the Ayushman Bharat program, which is called the “National Health Stack”, the objective of which is to help achieve Continuum of Care across Primary, Secondary and Tertiary care for each of its citizens and facilitate payment for the care.


A draft of the National Health Stack (NHS) strategy and approach was put out in July 2018 for feedback and comments till July 31, following which no final draft has been published in the public domain. Hence the shortfalls brought out in this write up are based on the July 2018 draft and so these are perceived shortfalls, because the final version may have addressed these concerns. If so, request that the final document be published in the public domain. http://niti.gov.in/writereaddata/files/document_publication/NHS-Strategy-and-Approach-Document-for-consultation.pdf  


There is  recognition for the need of holistic longitudinal individual electronic health records for citizens, rather than just collated population-based data, for which one of the key components in the NHS Stack is going to be the Federated Personal Health Record. But is this requirement of an individual’s record to ensure continuity of care or mainly to avoid fraud and bring greater trust into the claim handling process? If it is for the stated objective of fulfilling the National Health Policy 2017 that states 
“The attainment of the highest possible level of health and wellbeing for all at all ages, through a preventive and promotive health care orientation in all developmental policies, and universal access to good quality health care services without anyone having to face financial hardship as a consequence… “
Then, in this write up I focus on two issues of immediate concern.

1.  No requirement explicitly stated for compliance to Healthcare Information Technology (HIT)/EHR standards as recommended by MOHFW and published on December 2016 

2. Different applications being developed at various levels of care, both in the public and private healthcare domain, which are not proven to “talk” to each other i.e. exchange healthcare data (interoperability)

Going into greater details about each of these issues:

1. No requirement explicitly stated for compliance to Healthcare Information Technology (HIT)/EHR standards as recommended by MOHFW and published in December 2016, except for patient/beneficiary identification. 
https://www.nhp.gov.in/categories-for-adoption-of-standards_mtl

It is understandable that when the program starts – the focus is going to be on assembling the registries of beneficiaries, providers, empanelled hospitals etc and the claims or payment for healthcare services rendered by providers. For validating the claims there is going to be proof of services rendered to be provided by filling forms and uploading supporting documents, such as test results, into the claims component of the stack by the hospitals/providers. However, instead of just having a checklist format of proof of service, if the data input is coded compliant to recommended standards (such as SNOMED CT for Diagnosis or LOINC for lab results) instead of just free text or proprietary codes –– then the healthcare data being collated is of much more immense value for clinical study and analytics. More importantly, this would bring about the perception that the information being asked for and checked on, has value in providing in-sights to providing better healthcare, instead of being perceived as an overseeing billing validation into the services provided by the clinicians, and so will facilitate onboarding clinicians to digitization.  

For continuity of care and to facilitate quality clinical care, the assumption that having an open API based paradigm for fetching the records of a citizen from across different points of care, without the need for being standard compliant, maybe misplaced. Ok, so touch points will bring across data from corresponding associated fields when different healthcare systems exchange data, for example diagnosis from the exporting system into the importing system. However here lies the problem if not standard compliant, when attempting to consolidate the diagnosis section of a patient in a repository or into a consolidated longitudinal record: - say a patient has Pulmonary Tuberculosis and over time, goes to 3 different doctors in a few years. It is very possible that the first doctor may record the diagnosis as “Pulmonary Tuberculosis”, the next doctor may have logged in this diagnosis as “Tuberculosis of the Lung” and yet a third doctor may have put in the diagnosis as “Pulmonary TB”. So, when the data is being collated - the computer will not understand that all these three different terminologies represent the same concept and site of the disease, and may record them as separate problems. However, if the diagnosis was standard compliant and coded with the recommended SNOMED CT code (Concept ID 154283005), then the compilation and consolidation of this individual’s diagnosis list will be correct, since this standard code consolidates all three terminologies as the same disease and site. Similarly, lab tests results may have various terminologies, for example Fasting Blood Sugar aka Fasting Blood Glucose aka FBS, but if the recommended LOINC code (1558-6) is tagged, then during consolidation of a patient’s test results, the correct interpretation that these are results of the same test will occur and so will be trended accurately. This will come into play even at the claims phase. Healthcare is knowledge intensive, with whole lot of concepts, terminologies, semantics and nuances involved, which needs a framework of standards to convey the correct meaning and interpretation, when exchanging information between different HIT systems.

Another trend is that in those states that already have such universal health coverage programs deployed, there is a tendency to come up with proprietary codes for procedures in each of these different schemes, to suit the billing/claims end users. For example, Andhra Pradesh’s NTRVS program has got procedure codes like S5 for orthopaedics procedures, drilling down to S5.1 for fracture correction in orthopaedics procedures, further drilling down to S5.1.4 for reduction of compound fracture and external fixation. The same procedures have a different proprietary coding system in the program run by Tamil Nadu. So, what happens when you try to compare outcomes from the same procedures between these two states?  If the recommended SNOMED coding system for procedures was applied in both the states – then carrying out such comparative studies become much more feasible and meaningful. Instead of reinventing the wheel with proprietary or local codes, if the recommended international standards that have been developed over the years by domain experts are put into place, then not only can we carry out such studies between our states but also between India and other countries, leading to adoption of the most efficient, cost effective, least invasive interventions with best outcomes. 

It is of utmost importance that these recommended standards, including clinical standards, be introduced at the foundational phase of the framework for the National Health Stack. With about 20% more effort upfront, it is possible to plug in the look up databases for these standards into their respective fields- such as Diagnosis, Labs, Procedures, Medications etc. Even better, that these standards be deployed and utilized (where relevant) even for claims (as explained above), while place holders be put into place for those  standards (mainly clinical) that may come into play only when the Federated PHR phase is activated. Importantly, to enable exchange of data between HIT systems, it is highly advisable to be compliant to HIT messaging standards such as HL7/FHIR. That will be the only way that the National Health Stack will have the robustness and flexibility to handle billing, claims and clinical healthcare functionalities optimally. If this is not done at the foundational phase and if the NHS framework is mainly set up for billing and claims, this will straitjacket the framework to effectively introduce these standards later and lead to fitting a square peg into a round hole situation. Also, an even bigger problem that proprietary codes could lead to, is if down the line wisdom prevails, and a decision is made to mandate recommended HIT standards, then the big headache issue of retrospective mapping of these proprietary codes to standard codes comes up for existing patients with past visits/admissions. It should not be billing and claims requirements that be the primary driving force for the National Health Stack, but ideally should be patient care and provider requirements in conjunction with billing/claims requirements that should be the driving force. 

 2. Different applications being developed at various levels of care, both in the public and private healthcare domain, which are not proven to “talk” to each other i.e. exchange healthcare data (interoperability)
   
The NHS document states that the National Health Stack a. Is designed to bring a holistic view across multiple health verticals and enable rapid creation of diverse solutions in health b. To enable patients to effectively become a Healthcare Information Exchange (HIE) of one: as meaningful data accumulates in a patient controlled repository, a complete picture of the patient emerges, resulting in improved quality of care across a range of providers.

For the above stated objectives to be attained, it requires at least these two conditions to be fulfilled: -

a. The diverse HIT systems that are involved in healthcare of the beneficiaries should " talk to each other " with ability to exchange data appropriately and without loss of meaning and interpretation in the exchange i.e. Interoperability. That is how accurate meaningful data of a patient should be accumulated.  Considering that 70% of healthcare in India is provided by the private sector, this accumulation of a patient’s data will require visits/admissions to private hospitals to be brought in. For this, there is the most important requirement and need to publish the open APIs specifically being used in the NHS, so that these private healthcare organizations’ systems can integrate and exchange healthcare data with the NHS. 

For example, if I am an authorized doctor for a patient – what is the API to be used to fetch this patient’s healthcare longitudinal record  from the National Health Stack?  Again, if the recommended standard like HL7's FHIR (which is API based) was adhered to for data exchange, it would have made this deployment, hooking up and integration with NHS much easier and effectively feasible.

b. For the data to be meaningful, classified and categorised correctly with terms implying the same concept put into the same category and not into different ones, need the variations in terminology (especially clinical terminologies) to map back to the correct concept as that intended by the provider - which requires the recommended HIT standards to be mandated. Only then can the healthcare data be meaningfully analysed, trends and patterns including outcomes be detected (by deploying statistical methodologies including machine learning and AI) and standard protocols with best outcomes for the various respective Indian ethnicities be formulated, thus achieving the stated goals and objectives of the NHS

If the National Health Stack does provide the latest and greatest in this  platform- with the recommended standards, then with our large numbers, English speaking brilliant human resources, internationally renowned prowess in Information Technology and Healthcare ; this assimilation  of a treasure trove of Healthcare Information, along with the  well-known Indian ingenuity, presents a huge opportunity for the country to leap frog healthcare to the next level and bring about betterment for humanity. 


Author
Dr Pramod D. Jacob (MBBS, MS- Medical Informatics)

After completing his medical degree from CMC Vellore and doing his Master of Science in Medical Informatics from Oregon Health Sciences University (OHSU) in the US, Dr Pramod worked in the EMR division of Epic Systems, USA and was the Clinical Systems Project Manager in Multnomah
County, Portland, Oregon. He went to do Healthcare IT consultancy work for states and counties in the US and India.

At present he is a Director and Chief Medical Officer of dWise Healthcare IT solutions. He was also a consultant for WHO India in the IDSP project and for PHFI for a Non Communicable Diseases Decision Support Application.

No comments:

Post a Comment




POPULAR POSTS

Popular Posts