Health Delivery Information Systems (HDIS) provide applications and software to record and manage healthcare data for every patient encounter. The document discusses designing a scalable and standards-based HDIS, including implementing it using a microservices architecture approach adhering to design principles from the National Digital Health Blueprint. Key elements include using interoperability standards, a mobile-first design, and building modules focused on core functionality for initial implementation.

1. Health Delivery
Information
Systems

2. Health Digital
Powering Future of Healthcare
Agenda
1
1. Introduction to Health Delivery Information Systems
2. Designing a scalable and standard Based HDIS
3. Implementation of HDIS
4. Change Management (CAUSE Methodology)

3. What are Health Delivery Information
systems?
Definition:
Applications or a computer software that are used to record and manage health
care data for every patient encounter during delivery of care grouped under the
term Healthcare Delivery Information Systems (HDIS).

4. 4
Hospital information systems market is
fragmented and processes are broken
• Tier I – iSoft, TrakHealth - left the market
• Tier – II – TCS, Wipro, Religare – shut
shop
• Tier – III – Akhil, Srishti – struggling with
client-server technology
• Digital Start-Ups – well funded but lack
size and scale
• Provider IT lacks standards
#Primary Interactions with Practo, Akhil Systems, Beato, CallHealth, Elseiver, Ohum

5. Products Offerings Digital Health Implication
Mfine Teleconsult platform
AI-based triage offering that helps the platform digitize
doctor-patient trust
SevaMob Teleconsult platform and asset lite pop up clinics
A good mixture of cyber-physical primary healthcare system
that leverages AI
Karma
Healthcare
Teleconsult platform led by a nurse at the patient side
A vertically integrated provider with teleconsults, physical
clinics and pharmacies. Have built a PHR/EHR platform.
Presence in 17 centers in 2 states
Medcords Aggregating rural healthcare capabilities Converting pharmacies into e clinics
MyUpchaar
Teleconsult and Rural Healthcare and Health Information
network in 13 Indian languages
Regional language based healthcare OTT content that is
validated by doctors is an important offering. Think of them
as an Indian WebMD.
Jiva Healthcare
Ayush based teleconsult and health e-commerce Vertically
integrated with manufacturing, supply chain, doctors and
clinic network
250 doctors are available on their tele-consultation platform.
Approximately 8k consults a day
Healthmir
Built AI-based health chatbot, with proprietary health content
created in association with a network of hospitals and health
experts
App-based healthcare model that focused on Indianized
content and virtual GP facetime
Nirog Street Ayush based teleconsultation and health e-commerce
App-based healthcare model that focused on chronic and
lifestyle diseases via Ayurveda
CURRENT DIGITAL HEALTH START UP
ECOSYSTEM

6. 6
HDIS SOLUTIONS IN THE MARKET
*Shortlisted by Strategy
Council Digital Health Panel
(Dr R Balaji – Ex CIO HCG, NH,
Parkway, Dr Pankaj Gupta -
Access Health, Dr Rajesh
Gupta – GM IT Medanta, JP
Dwivedi – CIO Rajeev Gandhi
Cancer, Priyanka Yadav –
Access Health)
PRIMARY CARE
• Practo Atom Ray
• Napier iLTC
• DocEngage
• LiveHealth by AdvancedMD
• My Healthcare
• DrApps
• myKlinic
• Akhil Systems
• CareXpert
SECONDARY & TERTIARY CARE
• iSoft’s Lorenzo
• TrakCare by InterSystems
• TrioHIS by Trio Tree
• SRIT
• HINAI by ICT Health
• Miracle Suite by Akhil Systems
• PARAS by Srishti
• Napier HIS
• MedMantra by TCS
• Insta, Qikwell by Practo
• Medica by UBQ
• Amrita Software
• Lifeline Suite by Manorama Solutions
• Palash
• Mediware by Datamate InfoSolutions
• APEX Enterprise HIS by 21 ci

7. 7
Public Health
Outreach
Health Delivery Information Systems (Public/Private)
Registration
Billing
ADT
Nursing
EMR
Emergency
Outreach
Module
LIS
RIS
Pharmacy
Diet
Inventory
CSSD
Treatment
Room
Specialty
POC
Diagnostic
OT
Blood bank
Telemedicine
Hospital
Accounting
Therapy
The blue blocks above are representation of functionality sets (also known as Modules) within HDIS universe. All these modules are required functions that any healthcare
ecosystem will need. There can be more modules but these are the minus that must exist in healthcare sphere. These modules caters not only the hospitals but also public
health delivery centres like PHCs, SCs, HWCs, Dispensaries, Pharmacies of private etc. But a PHC might not need full set of modules rather a subset of these modules.
HDIS Modules at a Glance

8. Challenges

9. 9
Holistic Enterprise Architecture Led Transformation is an Approach for Future
Senior Leadership has to often put significant efforts
to further gather and organize information for making decisions!
Siloed Systems
Low
interoperability
Little system
flexibility for
quick change …
One Citizen –
Multiple
Government
Experience
Current Landscape| While we have developed several systems to
automate, key government processes, resulting landscape is far from
optimal

10. HEALTH IT APPLICATIONS IN SILOS
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
Directorates
Center
Ministry
District
Admin
State HQ
IDSP
National
Disease
Program
Malaria
National
Disease
Program
RNTCP
National
Disease
Program
Web
portal –
Reprod.
& Child
Health
System
at
National
Level
Private
Sector
o Local Identifiers- Lack of Global Unique identifiers for person, provider, facility and health workers
o Standards lacking –
o Architecture, I/O
o Data and interoperability standards
o Semantic mismatch of concepts- Lack common meaning of data across systems

11. 1
Healthcare
Delivery
Information
System
INERTIA TO CHANGE
NO INCENTIVES
LOW DIGITAL LITERACY
LEADERSHIP BOUND
MANDATED
REPORTING
NAMESAKE
REGULATIONS
USER UN-
ACCOUNTABILITY
People Process Technology
HIGHLY COMPLEX
INEFFICIENT DESIGNS
NO STANDARDS
CUSTOMIZED THAN
CONFIGURED
*There has been only piecemeal development of management,
institutions & people over time
Built but not adopted

12. Health Digital
Powering Future of Healthcare
Agenda
Designing scalable, configurable
and interoperable HDIS
1

13. NDHB- Building Block integration in HDIS

14. Key Design Principles as per NDHB
• Registries as Single
source of truth for data
• Mobile First Design
strategy
• Open standards based
Building blocks
• Interoperability
• Minimalistic Design with
Scale Fast Approach
• Patient control over his
records
• Continuum of care
• Health Data fiduciary
at local and state
levels with central
Data lake for indicators
• EHR and PHR for
Health data exchange
• FHIR based open API
for interoperability
• Unique Identification of
entities
• Common meaning of
data
• API based model
• Domain driven design
based decomposition of
business concerns
• Scalability, Maintainability,
Resilience, Loose
Coupling by design
• Continuous Delivery and
light container (Docker and
Pods) based Deployment
(easy DevOps)
• Easy integration with
existing Monoliths
• Data Privacy, security and
integrity by design
• Controlled Data Visibility
and Consent Based Data
Sharing
• Data Provenance
• Physical security
• Network security
NDHB Design
Principles
Federated
Architecture
Microservice
Architecture
Privacy &
Security
Ensure Compliance by conducting a Standardization Testing and Quality Certification (STQC) or
STQC like audits

15. Purpose Recommended Standard
Consent Management ISO/TS 17975:2015 Health Informatics - Principles and
Consent Framework Electronic Consent Framework (Technology
Structured Clinical information
exchange
FHIR Release 4 (subject to section 3.4.2) (with any future
errata(s))
Still Images / Documents Audio /
Video
Still Image: JPEG Document/ Scan: PDF A-2 Audio: MP3 /
OGG Video: MP4 / MOV (embedded as Binary Content in
relevant FHIR resource)
Diagnostic Images (Radiology
including CT, MRI, PET, Nuclear
Medicine / US / Pathology),
Waveforms (e.g. ECG)
DICOM PS3.0-2015c (embedded as Binary Content in
relevant FHIR resource)
Terminology/ Vocabulary
SNOMED CT- (for all clinical terminology requirements in
health records)
Coding System
WHO ICD-10- (for statistical classification of diseases and
related health problems)
LOINC-(for observation, measurement, test-panels, test
items and units)
Security Digital Certificate, TLS / SSL, SHA-256, AES-256
Access Control
ISO 22600:2014 Health informatics - Privilege
Management & Access Control (Part 1 through 3)
Should follow minimum standards
recommended by NDHB

16. Should have placeholders for unique Identifiers that will be generated and maintained
Nationally.
Unique Identifier
Facility
Provider
Personal Health
Identifier (PHI)
Health
Worker
• As per NDHB, every healthcare
stakeholder/ entity will be identified
uniquely
• Govt. will develop and implement these
registries and every stakeholder should
connect to these for an integrated and
interoperable healthcare ecosystems
Minimum National Identifiers

17. 1
7
Add - on Modules
Registration
EMR
ADT
Billing
Outreach
LIS
RIS
Pharmacy
Modules for Health Delivery Information System (HDIS)
The green blocks above are representation of functionality sets (also known as Modules) within HDIS universe. All these modules are
required functions that any healthcare ecosystem will need. There can be more modules but these are the minus that must exist in
healthcare sphere. These modules caters not only the hospitals but also public health delivery centres like PHCs, SCs, HWCs,
Dispensaries, Pharmacies of private etc. But a PHC might not need full set of modules rather a subset of these modules.
Core Modules for MVP
Appointment
Telemedicine
CSSD
Emergency
Diet
Inventory
eObject
Surgery Mgmt.
Blood Bank
Nursing
Alert & Reminder
Primary, Secondary, Tertiary

18. Interoperability built into design through standardized
master data for the Nation (MDDS)
DATA
ELEMENT
XXX
DATA TYPE,
DATA SIZE,
VALUE SETS,
CODE DIRECTORIES
META DATA AND DATA STANDARDS FOR HEALTH
1. Library of 1000+ Data Elements,
2. 140+ Code Directories
3. Registry Design
*Notified standard since Aug 2018
MDDS- Common Master Data set for India for semantic interoperability.
Common meaning conveyed by different code sets
Gender பாலினம்
HDD
System 1 System 2
ल िंग

19. Configurability Built into application
design – Microservices Architecture
Loosely
Coupled
Fine
Grained
Lightweig
ht
SOA
variant
Highly scalable,
resilient and
Configurable Design
Web/mobile/IOT Devices
Type
Format
Size
Registration
service
Visit Mgmt Service
Ordering Service
Rest API
(Req/Response)
API
Gateway
Microservice Architectural style is an approach to
developing a single application as a suite of small
services, each running in its own process and
communicating with lightweight mechanisms, often
an HTTP resource API.
Rest
API
Rest
API
Rest
API
Decomposition of
Business Concerns
based on DDD Principle

20. 2
0
DATA ELEMENTS >> MICROSERVICES >> HDIS
MVP
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
MICROSERVICES
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
MICROSERVICES
MODULES
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
DATA ELEMENT XXX
MODULES
HDIS MVP

21. 2
1
PRIMARY
CARE
Register
Patient
Registration
Module
Billing
Module
Generate Bill
Bill Collection
Eg:- HDIS MINIMUM VIABLE PRODUCT - DATA SETS FOR
PRIMARY CARE
Let's take example of two
modules. Within
Registration Module there
are many functionalities
mentioned above. Likewise
Billing module also has
many functionalities. So for
a Primary care there is
functionality bundle that
comprises of all the
functionalities that caters
services of a typical Primary
care. This set differs from
the set required by another
facility as services defines
the level of functionality
needed per module.

22. 22
Bill Generation Type
Bill Date
PRIMARY
CARE
Register
Patient
Registration
Microservice
Billing
Microservice
Generate Bill
Bill Collection
Patient UID
Patient Name
Payment Type
REST API
REST API
API
GATEWAY
HDIS MINIMUM VIABLE PRODUCT – DOMAIN DRIVEN
MICROSERVICES

23. 23
Insurance Policy ID
Bank Account No.
Bill Generation Type
Bill Date
PRIMARY
CARE
TERTIARY
CARE
Register
Patient
Payer
Details
Registration
Microservice
Billing
Microservice
Bank
Details
Generate Bill
Bill Collection
Bill Discount
Patient UID
Patient Name
Payment Type
Discount
REST API
REST API
API
GATEWAY

24. Design that is user friendly and facilitates
Adoption
Design an application that helps in reducing the end user burden than
increasing it.
Clinically Rich Application that
aids decision making
Intuitive User Interface Minimal clicks, typing and
scrolling
a.Order Sets,
b.Favourites etc
User Configurable UI
a. Form builder
b. Specialty based templates
a. Configurable Rule Engine
b. Standard Treatment
Guidelines

25. Provider E-Objects and
Envisioned EHR Framework
(NDHB)
For structural interoperability across facilities

26. Visualising the National Health Ecosystem
National Health
Claims Platform
National Health Registries (Providers, Doctors, Beneficiaries, Health ID, etc.)
eHospital
s
NCD
Other
Health
Apps
India Stack
Aadhaar, Mobile
Federated PHR
Framework
National Health
Analytics
Platform
National Health
Upskilling
Platform
PMJAY
Specific
Application
s
Existing
State
Insurance
systems
Health and
Wellness
Clinics
2.7 2.8 2.9 2.10 2.11 2.12 2.13

27. How does the proposed EHR work?
Health ID and
Consent from
user
PHR
(real-time data aggregation)
Hospital
Diagnost
ic lab
Clinic
Health
Data
Access
Fiduciaries
(HDAF)
Health Data stays with providers (or TSPs) and is
pulled together on demand with consent into a
longitudinal record
• Providers integrate with
HDAFs using std Open APIs
• Documents use embedded
schemas - Initially we expect
items already digitized and
currently given to patients
• Diagnostic reports, Discharge
summaries. Over time -
prescriptions, primary care
encounters will come in
2.7 2.8 2.9 2.10 2.11 2.12 2.13

28. What are e-objects
Address
To and
From
Policy Details
Package Details
Diagnosis Details
Claim amount Details
NDHB and
MDDS
Compliant
E-object is like an
Envelope with machine
readable letter inside it
 Standard Format
 standard value sets
 machine-readable
 Interoperable
Header
Segments –
Standard and Custom
MDDS based metadata
Header will contain Unique
identification of all the
parties involved in the
transaction or episode
Segments will be specific
to the e-object type and
will group various
informative data elements
together. Eg: Facility
Details or Patient
Demographics etc
All the data elements and
code directories or value
sets used in e-objects will
be taken from MDDS
standard.
JSON
based
Object
FHIR R4 –
messaging
standard

29. Provider E-Objects
Header (Information about facility,
provider and beneficiary/patient
Clinical Brief(Active Allergies,
Active complaints, comorbidities,
Active Diagnosis),
Prescriptions (Ordered Rx, Labs
with result, Procedures)
Doctor’s Advice for
admission/follow up
• E-ENCOUNTER NOTE
• E-PRESCRIPTION
• E-REFERRAL
• E-DISCHARGE
2.7 2.8 2.9 2.10 2.11 2.12 2.13

30. Header (Information about
facility, provider and
beneficiary/patient)
Clinical Brief(Active
Allergies, Active complaints,
comorbidities, Active
Diagnosis),
Prescriptions (Ordered Rx,
Labs with result,
Procedures)
Doctor’s Advice for
admission/follow up
E-PRESCRIPTION/ENCOUNTER
OBJECT
ACCESS Health [Prof Dennis Straveler and Dr Pankaj Gupta] first wrote the concept of eObjects in NITI Aayog Theme papers,
Health System for a NEW India: Building Blocks, Delhi, India, 2019.

31. Header (Information about
facility, provider,
patient/beneficiary, referred
facility ID, Referred Provider
ID)
Clinical Brief (Relevant visit
details)
Prescriptions (Ordered Rx,
Labs with result,
Procedures)
Referral Note
E-REFERRAL OBJECT
ACCESS Health [Prof Dennis Straveler and Dr Pankaj Gupta] first wrote the concept of eObjects in NITI Aayog Theme papers,
Health System for a NEW India: Building Blocks, Delhi, India, 2019.

32. E-DISCHARGE SUMMARY OBJECT
Header
Pre-auth ID Health Plan ID/code
Pre-auth Status Policy no./Health Card
no.
Patient UHID (NDHM) Referring Physician ID
Unique Facility
Identification Number
Beneficiary ID
Payer ID E-prescription ID
Or e-referral ID
Header
Relevant clinical history (
Co-morbidities or
secondary diagnosis)
In-hospital treatment
details (services)
Discharge Details
ACCESS Health [Prof Dennis Straveler and Dr Pankaj Gupta] first wrote the concept of eObjects in NITI Aayog Theme papers,
Health System for a NEW India: Building Blocks, Delhi, India, 2019.

33. Proposed Health Information Network
1.1 1.2 1.3 1.4 1.5 1.6
Facility1 Facility2 Facility3 Facility1 Facility2 Facility3
Block1 Block 2
Nutrition
National
Reproductive
& Child
Health Portal
National
Disease
Programs e.g.
Malaria,
IDSP, NACO
Hospital
Information
Systems,
EMR
State Health
Programs e.g.
EMRI,
eMamta,
HMIS, DHIS
Birth,
Deaths
Private
Sector
HDD (Co-Directory
lookups)
Registry
Lookup APIs
MDDS ~ concept
translation layer
Terminology
lookups
E-Object
Modellers
FHIR
APIs
State Health Information Exchange
Data Lake
Disease
Registry
State
Registry
Indicator
Registry
Payment
Registry
Patient
Registry-UID
Service
Registry
Patient
Private and Govt. e.g.
NHPS, ESI, PM-JAY, JSY
Payers
Providers
Private
Sector
MOHFW
District
Admin
State
HQ
Reprod.& Child
Health
Directorates e.g.
Malaria, IDSP, NACO
Claim
portal
Block 1

34. Implementation Methodology
for Health Delivery Information
System

35. Understanding Client’s
Requirement
Solution Mapping
Configure Application
Standardize Master
Data
Black Box Testing
Key User Training & UAT
Go-Live Plan
Go-Live & Support
CHANGE
MANAGEMENT
Steps to successful HDIS Implementation

36. Requirement Gathering
Get it right the first time !
*Never forget to take a documented formal sign off from the customer on requirement
Technical
Rqmts
Business Vision
& Goals
Clinical and
Admin Rqmts
Phase I - Assessment

37. Requirement Lifecycle

38. Detail out Solution architecture
Solution Framework
User
Interface
PATIENT
TRACKING
Output
Reports
ERP
[HR, FIN]
PATIENT
CENTRIC
CARE
ALERTS
MGMT
HIS + EMR
CLINICAL
PATHWAYS
REPORTING
mHEALTH
PHYSICIAN
PORTAL
Third Party
Apps
LIS, RIS, PHARM
-
MATERIAL
MANAGEMENT
PATIENT
PORTAL
SCHEDULING
SYSTEM
BIOMETRICS
SOCIAL
MEDIA
3 – 6 months
6 – 12 months
1 – 2 years
INTRANET
SOLUTION COMPONENT INTEGRATION

39. Requirement Prioritization
Prescribed
Medicines
Lab
Results
In-Patient
Records
Out- Patient
Records
Single
Sign-On
Database
Integration
Reporting
HIS + EMR
Patient
Portal
Physician
Portal
Base HIS
Single
Sign-On
Schedule
Visit
Drug
Information
Lab
Results
CPOE
Phase I Phase II
High ROI on
Low Complexity Left
Moderate ROI and
High Complexity Right
Solution Framework Phasing of the components of the IT solution will be done based upon ROI and
complexity

40. Solution Mapping & Sign-Off
Solution Mapping is done after identification of customer’s problems and
prioritized requirements.
1. Map client specific functions with standard product
functions and features.
2. Map specific requirement with configurable functions
& features.
3. Custom develop (Code) functions to provide solution.
to client’s custom requirements or exceptional scenarios.
4. Define As-Is and To-Be Process.
5. List down and design business specific reports and indicators.
6. Get a solution mapping sign off .

41. Standardized Master Data
Master Data- Data that remains constant or doesn’t change often
which is required to facilitate transactions in an application.
Eg: List of Doctors working in a client hospital.
One stop solution for repeated master data creation and upload for every new
customer
MDDS Implementation

42. Configure Application as per solution
mapping
Client specific workflows
Client specific Rules
Client specific Price Master
Develop any custom requirement
Configure or design client specific forms or templates

43. Functional or Black Box Testing
(Business Analyst)
1. Build story boards and Testing scenarios
2. Internal Testing
3. Course correction if any

44. Key user Training and User acceptance
Test

45. Go-Live Planning
1. End user Training Plan
2. Pilot Testing (Load balancing)
3. Parallel Run
4. Risk Mitigation plan and support in case of
application/function failure
1. Big Bang or Module wise
2. Post Go-Live support Plan

46. Go-Live support

47. Change Management- Key to successful
Implementation
Boot-strapping healthcare organisation change
management
CAUSE methodology
CAUSE methodology for managing change in
people, process and technology.
•Consciousness of need to change
•Aspiration to support change
•Understanding how to change
•Strength to over come hurdles and implement
change
•Ecosystem to support, sustain and adopt
change
Smooth transition from
current to optimal state
47
CAUSE
METHODOLOG
Y

48. CAUSE Methodology – change Management
CONSCIOUSNESS OF NEED TO
CHANGE
ASPIRATION TO SUPPORT
CHANGE
UNDERSTANDING HOW TO
CHANGE
STRENGTH TO OVER COME
HURDLES AND IMPLEMENT
CHANGE
ECOSYSTEM TO SUPPORT,
SUSTAIN AND ADOPT
CHANGE
PEOPLE
It is important for the CxO to
communicate the ‘Need to
Change’. The people must be
informed by the Head of the
organization again and again
until they are very clear in their
mind about why the change is
coming.
Leader of the organization and
every Dept Head needs to lead
by example i.e. he/she needs to
undergo the full training first and
demonstrate that he can adapt
and adopt the new process and
technology.
Identify Champions from the team
who demonstrate the competence
to learn the new process and
technology.
Build Trainer pool by Train-the-
Trainer concept
Institutionalize informal learning by
Buddy system. Pair a Champion with
a person who needs extra help.
The major hurdle can come
from “People” as they are
the one who are most
affected by the process. Top
management should be
ready to cope up with the
hurdle and internal
resistance from this group.
Constant hand holding and
support is required till the
people genuinely start
relying on each and the new
systems and processes.
External support can be
withdrawn once this
ecosystem is built.
PROCESS
The CxO must inform the team
that it is not just an IT project
but many processes are going to
change. Infact it is an
opportunity to redefine and
improve the existing processes.
Get into a mode of continuous
process improvement.
The organization must Aspire to
support changes in processes.
Since the organization is going
through a transition this is an
opportunity for the organization
to define processes across the
organization.
Train the team on new processes
extensively, again and again till it
becomes second nature to them.
Check for gaps in process
knowledge between expected and
achieved.
It’s important to realize that
processes will break and
problems will happen when
such a major
implementation is done.
Trick is to recognize the
problem areas before it is
too late to avoid big
failures.
The top management needs
to keep clearing the bottle
necks till all the processes
are stabilized and the
ecosystem takes over the
self management of the
processes.
TECHNOLOG
Y
The CxO must inform the team
that existing technology tools
will be phased out and the better
technical solutions will be
brought in. This is required
because the current IT systems
are not geared to support the
massive growth plans of the
organization.
The organization must Aspire to
support changes in technology.
CxO needs to create a positive
Buzz about the technology
changes. Once people are aware
that technology is there to help
them, they’ll easily accept the
technology change.
Train the team on new technology
extensively, again and again till it
becomes second nature to them.
Use Carrot and Stick approach to
motivate people for undergoing the
training and learning the new
systems
It’s important to realize that
system will breakdown and
problems will happen when
such a major
implementation is done.
Trick is to recognize the
problem areas before it is
too late to avoid big
failures.
Lot of support is required in
terms and hand holding and
training till the Technology
gets adopted by the users
and is irreversibly
embedded into the
ecosystem.

49. Thank You!