Healthcare-IT Business Strategy

Sunday, August 16, 2020

National Digital Health Mission [NDHM]



National Digital Health Mission launched by PM Modi from Red Fort on 15th August 2020. ABPMJAY set the stage in 2018. Now India is taking the next big Digital Health leap in 2020. NDHM will serve as the Digital backbone for Health Insurance and the Provider Healthcare Ecosystem. https://lnkd.in/dsRK3te

I had coined the term national ehealth authority [NeHA] in 2011 while doing the public health IT study report together with national health systems resource center [NHSRC]. I then spoke about NeHA, HIE and NHIN at the WITFOR 2012. I again spoke about NeHA, HIE and NHIN @ the eHealth conference Hyderabad 2012. I then wrote about it in the meta data and data [MDDS] standards for health domain again in 2013. On 30th Dec 2016 MDDS had been notified as part of the EHR v2 2016. Aug 2018 - MDDS for Health had been Notified. Nov 2019 - NDHB carried forward MDDS for Health and recommended the creation of NDHM.

#NDHM vision is to create a national digital health ecosystem that provides access to efficient, accessible, inclusive, affordable, timely and safe healthcare for all citizens.

Clearly India is moving from a payout-of-pocket model to a Universal Healthcare Coverage model. About 60% of India's population will soon be covered as
all Govt Health Schemes are folding-in to ABPMJAY and the Missing-Middle is all set to be covered too. Total claims are set to go up by 10-13 times. Digital is the only way to manage the upcoming Tsunami of claims.

World over Health Insurance does not just pay for Secondary and Tertiary care; it is in the interest of Health Insurance to reduce the overall Disease burden. Digital will help us catch the disease earlier at Primary care levels. Will better manage the Referral network. Data driven Clinical Protocols to slow down the disease progression. Evidence based medicine to reduce the disease burden. Some Examples -
John Hancock shifts from Life Insurance to Disease management; CVS purchased Aetna; UnitedHealth bought a large Doctors Group. ICICI Prudential Life Insurance covers Critical illnesses. 

Healthcare Wallet will Emerge: Soon a level playing field will enable a Healthcare Marketplace to emerge, to help the Person make better choices on Hospitals, Doctors, Appointments, Pharmacies, Labs and more. Patients will be inundated with plethora of choices and price competition will play out for them just like it happened in Telecom, Airlines and Retail.

Covid19 did not break the Healthcare system, it only exposed a broken system. Today Public Health cant do resource optimization because they don't really know how many Doctors, Nurses, Beds, Hospitals, Assets exist. This is not going to be the last epidemic hitting us. In this Pandemic, and Next time around we will be better prepared with resource optimization tools, predictive analytics and armed with Epidemiological studies to tackle it. 

NDHB Standards Compliance: To comply with NDHB Standards, the Health System has 2 options:

For Legacy systems - apply the
eObjects published here with FHIR Extensions and JSON. https://openhealthcode.blogspot.com/2020/04/provider-eobjects-published.html

For new systems - please build the Standards into your information model.
https://openhealthcode.blogspot.com/2020/06/hdis-mvp-microservices-published.html Health Delivery Information System MVP Microservices published in #opensource. It is Free. Anyone can use the code under MPL 2.0 #opensourcesoftware license. Our objective is to take the Digital Healthcare Ecosystem to the next level.
----------------

Labels: , , , , , , ,

Wednesday, May 20, 2020

Summary - Telemedicine Practice Guidelines

 




Doctor friends,

Telemedicine guidelines now allow you to do everything. Just be careful; Liability is on you now, so:
  • Do not step out of your clinical comfort zone;
  • Keep all the past and present records - Text, Audio, Video, Paper, Films etc. It is mandatory to keep records. Also the records provide a legal cover to the medical practitioner in case of any MLC.
Telemedicine guidelines have solved all the old issues:
  • Any Consultation without Physical Examination was not allowed.
  • Telemedicine needed Healthcare professionals on both sides of the Electronic Line.
  • Only Triage was allowed over a Voice call.
  • ePrescription was not allowed. MCI insisted on physically signed prescriptions.
  • Online Pharmacy delivery without verification of physically signed prescriptions was not allowed.
  • As per MCI, Patient walking into the Physical clinic is considered as Deemed consent. Law did not interpret the same for Telemedicine calls.
  • Guidelines were silent on Consent, privacy and data security.
  • Telemedicine service providers had to be registered with respective States under the Shops Act and Clinical establishment Act.
  • MCI Contributory Negligence Clause included the Telemedicine software and service providers also i.e. they also had to share the legal Liability.
  • Access and Availability.
----------------------

Technology Requirement:
  • Cloud First Design: Gone are the days when you needed a big technology infrastructure for Telemedicine setup. Just host your App on the cloud.
  • Mobile First Design: Now in the FAANG Digital era, all you need is an EMR on your mobile with a Text/ Audio/ Video calling plugin like Skype, WhatsApp, Team, Meet...etc.
  • EMR is Mandatory: Make sure the EMR output is in compliance with the NDHB/EHR/MDDS Digital Health Standards. EMR should have ability to push the medical records to a National PHR whenever it becomes available.
  • Connectivity: Internet 4G is required for Video calling. Internet 3G is enough for Audio calling and Text Consultation.
Functional Requirements as per Digital Health Policy of India:
  • Patient demographics & encounter / visit clinical summary should use the government published libraries of data elements & code directories from MDDS_EHR standards. There are 1000 + data elements and 144 code directories defined and available in PDF format to be used by application developers. (XSDs, CSV, JSON, XML formats for the same are available with Access Health International in open source)
  • Diagnosis & chief complaints- Diagnosis & chief complaints to be captured using WHO- ICD 10 code list.
  • Clinical Notes- SNOMED CT codes to be used that are published and available with NRCeS on their website with tools for implementation.
  • Lab & radiology Investigations- LOINC mapped with local investigation codes are to be used for all investigation orders to be paced through an EMR.
  • Procedures (non-diagnostics & radiology procedures) - SNOMeD CT is recommended to be used for creating/prescribing any procedure order for the patient. A telemedicine provider can download and use free SNOMeD codes for India by registering on NRCeS website.
  • Drug Prescription- An electronic prescription is required to be generated with a prescribing physician licence ID using NFI recommended Generics or Indian Drug Extension available on NRCeS website in SNOMed format.
  • Referral Management- Solution shall support an electronic referral and an E-referral note with standardized digital visit/encounter summary to facilitate "continuum of care" with futuristic place holders for Facility & doctor registry lookup services.
  • Health Information Exchange- NDHB recommends FHIR resource 4 to be used for clinical & health claim information exchange between providers and payers with indian specific semantic & terminology standards.
  • Note- A FHIR compliant Digital clinical summary structure & design (electronic encounter note ,electronic referral note and electronic prescription note) as per telemedicine guidelines & MCI guidelines, are readily made available in JSON format on www.openbodhik.in
----------------------

Relevant Clause by Clause Summary - Telemedicine Practice Guidelines - 25 March 2020

This constitutes Appendix 5 of the Indian Medical Council (Professional Conduct, Etiquette and Ethics Regulation, 2002Definition:‘The delivery of health care services, where distance is a critical factor, by all health care professionals using information and communication technologies for the exchange of valid information for diagnosis, treatment and prevention of disease and injuries, research and evaluation, and for the continuing education of health care providers, all in the interests of advancing the health of individuals and their communities.'

With telemedicine, there is higher likelihood of maintenance of records and documentation hence minimalizes the likelihood of missing out advice from the doctor and other health care staff. Conversely, the doctor has an exact document of the advice provided via tele-consultation. Written documentation increases the legal protection of both parties. <Interpretation>: Keeping Electronic Medical Records is now mandatory.

help patients adhere better to their medication regimens and manage their diseases better. Telemedicine can also enable the availability of vital parameters of the patient available to the physician with the help of medical devices such as blood pressure, blood glucose, etc management.

Unnecessary and avoidable exposure of the people involved in delivery of healthcare can be avoided by using telemedicine and patients can be screened remotely.

India’s digital health policy advocates use of digital tools for improving the efficiency and outcome of the healthcare system and lays significant focus on the use of telemedicine services, especially in the Health and Wellness Centers at the grassroots level wherein a midlevel provider/health worker can connect the patients to the doctors through technology platforms in providing timely and best possible care. <Interpretation>: Telemedicine Guidelines have to be read in conjunction with and will be governed under the ambit of India's Digital Health policy i.e. NDHM, NDHB Standards, EHR Standards and MDDS Standards for Health.

However, there has been concern on the practice of telemedicine. Lack of clear guidelines has created significant ambiguity for registered medical professionals, raising doubts on the practice of telemedicine. The 2018 judgement of the Hon’ble High Court of Bombay had created uncertainty about the place and legitimacy of telemedicine because an appropriate framework does not exist. <Interpretation>: All the ambiguity is now removed.

In India, till now there was no legislation or guidelines on the practice of telemedicine, through video, phone, Internet based platforms (web/chat/apps etc). The existing provisions under the Indian Medical Council Act, 1956, the Indian Medical Council (Professional Conduct, Etiquette and Ethics Regulation 2002), Drugs &Cosmetics Act, 1940 and Rules 1945, Clinical Establishment (Registration and Regulation) Act, 2010, Information Technology Act, 2000 and the Information Technology (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules 2011 primarily govern the practice of medicine and information technology. Gaps in legislation and the uncertainty of rules pose a risk for both the doctors and their patients.

It also spells out how technology and transmission of voice, data, images and information should be used in conjunction with other clinical standards, protocols, policies and procedures for the provision of care.

1.3.3 - All registered medical practitioners intending to provide online consultation need to complete a mandatory online course within 3 years of its notification. <Interpretation>: RMP must be trained on Telemedicine course within 3 years of this notification

1.4 - Classification of Telemedicine:
Communication - Real time vs Asynchronous
Purpose - First, Follow-up, Emergency
Individuals - RMP, Health worker, Caregiver, Patient

2.0 - Limitations of Telemedicine: <Interpretation>: It is difficult to establish the ID of the Patient and the RMP over Video/Audio/Text. Hence proper and sufficient ID proof has to be presented from both sides. Patient identification needs to be clearer, greater chance of imposters representing the real patient over a Audio Call. It is difficult for the RMP to do a Physical Examination. Only possible when there is a Healthcare Worker on the other side also.

3.0 - The professional judgment of a Registered Medical Practitioner should be the guiding principle for all telemedicine consultations: An RMP is well positioned to decide whether a technology-based consultation is sufficient or an in-person review is needed. Practitioner shall exercise proper discretion and not compromise on the quality of care.

3.2.2 - An RMP should verify and confirm patient’s identity by name, age, address, email ID, phone number, registered ID or any other identification as may be deemed to be appropriate. The RMP should ensure that there is a mechanism for a patient to verify the credentials and contact details of the RMP.

3.4.1 - If, the patient initiates the telemedicine consultation, then the consent is implied [Similar to Physical In Office Consultation]

3.4.2 - An Explicit patient consent is needed if: A Health worker, RMP or a Caregiver initiates a Telemedicine consultation.

3.5.1 - An RMP would use his/her professional discretion to gather the type and extent of patient information (history/examination findings/Investigation reports/past records etc.) required to be able to exercise proper clinical judgement. This information can be supplemented through conversation with a healthcare worker/provider and by any information supported by technology-based tools. If the RMP feels that the information received is inadequate, then he/she can request for additional information from the patient.If a physical examination is critical information for consultation, RMP should not proceed until a physical examination can be arranged through an in-person consult. RMP shall maintain all patient records including case history, investigation reports, images, etc. as appropriate. <Interpretation>: Data of the Current Consult and sufficient data of the past is required for providing the Consult. Digital or Non-Digital Data has to be kept by the RMP. How much Information required is Left to the discretion of the RMP but it has to be sufficient to support the diagnosis and treatment plan.

3.6.2 - Follow-Up Consult(s) means - The patient is consulting with the same RMP within 6 months of his/her previous in-person consultation and this is for continuation of care of the same health condition.

3.7.1 - If the condition can be appropriately managed via telemedicine, based on the type of consultation, then the RMP may proceed with a professional judgement to:
Provide Health Education as appropriate in the case; and/or
Provide Counseling related to specific clinical condition; and/or
Prescribe Medicines

<Interpretation>: RMP can prescribe Medicines over a Telemedicine Consult.

3.7.4 - Prescribing medications, via telemedicine consultation is at the professional discretion of the RMP. It entails the same professional accountability as in the traditional in-person consult. RMP may prescribe medicines via telemedicine ONLY when RMP is satisfied that he/ she has gathered adequate and relevant information about the patient’s medical condition and prescribed medicines are in the best interest of the patient. Hence, Prescribing Medicines is Left to the clinical judgement of the RMP as per the guiding lists given below:
List O - OTC with Any kind of communication mode.
List A - Re-Fills and reasonably safe medication after Video Consult.
List B - Follow-Ups with Any kind of communication mode.
Prohibited - Potential for Abuse, Scedule X, Narcotics etc. can not be prescribed.

3.6.4.2 - Prescription Format is given in the Annexure. RMP shall provide photo, scan, digital copy of a signed prescription or e-Prescription to the patient via email or any messaging platform o In case the RMP is transmitting the prescription directly to a pharmacy, he/ she must ensure explicit consent of the patient that entitles him/her to get the medicines dispensed from any pharmacy of his/ her choice. <Interpretation>: ePrescription is explicitly allowed. No need for physical signatures in ePrescriptions. RMP has to obtain explicit Consent of patient before sending ePrescription to the Pharmacy.

3.7.1.2 - Registered Medical Practitioner would be required to fully abide by Indian Medical Council (Professional conduct, Etiquette and Ethics) Regulations, 2002 and with the relevant provisions of the IT Act, Data protection and privacy laws or any applicable rules notified from time to time. Interpretation: All Telemedicine controls to be built as per IT Act, Data Privacy and Data Security regulations etc.

3.7.1.3 - RMP Protected from breach if the breach is attributable to Technology or a person other than the RMP. The RMPs should ensure that reasonable degree of care undertaken during hiring such services.

3.7.2 - MAINTAIN DIGITAL TRAIL/ DOCUMENTATION OF CONSULTATION: It is incumbent on RMP to maintain the following records/ documents for the period as prescribed from time to time. Log or record of Telemedicine interaction (e.g. Phone logs, email records, chat/ text record, video interaction logs etc.). Patient records, reports, documents, images, diagnostics, data etc. (Digital or non-Digital) utilized in the telemedicine consultation should be retained by the RMP. Specifically, in case a prescription is shared with the patient, the RMP is required to maintain the prescription records as required for in-person consultations. <Interpretation>: RMP is responsible for Maintaining Digital Trail or Documentation including Logs, Digital or Non-Digital patient records.

3.7.3 - RMP can charge a reasonable Fee for Consultation and should provide a receipt for the Fees.

4. - Telemedicine envisaged in 5 scenarios:
Patient to Registered Medical Practitioner
Caregiver to Registered Medical Practitioner
Health Worker to Registered Medical Practitioner
Registered Medical Practitioner to Registered Medical Practitioner
Emergency Situations

<Interpretation>: In 3 and 4 physical examination is possible. Gives greater visibility into the disease condition of the patient. RMP can prescribe medicine with more confidence.

5.4 <Interpretation>: Artificial Intelligence not allowed to Consultation. Artificial Intelligence can at best be an assistant the RMP.

-------------------------

Points to Ponder:
  • Telemedicine guidelines have Equated Telemedicine Consult with Physical in office Consult. All laws and regulations that apply to physical in-office Consult will now apply to Telemedicine Consults also.
  • All Liability is now on the Medical Practitioner. So commensurate Standard Treatment Guidelines [STG] should emerge. STG have to emerge for prescribing List A, B drugs.
  • Mandatory for Medical Practitioner to keep sufficient Medical records, of current and enough records of the past. In other words the Telemedicine marketplace has to get together to build an interoperability framework across facilities and geographies to enable the longitudinal patient health record [PHR].
  • RMP absolved of Liability if problem attributed to Technology - So Contributory negligence for Telemedicine software and service provider should also be spelt out.
----------------------------------

Telemedicine Notes shared by Dr Pankaj Gupta for the Medical Fraternity

Labels: , , , , ,

Friday, January 31, 2020

Health Systems for a New India: eObjects #Opensource Building Blocks

 



Here is a sequence of events over the last 8-10 years that lead to the #Opensource eObjects.

India has been majorly a paper-based Healthcare System. However, there have been pockets of success in transforming paper-based processes to electronic systems. Max Healthcare was one such initiative that took a leap of faith well before the rest of the market could even think in that direction. I happened to be part of that journey with an eclectic team that got dispersed at the end of the project but continued the journey in their individual capacities. Who could think then that such small individual efforts could come together later for the transformation of the country as a whole? It probably happens once in a lifetime. Serendipity positioned a very strong National leadership that could collate all these pieces together for building the National Digital Health Blueprint.

It all began when Max Healthcare partnered and outsourced its IT infrastructure support to Dell Services formerly Perot Systems in September 2009 for developing and maintain their IT operations across all Max Hospitals in India. This unique partnership provided significant value to Max in terms of enhancing the quality of services and reducing the treatment costs. While doing the transformation at max healthcare the team stumbled and fell and then learnt to walk again. For India the full implementation of EHR, Registries, Meta Data, Master Code Directories and Interoperability were seen first time in action here. Max Healthcare gave invaluable learnings of applying the global standards and architectures to Indian settings, something that had never been done before!

Looking at the successful transformation of Max Healthcare, Perotsystems was contacted by the Ministry of Health India to conduct current IT systems study in health sector in India and do the health checks. Due to merger of PerotSystems and Dell Services, Dell Services could not undertake the task. Later I picked-up that work and submitted the Public Health IT Study Report through Sector Innovation Council on Health, India. Since it was not possible to study every system being in use in a country like India, I and my team picked up the representative set that was diverse enough to extract critical findings that needed immediate attention. Later these findings and recommendations from the Public Health IT study became important part of Twelfth Five Year plan.

Setting up Meta Data and Data Standards was an initiative taken by the Ministry of Electronics and Information Technology under National e-Governance Plan (NeGP). It intended to promote the growth of e-Governance within the country by establishing interoperability across e-Governance applications for seamless sharing of data and services. Domain-specific committees were constituted under MDDS initiative. MDDS for Health Standards committee was one such initiative, which was constituted on September 2012 under the chairmanship of Joint Secretary MoHFW in pursuance of communication received from Secretary, Ministry of Electronics and Information Technology (MeitY).

Role of Meta Data and Data Standards in Primary and Public Healthcare
MDDS for Health Data Dictionary
Facility Registry: NIN HFI Project Report
National Digital Health Blueprint

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 NDHB 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.

My ACCESS Health Digital team got an eGovernance Award for the work.

The details of eObjects are published in #Opensource under MPL 2.0 #Opensourcesoftware license on OpenBodhik blog: www.openbodhik.in
FHIR based eObjects published in CSV/XML/JSON
Library of 1000 Data Elements and 140 Code Directories published in XSD
National Formulary of India - Generics Drug List Published in CSV
Healthcare Delivery Information System [HDIS] Minimum Viable Product [MVP] Definitions and Microservices Code Published

eObjects also published by ExpressHealth

eObjects referenced extensively by Nachiket Mor in his paper and book published by John Hopkins USA


Labels: , , , , ,

Friday, December 14, 2018

India has its own National Digital Health Standards Now





Role of #DataQuality and #DataGovernance in #PrimaryHealth and #PublicHealth

Dr Pankaj Gupta, Primary Health Care 2017, 7:1(Suppl), DOI: 10.4172/2167-1079-C1-005, ISSN: 2167-1079 PHCOA.
Meta Data and Data Standards [MDDS] for Health was written in 2013, 
the MDDS for Health was Released and Notified in August 2018, 
now included in the National Digital Health Blueprint [NDHB] in 2019.
Abstract:

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

Specific On the Ground:

E-Governance systems for Health which are operational today include a variety of applications such as Mother and Child Tracking System (MCTS), Health Management Information System (HMIS), Hospital Information Systems (HIS), Supply Chain Management for Drugs and Vaccines, Integrated Disease Surveillance Project (IDSP), Revised National Tuberculosis Program (RNTCP) etc. There are states with over 30 distinct operational systems. The Private Healthcare sector also eludes transparency by hiding behind an equally diverse maze of complicated data silos.

1. Introduction:

The Metadata and Data Standards is an initiative taken by Ministry of Communication and Technologies under National e-Governance Plan (NeGP). The intent was to promote the growth of e-Governance within the country by establishing interoperability across eGovernance applications for seamless sharing of data and services. Under the MDDS initiative domain specific committees have been constituted in priority areas. The Health Domain MDDS Committee was one such initiative, which was constituted on Sept 2012, under the chairmanship of Joint Secretary in pursuance of communication received from Secretary, Ministry of Electronics and Information Technology (MeitY) previously known as Ministry of Communication and Technology.

Post formation, the Committee had initial orientation meetings on Metadata and Data Standards development for health domain. After initial discussions, National Health System Resource Centre was constituted as secretariat for the committee. To help develop Meta Data & Data Standards, two agencies were brought on-board following a proper selection process based on their merit on Health informatics. The due diligence was thoroughly done to study the landscape of existing health domain by involving all relevant stakeholders and knowledge partners including Program Officers and System Managers of Central and State Health IT Systems. As part of terms of reference, a thorough study of global data and interoperability standards were taken into account.

Initially generic data elements were extracted from the existing health IT systems. However these existing systems were geared towards addressing specific program requirements which was falling short to address the vast scope of Health domain. The other challenge was that data elements of these systems were not aligned with global data standards. Efforts were made to adopt and modify global standards in such a way that these existing applications could easily be upgraded to MDDS standards.

The exercise yielded to approximate 1000 data elements which were regrouped and formatted into 39 entities for better assimilation and presentation. These data elements will serve as the common minimum data elements for development of IT applications for various sub domains of health care. This is intended to facilitate interoperability among all these applications.

2. Purpose of Health Domain MDDS

The adoption of Metadata and Data Standards across healthcare IT systems will enable easier, efficient exchange and processing of data. It will also remove ambiguities and inconsistencies in the use of data. Once the MDDS standards are adopted by all eGovernance applications in healthcare, the interoperability would be easier.

Inevitably the migration to these new Standards may appear at the outset to be costly and time-consuming to some parts of government. However this burden should be outweighed by reduced development costs through the use of the agreed schemas that use these standards. It is also expected that new IT system in healthcare, as and when they come will use MDDS standard and will participate in information sharing and data exchange.

3. Structure of the MDDS Standard

The Metadata and Data Standards in Health Domain are developed following below mentioned guidelines set by MeitY. a. Metadata and Data Standards – Demographic v1.1 b. Operational Manuals for formulation of Domain specific MDDS c. Institutional Mechanism for formulation of Domain specific MDDS

As per the guidelines the MDDS Standards are broadly covered under three sections as given below. 1. Data Element Quick Reference (ref: Part-II) 2. Code Directory Quick Reference, Sample values and their structure (ref: Part-III) 3. Data Element Metadata (ref: Part-IV)

Data Elements common across all health domain applications are listed, defined and standardised in the Data Element Quick Reference document (Part II). This list gives brief description about the data elements in addition to the data format & size it follows. For easy readability the data elements are grouped in various entities. However these entities should be considered as logical grouping only and users are free to regroup these data elements as per their need. Under the quick reference document, each data element is classified into four categories to help identify following:-

Data elements which can be used from health domain to other domains (Prospective Generic Across Domain (Viz.: PGAD) Data elements which are common within health domain (Prospective Generic Within Domain (Viz.: PGWD)),  Data elements which are customised from already standardized generic data elements (Custom (Viz.: C))  Data elements which are application specific in health domain (Application (Viz.: A)).

Health Domain MDDS has followed ISO/IEC 11179 standard for development of data elements, value sets and code directories. As per the conceptual design of data element in ISO/IEC 11179, each data element can have a single value or multiple values attached to it. The data element which has a single value will be complete in itself and if a data element has a limited list of values associated with it, then those values will be a part of value list for that data element. However if there is a long list of complex values for the data element, they have been put in relevant code directories. Values in the code directories can grow and mature with review and modification.

Code Directory Quick Reference document is ready reference to the code directories developed (Part III). This indicates name of code directory, source of code directory and the ownership rights for each of the code directory. The metadata of each code directory is given in the Code Directory Meta Data and the sample values for each code directory are also populated in the Part III of the MDDS Standard. The sample value for each code directory is populated in the Part III. Some code directories (i.e. Inventory Store Master; Employee Master; Service Tariff; Package; OT Preference Card; Blood Bank Master; Ward; Bed; Authority; Supplier Master; Laboratory Master; Floor Master), which are highly implementation specific, no sample values are populated and it is expected that each implementer will populate the values in these code directories and help MDDS committee to enrich these code directories. In addition there are few code directories (i.e. Test Result Reference Range; Homeopathic Generic Drug; Non-Drug Item Brand; Homeopathic Brand Drug; Brand Drug; Manufacturer Master; Equipment Classification; Equipments; Ayurvedic Generic Drugs; Ayurvedic Brand Drugs; Unani Generic Drugs; Unani Brand Drugs) for which standard value set is presently not available. Domain specific Working Groups would be constituted to help populate these code directories. Work is presently going on for population of remaining 8 Code Directories (Facility Master; Facility Type; Ownership Authority; Facility Area Coverage; Facility Beds; Facility Human Resources Type; Administrative Linked or Referral Facility; Facility Services Master) which are part of the National Health Facility Registry initiative of MoHFW.

4. What is Common Data Elements

The Health Domain MDDS Committee provides a list of data elements that will serve as the common data elements [CDE] for any new application being developed in Health domain.

The need for the CDE arose because most of the Healthcare-IT applications are being developed without any standards by different agencies and vendors in public and private sector in India. Later it becomes difficult to connect the systems and make them talk to each other because they were never designed for that purpose.

Due to the inherent complexity of Health domain - It is difficult to create minimum set of data elements that every sub-domain must adhere. Each sub-domain’s minimum data element may not be completely applicable to other sub-domains – meaning ‘My minimum need not be your minimum’. For example the Lab Order data elements required at Primary care setting will be far less than the Lab Order data elements required at Secondary care and Tertiary care settings.

Therefore the health domain MDDS committee has come up with the Common Data Elements. CDE will provide most of the data elements required for any new Healthcare application to be built. However the users may add additional data elements above and beyond the CDE for their local needs. Using CDE the applications would be able to share information with each other. There are two ways to use CDE, either use CDE from the design phase of application development or make applications compliant with the CDE post implementation. The latter option is cost and efforts intensive and may be difficult to implement. It would be easy to use CDE from the design phase of application development.

While developing CDE the attempt was to be universal. However the healthcare is so vast that some specific data elements on the fringes may have been left out inadvertently. CDE is intended to be a living document and a designated Health Domain MDDS Committee will have the authority to add any new data elements, values or code directories that were left out at this stage or that may emerge as a result of natural evolution of the Healthcare domain. When new applications do not find the relevant data element or values for their use, they will have to use ‘Free Text’ data element or ‘Other’ Value from the code directory or value list. Though the usage of ‘Free Text’ data element or ‘Other’ Values will have to be discouraged in principle; however this usage of ‘Free Text’ data element or ‘Other’ Values has to be regularly monitored by the Health Domain MDDS Committee and used as valuable feedback for the next versions of the CDE.

Therefore CDE is intended to be a living document and a designated Health Domain MDDS Committee will have the authority to add any new data elements, values or code directories that were left out at this stage or that may emerge as a result of natural evolution of the Healthcare domain.

Why is Common Data Elements Required?

Organizations often want to exchange data quickly and precisely between computer systems. The need for the CDE arose because most of the Healthcare-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 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 insurance company/government, the recipient application should be able to understand and re-present the same meaning of bill information.

5. Health Domain MDDS: Conceptual Framework

The holy grail of Healthcare is the Provider – Patient relationship. The entire common data elements have been designed by keeping the Provider – Patient relationship in mind rather than either entity as the centre. The CDE has been designed based on the standard ISO/IEC 11179.This standard is a result of the following principles of semantic theory, combined with basic principles of data modelling.

Conceptual Domain: The first principle from semantic theory is the thesaurus type relation between wider and more specific concepts; For Example- the wider concept ‘Order’ has a relationship with similar more specific concept Pharmacy Order And immunization order. Therefore the CDE has created Pharmacy Order and Immunization Order entity.

Concept: The second principle from semantic theory is the relation between a concept and its representation. Different synonyms or closely related keywords can convey the same concept. For Example –The number of times the drug/medication has to be taken at what interval is a concept. ‘Frequency of Drug’ and ‘Frequency of Medication’ are different representations of the same concept.

Data Element: The basic principle of data modelling is the combination of an Object class and an Attribute to form a more specific ‘data element concept’. For example- the abstract concept ‘Frequency of Medication’ is combined with the object class ‘Medication Order’ and is associated with Attribute ‘Frequency’ to form the data element concept ‘Medication Frequency’. The standard must select the most appropriate keyword as the representation of the concept. In the above case the o Object: is ‘Medication Order’ and, o Attribute: is ‘Frequency’

Value Domain: A value domain is the permitted range of values for a Concept. If the data element concept has a single value then it will remain as a single data element. If it has a limited set of values attached to it then it will have a value list. If the data element has a long list of values that are liable to change or be modified due to the business needs of the Health domain then it is advisable to create a Code Directory for those values. For Example- For data element concept ‘Medication Frequency’ the related Code Directory will have values: BID, TID, QID, HS, SOS, and Stat.

The associated Code Directories are drawn from standards such as –
  • ICD-10 for Diagnosis and Classification: ICD is used to classify diseases and other health problems recorded on many types of health and vital records including death certificates.
  • LOINC for Lab and Diagnostics: LOINC is a universal code system to identify laboratory and clinical observations to facilitate exchange and storage of clinical results or vital signs for patient care and research
  • Procedure & Radiotherapy Codes (preferred primary terminology): SNOMED CT.
  • WHO Morbidity list: The noun morbidity means "the quality of being un-healthful." The special tabulation list for morbidity published in ICD-10 volume 1 consists of 298 groups defined by their ICD-10 codes.
  • WHO Mortality list: The noun mortality means "Death" The special tabulation list for mortality published in ICD-10 volume 1 consists of groups defined by their ICD-10 codes.
  • WHO ICF: The International Classification of Functioning, Disability and Health (ICF) are used for defining functionality & disability.
  • WHO Verbal Autopsy Standards: Is list of standards for causes of death with mapping to ICD-10 Codes.

6. Identifiers and Registries

For data exchange across applications, accurate identification of each person/ facility receiving or providing healthcare services, and also anyone accessing or using this information is extremely important. It is critical that a set of standards be established for identifying the Facility, the Medical Provider, Patient, and all others handling healthcare data so that information across different locations can be exchanged easily and securely.

An Identifier could be a number, image (e.g. Bar Code or Blackberry ID), Biometrics (e.g. finger print or retinal scan), Radio Frequency Identifier Tag (RFID), Smart Card or a combination of these. Considering that none of these identifier standards exist today in Public Health space- The Health Domain MDDS Committee proposes basic number based identifiers. The standard can be upgraded to include Alternate Identifiers such as Bar Codes, RFIDs, Digital Signature etc., as the healthcare industry matures. For now appropriate Data Elements have been created to capture information about these Alternate Identifiers.

With regards to the nomenclature of the Identifiers some qualifiers were followed to maintain the uniformity.

a) Identifiers which were drawn from established sources were used as it is and no change is made in their names. e.g. Unique Identification Number (UID), PAN etc.

b) Identifiers which are proposed to be used uniquely and uniformly across states are termed as “Numbers” e.g. Unique Facility Identification Number, Alternate Unique Identification Number etc.

c) Identifiers where code directory or value list from established source is used are termed as ‘Codes” e.g. Diagnosis Codes (ICD10 Codes) etc.

d) Identifiers which were transaction specific are termed as “Identifiers or IDs”. E.g. Employee ID, Document ID etc. However some of these can come from code directory master but are named as IDs because they are transaction identifiers to be populated at the time of implementation.

I. Facility Identifiers: Facility Identity management is complex – therefore a Facility Code Directory is created to give a structure to it. This Facility code directory will serve as a Master to which all the Applications will refer. Two set of identifiers are proposed to uniquely identify each facility-GUID & NIN.

a. Global Unique Identifier (GUID) – This data element is a 16-bit number, which will be generated following a standardized algorithm by system. An example of a GUID in its standard form is 40e74fae-c0ab-11dfb090-0017f2300bf5. GUID will be used at the back-end to uniquely identify each facility. GUID will guarantee global uniqueness of each facility no matter where or by whom they are generated. All prospective systems need to follow standard algorithm in their backend to use GUID.

b. Facility National Identification Number (NIN)-NIN is a 10 digit random number given for each facility (public & private) engaged in providing some form of health care services. NIN will be used at the front-end with some form of human readability. There are two ways to do this.  Give the facility a number with facility related information embedded in it (e.g. ABC-13-05-0001, where AB&C represents State, District & Block respectively and next two digits represent year of facility formation and next two digits represent type of facility and last four digits represent the facility itself). However this approach has certain challenges as facilities might upgrade or facility attributes change due to administrative, geographic or political realignments.  The other way of doing it is by giving a unique running number to each facility without making this number dependent on any other factor. Where the facility related information can be added as an attribute to the NIN. The Health Domain MDDS Committee has adopted the later approach to uniquely identify each facility.

Why two identifiers for a facility? Although each facility will also be given a sequential 10 digit integer number (NIN) and this is used as a unique facility identifier by all users, still the uniqueness of these codes will be dependent on database system which generate these numbers, which still does not necessarily guarantees to be always unique e.g. if the database is ported from one Database Management System (DBMS) to another, the unique sequential number (or auto increment primary keys of tables) will change. In order to avoid this problem GUID is proposed along with NIN.

Summary:
  • MDDS for Health is a library of 1000+ Data Elements logically organised into 39 Entities. Data Elements are Containers that carry the Semantics.
  • MDDS has over 140 Code Directories providing the values that go into the Data Element Containers and give the meaning to the Container.
  • MDDS leaves it to the market to organize the Data Elements into Minimum Viable Product Definitions or Minimum Viable building blocks.
  • Most of these standards are drawn from global standards however these are developed keeping in view local health information systems requirements.

---- Read the Rest in # MDDS for Health Domain Standards on STQC website --

Date Line:

2011, 12th Plan requested for Min. of Health and Family Welfare [MoHFW] and Ministry of Electronics and Information Technology [MeitY] to come together and write Digital Health Standards for India; references to this recommendation are available in the 12th Plan. Public Health IT Study Report coined the term national ehealth authority [#NeHA], now being called national digital health authority [#NDHA]. national health systems resource center [NHSRC] had proposed Health Information exchange [HIE] in the Public Health IT Study Report. You can see it here under Studies and Evaluations: http://nhsrcindia.org/resource-detail/studies-and-evaluations/OTI0

2012, Dr Pankaj Gupta spoke about Digital Health Standards, Health Information exchange [HIE] at the WITFOR. You can read it here: http://www.witfor.org/images/stories/presentations/dr.%20pankaj%20gupta%2C%20partner%2C%20taurus%20glocal%20consulting%2C%20india.pdf

Dr Pankaj Gupta again spoke about Digital Health Standards, Health Information exchange [HIE] @ the eHealth conference Hyderabad 2012. You can watch it here: https://www.youtube.com/watch?v=v048j04FCd0

2013, Dr Pankaj Gupta and Dr Amit Mishra were leading the team that wrote the meta data and data [MDDS] standards for health domain. This was written as a reference Architecture for Digital Healthcare Software and as a framework for Interoperability - Semantic, Syntactic and Institutional Interoperability. MDDS is an Meta Data and Data Standard defined by Ministry of Electronics and Information Technology [MeitY] mandated to be implemented across Ministries.

#MDDS for Health: Committee on Health Domain Metadata and Data Standards has approved the Health Domain MDDS standards. The MDDS is intended to bring semantic interoperability among all health IT system. This is a prerequisite for establishing interoperability among disparate health information systems. The standards were developed following a rigorous consultation and review process and public opinion was also sought and incorporated on these standards.

2016, #NIN_HFI: Completed the National Identification Number for Healthcare facilities of India [NIN_HFI] project. NIN is like a AADHAAR card for all Healthcare Facilities. Facility Registry of the HIE and NHIN will be NIN_HFI. It is based on the Facility Registry defined in the Metadata and Data Standards (MDDS) of Health.

#NIN_HFI is a unique identification number, which a key requirement for achieving inter-operability and creation of EHRs, is being assigned to all health facilities (both public & private) to facilitate inter-operability among health IT systems deployed. So far more than 2 lakh Public Health Facilities have been allocated NIN. The process for setting up mechanism for allocating NIN to private facilities is underway. In other words the National Identification Number for Healthcare facilities of India is the Healthcare Facility Registry.

2017, Role of meta data and data standards in primary and public healthcare, 3rd Annual Congress & Medicare Expo on Primary Healthcare, Clinical & Medical Case Reports. April 17-19, 2017 Dubai, UAE. Pankaj Gupta, Primary Health Care 2017, 7:1(Suppl), DOI: 10.4172/2167-1079-C1-005, ISSN: 2167-1079 PHCOA. https://www.slideshare.net/PankajGupta9/role-of-meta-data-and-data-standards-in-primary-and-public-healthcare

2018, # MDDS for Health Domain Standards Notified by the STQC, Meity, GoI

References:

# PMJAY #AyushmanBharat launch speech by PM Modi.

# Healthcare For All - Four Years of Transforming India (May 2014 - April 2018) - Ayushman Bharat, MDDS for Health, NIN Facility Register..

# Public Health IT Study Report

#MDDS for Health: EHR Standards, Public Health IT Standards, Interoperability Framework and Health Information Exchange

#NIN_HFI: Will serve as the Healthcare Facility Registry https://nin.nhp.gov.in/about_nin2hfi.php

#Digilocker: Will serve as the HIS/LIS/RIS/EHR Document Registry: http://indianexpress.com/article/india/india-news-india/digital-india-scheme-to-focus-on-health-sector-arvind-gupta/

Building a healthy India: The government’s National Health Policy will improve health outcomes and reduce out of pocket expenses - JP Nadda. The Policy recommends establishing federated national health information architecture, consistent with Metadata and Data Standards (MDDS) http://blogs.timesofindia.indiatimes.com/toi-edit-page/building-a-healthy-india-the-governments-national-health-policy-will-improve-health-outcomes-and-reduce-out-of-pocket-expenses/

Informatics in Healthcare - The Statesman: http://epaper.thestatesman.com/c/18200138

Labels: , , , , ,