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

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 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

India will be the next battleground for Global Retail and Healthcare!

India had 60 million online shoppers in 2016, which is only 14% of the internet user base in the country. This will rise to over 50% by 2026, according to a report by Morgan Stanley.
On top of that India has over 900+M mobile phones. 60% of these are smart phones. 90% of these are Android phones. 200M Jan Dhan Accounts have been opened at the bottom of the pyramid. Digital transactions have crossed 1 Billion every month. Rupay has emerged as the largest payment gateway in India dislodging Visa and Mastercard. Electricity has reached 500K villages. All this is expected to fuel the organized retail market.

Online retail is fast catching on, not just in the larger metros but also in the Tier II and Tier III cities. This growth can be attributed to increasing internet penetration and smartphone revolution. The Indian retail industry has come of age and has emerged as one of the most dynamic industries in the world. Accounting for over 10 per cent of the country's Gross Domestic Product (GDP) and approximately 8 per cent of the employment, it is expected to nearly double to $1 trillion by 2020 from $600 billion in 2017, registering a Compound Annual Growth Rate (CAGR) of 16.7 per cent over 2018-2020. Keeping in mind the growing online potential, brands and retail chains alike are upgrading their online presence to draw customers to their e-shops. India's growing per capita income, a rising middle class, changing demographic profile, urbanization, and attitudinal shifts in the consumer spending pattern, all indicate the retail sector's potential to be the real growth engine of the country's economy.
NHPM or Ayushman Bharat has created a huge Healthcare market i.e. INR 500K cover per family for 100 Million families in India. This is a game changer and all big players will run after it. Drugs form approximately 70% cost of any treatment. Obviously this Coverage needs an e-commerce platform, telemedicine apps, and digital community to support the physical Healthcare Ecosystem.

Myntra, Online retail store for fashion and lifestyle products, acquires smart wearables devices startup WitWorks. Flipkart owns India’s largest online fashion retailers -- Myntra and Jabong -- both of which it acquired. Together, Flipkart-Myntra-Jabong has a 70 percent market share of the online fashion business in India. It also owns eBay’s India business as well as popular mobile payments app, PhonePe. With over 100 million users and these popular properties, Flipkart is a valuable asset in the global internet economy for its long-term potential. Walmart is now looking to pick up majority stake in Flipkart. Walmart may rope in Alphabet [Google] also for Flipkart.

Amazon is already in India Retail sector. Amazon is already selling its services to many in Healthcare and has also announced it's desire to do more in Healthcare markets in US. Amazon said that it is working with Berkshire Hathaway (BRKA) and JPMorgan Chase (JPM) to better control costs and reduce spending on the health insurance they offer for the 840,000 people who work for them. Amazon has invested $4.74 billion in Amazon.in, to go after the India market and compete with Flipkart, Myntra, Jabong.

For traditional physical world Retailers, this means entering the playing field with the likes of e-commerce behemoths Amazon and Alibaba, both of which are leveraging big data and powerful AI algorithms to transform the retail space. The traditional Retailer Shopping giants are feeling the heat from Flipkart and Amazon in India.

Cooper Smith, who advises retail clients with Galloway's firm, L2, thinks we may be years away from a serious discussion on breaking up Amazon, but he advises retailers to not sit around and wait for that to happen. He thinks the announcement that Wal-Mart is partnering to sell some of its products on Google Home is significant for struggling retail survivors: "A lot of luxury brands like LVMH, which has refused to touch Amazon with a 10-foot pole, are talking about banding together to create a new luxury e-commerce space. Amazon hasn't been able to disrupt that market yet. Google and Facebook are the platforms with the reach, those are the alternative platforms that would help brands and retailers reach consumers without having to partner with Amazon."

In the US, Wal-Mart shoppers can link their Wal-Mart accounts to Google Express and quickly order — either through voice on Google Home or by shopping on Google Express. By linking a shopper's past Wal-Mart purchase history, Google will be able to more quickly learn the customer's shopping patterns and recommend suitable products. Using the platform now, a customer can say, "Google, buy peanut butter." Google will then suggest the brand it thinks the customer would like the most. The same can be leveraged by many other smaller struggling Retailers in India to compete with likes of Amazon and Alibaba.
On top of that Google is betting that the future of healthcare is going to be structured data and AI. The company is applying AI to disease detection, new data infrastructure, and potentially insurance.

FinTech mobile based payments developments supported by Govt of India's Digital India, Jandhan/Aadhaar/Mobile and BHIM App are only adding to the fire. Many local startups like Paytm and All big Internet and Retail giants are jumping into the ring - Flipkart, WhatsApp, Samsung, Android...

After USA, India has the largest user base for these Internet Giants. Obviously India is fast becoming the next battleground for Retail and Healthcare?

Can you extrapolate the Dots? I can see the Trend!

#India #Retail #Healthcare #NHPS #AyushmanBharat #Amazon #Flipkart #Walmart #Alibaba #Digital #e-commerce