Meta Data & Data Standards for Health
12th December 2013
• Initiated under National e-Governance Plan (NeGP) by DeitY.
• Aims to promote- e-Governance by making systems speak to
• Domain specific committees constituted –Health MDDS
Domain committee constituted on Sept. 2012.
– Chairperson - Joint Secretary (Policy), Sr. Technical Officer (NIC) as
– Secretariat- National Health System Resource Centre (NHSRC).
– Tasks of Secretariat- Stakeholder Consultations, selecting appropriate
technical agencies to support this work and Domain Expertise.
– Members from public health programme divisions, industry, IT domain
Meta Data & Data Standards- The Initiative
Terms of Reference:
1. To identify Generic Data Elements in the health domain,
which are common across e-Governance applications within
the domain as well as other domains involved in providing
sectoral services delivery under e-governance.
2. To study the Global Standards for standardising the
metadata of identified generic data elements for adoption as
3. To develop own standards / extension of global standards in
Indian context, wherever required, around policy on Open
(and in synergy with other domain committees by following
Institutional Mechanism for formulation of Domain specific MDDS
formulation published by DietY).
MDDS Health Domain Project - Mandate
Mandate of MDDS Committee….
4. Create and maintain repository of metadata of
standardised generic standards, and include the same
in central repository by having liaison with e-Gov
standards Div, NIC.
5. Ensure enforcement of standards in the applications
being developed in health domain at central/ state
6. To advise for identification of suitable test suits for
conformance testing of the implementation.
• Malaria Control
• State Health Management Information
Systems- In seven States with Hospital
• Routine Immunization Management Program
• Sporadic use in Medical College Hospitals
The first generation IT systems are characterized
by low expectations, effectiveness and
• The National Health Management
Information System- common Web- Portal
States develop a large number of systems-
1.Human Resource Management Information System.
2.Hospital Information Systems
3.Disease Surveillance Systems
4.Drug Logistics and Inventory Systems
5.E- Tendering and Procurement Systems
6.Clinical Establishments Licensing and Regulation
7.Emergency Call Centre and Ambulance Services
8.Mother and Child Tracking Systems- over 6 crore
9.Financial Transaction Recording Systems
10.Major initiatives in Tele-medicine.
11.Mobile Health , Insurance etc etc.
Main Positives of the Second Phase
• IT is now seen as mandatory in all aspects of
health systems management.
• High degrees of complexity and sophistication in
• Rapidly accelerating expectations.
• For example : From 600 district reports (2008), to
5000 block block reports ( 2011) to 2 lakh facilities(
2012), to 6 crore mothers and children, below 2
• AND NOW to every health encounter ???
BUT the problem : All Public Health IT Systems in silos
Malaria, IDSP, NACO
o Every program/ state develops own IT solutions. States have 10 to 30
o No help to integrated decision making for Public Health management.
o State to central exchange very poor- and even at the same level.
o Systems a struggling with poor design and falling short of objectives.
o Private Providers not participating in information exchange.
Importance of Inter-operability
• In Public Systems:
– To reduce work load in data recording and
– To support decentralized , horizontally
integrated decision making.
– To improve quality and use of information.
– To allow rapid growth of new systems and
uses of IT.
• For Providers AND Patients
– to improve quality of care
– To enable continuity of care
• For Insurance Payers
– access to patient records for claims
Systems to IT
Three Levels of Interoperability:
MDDS Builds Semantic Operability
Consultation with key stakeholders- MoHFW, NIC, C-DAC, MMP,
HISP, International Domain Experts, health care IT industry,
Program Managers, EHR Committee etc.
Review of Documents –EHR Standards, MMP, 12th Five Year Plan,
Public Health IT Systems Study, System Manuals, Program
Guidelines, MDDS Standard Document
Refer Global Data Standards- ICD-10, CPT, SNOMED, CCI, ICHI,
ICF, WHO Morbidity & Mortality Codes, LOINC
Refer Globally recognized Interoperability Standards –HL7 V2.X,
V3, CCD, SDMX.
Study of public IT Systems- HMIS Web Portal, MCTS, DHIS 2.0,
IDSP, Nikshay- RNTCP, iHRIS, e-Aushadhi
Part I Overview Report •Design Principles - Semantic Theory & its
application in Health Domain
•Roll-out mechanism, Institutional framework.
Part II Data Element Quick
List of 1077 Data Elements with their
definitions and Values
Part III Code Directories •Code Directory List,
•Meta Data for Code Directory
Part IV Data Element Meta Data Meta Data for Each Data Element. Including
Data Element Type, Format, Size, Validation,
Values, Default Value, Owner etc.
Annexure •Data Sets- Inventory, Blood
•Some examples of data sets created form the
common data elements.
Integration & Upgrade as
•Integration Solutions for existing system-
•MDDS Mapping with HMIS. IDSP & RNTCP
•Part II, III & IV and Annexure are in soft copy in CD.
•For online access visit- http://mohfw.nic.in, www.nhsrcindia.org
MDDS Health Domain Standards
Building Blocks of MDDS Health Domain
o The health domain landscape are broadly
divided into 39 Entities.
o These entities are described and qualified
with the help of 1077 Data Elements.
o Values of Data Elements are categorized
under Data Elements (735), Values List
(201) & Code Directories (141)
o Meta Data are constructed to define each
Data Element and Code Directory to
establish Interoperability Standards
o Interoperability Standards
o Reference Architecture for Interoperability
MDDS The Conceptual Design
ENTITY (E.G. PHARMACY ORDER)
LIST OF VALUES
(BID, TID, QID,HS, STAT)
FREQUENCY OF MEDICATION
MDDS The Conceptual Design
Entity (e.g. Facility)
List of Values
Repair , Closed,
MDDS The Conceptual Design
Entity (e.g. Diagnosis)
List of Values
ICD-10 Disease Codes
Tuberculosis - Lab
MDDS The Conceptual Design
Medical Reason for
Scheduled Trip Code
List of Values
Delivery, RTA, chest
pain, -drawn from
ICD and WHO
Common Data Elements
• Defining Minimum Data Elements as standards is
difficult in Health Domain.
• Minimum Data needs of the Primary Care Setting would
be different from the Secondary and Tertiary Care
• Health Domain has come-up with the Common Data
Elements which will act as superset from which program
specific data sets can be created.
• Data Set design is better left to the users.
Common Data Element - ENTITIES
Description of Entities
No. of Data
No. of Data
Generic 35 Lab 39
Person 32 Radiology 10
Patient 21 Pharmacy 32
Employee 155 Immunisation Order 10
Provider 16 Clinical Order 19
Source of Payment 38 Procedure 8
Bill 39 Blood Bank 36
Facility 32 Nursing 21
Episode 2 OT 33
Encounter 9 CSSD 20
Advance Directives 6 Inventory 179
ADT 56 Remission 5
Emergency 19 Complications 5
Outreach 11 Relapse 5
Disaster Response 31 Morbidity 6
Examination 5 Disability 7
Vital Signs 16 Mortality 6
Allergy 13 Ambulance 66
Clinical Notes 15 Indicator 5
Diagnosis 14 Total 1077
Common Data Elements: Snapshot
Number Name of Data Element Data Format Maximum Size
05.020.0001 Health Condition Type Integer 2
05.020.0002 Health Condition name Varchar 99
05.020.0003 Health Condition Code Varchar 10
05.020.0004 Health Condition Free text Varchar 254
05.020.0005 Health Condition Category Char 1
05.020.0006 Diagnosis Priority Char 1
05.020.0007 Health condition status Integer 2
05.020.0008 Co-morbidity Flag Integer 1
05.020.0009 Co-morbidity Health Condition
05.020.0010 Present Health Condition Onset
05.020.0011 Prognosis Integer 2
Complexities Pushed to Code Directories
Code Directory Facts:
Total Code Directory- 141
Code Directory Populated-111 (79%)
Code Directory Derived from established sources- 42%
7 Code Directories - Facility Master.
Ref No Name of Code Directory Ownership & Source
CD05.001 Facility Master MDDS Committee
CD05.019 ICD - 10 Codes WHO
CD05.024 LOINC LOINC
CD05.030 System of Medicine MDDS Committee
CD05.036 Immunization Product WHO
CD05.043 Procedure Code
Canadian Classification of Health
CD05.056 WHO List for General Mortality WHO
WHO International Classification of Functioning,
Disability and Health (ICF)
CD05.104 Generic Drug National Formulary of India
CD05.109 Pharmaceutical Unit of Measurement Food and Drug Administration
CD05.118 Third Party Administrator IRDA
CD05.130 Medical Reasons for Scheduled Ambulance Trip LOINC & WHO
Identity Management in Indian Health System
• Health information exchange between
systems through Identifiers
– Facility Identifiers (Unique Facility
– Provider Identifiers – Unique
Individual Health Care Provider
– Patient Identifiers– UID/ Alternate
Unique Identification Number
– Disease Identifiers– ICD-10 Codes
– Service Identifiers– CCI Codes
– Document Identifiers– Document ID
Facility Identity Management
Unique Facility Identification
I. Facility Signature Domain:
– Unique Facility Identification
– Global Unique Identifier
– Type of Facility
– Difficulty status- Easy/Difficult
– Rural/Urban Area
– Population covered
– Administrative linked parent
– Operational Status
– Referral facility
– Ownership Authority & Type
II. Facility Services Domain:
– Facility System of Medicine
– Facility Services Master
III. Facility Human Resource
IV. Facility Infrastructure
– Facility Bed Master
– Facility Bed Type Master
Suggested Model – Central Model
Further gains of this effort…
• Gone far beyond just clinical terminology standardization: Set
standards - administrative and operational parameters
• MDDS provides platform to dramatically accelerate use of
EHR standards/HL7/DICOM communication standards.
• Now in a position to be a global leader in healthcare IT useage
and implementations. Global Governments could also use
MDDS as a base and modify it for their local healthcare
• Allows greater democracy – in choose their own systems and
software applications, vendors and technical infrastructure :
within a ‘standards’ framework that ensure national
consistency in the reporting and management of healthcare
The Second Level of Interoperability:
Appropriate Integration Solutions will ensure Syntactic
• Useful for all historical applications without much disruptive
• One eligible application can receive message from a source
application message channel.
• Extra effort, time and cost to write Transformation logic for each
• Semantic interoperability difficult to implement across different
<?xml version=“1.0” ?>
<HMIS_dataelement>id=” M1|1.1” name=” Total Number of Pregnant Woman Registered for ANC”
<MCTS_dataelement> id=“1” value=“100” isChild=”F”</MCTS_dataelement>
<HMIS_dataelement>id=” M1|1.1.1” name=” Of which Number Registered with in First
<MCTS_dataelement> id=“2” value=“30” isChild=”T” Parentdataelement=”M1|1.1”</MCTS_dataelement>
<REPORTING_PERIOD> <TYPE>”Monthly”</TYPE> <FROM_VALUE>=”July 2013”</FROM_VALUE>
• Message broker can be
used to receive messages,
transform and route to
recipient application (Hub
and spoke architecture.)
• Data from finite set of
disparate applications can
be integrated using this.
• Data discovery at run
time based on a service
request is difficult.
• May lead to a highly
difficult to maintain.
(Health Information Exchange)
• Better suited to
• Based on Registry
• Allows to
locate the data
records and the
• Integration with
Choosing Integration Options
If within range of Tower in
Mumbai Circle, it has a registry
lookup to connect the 2
o Condition - II
• Condition - I
• Point to Point
√ Condition - III
• Any No. of Apps.
• Need to know where the book
is located in the Library. Else it
is like trying to find any book
without library catalogue
• Limited No. of Historical
• If Time & Effort not a
• Scalable to any number of
• Historical apps cant be retired.
• MDDS implementation with
deviations- Real world
• Intelligent broker is like -
Searching a book in electronic
catalogue – E.g. Amazon Books.
Trunk Dialing – Operator needs to
know where to route the call
Third Level of Interoperability
Set of rules, guidelines on the way we collect and report
data- and of course the desire to dialogue and share:
Guidelines, norms for data collection and
reporting, patterns of flow, aggregation and
context of usage.
Different levels of digital capacity, different
granularities of reporting,
Choice of standard, Indicators for data exchange.
Most importantly a dialogue between
organizations, to understand information needs,
as well as barriers to better quality and use of
National Authority should be able to facilitate
Key Principles: Follow-up and Roll-out
1. Data standards are seen as dynamic- provision to be made
for constant upgradation and corrections.
2. Even the starting standards as released now, will need
clarifications, corrections, additions, deletions- standing
committee to help to this.
3. In private sector, the adoption would be voluntary- driven by
the advantages and ease of doing so.
4. In public sector it would be driven by financing
conditionality and needs for sharing information.
5. Once standards prove themselves, and ecosystems to test
and certify measure a mix of financial incentives and
disincentives for private sector could be considered.
Standards Roll-out and Adoption–The Steps
a. All centrally financed applications and software should
comply with these standards. This will be part of the
sanction of funds.
b. Specific proposals received to reengineer available public
health IT products to confirm to standards can be taken-up
on Case to case basis. Same would not be applicable to new
c. Adherence to standards- The MDDS committee may
consider accreditation and rate contracting suitable testing
agencies and only these may be allowed.
d. Creating Awareness- All major health IT symposia and
seminars to be covered to explain and popularise standards
so that industry voluntarily adopts the standards even solely
for private purposes.
Standards Roll-out contd..
e. Standards Updation- Suggestions, complaints, technical
snags should be conveyed to secretary of the MDDS
committee (email@example.com). (Reply to each of these
queries within a one month time standard).
f. Any modification would be notified on the website of
MoHFW, NHSRC and the main portal of the standards.
g. MoHFW would facilitate integration where requested.
h. Exchange between state financed and central financed
systems desirable- not mandatory.
National Health Information Authority
• Testing &
• Identify gaps
• Help lines
The Structure & Function
Health IT Forum
• Solving the semantic barriers brings inter-
operability much closer, but there would be still
challenges to face.
• EHR standards and MDDS publication is thus
the first step of a long journey
….. not its final destination.
• We- in the MDDS committee- gratefully acknowledge the
contributions of all our technical partners especially the work
UNITED HEALTH GROUP & TAURUS GLOCAL
• We also acknowledge the contributions of technical experts in
NIC and NHSRC who co-ordinated and contributed to this
• And of many many others- with apologies for not naming