Showing posts with label ACCESS Health. Show all posts
Showing posts with label ACCESS Health. Show all posts

Sunday, July 26, 2020

AHD ACADEMY: DIGITAL HEALTH 101










Digital Health 101 is a basic course from AHD Academy. It is meant for Digital Health Students and Professionals working in Providers, Payers, the IT Department of Healthcare organizations, building Digital Health products, or engaged in Digital Health Transformation projects.

It is an 80 Hour course either full-time or spread out. It is free, learn at your own pace. You may contact your College, University, Organization for moderated sessions on these Digital Health topics.

LESSON 1: HEALTHCARE IT IS DIFFERENT

Note: This is a preparatory Lesson that will open your mind and help you understand the higher lessons. Reading material for this Lesson is based on white paper written by Dr Pankaj Gupta on the same topic.

LESSON 2: GOVERNANCE AND FINANCIAL LEVER

Note: This is a preparatory Lesson that will open your mind and help you understand the higher lessons. Reading material for this Lesson is based on white paper written by Dr Pankaj Gupta on the same topic.

LESSON 3: FUZZY BOUNDARIES FOR GOVERNANCE

Note: This is a preparatory Lesson that will open your mind and help you understand the higher lessons. Reading material for this Lesson is based on white paper written by Dr Pankaj Gupta on the same topic.

LESSON 4: LINES ARE BEGINNING TO BLURR!

Note: This is a preparatory Lesson that will open your mind and help you understand the higher lessons. Reading material for this Lesson is based on white paper written by Dr Pankaj Gupta on the same topic.

LESSON 5: HEALTH DELIVERY INFORMATION SYSTEM [HDIS] MVP


LESSON 6: CLOSED LOOP MEDICATION ADMINISTRATION


LESSON 7: HEALTH INSURANCE INFORMATION PLATFORM [HIIP] MVP


LESSON 8: HEALTH INFORMATION EXCHANGE [HIE]


LESSON 9: HL7 AND FHIR


LESSON 10: META DATA AND DATA STANDARDS AND NDHB


LESSON 11: eObjects IMPLEMENTATION


LESSON 12: MICROSERVICES


LESSON 13: CLOUD COMPUTING


LESSON 14: FEDERATED ARCHITECTURE


LESSON 15: COMPUTER NETWORK


LESSON 16: JAVA PART 1


LESSON 17: JAVA PART 2


LESSON 18: JAVA PART 3


LESSON 19: DESIGN PATTERNS


LESSON 20: DATABASE CONCEPTS


LESSON 21: OOPS CONCEPTS


DIGITAL HEALTH ECOSYSTEM - ACCESS HEALTH DIGITAL VISION


Congratulations! This completes the AHD Academy's Digital Health 101 Course. Best of Luck for implementing the concepts on the field.

Your feedback is welcome, Write to digital.health@accessh.org

Note: All Content is released under MPL 2.0 License. It is free to use with proper attributions.



Monday, June 8, 2020

Health Data Dictionary Published in XSD Formats



The Public and Private 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.

MDDS for Health Final Part I Report in PDF: https://www.slideshare.net/PankajGupta9/part-i-mdds-overview-report

Final MDDS for Health Full Report in PDF: http://egovstandards.gov.in/notified-standards-0

Here is the link to MDDS for Health in XSD Format in GITHUB folder. This includes about 1000 Data Elements and about 140 Code Directories in technically usable formats such as - CSV, JSON, XML, XSD: 
https://github.com/accesshdigital/mdds 

It also has a readme file for your reference.

Thank You for your continuous association with us.

-- ACCESS Health Digital --

Contact for Clarifications:
Access Health Digital
digital.health@accessh.org 



Saturday, June 6, 2020

National Health Facility Registry - Concept Note


What is a Registry?

A registry is an organized system or database that collects, stores uniformed data or information about an entity like patient, person , or facility etc and is kept updated at all times to act as “Single Source of Truth” for the entity in question. The data facilitated by the registry can be accessed as service by information technology applications or by the government for planning initiatives and governance.

How a Registry is different from a Directory?

A registry is an official record keeping database which not only identifies an entity uniquely but also proves its existence in the ecosystem in question. E.g.: ADHAAR- A person must be listed in AADHAAR registry to be able to verify his/her identification as an Indian Citizen with authentic demographic details.

Directory on the other hand does not required to be an official or comprehensive, but mere a collection of data without uniquely identifying entities listed in it and do not serve as “single source of truth”. Example- A telephone directory.

What is a National Health Facility Registry?

A National Health Facility Registry is a centrally maintained registry that stores and facilitates uniform minimum required data or information about both public and private health facilities in the country. It is a building block that is essential to enable nationwide health information exchange. It will do so by identifying each health facility uniquely and creating a unique Identifier for every registered facility. This unique identifier then becomes available to be utilized by states and IT systems as a pointer or primary key to store more facility related data in directories maintained at state/district level, providing comprehensive data on all private and public health establishments

Problem Statement

Indian healthcare has been trying to overcome the problem of interoperability and siloed systems to enable continuum of care. This requires a standard driven health information exchange (HIE), and to enable a HIE, it is essential to uniquely identify each stakeholder and resource (Patient, Provider, facility, health worker) involved in an episode of care.

Also, from a quality of care and governance perspective a facility registry becomes very critical for resource planning to create a reliable, unified registry of country’s healthcare infrastructure & associated resources through associated state or national level repositories like NHRR to show their distribution pattern of health facilities and services areas across the country. This assumes even greater significance in emergencies like Pandemics and disasters.

Several initiatives have been made by the Indian Government in the past to enable a centrally maintained facility registry for India.

Key initiatives undertaken in India for facility registry includes:

  • National Identification Number (NIN) project that was undertaken by National Health System Resource Centre (NHSRC) in 2016 where data pertaining to approximately 1,11,990 health facilities was cleaned and validated by 25 states including longitude-Latitude details. A 10-digit unique National Identification Number (NIN) was allocated to the identified public health facilities. A NIN portal was also developed for missing facilities or new facility registrations and states were provided trainings on the same to keep the NIN facility data updated.
  • National Health Resource Repository (NHRR) project by Ministry of Health and Family Welfare (MoHFW)- In NHRRa Healthcare establishment Census was conducted which included on ground physical survey to enlist all the health facilities as well as resources. NHRR database has listed approximately 8.5 lakhs+ facilities and provides around 7000+ attributes withspatialinformation maintained by the technology partner ISRO.
  • ROHINI (Registry of Hospitals in Network of Insurance)– Dubbed as the AADHAAR of Hospitals by Insurance Information Bureau of India (IIB)- ROHINI is a PAN India registry of hospitals/day care centers that are empanelled with health insurance payers/Third Party Administrators(TPAs) for service delivery to the beneficiaries. It has approximately 35,000 facilities listed so far. Each registered facility is allotted a 13-digit Global unique GS1 identifier, along with geo coding of facility address. ROHINI also has self service portal for registration/inactivation /deletion or amendment of registered facilities. All network hospitals and hospitals involved in cashless reimbursement claims or those that wish to provide this facility, are registered on ROHINI.

All the initiatives as mentioned above had common goals, one to act as single source of truth and second to become single point of reference for facility information as per their identified scope.

Since a lot of effort has gone into each of these initiatives, they should be brought together and harmonized to enable a National Facility Registry that can identify both public and private health facilities uniquely. The data collected under each mentioned initiative can be consumed or exposed as service to get/retrieve additional data about a facility using the same National Unique Facility Identifier that can be allotted by the National facility registry and act as a primary key to stitch the different databases together.

Recommended Approach

1.  Identify Minimum required data elements for Centrally maintained Registry

A central or nationally maintained registry that can be self-sustainable and easy to maintain should not have a long list of data elements or attributes. It should consist of only a set of minimum required data elements that helps to identify the facility uniquely and can be kept updated at all times. The recommended data elements should follow Metadata and Data standards for India (MDDS) which is a standard notified by Ministry of Electronics and Information Technology (MeITY). It is essential to use data standards to collect and store information in a registry, so that if states want to maintain their own facility directories/state registry/database they can use the same standard MDDS elements to define the local registry structure and will be able to push data seamlessly to the National facility registry.

The recommended minimum viable data elements are listed in the Annexure.

2.  Map NHRR-NIN-ROHINI Facilities& State verification and updation

Facilities listed in all the three mentioned databases can be mapped using Machine Logic/AI and manual interventions by making use of the key attributes like name, address and longitude-latitude details.

Following steps are recommended to harmonize and enable a National Health Facility Registry

  • Map ROHINI, NIN and NHRR facilities. The facility data from NHRR, NIN and ROHINI data sources will be harmonized by employing Fuzzy logic-based matching of facility data from each of these different sources. Facility data (NHRR, NIN and ROHINI) shall be matched by deploying fuzzy algorithms like Soundex or levenshtein distance matching etc. The unique minimum required attributes as described in appendix 1 shall be loaded in the facility registry database.
  • Develop standard definitions for attributes using MDDS elements as provided in the Annexure I.
  • Identify & publish mismatches and duplicates in the standard definition template and suggests standard process of verification with district and health state departments.
  • State can filter facilities district wise and get the data verified through the respective district health department.
  • Districts can update information in excel format and request corrections if any to the state.
  • State after verification and validation can push the cleaned facility data to the centre.

 3.  Convert the clean, verified data using a technology partner like NIC into a registry.

The first step towards digitalizing the National Facility Registry after receiving clean and validated data is to load the cleaned facility data into the National Facility Registry. The facility registry shall store the source ID of each system (NHRR ID, NIN ID and ROHINI ID) against the set of data attributes loaded from each of these three data sources to facilitate the facility data set retrieval from registry based on different identifiers (e.g. based on ROHINI ID or NHRR ID) and thus it shall not disrupt the design of existing systems which are using this data.

The loading process of facility data into facility registry shall ensure the uniqueness and deduplication of facility data by using validation/data deduplication engine. A National unique facility Identifier shall be generated for each facility populated in the facility registry (the algorithm to generate the unique facility identifier should be decided by the authority implementing the design of facility registry), The facility unique Identifier will be a 10 digit unique Integer value and should not contain any data attribute based logic in the design of identifier code due to volatile nature of the facility data attributes as that may change in future e.g. if facility identifier contains the logic built based on the location of facility e.g. state and district code, the same may change due to administrative change of the location of facility due to addition or deletion of state or district by the respective state government in future. It is recommended that facility identifier should be a running serial number generated based on a selected algorithm like generation of AADHAR NUMBER which generate a unique number which is unique across the lifetime.

4.    Develop a central portal with standard operating procedures on deletion, updation or addition of facilities.

  • Portal for enrolling new public and private facilities into National Facility Registry.
  • Public Portal for access to National Facility Registry data as part of e-governance.  

 5.    Develop a roadmap for training & updation of National Facility database by state users.

 6.    Maintenance of National Health Facility Registry

For maintenance of Facility data in Facility Registry. openAPI/web service standards can be used to add/update or delete facility data. After Initial load of facility in facility registry any new facility shall be added in the Registry by use of openAPIs/webservices. The updation of facility registry shall follow the design principles for registries as laid out in National Health Stack document and will ensure the single source of truth and non repudiablity of facility data in registry.

Advantages of a harmonized facility registry using NHRR, NIN and ROHINI

  • The National Facility Registry will be a single source of truth for all the clinical establishments or healthcare facilities in India and can be a single point of reference for health infrastructure planning.
  • The Facility registry will always also help the Government to plan emergency responses and predict healthcare expenditure by making operational status of facilities available.
  • Harmonizing the different initiatives like NHRR, NIN and ROHINI will help in collating authentic data for facilities which are already recorded under respective initiatives while the initiatives coexist in harmony and expose the data as a service.
  • A repository like NHRR and state repositories if linked with the National Facility Registry can provide more information about a facility’s resources like Doctors, Nurses, equipment etc which will help a state to plan optimized utilization of available resources.

 A harmonized National facility registry can be one shot solution, which can support the Government to manage and optimize healthcare infrastructure & resources effectively and predict the unmet needs to design an effective risk mitigation plans in advance to combat a future pandemic. It can identify key areas of improvement by upgrading existing health facilities or establishing new health facilities keeping in view the population density, geographic nature, health condition, distance.

For Annexures please read the full Health Facility Registry document on slideshare.

Reach out to us for clarifications:

digital.health@accessh.org

Department of Digital Health, ACCESS Health

DOCTORS REGISTRY OF INDIA – CONCEPT NOTE



Overview

 With a proactive concern for patient safety and quality of care, The Indian Medical Council Act 1956 prohibits a person other than a medical practitioner enrolled on a State Medical Register or the Indian Medical Register (IMR) to practice in India. Every New Medical Graduate must Register with the respective State Medical Council Register and is then allocated a registration number. With that Registration Number, the Doctor can Practice anywhere in India.

 As it works Currently, apart from MCI’s National level Indian Medical Register (IMR), different state councils have their own medical Registers. The MCI then compiles data received from state medical councils.

Problem Statement

 Healthcare being a State Subject, a degree of latency creeps into the system. However, when a Doctor migrates to any other part of India, he/she often overlook to update the State Register and also similarly about recent Qualifications, Degrees, Certifications, etc.

This makes for high chances of duplication of data of Registered Doctors between the various registers. This makes the compilation and de-duplication exceedingly difficult because of the administrative dependencies which are beyond the MCI’s control.

There are also then, several unqualified or fake Doctors working in the country without proper qualifications and/or registration with IMR or State Registers. MCI has no way of tracing, tracking, and weeding out such practitioners from a wide variety of genuine Doctors working in the Country.

On the other hand, the patient also has no way of differentiating between genuine and fake doctors.

With the adoption of Universal Healthcare as a Policy in 2017, increasingly healthcare services are going to be paid for by Insurance or state programs. From a Health Insurance perspective, it becomes exceedingly difficult to establish the veracity of the Claim. The liability lies on the payer whereas there is no authentic single source of truth.

Similarly, in the event of medico-legal cases, it is hard to trace back from the prescription to build a legal case. A wide variety of degrees appear on Doctors’ Prescription pads. MCI lacks a master list of accepted Qualifications including Indian and International Degrees/Diplomas/Certificates. Hence there is no way of finding out if these Degrees are genuine, equivalent international qualifications, derecognized, or even completely fake!

Current Issues

There are many use cases where the sanctity and harmonization of the Registers come into question. These are some of the practical detractors to the authenticity of data on the Medical registers.

Doctor has Migrated/Died or left the practice:

  • Migrated Doctor may Re-Register in the other State Register at the time of Renewal. Though a procedure exists about taking a No-Objection-Certificate from the previous State Register; but it is not very strictly followed. There is a possibility of Doctor getting counted in both Registers.
  • When a Doctor dies, the Register is usually not updated with a Death Certificate.
  • When a Doctor has Left the country, the Register is usually not updated because usually it is not known if the migration is temporary or long-term or permanent.
  • When the Doctor has left Practice due to any reason e.g. Administrative job, Higher Education, Change of Sector, etc.

Name Change or Mismatch:

  • The Register is usually not updated when Doctor Changes Name E.g. Marriage, Religious reasons, etc. This results in a Name mismatch between IMR Register and the changed Government IDs.
  • The Register is usually not updated when Doctor Name Spellings is changed e.g. Family, Social or Numerology reasons, etc. This results in a Name mismatch between IMR Register and the changed Government IDs.
  • Name Mismatch between Degree, Internship Certificate, and Registration. Only possible to check at the time of first Registration, later it is very difficult to harmonize.
  • Demographics Mismatch between Degree, Internship Certificate and Registration. Only possible to check at the time of first Registration, later it is very difficult to harmonize.

Degrees and Specialisations

  • When a Doctor attains a Specialized/ Super Specialized Degree or Certificate, it is usually not updated in the Register because there is no real mandate to do so.
  • Equation of Foreign Degrees with Indian Medical Degrees e.g. MD from US equivalent to MBBS or MD or DM? DNB equated to MD or DM? Exceedingly difficult for MCI to decide if the Registration should be granted or not.
  • Equation of Degrees in India e.g. Ph.D. Clinical Pathology without MBBS, or MD Pathology? MCI usually does not grant Registration for such cases. Though they may be equated Internationally. Will the documents signed by such professionals be recognized e.g. Genetic Testing Reports.

Government/Administrative Issues:

  • University Mismatch – e.g. Individual Universities in Maharashtra no longer gives Medical Degrees. Nasik University has taken over that function and gives Degrees across all Medical Colleges in Maharashtra. Only possible to check at the time of first Registration, later it is exceedingly difficult to harmonize.
  • If the Doctor has lost the Graduate Medical Degree. It is hard to justify the details mentioned in the IMR Register. The only way is to ask for a Duplicate Degree from the University, which is also a very long process and is usually not pursued.
  • Medical Graduates of States having special status were given Provisional Registration to Practice pending the legal decision on the State – e.g. J&K, Arunachal, Sikkim, Pondicherry, Goa. Later there is no way of revalidating the data before regularizing the Registration. So the old Registrations continue to languish.
  • How do you split the Medical Graduates between States that were split or newly carved out – e.g. Goa, Uttarakhand, Chhattisgarh, Jharkhand, Telangana. Later there is no way of revalidating the data before regularizing the Registration for the New State. So the old Registrations continue to languish.
  • Medical College recognized by the State but not by MCI Govt of India. State Register gives the Registration, but MCI does not recognize it.
  • Medical College derecognized by MCI Govt of India. State Register gives the Registration, but MCI does not recognize it.
  • Provisional Registration is granted in cases of Emergency e.g. Disasters and Epidemics. This should be withdrawn after the Emergency. However, no clear process has been defined for this purpose.

Foreign Degrees and Passports:

  • Foreign Passport but studied from Medical College in India. State Register gives the Registration though the foreign national will not practice in India e.g. Nepal, Bhutan, Sri Lanka, ASEAN, Africa, West Asian countries.
  • Indian Citizen but studied from Foreign Medical College e.g. Russia, China. MCI Register gives the Registration after an examination. Though many of these Indian nationals migrate out and do not practice in India.

Recommended Solution

As per newspaper reports[1], In 2017 the Medical Council of India had directed all states to provide a unique permanent registration number (UPRN) to every Doctor Registered in their jurisdiction.

MCI had envisaged a digital platform. The MCI initiated the process of implementing e-governance through digital mission mode project (DMMP); one of the ambitious modules under DMMP project is the implementation of new IMR through unique permanent registration number generation for each Registered Doctor in India, the MCI said in a letter sent to the Indian Medical Association (IMA).

On implementation of the system, the existing registration numbers of the Doctors shall be migrated to a standard system of UPRN. Doctors shall also apply online for additional qualification registration in IMR like Postgraduate, super-specialty etc. After commissioning, Doctors can use the system to make online applications for services like issue of certificates etc.

 The initiative will put an end to the duplication of Doctors Registered by various state medical councils as well as the Indian Medical Register under the MCI and provide a clear picture of how many Doctors are practicing in India. A UPRN number is to be generated for the over one million Doctors recorded in the IMR.

We will get to know about the actual number of Doctors and the list of medical specialists practicing in the country. We will have all the details about a Doctor, ranging from addresses to personal details, and Specializations. Currently, we seek information about Doctors from the state medical council. Once all the Doctors are given a separate code or UPRN, it will become amazingly easy to trace them in a case of medical emergency, epidemics, disasters, negligence, or second opinions for their expertise.

However, from 2019 the MCI role has now been taken over by the National Medical Commission [NMC]. The handover of charge by MCI BoG to the NMC is awaited.

Para 31 of The NMC act of 2019, mandates it to ensure electronic synchronization of National and State register in such a manner that any change in one register is automatically reflected in the other register [2]

Fortunately, this can easily be accomplished by leveraging the MDDS recognized in the National Digital Health Blueprint, 2019. This would make it possible for the IMR to evolve into a single-source-of-truth and be looked up appropriate stakeholders.

Recent events like the COVID 19 Pandemic have brought the vital role that Telemedicine and similar technologies can play sharply into focus. Para 32 of the NMC act also conceives a role for a limited number of Community Health Providers to work under the supervision of a medical practitioner.

These emerging trends make the authenticity of the medical register critical to healthcare delivery in a safe, accessible and equitable way.

Architectural Approach for Doctor’s Registry

1.  Federated Architecture for Doctor’s Registry

As per NMC Act, the Ethics and Medical Registration Board shall maintain a central National Medical Register (aka National Doctor’s Registry) containing the set of minimum data elements for identification and credentialing of a licensed medical practitioner (aka provider) practicing anywhere across the country. To enable this a federated architecture design is recommended for the National Doctors Registry that it can be kept updated at all times and will not have a single point of failure.

The National Medical Register will be responsible for allocating a Unique National Provider Identifier (NPI) to every new provider that gets registered through a state medical council or directly through the central medical register by performing de-duplication and validation of a new provider record. This unique identifier will remain unique for the lifetime of a provider.

Every state medical council will then use this Unique Provider Identifier to maintain and regularly update the state register (aka as Provider Directory at the state level) for the providers registered within that state with not only the registration details but also with additional information about their credentials, employment, training, qualifications, CMEs attended and active status etc. There will be an electronic mechanism to update the central register with the data from the state level provider directories for new provider registration as well as for any information update through the state register. Lookup the details in ANNEXURE – 2.

Read the Full Article on Slideshare.

References:

[1] All practicing Doctors to have unique digital identification, 02 Oct 2017, Livemint

[2] NMC Notified: http://egazette.nic.in/WriteReadData/2019/210357.pdf

Tuesday, June 2, 2020

HDIS MVP Microservices Published





Minimum viable product (MVP) is a strategy that has gained rapid and widespread acceptance among the startup community. Used effectively, it can be a compelling strategy to evaluate product-market fit, which often is the largest risk facing a new medical software company. The idea of MVP is to focus a product or service on the key value that it provides to a customer. 

MVP is about the minimal functionality that will do the job. The MVP will fail if you go any lower or remove any functionality from the MVP. So the trick is that if the product can work without any Functionality - please remove it from the MVP. Figuring out whether organizations or individuals will adopt the product often is the largest challenge facing new companies. The goal of MVP is to test the adoption and payment assumptions as early as possible. MVP is that product which has just those basic functionality that allows you to ship the product out.  

A Healthcare delivery organization typically only needs a few core Modules to run the organization e.g. Registration, Appointment, ADT etc. We call these core modules are MVP. Rest of the functionality is fluff or Add-On that is not really essential but good to have. 

The core blocks are representation of minimum functionality sets (also known as Minimum Viable Product Modules) within HDIS universe. All these core modules are required functions that any healthcare ecosystem will need. There can be add-on modules but the core are the minimum that must exist in a healthcare system. These modules caters not only the hospitals but also smaller health delivery centres like Clinics, Nursing Homes, PHCs, SCs, HWCs etc. But a PHC might not need full set of core functionality rather a subset of these MVP modules. 

A Module has many Functionalities inside it. There could be 1 or multiple Microservices for each Functionality. Each Microservice has multiple data elements inside it. A Module has multiple Microservices. MDDS provides a library of 1000 Data Elements and 140 Code Directories. It is like a set of Lego blocks that you can use to build your own Apps.

We run a Social Entrepreneurship Accelerator [SEA] program. There are 25+ digital start-ups and HIS/EMR vendors working with us to implement the Digital Health standards and MVPs.

One of the technical approaches to comply with NDHB & EHR standards of India is implementation of microservices architecture with MDDS (Metadata Data Standards) as base.

Some of the SEA members had picked up microservices as a technical approach and have volunteered to contribute the same to our GITHUB repository that other SEA members and Government partners can benefit from. We would like to extend our gratitude and thanks to all the SEA members who have volunteered to build this open source community for India.  

https://github.com/accesshdigital/sea-mvp-microservice .
 
The first set of microservices that we are releasing includes infrastructure microservices which serve as a base for setting up a microservice development environment. The description and implementation of these microservices is provided in the "readme " file. Please refer the same to get more detail about the uploaded microservices.

Please note we will be releasing more microservices in open source in an incremental way, whenever our volunteer SEA partners contribute the code to the GITHUB repository and is reviewed and approved by Access Health Digital.

How can the digital health opensource community benefit from these microservices codes?

1. New product development - If you are planning to build a new product , it is recommended to build the solution on microservices architecture using the shared microservices.
2. Legacy application - If you have a Legacy system and you dont want to disrupt your ongoing business model. then you have an option of building a Bolt-On translator layer on top of the Legacy system such that it populates the eObjects.

Note:- Soon we will also be releasing other MVPs like eObject schema, Open API specifications and other open source components in the GitHub.

Our collective endeavor is to convert our siloed health system to an interoperable digital health ecosystem. Let's get together and make it a success story!

Thank You for your continuous association with us.

-- ACCESS Health Digital --

Contact for Clarifications:
Access Health Digital
digital.health@accessh.org

Saturday, May 30, 2020

National Formulary of India (NFI)



The need of a national level drug database has been recognized as a priority by the government in recent times. Even though it has gained government's attention it will take some time for a national level Drug Index to be available. Hence, we recommend the use of National Formulary of India (NFI) as a standard drug database. NFI has been adopted from World Health Organization (WHO) Model Formulary. For the promotion of rational use of drugs, the Indian Pharmacopiea Commision publishes National Formulary of India (NFI) at regular time intervals. The Formulary enlists the generic drugs, their classification, dosage, availability, indications, contradictions,precautions. To facilitate the use of NFI, the branded drugs can be mapped against the specific generic drugs or generic drug combinations and use relevant MDDS data elements and Code directories to prescribe their usage in a standardized format. 
  • CSV Format NFI: 
    https://drive.google.com/file/d/1vJUIWg971MIVreMrbBhZ3cQ--IpL_bG0/view?usp=sharing
  • PDF Format NFI: 
    https://drive.google.com/file/d/1xJK9X1rHnbdloHTvpQUH92w4reMOGZFd/view?usp=sharing
  • PDF Format NFI Update: 
    https://drive.google.com/file/d/11V8XjQRLfqjN2PoiRzorCtrdrcOdIlsH/view?usp=sharing
The document also consists of a proposed Drug Index template beyond the NFI. Since, the availability of a standardized drug database is of utmost priority in the present scenario. The structure of the template is largely based on MDDS with some added custom fields. The template consists of the following fields. 

Drug Classification
Drug Unique Code
Generic Drug Code 
Generic Drug Name
Brand Drug Code
Brand Drug Name
Manufacturer 
Drug Form
Strength Value
Drug Frequency
Route of administration
Drug Restriction (Max Dosage)
Drug Drug Interaction
Alternate Drug (generic drug)
Medication package type 

Note: NFI is a list of Drug Generic Names only. It is left to the users, vendors and the industry to get together and populate the Drug Brands etc. at the time of implementation and/or based on the Physician preferences.

Thank You for your continuous association with us.

-- ACCESS Health Digital --

Contact for Clarifications:
Access Health Digital
digital.health@accessh.org

Thursday, April 16, 2020

Health Systems for a New India: eObjects Building Blocks



eObjects were first written by Prof Dennis Streveler and Dr Pankaj Gupta in a white paper in Nov 2018 that was published by Niti Aayog in the book Health Systems for New India, Chapter 5 - Reimagining India's Digital Health Landscape Wiring the Indian Health Sector in Nov 2019.

ACCESS Health Digital Strategy Council defined the details of the National Digital Health Blueprint building blocks - Minimum viable products including the eObjects and microservices architecture to comply with the NDHB Standards. ACCESS Health Digital runs a Social Entrepreneurship Accelerator to accelerate the implementation of the NDHB Standards through these building blocks. 

The eObjects have now been adopted by Joint working Group of National Health Authority NHA and Insurance Regulatory Development Authority IRDAI Sub group on common IT infrastructure, in its report published on 11 Sep 2019 and will be built into the India’s national Health Claims platform.

The eObjects were designed for interoperability across the healthcare ecosystem on a federated architecture. eEncounter, eDischarge Summary Objects are for Provider-to-Provider interoperability; such that the data can flow across healthcare facilities, State HIE and National Data Lake. Whereas the eClaims Object creates a Financial Lever for the market. If the providers submit the claims in standard eClaims Object format then the turnaround time for their payments can be expected to be faster. Clearly eObjects are an innovative breakthrough.

This is very similar to what happened in the FinTech revolution in India where Government of India created the Unified Payment Interface UPI platform and then created the BHIM App and released the related Application Programming Interface APIs to the market. Later the Market used the API’s and built the hugely successful Paytm, Googlepay, Phonepe wallets. In 3 years the UPI transactions went from negligible to 1 Billion transactions per month.

Financial lever and strong governance for digital health transformation, plays a vital role in ensuring successful outcomes of such undertakings. India would do well to heed this truth. 

Provider eObjects Published



Immediate usecases: 
  • ePrescription and eEncounter FHIR based Objects for Telemedicine interoperability. 
  • The same eObjects can also be used for Referral across Primary, Secondary and Tertiary care.
  • Epidemiological Surveillance is the next big thing. We will need eEncounter, ePrescription and eDischarge Objects to fetch the data from disparate OPD/IPD HIS/EMR systems.
  • eObjects act as a Standard Output Format in these use cases.

The need for the eObjects arose because most of the Healthcare-IT applications are being developed without any standards by different agencies and vendors in the 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 the insurance company/government, the recipient application should be able to understand and re-present the same meaning of bill information.

Interoperability among e-Governance applications for the health sector requires exchange of information across applications. There is a need for commonly accepted data definitions for the various data elements used in e-Governance systems in Healthcare. Hence, standardization of data elements is the prerequisite for systematic development of e-Governance applications in the health sector.

The old HIS and EMR systems or even the new breed Digital Health Apps lack credible Global Digital Health Standards. Hence, they exist in silos and don’t interact with each other or the larger Healthcare ecosystem. The data cannot be referred for any meaningful analysis. For example, we still don’t know clearly the size, scale and depth of the Dengue, Chikungunya and H1N1, Flu epidemics that strike us every year. Hence, we are always left gasping for breath when the seasonal spike starts. 

India is already the Diabetes capital of the world with 70 million cases and counting. We still don’t have standard protocols based on the Digital Disease Management Platform.

The HMIS/HIS/EMR market in India requires Digital Health Standards based FHIR/JSON eObjects that can help the existing systems to communicate with the external world in a Standardized format. 

These Provider eObjects were first published in Health Systems for New India book by Niti Aayog and comply with NDHB, EHR and Meta Data standards, guidelines provided by Medical Council of India, Clinic Establishment Act and as per the latest Telemedicine guidelines released by the Government of India.

We have published the details of the eObjects on the openbodhik.in. To facilitate standard value sets for the entire ecosystem, we have also provided all the required value sets/code directories/master in an excel format.
  • eEncounter Note
  • ePrescription and
  • eDischarge Summary

Please follow the link provided here to access the e-provider objects and related documents:

Your respective Healthcare Delivery Systems should be able to generate the Provider eObjects formats. You can use the eObjects as input forms i.e. if you are building a new system. Legacy systems will use eObjects as Standard Output format.

The provider e-object can also facilitate capturing of signs, symptoms, vitals and procedures data during an active surveillance, which would in turn be useful in studying and analysing a disease outbreak.

We request you to kindly use these eObjects to collect data in your respective health delivery systems, that we can together facilitate Government with valuable clinical data for analysis and planning.

Reach out to us for any help to understand or implement the e-objects. We can set up a group call with all of you to explain these eObjects in detail or even can set up one to one calls.

Thank You for your continuous association with us.

-- ACCESS Health Digital --

Contact for Clarifications:
Access Health Digital
digital.health@accessh.org