Regulatory Pathways for Medical Software

Why India needs to regulate medical software

Medical software is a rapidly evolving field that has the potential to transform healthcare delivery and improve patient outcomes. Medical software can be defined as any software that is intended for medical purposes, such as diagnosis, treatment, prevention, monitoring, or management of diseases or conditions. Examples of medical software include electronic health records, clinical decision support systems, telemedicine platforms, mobile health apps, artificial intelligence tools, and wearable devices.

However, medical software also poses significant challenges and risks for patients, healthcare providers, and regulators. Medical software can have direct or indirect impact on the health and safety of users, and can cause harm if it is not designed, developed, tested, and maintained properly. Some of the potential harms include incorrect diagnosis, inappropriate treatment, data breaches, privacy violations, cyberattacks, and adverse events.

Therefore, it is essential that medical software is regulated by competent authorities to ensure its quality, safety, effectiveness, and reliability. Regulation can also foster innovation and trust in the medical software industry by providing clear and consistent standards and guidelines for developers and users.

How other countries regulate medical software

Several countries have already established regulatory frameworks for medical software, such as the United States (US), the European Union (EU), and Australia. These frameworks are based on the principle of risk-based classification, which means that different levels of regulatory oversight are applied depending on the potential harm that the medical software can cause to users.

For example, in the US, the Food and Drug Administration (FDA) regulates medical software as a type of medical device under the Federal Food, Drug, and Cosmetic Act. The FDA classifies medical software into three classes: Class I (low risk), Class II (moderate risk), and Class III (high risk). The FDA also provides guidance documents and policies to clarify the scope and requirements of regulation for different types of medical software.

Similarly, in the EU, the Medical Device Regulation (MDR) regulates medical software as a type of medical device under the EU law. The MDR classifies medical software into four classes: Class I (low risk), Class IIa (low-medium risk), Class IIb (medium-high risk), and Class III (high risk). The MDR also provides rules and criteria for conformity assessment, clinical evaluation, post-market surveillance, and vigilance for medical software.

In Australia, the Therapeutic Goods Administration (TGA) regulates medical software as a type of medical device under the Therapeutic Goods Act. The TGA classifies medical software into four classes: Class I (low risk), Class IIa (low-medium risk), Class IIb (medium-high risk), and Class III (high risk). The TGA also provides guidance documents and standards to help developers and users understand the regulatory requirements for medical software.

What India can learn from other countries

India is one of the largest and fastest-growing markets for medical software in the world. According to a report by Nasscom, the Indian healthcare IT market is expected to reach $8.5 billion by 2023. However, India does not have a comprehensive and coherent regulatory framework for medical software yet.

Currently, medical software in India is regulated by various authorities under different laws and regulations. For example, some types of medical software are regulated by the Central Drugs Standard Control Organization (CDSCO) under the Drugs and Cosmetics Act; some types of medical software are regulated by the Ministry of Electronics and Information Technology (MeitY) under the Information Technology Act; some types of medical software are regulated by the Ministry of Health and Family Welfare (MoHFW) under the National Digital Health Mission; and some types of medical software are not regulated at all.

This situation creates confusion, inconsistency, ambiguity, and uncertainty for developers and users of medical software in India. It also hampers innovation and adoption of medical software in India by creating barriers to entry, increasing costs and risks, and reducing competitiveness.

Therefore, India needs to learn from other countries and develop a harmonized and streamlined regulatory framework for medical software that is based on the following principles:

• Risk-based classification: Medical software should be classified into different classes based on the potential harm that it can cause to users. The level of regulatory oversight should be proportional to the level of risk.
• Conformity assessment: Medical software should undergo a process of verification and validation to demonstrate its compliance with the applicable standards and regulations. The process should be transparent, efficient, and consistent.
• Clinical evaluation: Medical software should provide evidence of its clinical performance and safety based on scientific data from clinical trials or real-world studies. The evidence should be relevant, reliable, and robust.
• Post-market surveillance: Medical software should be monitored after its deployment to identify any problems or issues that may arise during its use. The problems or issues should be reported, analyzed, and resolved in a timely manner.
• Vigilance: Medical software should have a system of reporting and managing any adverse events or incidents that may occur during its use. The adverse events or incidents should be investigated, mitigated, and prevented from recurring.

How India can implement a regulatory framework for medical software

To implement a regulatory framework for medical software in India, the following steps are recommended:

• Revise the Drugs and Cosmetics Act: The Drugs and Cosmetics Act should be revised to include medical software as a type of medical device and to define its scope and criteria. The CDSCO should be empowered to regulate medical software as a central authority under the Act.
• Align with NDHB and ABDM: The CDSCO should align its regulatory framework with the National Digital Health Blueprint (NDHB) and the Ayushman Bharat Digital Mission (ABDM), which are the national initiatives to create a digital health ecosystem in India. The CDSCO should recognize the NDHB and the ABDM as the digital health standards bodies in India and adopt their specifications and protocols for medical software regulation.
• Collaborate with MeitY and STQC: The CDSCO should collaborate with MeitY and the Standardization Testing and Quality Certification (STQC) Directorate to leverage their expertise and resources in the field of information technology and quality assurance. The CDSCO, ABDM, MeitY, and STQC should work together to develop and implement standards, guidelines, and procedures for medical software regulation.
• Engage with Ecosystem: The CDSCO should engage with various healthcare ecosystem stakeholders, such as software developers, end-users, healthcare providers, payers, pharma, researchers, academia, industry associations, civil society organizations, and international agencies, to solicit their feedback and inputs on the regulatory framework for medical software. The CDSCO should also conduct awareness and education campaigns to inform and educate the stakeholders about the benefits and obligations of medical software regulation.

Conclusion

Medical software is a promising and challenging field that can revolutionize healthcare delivery and improve patient outcomes in India. However, medical software also requires proper regulation to ensure its quality, safety, effectiveness, and reliability. India can learn from other countries that have established regulatory frameworks for medical software based on risk-based classification, conformity assessment, clinical evaluation, post-market surveillance, and vigilance. India can also implement a regulatory framework for medical software by revising the Drugs and Cosmetics Act, collaborating between CDSCO, ABDM, MeitY and STQC, aligning with NDHB Standards, and engaging with healthcare ecosystem. By doing so, India can create a conducive environment for innovation and trust in the medical software industry.

----------

Here is a summary of the lecture by Dr Pankaj Gupta on the topic Regulatory pathways for medical software:

Dr Gupta begins by discussing the different categories of medical software, including standalone software, software inside a medical device, software associated with a medical device, and software as a medical device.

Dr Gupta then moves on to discuss the risk classification of medical software. They explain that most regulatory bodies treat medical software as a medical device and that medical devices are classified into three classes based on their risk: Class I, Class II, and Class III.

Dr Gupta then discusses the regulatory pathways for medical software in the United States, the European Union, and Canada. They explain that the regulatory pathway for medical software depends on the risk classification of the software.

Dr Gupta concludes by discussing the future of the regulatory framework for medical software. They argue that the regulatory framework needs to be strengthened to keep up with the rapid pace of technological advancement.

Here are some of the key points from the presentation:

• Medical software is a broad category that includes a variety of different types of software.
• Medical software is regulated as a medical device in most countries.
• The risk classification of medical software determines the regulatory pathway that the software must follow.
• The regulatory framework for medical software is evolving to keep up with the rapid pace of technological advancement.

Libra Social Academy

Libra Social Academy brings to you Library of PankajGuptadr Healthcare Management YouTube Channel -- valuable insight into the teachings of Dr Pankaj Gupta and Team, well know HealthTech and Healthcare Management experts. 

All the documents, design, code and content is published in opensource for the larger public good as per MeitY opensource policy and under the MPL 2.0 License.

BWHealth - Bharat Swasth Mahotsav - Padma Awardee Doctors Conclave - 22 Aug 2022
See the first panel discussion on HealthTech.

10th Elets Healthcare Innovation | Technology in Healthcare pushing the Atmanirbhar Bharat Mission

Building Unique and Innovative strategies for Healthcare & Life Sciences Sector

Training on Successful Implementation of a Digital Financial Services for Health Project

Message on Universal Health Coverage

Biospectrum India at Healthscape Summit India 2017

Elets Interview- Dr. Pankaj Gupta, at Annual HIS

At Global VC Summit with Dr Pankaj Gupta.

Elets Healthcare Award 2019 : Dr Pankaj Gupta

CII DX Summit 3.0 | Day 1 22 February, Session on  Building Unique and Innovative strategies for Healthcare & Life Sciences Sector - Opportunities & Road Ahead.

Elets Annual HIS 2019

Healthscape IDE 2017 Panel Discussion Video1

Jaipur National University - one day virtual international conference - See 4:51 to 6:45

BRICS CCI: Webinar on 'Exploring Opportunities in the Digital Health Market' - See 1:42 to 1:46

HPIE Day 1: Friday,17th September, 2021- Healthcare Planning & Infrastructure Expo and Conference - See 3:09 to 4:07 

Improving process standards in healthcare webcast

APICON 2015 presentation by Dr Pankaj Gupta 19Feb2015 Gurgaon

Elets Exclusive: How TeleMedicine is Being used on the Frontlines of the Coronavirus Crisis

Dr Pankaj Gupta speaking @ IoT Grand Slam

Learnings : Teleconsulting - Changing Paradigms

India's National Digital Health Blueprint: From Paper to Practice

Panel Discussion: Transforming Healthcare Ecosystem Post Covid-19

NDHM will Integrate Digital Health Infra in India

Pharma Digital Transformation Conclave 2018 Panel Discussion

DR PANKAJ GUPTA | VOICE OF CHANGE

2017 Healthscape Summit | Dr. Pankaj Gupta, 3737 North | Testimonial

eINDIA 2012 Health Summit eHealth mHealth Dr Pankaj Gupta

Ayushman Bharat Conclave: Panel Discussion 5

Elets 2nd HTS-Day 2: Next Gen Realities: IoT, Machine Learning, Robotics & AI, Cloud and data Centre

2017 Healthscape Summit | Panel Discussion | Prescribing Technology

4th Annual Healthscape Summit | INTEGRATING SMART MEDICAL DEVICES INTO PEOPLE, PROCESS & TECHNOLOGY

Summary - Telemedicine Practice Guidelines

 

Doctor friends,

Telemedicine guidelines now allow you to do everything. Just be careful; Liability is on you now, so:

• Do not step out of your clinical comfort zone;
• Keep all the past and present records - Text, Audio, Video, Paper, Films etc. It is mandatory to keep records. Also the records provide a legal cover to the medical practitioner in case of any MLC.

Telemedicine guidelines have solved all the old issues:

• Any Consultation without Physical Examination was not allowed.
• Telemedicine needed Healthcare professionals on both sides of the Electronic Line.
• Only Triage was allowed over a Voice call.
• ePrescription was not allowed. MCI insisted on physically signed prescriptions.
• Online Pharmacy delivery without verification of physically signed prescriptions was not allowed.
• As per MCI, Patient walking into the Physical clinic is considered as Deemed consent. Law did not interpret the same for Telemedicine calls.
• Guidelines were silent on Consent, privacy and data security.
• Telemedicine service providers had to be registered with respective States under the Shops Act and Clinical establishment Act.
• MCI Contributory Negligence Clause included the Telemedicine software and service providers also i.e. they also had to share the legal Liability.
• Access and Availability.

----------------------

Technology Requirement:

• Cloud First Design: Gone are the days when you needed a big technology infrastructure for Telemedicine setup. Just host your App on the cloud.
• Mobile First Design: Now in the FAANG Digital era, all you need is an EMR on your mobile with a Text/ Audio/ Video calling plugin like Skype, WhatsApp, Team, Meet...etc.
• EMR is Mandatory: Make sure the EMR output is in compliance with the NDHB/EHR/MDDS Digital Health Standards. EMR should have ability to push the medical records to a National PHR whenever it becomes available.
• Connectivity: Internet 4G is required for Video calling. Internet 3G is enough for Audio calling and Text Consultation.

Functional Requirements as per Digital Health Policy of India:

• Patient demographics & encounter / visit clinical summary should use the government published libraries of data elements & code directories from MDDS_EHR standards. There are 1000 + data elements and 144 code directories defined and available in PDF format to be used by application developers. (XSDs, CSV, JSON, XML formats for the same are available with Access Health International in open source)
• Diagnosis & chief complaints- Diagnosis & chief complaints to be captured using WHO- ICD 10 code list.
• Clinical Notes- SNOMED CT codes to be used that are published and available with NRCeS on their website with tools for implementation.
• Lab & radiology Investigations- LOINC mapped with local investigation codes are to be used for all investigation orders to be paced through an EMR.
• Procedures (non-diagnostics & radiology procedures) - SNOMeD CT is recommended to be used for creating/prescribing any procedure order for the patient. A telemedicine provider can download and use free SNOMeD codes for India by registering on NRCeS website.
• Drug Prescription- An electronic prescription is required to be generated with a prescribing physician licence ID using NFI recommended Generics or Indian Drug Extension available on NRCeS website in SNOMed format.
• Referral Management- Solution shall support an electronic referral and an E-referral note with standardized digital visit/encounter summary to facilitate "continuum of care" with futuristic place holders for Facility & doctor registry lookup services.
• Health Information Exchange- NDHB recommends FHIR resource 4 to be used for clinical & health claim information exchange between providers and payers with indian specific semantic & terminology standards.
• Note- A FHIR compliant Digital clinical summary structure & design (electronic encounter note ,electronic referral note and electronic prescription note) as per telemedicine guidelines & MCI guidelines, are readily made available in JSON format on www.openbodhik.in

----------------------

Relevant Clause by Clause Summary - Telemedicine Practice Guidelines - 25 March 2020

This constitutes Appendix 5 of the Indian Medical Council (Professional Conduct, Etiquette and Ethics Regulation, 2002Definition:‘The delivery of health care services, where distance is a critical factor, by all health care professionals using information and communication technologies for the exchange of valid information for diagnosis, treatment and prevention of disease and injuries, research and evaluation, and for the continuing education of health care providers, all in the interests of advancing the health of individuals and their communities.'

With telemedicine, there is higher likelihood of maintenance of records and documentation hence minimalizes the likelihood of missing out advice from the doctor and other health care staff. Conversely, the doctor has an exact document of the advice provided via tele-consultation. Written documentation increases the legal protection of both parties. <Interpretation>: Keeping Electronic Medical Records is now mandatory.

help patients adhere better to their medication regimens and manage their diseases better. Telemedicine can also enable the availability of vital parameters of the patient available to the physician with the help of medical devices such as blood pressure, blood glucose, etc management.

Unnecessary and avoidable exposure of the people involved in delivery of healthcare can be avoided by using telemedicine and patients can be screened remotely.

India’s digital health policy advocates use of digital tools for improving the efficiency and outcome of the healthcare system and lays significant focus on the use of telemedicine services, especially in the Health and Wellness Centers at the grassroots level wherein a midlevel provider/health worker can connect the patients to the doctors through technology platforms in providing timely and best possible care. <Interpretation>: Telemedicine Guidelines have to be read in conjunction with and will be governed under the ambit of India's Digital Health policy i.e. NDHM, NDHB Standards, EHR Standards and MDDS Standards for Health.

However, there has been concern on the practice of telemedicine. Lack of clear guidelines has created significant ambiguity for registered medical professionals, raising doubts on the practice of telemedicine. The 2018 judgement of the Hon’ble High Court of Bombay had created uncertainty about the place and legitimacy of telemedicine because an appropriate framework does not exist. <Interpretation>: All the ambiguity is now removed.

In India, till now there was no legislation or guidelines on the practice of telemedicine, through video, phone, Internet based platforms (web/chat/apps etc). The existing provisions under the Indian Medical Council Act, 1956, the Indian Medical Council (Professional Conduct, Etiquette and Ethics Regulation 2002), Drugs &Cosmetics Act, 1940 and Rules 1945, Clinical Establishment (Registration and Regulation) Act, 2010, Information Technology Act, 2000 and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011 primarily govern the practice of medicine and information technology. Gaps in legislation and the uncertainty of rules pose a risk for both the doctors and their patients.

It also spells out how technology and transmission of voice, data, images and information should be used in conjunction with other clinical standards, protocols, policies and procedures for the provision of care.

1.3.3 - All registered medical practitioners intending to provide online consultation need to complete a mandatory online course within 3 years of its notification. <Interpretation>: RMP must be trained on Telemedicine course within 3 years of this notification

1.4 - Classification of Telemedicine:
Communication - Real time vs Asynchronous
Purpose - First, Follow-up, Emergency
Individuals - RMP, Health worker, Caregiver, Patient

2.0 - Limitations of Telemedicine: <Interpretation>: It is difficult to establish the ID of the Patient and the RMP over Video/Audio/Text. Hence proper and sufficient ID proof has to be presented from both sides. Patient identification needs to be clearer, greater chance of imposters representing the real patient over a Audio Call. It is difficult for the RMP to do a Physical Examination. Only possible when there is a Healthcare Worker on the other side also.

3.0 - The professional judgment of a Registered Medical Practitioner should be the guiding principle for all telemedicine consultations: An RMP is well positioned to decide whether a technology-based consultation is sufficient or an in-person review is needed. Practitioner shall exercise proper discretion and not compromise on the quality of care.

3.2.2 - An RMP should verify and confirm patient’s identity by name, age, address, email ID, phone number, registered ID or any other identification as may be deemed to be appropriate. The RMP should ensure that there is a mechanism for a patient to verify the credentials and contact details of the RMP.

3.4.1 - If, the patient initiates the telemedicine consultation, then the consent is implied [Similar to Physical In Office Consultation]

3.4.2 - An Explicit patient consent is needed if: A Health worker, RMP or a Caregiver initiates a Telemedicine consultation.

3.5.1 - An RMP would use his/her professional discretion to gather the type and extent of patient information (history/examination findings/Investigation reports/past records etc.) required to be able to exercise proper clinical judgement. This information can be supplemented through conversation with a healthcare worker/provider and by any information supported by technology-based tools. If the RMP feels that the information received is inadequate, then he/she can request for additional information from the patient.If a physical examination is critical information for consultation, RMP should not proceed until a physical examination can be arranged through an in-person consult. RMP shall maintain all patient records including case history, investigation reports, images, etc. as appropriate. <Interpretation>: Data of the Current Consult and sufficient data of the past is required for providing the Consult. Digital or Non-Digital Data has to be kept by the RMP. How much Information required is Left to the discretion of the RMP but it has to be sufficient to support the diagnosis and treatment plan.

3.6.2 - Follow-Up Consult(s) means - The patient is consulting with the same RMP within 6 months of his/her previous in-person consultation and this is for continuation of care of the same health condition.

3.7.1 - If the condition can be appropriately managed via telemedicine, based on the type of consultation, then the RMP may proceed with a professional judgement to:
Provide Health Education as appropriate in the case; and/or
Provide Counseling related to specific clinical condition; and/or
Prescribe Medicines

<Interpretation>: RMP can prescribe Medicines over a Telemedicine Consult.

3.7.4 - Prescribing medications, via telemedicine consultation is at the professional discretion of the RMP. It entails the same professional accountability as in the traditional in-person consult. RMP may prescribe medicines via telemedicine ONLY when RMP is satisfied that he/ she has gathered adequate and relevant information about the patient’s medical condition and prescribed medicines are in the best interest of the patient. Hence, Prescribing Medicines is Left to the clinical judgement of the RMP as per the guiding lists given below:
List O - OTC with Any kind of communication mode.
List A - Re-Fills and reasonably safe medication after Video Consult.
List B - Follow-Ups with Any kind of communication mode.
Prohibited - Potential for Abuse, Scedule X, Narcotics etc. can not be prescribed.

3.6.4.2 - Prescription Format is given in the Annexure. RMP shall provide photo, scan, digital copy of a signed prescription or e-Prescription to the patient via email or any messaging platform o In case the RMP is transmitting the prescription directly to a pharmacy, he/ she must ensure explicit consent of the patient that entitles him/her to get the medicines dispensed from any pharmacy of his/ her choice. <Interpretation>: ePrescription is explicitly allowed. No need for physical signatures in ePrescriptions. RMP has to obtain explicit Consent of patient before sending ePrescription to the Pharmacy.

3.7.1.2 - Registered Medical Practitioner would be required to fully abide by Indian Medical Council (Professional conduct, Etiquette and Ethics) Regulations, 2002 and with the relevant provisions of the IT Act, Data protection and privacy laws or any applicable rules notified from time to time. Interpretation: All Telemedicine controls to be built as per IT Act, Data Privacy and Data Security regulations etc.

3.7.1.3 - RMP Protected from breach if the breach is attributable to Technology or a person other than the RMP. The RMPs should ensure that reasonable degree of care undertaken during hiring such services.

3.7.2 - MAINTAIN DIGITAL TRAIL/ DOCUMENTATION OF CONSULTATION: It is incumbent on RMP to maintain the following records/ documents for the period as prescribed from time to time. Log or record of Telemedicine interaction (e.g. Phone logs, email records, chat/ text record, video interaction logs etc.). Patient records, reports, documents, images, diagnostics, data etc. (Digital or non-Digital) utilized in the telemedicine consultation should be retained by the RMP. Specifically, in case a prescription is shared with the patient, the RMP is required to maintain the prescription records as required for in-person consultations. <Interpretation>: RMP is responsible for Maintaining Digital Trail or Documentation including Logs, Digital or Non-Digital patient records.

3.7.3 - RMP can charge a reasonable Fee for Consultation and should provide a receipt for the Fees.

4. - Telemedicine envisaged in 5 scenarios:
Patient to Registered Medical Practitioner
Caregiver to Registered Medical Practitioner
Health Worker to Registered Medical Practitioner
Registered Medical Practitioner to Registered Medical Practitioner
Emergency Situations

<Interpretation>: In 3 and 4 physical examination is possible. Gives greater visibility into the disease condition of the patient. RMP can prescribe medicine with more confidence.

5.4 <Interpretation>: Artificial Intelligence not allowed to Consultation. Artificial Intelligence can at best be an assistant the RMP.

-------------------------

Points to Ponder:

• Telemedicine guidelines have Equated Telemedicine Consult with Physical in office Consult. All laws and regulations that apply to physical in-office Consult will now apply to Telemedicine Consults also.
• All Liability is now on the Medical Practitioner. So commensurate Standard Treatment Guidelines [STG] should emerge. STG have to emerge for prescribing List A, B drugs.
• Mandatory for Medical Practitioner to keep sufficient Medical records, of current and enough records of the past. In other words the Telemedicine marketplace has to get together to build an interoperability framework across facilities and geographies to enable the longitudinal patient health record [PHR].
• RMP absolved of Liability if problem attributed to Technology - So Contributory negligence for Telemedicine software and service provider should also be spelt out.

----------------------------------

Telemedicine Notes shared by Dr Pankaj Gupta for the Medical Fraternity

Health Systems for a New India: eObjects #Opensource Building Blocks

 

Here is a sequence of events over the last 8-10 years that lead to the #Opensource eObjects.

India has been majorly a paper-based Healthcare System. However, there have been pockets of success in transforming paper-based processes to electronic systems. Max Healthcare was one such initiative that took a leap of faith well before the rest of the market could even think in that direction. I happened to be part of that journey with an eclectic team that got dispersed at the end of the project but continued the journey in their individual capacities. Who could think then that such small individual efforts could come together later for the transformation of the country as a whole? It probably happens once in a lifetime. Serendipity positioned a very strong National leadership that could collate all these pieces together for building the National Digital Health Blueprint.

It all began when Max Healthcare partnered and outsourced its IT infrastructure support to Dell Services formerly Perot Systems in September 2009 for developing and maintain their IT operations across all Max Hospitals in India. This unique partnership provided significant value to Max in terms of enhancing the quality of services and reducing the treatment costs. While doing the transformation at max healthcare the team stumbled and fell and then learnt to walk again. For India the full implementation of EHR, Registries, Meta Data, Master Code Directories and Interoperability were seen first time in action here. Max Healthcare gave invaluable learnings of applying the global standards and architectures to Indian settings, something that had never been done before!

Looking at the successful transformation of Max Healthcare, Perotsystems was contacted by the Ministry of Health India to conduct current IT systems study in health sector in India and do the health checks. Due to merger of PerotSystems and Dell Services, Dell Services could not undertake the task. Later I picked-up that work and submitted the Public Health IT Study Report through Sector Innovation Council on Health, India. Since it was not possible to study every system being in use in a country like India, I and my team picked up the representative set that was diverse enough to extract critical findings that needed immediate attention. Later these findings and recommendations from the Public Health IT study became important part of Twelfth Five Year plan.

Setting up Meta Data and Data Standards was an initiative taken by the Ministry of Electronics and Information Technology under National e-Governance Plan (NeGP). It intended to promote the growth of e-Governance within the country by establishing interoperability across e-Governance applications for seamless sharing of data and services. Domain-specific committees were constituted under MDDS initiative. MDDS for Health Standards committee was one such initiative, which was constituted on September 2012 under the chairmanship of Joint Secretary MoHFW in pursuance of communication received from Secretary, Ministry of Electronics and Information Technology (MeitY).

Role of Meta Data and Data Standards in Primary and Public Healthcare
MDDS for Health Data Dictionary
Facility Registry: NIN HFI Project Report
National Digital Health Blueprint

eObjects were first written by Prof Dennis Streveler and Dr Pankaj Gupta in a white paper in Nov 2018 that was published by Niti Aayog in the book Health Systems for New India, Chapter 5 - Reimagining India's Digital Health Landscape Wiring the Indian Health Sector in Nov 2019.

ACCESS Health Digital Strategy Council defined the details of the NDHB building blocks - Minimum viable products including the eObjects and microservices architecture to comply with the NDHB Standards. ACCESS Health Digital runs a Social Entrepreneurship Accelerator to accelerate the implementation of the NDHB Standards through these building blocks.

The eObjects have now been adopted by Joint working Group of National Health Authority NHA and Insurance Regulatory Development Authority IRDAI Sub group on common IT infrastructure, in its report published on 11 Sep 2019 and will be built into the India’s national Health Claims platform.

The eObjects were designed for interoperability across the healthcare ecosystem on a federated architecture. eEncounter, eDischarge Summary Objects are for Provider-to-Provider interoperability; such that the data can flow across healthcare facilities, State HIE and National Data Lake. Whereas the eClaims Object creates a Financial Lever for the market. If the providers submit the claims in standard eClaims Object format then the turnaround time for their payments can be expected to be faster. Clearly eObjects are an innovative breakthrough.

This is very similar to what happened in the FinTech revolution in India where Government of India created the Unified Payment Interface UPI platform and then created the BHIM App and released the related Application Programming Interface APIs to the market. Later the Market used the API’s and built the hugely successful Paytm, Googlepay, Phonepe wallets. In 3 years the UPI transactions went from negligible to 1 Billion transactions per month.

Financial lever and strong governance for digital health transformation, plays a vital role in ensuring successful outcomes of such undertakings. India would do well to heed this truth.

My ACCESS Health Digital team got an eGovernance Award for the work.

The details of eObjects are published in #Opensource under MPL 2.0 #Opensourcesoftware license on OpenBodhik blog: www.openbodhik.in
FHIR based eObjects published in CSV/XML/JSON
Library of 1000 Data Elements and 140 Code Directories published in XSD
National Formulary of India - Generics Drug List Published in CSV
Healthcare Delivery Information System [HDIS] Minimum Viable Product [MVP] Definitions and Microservices Code Published

eObjects also published by ExpressHealth

eObjects referenced extensively by Nachiket Mor in his paper and book published by John Hopkins USA

India Leads the Way in Digital Health

 

India is in the midst of what some have dubbed the “world’s biggest healthcare overhaul.” In addition to recently launching one of the world’s largest publicly funded health insurance programs, set to cover some 500 million people living in poverty, the government has also been working diligently to develop a new digital health strategy for the nation.

The work on the strategy began more than five years ago, when the Ministry of Health and Family Welfare and the Ministry of Communication and Technologies developed a new set a metadata and data standards for health – essentially a common set of standards for the collection, creation, and coding of all health data that can be easily transferred across computers and information systems anywhere in the country. The standards were based on global best practices but adapted to better serve the local context. Previous to its work on data standards, the government also developed a system to allow it to issue a National Identification Number to all healthcare facilities in India.

These efforts have now put the government of India in a position to launch a new National Digital Health Blueprint. The blueprint, which is now open for public comments and consultations, validates the six pillar strategy that ACCESS Health has advocated for, namely:

1. A governance methodology and framework to help the digital health blueprint bring balance between patient privacy and scale.
2. Highlight the value and role of standards-based system design, including meta data and data standards for health, the health data dictionary, and registries.
3. A Health Delivery Information System to better manage healthcare provider operations, including software for patients medical records.
4. A Health Insurance Information Platform to provide better underwriting support for government schemes and to manage fraud and risks.
5. Electronic Health Records and a Health Information Exchange to provide citizens access to their health records and allow policy experts to understand disease burdens patterns.
6. Information and communications technology for infrastructure and capacity building to support digital health transformation.

A number of key members now on the ACCESS Health Digital Health team previously worked on the metadata and data standards initiative and on developing the national identification numbers. Their work was carried forward in the national blueprint.

In addition to its impact in India, the work the government has undertaken is likely to become a model for other emerging nations. The blueprint highlights some of the key points that ACCESS Health believes should be a part of any national digital health strategy. These include:

The need for federated governance and technology models to reflect the healthcare system, given that healthcare in India is a state-related subject;

The need to shift focus to more preventive medicine via a focus on strengthening the primary healthcare system and promoting alternative schools of medicine;

The importance of issuing of a personal health identification number that allows consent-based identification and portability of medical records across the continuum of care;

The importance of a mobile-first design approach that recognizes the growing penetration of telecommunication links on the back of low data tariffs;

The need for a data-driven approach to health policy making that recognizes the role of disease registries for accurate capturing of health burden; and

Recognition that there’s a need for keeping citizens healthy and productive to achieve economic growth as sick citizens become a burden on the system.

ACCESS Health Digital team looks forward to supporting the Government of India in its ongoing efforts to develop and implement this critical new strategy to improve health in the country.

https://accessh.org/india-leads-the-way-in-digital-health/

Healthcare Wallet will Emerge!

 

Healthcare Wallet will Emerge!

India is poised for 10 fold increase in digital payments. Will become 4th largest in the world after Singapore, Sweden and USA. This will have a profound impact on Digital Health. Will become a major driver in adoption of Digital Health across payer and provider systems.

Consider This:

Health Insurance coverage has gone up from 3% of Indias population to over 40% with Ayushman Bharat.

90% of Health Insurance claims is reimbursement of out of pocket out patient expenses related to the inpatients episode.

Insurance is more comfortable reimbursing a Digital expense because it reduces the chances of fraud and abuse. From a Actuarial perspective the risk comes down because of full traceability.

Patients will gravitate toward clinics and hospitals that provide Referrals, Prescriptions, Reports in Standards based electronic format. Because Insurance companies will clear the standard eClaims format faster.

About 8% of out patient gets converted to inpatient procedures for any hospital OPD. Any reduction in out patient foot fall will negatively impact the inpatient load and hence the top line.

A Fintech based rating engine will appear to rate the clinics and hospitals. This rating engine will be far more pervasive than the Practo rating engine because money in the pocket is always a more powerful driver.

A whole new sand box gets created for the digital health startups, software vendors and fintech companies to play. Someone will fill the vacuum. For lack of a better word a Paytm or Jio Wallet for Healthcare expenses and reimbursements is on the anvil.

India will be the next battleground for Global Retail and Healthcare! After USA, India has the largest user base for the Internet Giants like FB and Google. Amazon is in India. Walmart is picking up majority stake in Flipkart. All the Internet and Retail giants have expressed interest in Healthcare.

Can you extrapolate the Dots? I can see the Trend! Fintech fueled transformations are underway.

The real innovation in mobile payments in India began a few months prior to the cash ban. It’s called a unified payment interface, or UPI.

With more than 140 Indian banks sharing the interface, and Alphabet Inc.’s Google and Facebook Inc.’s WhatsApp offering instantaneous payment services on it, UPI has become a keenly watched experiment. By the looks of it, things are going well: From nothing to 800 million monthly transactions in less than three years, India’s UPI has taken off. Growing smartphone use and crashing data costs have helped immensely.

Google and WhatsApp will fight for market share. So will PhonePe, now owned by Walmart Inc. as well as new entrant Amazon Pay, which hasn’t made much of a dent globally into PayPal’s dominance of e-commerce. Indian banks that run their own UPI services. Indian tycoon Mukesh Ambani’s Jio with its 300 million subscribers will push JioMoney. Masayoshi Son and Warren Buffett will keep an eye on their Paytm stakes.

Now RBI has removed charges on RTGS/NEFT transactions; and asked banks to pass on benefits.

Cities Perspective:

Tier 1 cities: Pune, Bengaluru, Chennai are leading the wave in UPI transactions. Pune topped the city list, with the highest average digital spend — per person per month — of ₹16,513. Followed by Chennai at ₹14,208 and Bengaluru at ₹14,000.

Tier II and III Cities: Razorpay says by 2020, 40 per cent of digital payment transactions in the country will be driven by businesses and consumers in Tier-II and -III cities, and 50 per cent of internet users will be using digital payments. Whereas Paytem says - We have been witnessing a tremendous increase in adoption of digital payments in tier II & tier III cities that constitute 50% of our total user base. Surat, Durgapur, Rajkot, Meerut, Imphal, Rohtak, Panipat, Mangalore, Ranchi, Puducherry, Rajamundri, Warangal, Jodhpur, Thrissur, Karnal, Madurai and Jamnagar are among the fastest adopters and are leading the wave of digital payments adoption.

Users of wallets are not updating their KYC (know your customer) details. Instead, they are using UPI (Unified Payment Interface) to make digital payments. Anyhow total payments via digital instruments are expected to be between $400-500 billion in 2020, up from $50 billion in 2017.

Hold your breath guys! Fintech is the digital health roller coasters.

India has its own National Digital Health Standards Now

Role of #DataQuality and #DataGovernance in #PrimaryHealth and #PublicHealth

Dr Pankaj Gupta, Primary Health Care 2017, 7:1(Suppl), DOI: 10.4172/2167-1079-C1-005, ISSN: 2167-1079 PHCOA.

Meta Data and Data Standards [MDDS] for Health was written in 2013, 
the MDDS for Health was Released and Notified in August 2018, 
now included in the National Digital Health Blueprint [NDHB] in 2019.

Abstract:

The Public Health System in India is struggling with multiplicity of information systems being used at central as well as at state level. Each of these systems is unable to exchange data and information with each other. To overcome similar challenges across ministries, the Ministry of Communication and Technologies initiated semantic standardization across various domains under Metadata and Data Standards (MDDS) project. The intent was to promote the growth of e-Governance within the country by establishing interoperability across e-Governance applications for seamless sharing of data and services. MDDS for health domain was created by adopting global standards in such a way that existing applications could be easily upgraded to the MDDS standards. The exercise yielded approximately 1000 data elements. These data elements were expected to serve as the common minimum data elements for development of IT applications for various sub domains of health care. The need for the CDE arose because most of the primary and public health IT applications are being developed without any standards by different agencies and vendors in public and private sector in India. Each application is developed for standalone use without much attention to semantic interoperability.

Later when the thought of interoperability emerges – it becomes difficult to connect the primary and public health systems and make them talk to each other because they were never designed for that purpose. Even if technical and organizational interoperability is done the semantic interoperability may remain a challenge. For example – all primary and public health applications must have the same Facility Master. When application A sends the ANC data for facility 123, the receiving application B should understand ANC and uniquely identify facility 123. Another example is if a hospital application sends the insurance reimbursement bill to insurance company/government, the recipient application should be able to understand and represent the same meaning of bill information.

Ministry of Health & Family Welfare has initiated development of the national health facility registry. The registry was intended to standardize facility masters used across public health information systems. Standardization of facility masters is required for two purposes, first when exchanging data the sending and receiving applications should be able to identify health facility similarly. For example – when application A sends the maternal health data for facility 123, the receiving application B should understand maternal health data and uniquely identify facility 123. Second, in public health, performance of each of the facility is assessed using aggregate indicators and facility master serve as the secondary data source on which primary program specific data is aggregated. For example data from number of doctors from system A and total outpatient attendance data from system B could be analyzed to get per doctor patient load across health facilities only when both applications use common facility masters.

Specific On the Ground:

E-Governance systems for Health which are operational today include a variety of applications such as Mother and Child Tracking System (MCTS), Health Management Information System (HMIS), Hospital Information Systems (HIS), Supply Chain Management for Drugs and Vaccines, Integrated Disease Surveillance Project (IDSP), Revised National Tuberculosis Program (RNTCP) etc. There are states with over 30 distinct operational systems. The Private Healthcare sector also eludes transparency by hiding behind an equally diverse maze of complicated data silos.

1. Introduction:

The Metadata and Data Standards is an initiative taken by Ministry of Communication and Technologies under National e-Governance Plan (NeGP). The intent was to promote the growth of e-Governance within the country by establishing interoperability across eGovernance applications for seamless sharing of data and services. Under the MDDS initiative domain specific committees have been constituted in priority areas. The Health Domain MDDS Committee was one such initiative, which was constituted on Sept 2012, under the chairmanship of Joint Secretary in pursuance of communication received from Secretary, Ministry of Electronics and Information Technology (MeitY) previously known as Ministry of Communication and Technology.

Post formation, the Committee had initial orientation meetings on Metadata and Data Standards development for health domain. After initial discussions, National Health System Resource Centre was constituted as secretariat for the committee. To help develop Meta Data & Data Standards, two agencies were brought on-board following a proper selection process based on their merit on Health informatics. The due diligence was thoroughly done to study the landscape of existing health domain by involving all relevant stakeholders and knowledge partners including Program Officers and System Managers of Central and State Health IT Systems. As part of terms of reference, a thorough study of global data and interoperability standards were taken into account.

Initially generic data elements were extracted from the existing health IT systems. However these existing systems were geared towards addressing specific program requirements which was falling short to address the vast scope of Health domain. The other challenge was that data elements of these systems were not aligned with global data standards. Efforts were made to adopt and modify global standards in such a way that these existing applications could easily be upgraded to MDDS standards.

The exercise yielded to approximate 1000 data elements which were regrouped and formatted into 39 entities for better assimilation and presentation. These data elements will serve as the common minimum data elements for development of IT applications for various sub domains of health care. This is intended to facilitate interoperability among all these applications.

2. Purpose of Health Domain MDDS

The adoption of Metadata and Data Standards across healthcare IT systems will enable easier, efficient exchange and processing of data. It will also remove ambiguities and inconsistencies in the use of data. Once the MDDS standards are adopted by all eGovernance applications in healthcare, the interoperability would be easier.

Inevitably the migration to these new Standards may appear at the outset to be costly and time-consuming to some parts of government. However this burden should be outweighed by reduced development costs through the use of the agreed schemas that use these standards. It is also expected that new IT system in healthcare, as and when they come will use MDDS standard and will participate in information sharing and data exchange.

3. Structure of the MDDS Standard

The Metadata and Data Standards in Health Domain are developed following below mentioned guidelines set by MeitY. a. Metadata and Data Standards – Demographic v1.1 b. Operational Manuals for formulation of Domain specific MDDS c. Institutional Mechanism for formulation of Domain specific MDDS

As per the guidelines the MDDS Standards are broadly covered under three sections as given below. 1. Data Element Quick Reference (ref: Part-II) 2. Code Directory Quick Reference, Sample values and their structure (ref: Part-III) 3. Data Element Metadata (ref: Part-IV)

Data Elements common across all health domain applications are listed, defined and standardised in the Data Element Quick Reference document (Part II). This list gives brief description about the data elements in addition to the data format & size it follows. For easy readability the data elements are grouped in various entities. However these entities should be considered as logical grouping only and users are free to regroup these data elements as per their need. Under the quick reference document, each data element is classified into four categories to help identify following:-

Data elements which can be used from health domain to other domains (Prospective Generic Across Domain (Viz.: PGAD) Data elements which are common within health domain (Prospective Generic Within Domain (Viz.: PGWD)),  Data elements which are customised from already standardized generic data elements (Custom (Viz.: C))  Data elements which are application specific in health domain (Application (Viz.: A)).

Health Domain MDDS has followed ISO/IEC 11179 standard for development of data elements, value sets and code directories. As per the conceptual design of data element in ISO/IEC 11179, each data element can have a single value or multiple values attached to it. The data element which has a single value will be complete in itself and if a data element has a limited list of values associated with it, then those values will be a part of value list for that data element. However if there is a long list of complex values for the data element, they have been put in relevant code directories. Values in the code directories can grow and mature with review and modification.

Code Directory Quick Reference document is ready reference to the code directories developed (Part III). This indicates name of code directory, source of code directory and the ownership rights for each of the code directory. The metadata of each code directory is given in the Code Directory Meta Data and the sample values for each code directory are also populated in the Part III of the MDDS Standard. The sample value for each code directory is populated in the Part III. Some code directories (i.e. Inventory Store Master; Employee Master; Service Tariff; Package; OT Preference Card; Blood Bank Master; Ward; Bed; Authority; Supplier Master; Laboratory Master; Floor Master), which are highly implementation specific, no sample values are populated and it is expected that each implementer will populate the values in these code directories and help MDDS committee to enrich these code directories. In addition there are few code directories (i.e. Test Result Reference Range; Homeopathic Generic Drug; Non-Drug Item Brand; Homeopathic Brand Drug; Brand Drug; Manufacturer Master; Equipment Classification; Equipments; Ayurvedic Generic Drugs; Ayurvedic Brand Drugs; Unani Generic Drugs; Unani Brand Drugs) for which standard value set is presently not available. Domain specific Working Groups would be constituted to help populate these code directories. Work is presently going on for population of remaining 8 Code Directories (Facility Master; Facility Type; Ownership Authority; Facility Area Coverage; Facility Beds; Facility Human Resources Type; Administrative Linked or Referral Facility; Facility Services Master) which are part of the National Health Facility Registry initiative of MoHFW.

4. What is Common Data Elements

The Health Domain MDDS Committee provides a list of data elements that will serve as the common data elements [CDE] for any new application being developed in Health domain.

The need for the CDE arose because most of the Healthcare-IT applications are being developed without any standards by different agencies and vendors in public and private sector in India. Later it becomes difficult to connect the systems and make them talk to each other because they were never designed for that purpose.

Due to the inherent complexity of Health domain - It is difficult to create minimum set of data elements that every sub-domain must adhere. Each sub-domain’s minimum data element may not be completely applicable to other sub-domains – meaning ‘My minimum need not be your minimum’. For example the Lab Order data elements required at Primary care setting will be far less than the Lab Order data elements required at Secondary care and Tertiary care settings.

Therefore the health domain MDDS committee has come up with the Common Data Elements. CDE will provide most of the data elements required for any new Healthcare application to be built. However the users may add additional data elements above and beyond the CDE for their local needs. Using CDE the applications would be able to share information with each other. There are two ways to use CDE, either use CDE from the design phase of application development or make applications compliant with the CDE post implementation. The latter option is cost and efforts intensive and may be difficult to implement. It would be easy to use CDE from the design phase of application development.

While developing CDE the attempt was to be universal. However the healthcare is so vast that some specific data elements on the fringes may have been left out inadvertently. CDE is intended to be a living document and a designated Health Domain MDDS Committee will have the authority to add any new data elements, values or code directories that were left out at this stage or that may emerge as a result of natural evolution of the Healthcare domain. When new applications do not find the relevant data element or values for their use, they will have to use ‘Free Text’ data element or ‘Other’ Value from the code directory or value list. Though the usage of ‘Free Text’ data element or ‘Other’ Values will have to be discouraged in principle; however this usage of ‘Free Text’ data element or ‘Other’ Values has to be regularly monitored by the Health Domain MDDS Committee and used as valuable feedback for the next versions of the CDE.

Therefore CDE is intended to be a living document and a designated Health Domain MDDS Committee will have the authority to add any new data elements, values or code directories that were left out at this stage or that may emerge as a result of natural evolution of the Healthcare domain.

Why is Common Data Elements Required?

Organizations often want to exchange data quickly and precisely between computer systems. The need for the CDE arose because most of the Healthcare-IT applications are being developed without any standards by different agencies and vendors in public and private sector in India. Each application is developed for standalone use without much attention to semantic interoperability. Later when the thought of interoperability emerges – it becomes difficult to connect the systems and make them talk to each other because they were never designed for that purpose. Even if technical and organizational interoperability is done the semantic interoperability may remain a challenge. For example – all applications must have the same Facility master. When Application A sends the ANC data for Facility 123, the receiving Application B should understand ANC and uniquely identify Facility 123. Another example is if a hospital application sends the insurance reimbursement bill to insurance company/government, the recipient application should be able to understand and re-present the same meaning of bill information.

5. Health Domain MDDS: Conceptual Framework

The holy grail of Healthcare is the Provider – Patient relationship. The entire common data elements have been designed by keeping the Provider – Patient relationship in mind rather than either entity as the centre. The CDE has been designed based on the standard ISO/IEC 11179.This standard is a result of the following principles of semantic theory, combined with basic principles of data modelling.

Conceptual Domain: The first principle from semantic theory is the thesaurus type relation between wider and more specific concepts; For Example- the wider concept ‘Order’ has a relationship with similar more specific concept Pharmacy Order And immunization order. Therefore the CDE has created Pharmacy Order and Immunization Order entity.

Concept: The second principle from semantic theory is the relation between a concept and its representation. Different synonyms or closely related keywords can convey the same concept. For Example –The number of times the drug/medication has to be taken at what interval is a concept. ‘Frequency of Drug’ and ‘Frequency of Medication’ are different representations of the same concept.

Data Element: The basic principle of data modelling is the combination of an Object class and an Attribute to form a more specific ‘data element concept’. For example- the abstract concept ‘Frequency of Medication’ is combined with the object class ‘Medication Order’ and is associated with Attribute ‘Frequency’ to form the data element concept ‘Medication Frequency’. The standard must select the most appropriate keyword as the representation of the concept. In the above case the o Object: is ‘Medication Order’ and, o Attribute: is ‘Frequency’

Value Domain: A value domain is the permitted range of values for a Concept. If the data element concept has a single value then it will remain as a single data element. If it has a limited set of values attached to it then it will have a value list. If the data element has a long list of values that are liable to change or be modified due to the business needs of the Health domain then it is advisable to create a Code Directory for those values. For Example- For data element concept ‘Medication Frequency’ the related Code Directory will have values: BID, TID, QID, HS, SOS, and Stat.

The associated Code Directories are drawn from standards such as –

• ICD-10 for Diagnosis and Classification: ICD is used to classify diseases and other health problems recorded on many types of health and vital records including death certificates.
• LOINC for Lab and Diagnostics: LOINC is a universal code system to identify laboratory and clinical observations to facilitate exchange and storage of clinical results or vital signs for patient care and research
• Procedure & Radiotherapy Codes (preferred primary terminology): SNOMED CT.
• WHO Morbidity list: The noun morbidity means "the quality of being un-healthful." The special tabulation list for morbidity published in ICD-10 volume 1 consists of 298 groups defined by their ICD-10 codes.
• WHO Mortality list: The noun mortality means "Death" The special tabulation list for mortality published in ICD-10 volume 1 consists of groups defined by their ICD-10 codes.
• WHO ICF: The International Classification of Functioning, Disability and Health (ICF) are used for defining functionality & disability.
• WHO Verbal Autopsy Standards: Is list of standards for causes of death with mapping to ICD-10 Codes.

6. Identifiers and Registries

For data exchange across applications, accurate identification of each person/ facility receiving or providing healthcare services, and also anyone accessing or using this information is extremely important. It is critical that a set of standards be established for identifying the Facility, the Medical Provider, Patient, and all others handling healthcare data so that information across different locations can be exchanged easily and securely.

An Identifier could be a number, image (e.g. Bar Code or Blackberry ID), Biometrics (e.g. finger print or retinal scan), Radio Frequency Identifier Tag (RFID), Smart Card or a combination of these. Considering that none of these identifier standards exist today in Public Health space- The Health Domain MDDS Committee proposes basic number based identifiers. The standard can be upgraded to include Alternate Identifiers such as Bar Codes, RFIDs, Digital Signature etc., as the healthcare industry matures. For now appropriate Data Elements have been created to capture information about these Alternate Identifiers.

With regards to the nomenclature of the Identifiers some qualifiers were followed to maintain the uniformity.

a) Identifiers which were drawn from established sources were used as it is and no change is made in their names. e.g. Unique Identification Number (UID), PAN etc.

b) Identifiers which are proposed to be used uniquely and uniformly across states are termed as “Numbers” e.g. Unique Facility Identification Number, Alternate Unique Identification Number etc.

c) Identifiers where code directory or value list from established source is used are termed as ‘Codes” e.g. Diagnosis Codes (ICD10 Codes) etc.

d) Identifiers which were transaction specific are termed as “Identifiers or IDs”. E.g. Employee ID, Document ID etc. However some of these can come from code directory master but are named as IDs because they are transaction identifiers to be populated at the time of implementation.

I. Facility Identifiers: Facility Identity management is complex – therefore a Facility Code Directory is created to give a structure to it. This Facility code directory will serve as a Master to which all the Applications will refer. Two set of identifiers are proposed to uniquely identify each facility-GUID & NIN.

a. Global Unique Identifier (GUID) – This data element is a 16-bit number, which will be generated following a standardized algorithm by system. An example of a GUID in its standard form is 40e74fae-c0ab-11dfb090-0017f2300bf5. GUID will be used at the back-end to uniquely identify each facility. GUID will guarantee global uniqueness of each facility no matter where or by whom they are generated. All prospective systems need to follow standard algorithm in their backend to use GUID.

b. Facility National Identification Number (NIN)-NIN is a 10 digit random number given for each facility (public & private) engaged in providing some form of health care services. NIN will be used at the front-end with some form of human readability. There are two ways to do this.  Give the facility a number with facility related information embedded in it (e.g. ABC-13-05-0001, where AB&C represents State, District & Block respectively and next two digits represent year of facility formation and next two digits represent type of facility and last four digits represent the facility itself). However this approach has certain challenges as facilities might upgrade or facility attributes change due to administrative, geographic or political realignments.  The other way of doing it is by giving a unique running number to each facility without making this number dependent on any other factor. Where the facility related information can be added as an attribute to the NIN. The Health Domain MDDS Committee has adopted the later approach to uniquely identify each facility.

Why two identifiers for a facility? Although each facility will also be given a sequential 10 digit integer number (NIN) and this is used as a unique facility identifier by all users, still the uniqueness of these codes will be dependent on database system which generate these numbers, which still does not necessarily guarantees to be always unique e.g. if the database is ported from one Database Management System (DBMS) to another, the unique sequential number (or auto increment primary keys of tables) will change. In order to avoid this problem GUID is proposed along with NIN.

Summary:

• MDDS for Health is a library of 1000+ Data Elements logically organised into 39 Entities. Data Elements are Containers that carry the Semantics.
• MDDS has over 140 Code Directories providing the values that go into the Data Element Containers and give the meaning to the Container.
• MDDS leaves it to the market to organize the Data Elements into Minimum Viable Product Definitions or Minimum Viable building blocks.
• Most of these standards are drawn from global standards however these are developed keeping in view local health information systems requirements.

---- Read the Rest in # MDDS for Health Domain Standards on STQC website --

Date Line:

2011, 12th Plan requested for Min. of Health and Family Welfare [MoHFW] and Ministry of Electronics and Information Technology [MeitY] to come together and write Digital Health Standards for India; references to this recommendation are available in the 12th Plan. Public Health IT Study Report coined the term national ehealth authority [#NeHA], now being called national digital health authority [#NDHA]. national health systems resource center [NHSRC] had proposed Health Information exchange [HIE] in the Public Health IT Study Report. You can see it here under Studies and Evaluations: http://nhsrcindia.org/resource-detail/studies-and-evaluations/OTI0

2012, Dr Pankaj Gupta spoke about Digital Health Standards, Health Information exchange [HIE] at the WITFOR. You can read it here: http://www.witfor.org/images/stories/presentations/dr.%20pankaj%20gupta%2C%20partner%2C%20taurus%20glocal%20consulting%2C%20india.pdf

Dr Pankaj Gupta again spoke about Digital Health Standards, Health Information exchange [HIE] @ the eHealth conference Hyderabad 2012. You can watch it here: https://www.youtube.com/watch?v=v048j04FCd0

2013, Dr Pankaj Gupta and Dr Amit Mishra were leading the team that wrote the meta data and data [MDDS] standards for health domain. This was written as a reference Architecture for Digital Healthcare Software and as a framework for Interoperability - Semantic, Syntactic and Institutional Interoperability. MDDS is an Meta Data and Data Standard defined by Ministry of Electronics and Information Technology [MeitY] mandated to be implemented across Ministries.

#MDDS for Health: Committee on Health Domain Metadata and Data Standards has approved the Health Domain MDDS standards. The MDDS is intended to bring semantic interoperability among all health IT system. This is a prerequisite for establishing interoperability among disparate health information systems. The standards were developed following a rigorous consultation and review process and public opinion was also sought and incorporated on these standards.

2016, #NIN_HFI: Completed the National Identification Number for Healthcare facilities of India [NIN_HFI] project. NIN is like a AADHAAR card for all Healthcare Facilities. Facility Registry of the HIE and NHIN will be NIN_HFI. It is based on the Facility Registry defined in the Metadata and Data Standards (MDDS) of Health.

#NIN_HFI is a unique identification number, which a key requirement for achieving inter-operability and creation of EHRs, is being assigned to all health facilities (both public & private) to facilitate inter-operability among health IT systems deployed. So far more than 2 lakh Public Health Facilities have been allocated NIN. The process for setting up mechanism for allocating NIN to private facilities is underway. In other words the National Identification Number for Healthcare facilities of India is the Healthcare Facility Registry.

2017, Role of meta data and data standards in primary and public healthcare, 3rd Annual Congress & Medicare Expo on Primary Healthcare, Clinical & Medical Case Reports. April 17-19, 2017 Dubai, UAE. Pankaj Gupta, Primary Health Care 2017, 7:1(Suppl), DOI: 10.4172/2167-1079-C1-005, ISSN: 2167-1079 PHCOA. https://www.slideshare.net/PankajGupta9/role-of-meta-data-and-data-standards-in-primary-and-public-healthcare

2018, # MDDS for Health Domain Standards Notified by the STQC, Meity, GoI

References:

# PMJAY #AyushmanBharat launch speech by PM Modi.

# Healthcare For All - Four Years of Transforming India (May 2014 - April 2018) - Ayushman Bharat, MDDS for Health, NIN Facility Register..

# Public Health IT Study Report

#MDDS for Health: EHR Standards, Public Health IT Standards, Interoperability Framework and Health Information Exchange

#NIN_HFI: Will serve as the Healthcare Facility Registry https://nin.nhp.gov.in/about_nin2hfi.php

#Digilocker: Will serve as the HIS/LIS/RIS/EHR Document Registry: http://indianexpress.com/article/india/india-news-india/digital-india-scheme-to-focus-on-health-sector-arvind-gupta/

Building a healthy India: The government’s National Health Policy will improve health outcomes and reduce out of pocket expenses - JP Nadda. The Policy recommends establishing federated national health information architecture, consistent with Metadata and Data Standards (MDDS) http://blogs.timesofindia.indiatimes.com/toi-edit-page/building-a-healthy-india-the-governments-national-health-policy-will-improve-health-outcomes-and-reduce-out-of-pocket-expenses/

Informatics in Healthcare - The Statesman: http://epaper.thestatesman.com/c/18200138