Preliminary Findings of Study on “ Policy issues for e-Health in Bangladesh ”

1. Preliminary Findings of Study on “Policy issues fore-Health in Bangladesh” Prepared by iStrategy Ltd. with support from Bangladesh Enterprise Institute (BEI) Sponsored by Rockefeller Foundation

2. Background • iStrategy and BEI were given the task to conduct the following: • Critical analysis of the current e-Health and HIS scenario in Bangladesh • Identify policy-level issues that need prioritization • This presentation is based on some results of that study

3. Agenda • Proposing realistic goals for HIS and e-Health in Bangladesh • Policy issues that need to be addressed for attaining those goals in the context of local realities and global experiences • A proposed phase-wise approach towards those goals

4. Purpose • Incite discussions and debates – not to suggest that there is only one way of looking at things • Part of an on-going exercise to bring out the policy issues that need attention

5. Setting Goals for Stronger HIS • Moving gradually from “integrated” system thinking to “inter-operable” system thinking • Moving gradually from aggregated data to individual-based data in electronic form • Using open standards to avoid lock-in and keeping flexibility for customization as needed • Focusing on “requirements specifications” and design before developing information systems

6. 1. Managing Identities

7. Managing Identities • The fundamental pre-requisite of a health system • Issues for MoHFW: • Health Service Provider Identity • Organization • Individual • Service • System user’s ID • Patient ID • Inter-ministerial issue: • Geo Location Code: Address and location

8. Managing IDs – Current Status • Unique universally accepted IDs for: • BMDC registration no for Physicians • Drug License • Hospital License • Medical College License • License for nurses • Issues that we don’t have unique IDs across systems for are: • Service ID • Health Indicators ID • Diseases ID • Patient ID • System User’s ID • Risk factors ID

9. Potential Consequences of not having IDs • Data from different systems cannot be aggregated • Data can never be normalized in a single data dictionary • Data exchange can be very expensive and time consuming • Like developed countries, data can be locked in several silos and never being used across the systems, expensive adaptors are taking place for data interchange

10. Managing IDs – global example • Australian ID standardization

11. Implementation Issues • Unique ID system for every patient in the context of Bangladesh is a huge challenge and will take time to be developed • However, many of the other IDs are more doable and can provide a basic platform for taking HIS to next level • Short to medium term: • IDs for health-service providers – individual and organizational, services, geo-locations • Long term: • Patient ID

12. 2. Privacy and Confidentiality

13. Privacy and Confidentiality • Setting rules for ‘governance of data’ is absolutely critical for designing an HIS • Who owns data? • Who has access to what data? • Specially important for public-private collaborations and data sharing • Consent of the patient regarding use of data

14. Privacy and confidentiality – current status • In practice, patient-doctor confidentiality is maintained by doctor himself • Scope for improvement in the Privacy Act in Bangladesh being made more relevant for medical field • No rules yet for ownership and access of data

15. Potential consequences of not having privacy and confidentiality rules • Critical to designing of health systems • Defining the role of each user of the system • Defining access control • Designing security standards • Without these, system development can be haphazard and adhoc – leading to expensive upgrades and changes later on • Citizens will not be comfortable in letting their data to be digitized

16. Privacy and Confidentiality: global scenario • Every e-Health policy and guideline has privacy and confidentiality • Example: HIPAA (Health Insurance Portability and Accountability Act) • provides federal protections for personal health information held by different entities • gives patients an array of rights with respect to that information.

17. Privacy and Confidentiality - Implementation Issues • We need to distinguish between individual and aggregated data since the former is much more sensitive • We can start with issues around aggregated data first • Short-to-Medium Term: • Regulations may be passed by the government regarding: • Ownership of health data • Access rights of health data • Security standards that need to be maintained by health systems • Long Term: • Deal with sharing of individual-level data • Patient’s consent

18. Reporting Standardization

19. Reporting Standardization • National Level Reporting • Governmental organizations reporting to higher authority • NGOs and private health-facilities reporting to the government • International Level Reporting • WHO • Health-related donors

20. Reporting Standardization – current status • National-level reporting: • Within MoHFW • Some standards such as those proposed by HMN, UN and Paris 21 declaration are used • However, standards that can be used across systems are yet to be defined • Collected manually, aggregated and sent through Excel spreadsheets • Entered in DHIS from different districts • Some of the comments that have come from the workshops: • Duplication in report generation • Aggregation across departments is often not possible • For many organizations, there is no reporting software – it is done manually and the results entered in Excel formats • Inter-ministry • Adhoc as needed • NGO/private sector reporting to MoHFW • Adhoc as needed • International reporting: • According to requirements of individual donors • Varies from project to project • Significant scope for standardization across projects

21. Potential consequences of not standardizing reports • Aggregation is not easily possible • For instance: Very difficult to track MDG goals effectively at national level • Costly and time consuming • Expensive adapters and mapping mechanisms may be required for aggregation

22. Reporting standardization – global practices • WHO Indicator and Measurement Registry (IMR) • Central source of metadata of health-related indicators used by WHO and other organizations • It promotes interoperability through the SDMX-HD indicator exchange format

23. 4. Enabling Standardized Data Entry

24. Enabling standardized data entry • Standardized entry of diseases, signs and symptoms • Standardized entry of patient data at: • Facility-level • Community-level

25. Enabling standardized data entry – current status • Public sector • Facility-level: • Aggregated data from record rooms at some hospitals are digitized and sent through Excel sheets or entered in DHIS • DHIS indicators are not standardized across systems but it has provided a solid foundation for further work • Community-level: • Data collection is done manually and aggregated manually, which is digitized at district levels • NGO sector • Each NGO has their own way of inputting data – no standardization • Private sector • 2 or 3 top private hospitals are found to be using ICD-10

26. Enabling standardized data entry: Implementation issues • ICD10 (International Classification of Diseases) • Coding of diseases, signs and symptoms, abnormal findings, complaints, social circumstances and external causes of injury or diseases • SNOMED (Systemized Nomenclature of Medicine) • Wider coverage than just diseases, including findings, procedures, microorganisms, pharmaceuticals etc. • Licensing involved • Less uptake than ICD10 • Short term: • Standardized digitization of aggregated data from record rooms at facilities • Standardized digitization of aggregated data coming from community level • Mid-term: • EMR for community level intervention based on remote feedback from doctors • Long term: • EMR at hospitals

27. Enabling standardized data exchange

28. Enabling standardized data exchange • Data may be entered in numerous ways and we cannot change those, we cannot change legacy systems already in place • What we can do is have a standard for exchanging of data • If the standards for data entry are not followed as discussed earlier, then aggregation will not be possible automatically

29. Enabling standardized data exchange – current status • Within MoHFW • Different projects have their own MIS –no interchange of data between systems • Between private sector and government • Adhoc as needed • Some comments from the workshops: • Private sector is willing to send data if there is a specific format for exchange is given to them

30. Scenario at Public Hospital

31. Scenario of selected private hospitals

32. Scenario of Projects Under DGHS

33. Scenario of some selected NGOs

34. Enabling standardized data exchange – implementation issues • HL7 • Also a messaging protocol • Much more extensive than SDMX-HD • Covers standardization in different workflows in the continuum of care – starting from billing to patient tracking • Country membership based • SDMX-HD • It is not about data entry or data storage format • SDMX-HD messages are defined for the process of exchanging indicator definitions and aggregate data and metadata

35. Enabling standardized data exchange – implementation issues • Short term: • Standardizing the format for data exchange with respect to indicators and IDs • Mid to long term: • Standardizing data exchange and inter-operability • Standardization for privacy and security during data exchange and inter-operability

36. Enabling standardized data exchange – global practices • For individual-level data, HL7 messaging format is often used • For aggregated data, SDMX-HD is being increasingly used because of its simplicity compared to HL7 • Use of software that already has SDMX-HD standards: • OpenMRS adopted by more than 50 countries

37. Going beyond data exchange • Getting data by querying into other information systems • Service Oriented Architecture (SOA) approach

38. Going beyond data exchange – current status • In the government: • SOA-based approach is not prevalent yet • In the private sector: • Sporadic instances • Example: inter-operability within different systems of BRAC

39. Potential consequences of sole dependence on data exchange • It is not feasible for everybody to have every data. • Systems cannot share functionality • Redundant data storage • Costly • Data integrity • Not taking advantage of “starting late”

40. Proposed Implementation Phases • Phase 1: Building on already developed foundation • Phase 2: Basic Inter-operability • Phase 3: Advanced Inter-operability

41. Phase 1:Building on already developed foundation • Form a high level steering committee for the following: • Identity Management of Health Service Providers, Locations and Services. • Role Based Privacy and Confidentiality Rules (like HIPAA). • Use a terminology standard ICD10/SNOMED during data entry before sending to the accumulation point • Implement regulation for Data interchange • Develop standardized formats for data interchange • Enterprise service bus (developed by A2I)

42. Phase 2: Basic Inter-operability • Digitization of record room (aggregated data) • Implementation of ICD10, SDMX-HD • Major private hospital and major NGOs involved in data interchange according to standardized formats • Shared registry of National level health information (building on NPR) • Implementation of privacy and security guideline (like HIPAA) • First steps towards EMR at health-facilities

43. Phase 3: Advanced Inter-operability • Identity management of patients • Roll out of EMR at health-facilities • Interoperability in HIS • SOA based- hub and spoke model • ESB based