Tuesday, June 2, 2020

Epidemiology Surveillance

Epidemiology Surveillance is a Lever of Change - for implementation of National Digital Health Blueprint and adoption of National Digital Health Ecosystem.

Given the vast and variable nature and quality of legacy and operational data being generated in real time which requires to be captured, any solution adopted requires to essentially ingest these disparate forms, allowing meaningful options in its use. This becomes a tall order for traditional architectures like Data Warehouses, that constrain the types of data that can be stored in them, both in terms of type and quality.

Data lakes are the leading edge and evolving architecture that can help store, share and use electronic health records and other patient data in its ever-expanding variety. Data Lakes open the possibility of taking Healthcare Analytics to its Next Level by keeping pace with the rapid growth in types and magnitude of data that needs to be harnessed and made use of. It is important here, to understand the differences between Data Lakes vs. Data Warehouses. Data Lakes store raw data on the one hand, while Warehouses store current and historical data in an organized fashion. Data warehouses are best for analyzing structured data quickly with great accuracy and transparency for managerial and regulatory purposes.

A federated data lake is essentially an architecture to store high-volume, high-velocity, high-variety, as-is, data, as it gets rolled up from State-level Health Information Exchanges. State-level Health Information Exchanges will pull in vast amounts of data — structured, semi-structured, or unstructured — in real-time, from local healthcare facilities.

Data Lakes can additionally, also ingest data from Internet-of-Things sensors, clickstream activity on public health websites, log files, social media feeds, videos and online transaction processing (OLTP) systems. Data Lakes are used for Big Data and real-time analytics. To ensure that a lake doesn’t become a mere swamp, it is very helpful to provide for a catalog that makes data visible and accessible to the business teams, as well as to IT and data-management professionals.

A healthy Data Lake requires maintenance. There are no constraints on where the data originates from, but it is a good practice to use metadata tagging, to add some level of organization to the data ingested. This will allow for relevant data to surface for queries and analysis. The value of a well-maintained data lake dealing with large volumes of disparate data, pivots on the links to metadata and ontologies. It requires consistent management of metadata, terminology management, ontology management, linked open data and modeling, and the kinds of automated algorithms that can be deployed to use these resources efficiently, to crack difficult problems such as epidemic surveillance.

The Provider eObjects can gather statistics for the appropriate authorities to allow calculation of burden of disease, epidemiological Studies for epidemic surveillance, monitor for incipient epidemics and compare outcomes across facilities. They will also play a vital role in providing epidemiological, utilization and quality data for analysis and action. Additionally, these eObjects can serve as a powerful means of recording and observing the natural history of a disease, determining the effectiveness of various clinical treatment protocols and assessing the quality of care being dispersed at different levels of care, facilitating biomedical research, while conducting analysis on disease trends.

Read the Reports:

  1. Data Insights Hub Report - ACCESS Health Digital
  2. Health Information Exchange Analytics Framework HIEAF Report - ACCESS Health Digital
For more information write to us: digital.health@accessh.org


















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 .
https://drive.google.com/file/d/1HU7cf6D4MmNx9YzNO1DpX2TInRgue1N5/view?usp=sharing

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

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

Wednesday, April 15, 2020

ACCESS Health India Perspectives: Digital Will Drive Access to Healthcare

India’s Healthcare system is fragmented, the country is too diverse and large for a single unified system. Each state has its own healthcare programs. The central government provides the majority of the funds but the implementation largely rests with the states. States that are better off are independent in their decision making and show better outcomes. However, India can still aim for standardized protocols and interoperability across states. Interestingly, digital technology is proving to be a binding force between the three important stakeholders of healthcare namely, payer, provider and people. The new Ayushman Bharat national health insurance program is becoming the melting pot for public and private healthcare and emerging as the biggest driver for digital health.
Healthcare in India has lagged in adoption of technologies, but digital technologies are now pushing the country in the right direction. Technology driven transformation has happened in many sectors like Mobile and Telecom, Aadhaar based eGovernance, Fintech and Banking. Healthcare is likely to go through a digital transformation now.
Technology has already taken its toll on the Hospital Information Systems [HIS] market. Large HIS vendors have exited the market. Either they have lost interest and exited or have been acquired. On the other hand, many tier-II incumbent players are not able to shift out to cloud because of their long term negotiated contracts in client-server model. The newer cloud-based players are comparatively smaller in size and yet to reach size and scale. The HIS market is ready for complete disruption by Digital Health!
Now is the Era of Mobile-First Apps. Small Data ^ = Big Data. The time has come when you don’t need big monolithic HIS software to run hospitals. Now you can do a lot with small mobile based Apps for every function. Clinical evidence-based medicine has got a new meaning with Digital devices run on Artificial Intelligence being introduced. These devices can automate Laboratory Reports, read Radiology reports better, do accurate differential Diagnosis, pin point relevant Order sets, send Referrals, drug refill alerts and follow-up reminders. Disease management has gone Digital and the devices are learning fast and outcomes getting better with every new patient.
However, 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 Digital Disease Management Platform.
The HIS/EMR market in India requires EHR and Meta Data Standards based XML/JSON wrapper/objects that can help the existing systems to communicate with the external world in a Standardized format.
We need centralized Registries for uniquely identifying the Patient, Provider and the Facility where the treatment was carried out. We need Reference data dictionaries for standardizing the Diagnosis, Prognosis, Procedures, Laboratory tests, Radiological examinations, Drug prescriptions. This should be the common lookup so that everyone can be interoperable. The need for such Central Registries and Lookup Dictionaries is of paramount importance. Though the vital question remains, as to who will build and manage it. Should it be privately owned and controlled or publicly funded and managed.
Health Insurance sector has similar challenges. Private Health Insurance covers about 3% of India Population. There are 17+ Private Insurance companies that also do business in Health Insurance. 4 Public Sector Companies also cover Health Insurance. Four Private Insurance companies whose core business is only Health Insurance.
Public Health insurance covers about 10-17% of India Population. 80+% is Out of Pocket expenses. About 2% of India’s population falls below the poverty line every year due to unaffordable hospitalization expenses. Now the Central Government Pradhan Mantri Jan Arogya Yojana (PMJAY) has come to the rescue of most of the uninsured population. PMJAY is set to cover 40-50% of India’s Population. In absolute numbers the market is set to expand from the current 150 million people and go up to 500 million people.
Obviously, the TPA business which has been servicing only the private health insurance i.e. 3% of India’s population, must gear up to support PMJAY covering over 40% of India’s population. Hence TPA business is ready for disruption. The number of daily claims is set to go up by multiple times.
All these claims pipelines cannot be processed manually. We need to use high end technology to process the claims. We need a Standardized Claims format. The TPA market in India requires XML/JSON based standard Claims wrapper/object that can help the existing systems to communicate with the Hospital HIS/EMR world and the Health Insurance world in a Standardized format.
Globally, winds of change are evident. Digital is totally changing the way Health Insurance business has been run in the past. CVS has been building retail Primary Care centers and Diagnostics in its Pharmacies. Now with CVS Purchasing Aetna! John Hancock is shifting from traditional Life Insurance model to incentivize longer, healthier lives. In brief, they will move away from Life insurance model to Disease management and Precision medicine. Blockchain based Unique Identifiers are emerging. AI based start-ups are working on meta data driven Discharge Summary, Hospital Billing and Claims, Intelligent Claims Adjudication and Fraud detections. The Digital Tech Giants are becoming Healthcare companies. The lines are beginning to blur.
Is India far behind? Not really, India has a habit of leapfrogging stages, specifically with regard to Telecom and FinTech sectors. It will now happen to Healthcare. A Digital Healthcare Ecosystem is already taking shape.
https://accessh.org/access-health-india-perspectives-digital-will-drive-access-to-healthcare/