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.
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/18200138Labels: #Digital, #Healthcare, #India, EHR, Healthcare Information Technology, MDDS
