Showing posts with label interoperability. Show all posts
Showing posts with label interoperability. Show all posts

Friday, May 22, 2020

ASHA: Health Worker Registry

 


Download the Full Report Here.

A federated health worker registry is proposed that will be maintained by the Central Government and will store “identified minimum required informative fields” and will assign a “unique identification number” for every ASHA worker. The ASHA registry will have pointers to the state ASHA enrollment repositories or databases (DBT, HR etc) that will push relevant data to the central registry for every new ASHA enrollment, any information updation or change in employment status or location.

Whenever a new ASHA health worker gets selected for final recruitment, gets enrolled through an online common cloud-based portal or application by a trained staff appointed by the district health dept or a private enrollment agency at the PHC or assigned anganwadi center maintained at village or district level. 

The enrollment process mandates ADHAAR card number authentication with the UIDAI and assigns a unique health worker identification number in the centralized registry. This Unique ID is unique across the country and ensures the portability of health workers from one district or state to another and provides a global mapping of the health worker ID with services delivered at the health and in various vertical health and nutrition IT programs.

This enrollment process may include an enroller-approver flow to get a final approval from the nodal/district health officer to foolproof the recruitment process and only after the approval a new ASHA can be assigned the Unique ID.

The DBT database at state level is required to be linked to the centrally maintained registry for every new enrollment as a prerequisite for activating the DBT service. Since an ADHAAR number is already a mandatory requirement for authenticating the DBT account, the same ADHAAR number should be used to authenticate every new ASHA enrollment and will facilitate single source for non-repudiable data.

It is suggested that a DBT account of the newly recruited ASHA will only be created after the unique ID is assigned to her. Unique ID becomes a pre-requisite for DBT payments. Any national or state program that requires assistance from ASHA on various health or nutrition activities, will have to use a look up service to the central registry to enroll the ASHA in their respective application and program that task tracking and workload assessment for payments can be made easier and automated. 

For all the existing ASHAs for whom information is maintained currently by states either in the DBT database or ASHA soft etc would be required to push data to the central registry for the identified minimum required fields.

The enrollment agency or district department whoever is responsible for the end to end enrollment or data migration work, will be required to setup a maker-checker workflow so that, only verified or correctly mapped information gets uploaded in the central ASHA registry.

A registry update process/mechanism on regular intervals precisely annually will be required to be implemented. Central registry may trigger annual reminder like that in vase of Voter update system for updation or confirmation of the updated information to ensure reliability of information. These reminders will be part of the workflow that can be sent to the assigned enrollment agency or the district health department that will be responsible for enrollment and updation.

Services for self-updation will also be required similar to in the address etc update process in ADHAAR at the anganwadi or PHC centers with OTP service or on approval by the district health.

For every critical process (like Mobile no. updation, last name change, village/district change etc in case of transfers or inactive ASHA update) in the entire the lifecycle of an ASHA that affects the information in the central registry directly or indirectly will have associated manual and electronic form and processes that will have to be completed through the same common portal or application with role based access.

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.

eObjects are evolving, check with us for the latest versions. 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