The document describes the development of metadata and data standards for the health domain in India by the Health MDDS Domain Committee. The committee was formed to promote interoperability across health IT systems. It identified over 1000 common data elements across 39 health entities. It defined the data elements and established 111 code directories derived from global clinical coding standards. The standards are intended to enable integration and information exchange between existing fragmented health IT systems in India.

1. Meta Data & Data Standards for Health
Domain
Dissemination Workshop
12th December 2013

2. • Initiated under National e-Governance Plan (NeGP) by DeitY.
• Aims to promote- e-Governance by making systems speak to
each other.
• Domain specific committees constituted –Health MDDS
Domain committee constituted on Sept. 2012.
– Chairperson - Joint Secretary (Policy), Sr. Technical Officer (NIC) as
member-secretary.
– 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
experts, NIC,
Meta Data & Data Standards- The Initiative

3. 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
Indian standards.
3. To develop own standards / extension of global standards in
Indian context, wherever required, around policy on Open
Standards,
(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

4. 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
Government level.
6. To advise for identification of suitable test suits for
conformance testing of the implementation.

5. • Malaria Control
• State Health Management Information
Systems- In seven States with Hospital
Information Systems.
• Routine Immunization Management Program
• Sporadic use in Medical College Hospitals
The first generation IT systems are characterized
by low expectations, effectiveness and
complexity..
The 1st
Generation
Systems
(1993–2005)

6. • The National Health Management
Information System- common Web- Portal
with entry-
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
records.
9.Financial Transaction Recording Systems
10.Major initiatives in Tele-medicine.
11.Mobile Health , Insurance etc etc.
2nd
Generation
Systems
National Rural
Health Mission
Catalyzed

7. 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
systems.
• 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 ???

8. BUT the problem : All Public Health IT Systems in silos
Nutrition
Block
Facility
MCTS –
Reprod.
& Child
Health
System
at
National
Level
NACO
National
Disease
Program
Hospital
Informati
on
Systems,
EMR
State
Health
Program
s e.g.
EMRI,
eMamta,
HMIS,
DHIS
Birth &
Deaths
Private
Sector
MOHFW
District
Admin
State HQ
Directorates e.g.
Malaria, IDSP, NACO
IDSP
National
Disease
Program
Malaria
National
Disease
Program
RNTCP
National
Disease
Program
Web
portal –
Reprod.
& Child
Health
System
at
National
Level
o Every program/ state develops own IT solutions. States have 10 to 30
systems
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.

9. Importance of Inter-operability
realized.
• In Public Systems:
– To reduce work load in data recording and
entry.
– 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
settlements:
3rd Phase-
(2012
onwards):
From IT
Systems to IT
Architecture…
.

10. Three Levels of Interoperability:
MDDS Builds Semantic Operability
Institutional
Interoperability
Syntactic
Interoperability
Semantic
Interoperability

11. The Process
 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

12. The Output
MDDS
Report
Name Description
Part I Overview Report •Design Principles - Semantic Theory & its
application in Health Domain
•Roll-out mechanism, Institutional framework.
•Integration Solutions.
Part II Data Element Quick
Reference
List of 1077 Data Elements with their
definitions and Values
Part III Code Directories •Code Directory List,
•Sample Values
•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
Bank etc.
•Some examples of data sets created form the
common data elements.
•Interim Measures
Integration & Upgrade as
per MDDS
•Integration Solutions for existing system-
HMIS-MCTS, DHIS-iHRIS
•MDDS Mapping with HMIS. IDSP & RNTCP
Systems
•Part II, III & IV and Annexure are in soft copy in CD.
•For online access visit- http://mohfw.nic.in, www.nhsrcindia.org

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

14. MDDS The Conceptual Design
Example-I
CONCEPTUAL DOMAIN
ENTITY (E.G. PHARMACY ORDER)
LIST OF VALUES
(BID, TID, QID,HS, STAT)
OBJECT CLASS
MEDICATION ORDERS
ATTRIBUTE
FREQUENCY
DATA ELEMENT
MEDICATION FREQUENCY
CONCEPT
FREQUENCY OF MEDICATION
VALUE DOMAIN
MEDICATION FREQUENCY
CODE DIRECTORY

15. MDDS The Conceptual Design
Example-II
Concept
Operational Status
of Facility
Value Domain
Operational Status
Value List
Conceptual Domain
Entity (e.g. Facility)
Object Class
Facility
Attribute
Operational Status
List of Values
Functional, Non-
Functional, Under
Repair , Closed,
Data Element
Facility Operational
Status

16. MDDS The Conceptual Design
Example-III
Concept
Health Condition
Code
Value Domain
ICD-10 Code
Directory
Conceptual Domain
Entity (e.g. Diagnosis)
Object Class
Health Condition
Attribute
Code
List of Values
ICD-10 Disease Codes
Pulmonary
Tuberculosis - Lab
Confirmed
Values: A15
Data Element
Health Condition
Code

17. MDDS The Conceptual Design
Example-IV
Concept
Scheduled
Ambulance Trip
Reasons
Value Domain
Medical Reason for
Scheduled Trip Code
Directory
Conceptual Domain
Entity (e.g.
Ambulance)
Object Class
Ambulance
Attribute
Scheduled Trip
Reasons
List of Values
Delivery, RTA, chest
pain, -drawn from
ICD and WHO
Data Element
Reasons for
Scheduled
Ambulance Trip

18. 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
Settings.
• 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.

19. Common Data Element - ENTITIES
Description of Entities
Entity
No. of Data
Elements
Entity
No. of Data
Elements
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

20. Common Data Elements: Snapshot
Entity- Diagnosis
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
Code
Varchar 10
05.020.0010 Present Health Condition Onset
Date
Custom
05.020.0011 Prognosis Integer 2

21. 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
Intervention (CCI)
CD05.056 WHO List for General Mortality WHO
CD05.059
WHO International Classification of Functioning,
Disability and Health (ICF)
WHO
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

22. Identity Management in Indian Health System
• Health information exchange between
systems through Identifiers
– Facility Identifiers (Unique Facility
Identification Number/Global
Unique Identifier)
– Provider Identifiers – Unique
Individual Health Care Provider
Number
– Patient Identifiers– UID/ Alternate
Unique Identification Number
– Disease Identifiers– ICD-10 Codes
– Service Identifiers– CCI Codes
– Document Identifiers– Document ID

23. Facility Identity Management
Unique Facility Identification
I. Facility Signature Domain:
– Unique Facility Identification
Number
– Global Unique Identifier
– Type of Facility
– Address
– Geocode
– Difficulty status- Easy/Difficult
– Rural/Urban Area
– Population covered
– Administrative linked parent
facility Type
– Operational Status
– Referral facility
– Ownership Authority & Type
II. Facility Services Domain:
– Facility System of Medicine
Type
– Facility Services Master
III. Facility Human Resource
Domain
IV. Facility Infrastructure
Domain:
– Facility Bed Master
– Facility Bed Type Master
Suggested Model – Central Model

24. 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
industry .
• 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
outcomes.

25. The Second Level of Interoperability:
Appropriate Integration Solutions will ensure Syntactic
Interoperability
Institutional
Interoperability
Syntactic
Interoperability
Semantic
Interoperability

26. Point-to-point Integration
 Pros
• Useful for all historical applications without much disruptive
changes.
• One eligible application can receive message from a source
application message channel.
 Cons
• Extra effort, time and cost to write Transformation logic for each
application.
• Semantic interoperability difficult to implement across different
applications.
<?xml version=“1.0” ?>
<Group group_id=1>
<dataelement>
<HMIS_dataelement>id=” M1|1.1” name=” Total Number of Pregnant Woman Registered for ANC”
Value”</HMIS_dataelement>
<MCTS_dataelement> id=“1” value=“100” isChild=”F”</MCTS_dataelement>
</dataelement>
<dataelement>
<HMIS_dataelement>id=” M1|1.1.1” name=” Of which Number Registered with in First
Trimester”</HMIS_dataelement>
<MCTS_dataelement> id=“2” value=“30” isChild=”T” Parentdataelement=”M1|1.1”</MCTS_dataelement>
</dataelement>
<FacilityCode> 00000000023</FacilityCode>
<FacilityType>”SC”</FacilityType>
<REPORTING_PERIOD> <TYPE>”Monthly”</TYPE> <FROM_VALUE>=”July 2013”</FROM_VALUE>
<TO_VALUE>=”July 2013”</TO_VALUE></REPORTING_PERIOD>
</Group>
Spaghetti framework

27. Broker-Based Integration
 Pros
• 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.
 Cons
• Data discovery at run
time based on a service
request is difficult.
• May lead to a highly
complex architecture-
difficult to maintain.

28. Intelligent Gateway
(Health Information Exchange)
• Better suited to
current context.
• Based on Registry
architecture
pattern.
• Allows to
dynamically
locate the data
records and the
application
locations.
• Integration with
other domain
applications is
quite easy.

29. Choosing Integration Options
If within range of Tower in
Mumbai Circle, it has a registry
lookup to connect the 2
o Condition - II
o Broker
Integration
• Condition - I
• Point to Point
Integration
√ Condition - III
√ Exchange
Integration
• 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
apps.
• If Time & Effort not a
constraint
• Scalable to any number of
systems.
• 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.
HOT Line
Roaming
Mobile from
Bangalore
Circle
Roaming
Mobile from
Delhi Circle
Trunk Dialing – Operator needs to
know where to route the call

30. 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:
Institutional
Interoperability
Syntactic
Interoperability
Semantic
Interoperability

31. Institutional Interoperability
 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
information.
 National Authority should be able to facilitate
this role.

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

33. 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
applications.
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.

34. Standards Roll-out contd..
e. Standards Updation- Suggestions, complaints, technical
snags should be conveyed to secretary of the MDDS
committee (mdds-mohfw@nic.in). (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.

35. Institutional Framework
National Health Information Authority
The Mandate
• Testing &
Certification
• Accreditation
• Compliance
• Update
• Upgrade
• Identify gaps
• Collect
Feedback
• Advocacy
• Capacity
Building
• Incentive
• Legislation
• Publish
• Disseminate
• FAQs
• Help lines
MAINTAIN FACILITATE
CERTIFYMANAGE
MDDS
Health Domain
Standard

36. The Structure & Function
The Mandate
Policy Formulation
Technical
Group
(4-5 Technical
Architect)
Functional
Group (4-5
Health IT
Professionals)
Management
Group
(4-5 Health
Mgmt
Professionals
Certification
Group
Core Groups
National Health
Information Authority
Core Functions
Health IT Forum
Academic &
Research
Institutions

37. Concluding Remark
• 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.

38. Thank You
• We- in the MDDS committee- gratefully acknowledge the
contributions of all our technical partners especially the work
of
UNITED HEALTH GROUP & TAURUS GLOCAL
• We also acknowledge the contributions of technical experts in
NIC and NHSRC who co-ordinated and contributed to this
process.
• And of many many others- with apologies for not naming
them individually…..