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

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

MAXimising Benefits

Max Healthcare IT Transformation Cover Story in Ehealth Magazine Eletsonline. Perot systems corporation Total ITO. Largest VistA EHR implementation outside the Veterans Health Administration (VHA) - U.S. Department of Veterans Affairs and outside the USA. The institutional memory of the grand success was lost in the merger of Perotsystems with Dell Services further merged with NTT Data. Though the success achieved in Max is unprecedented and still largely unmatched. Lot of firsts here. First Indian Hospital chain to go on a private cloud. All Hospitals working from the same HIS/EHR/LIS with common IDs for Patients, Doctors, Facilities. Records having Diagnosis, Procedure, Lab Standard Code Sets.

Published in eHealth Magazine : 01 October, 2010, Read the details

The IT outsourcing deal puts Max Healthcare on the roadmap for becoming the best IT-enabled hospital chain in the country The Indian healthcare system has recently realised the potential of information and communication technologies in completely transforming care delivery at hospitals. The industry witnessed its first complete IT infrastructure technology outsourcing deal in September 2009, when Max Healthcare and Dell Services (formerly Perot Systems) partnered for developing IT operations at all Max Hospitals. The cost of the deal, Rs 90 crore (excluding infrastructure cost), is an indicator of the increased priority that is now being given by Indian hospitals to IT, which is an extremely positive sign. As per the agreement, the deal will last for ten years, out of which one year has already passed, and a lot of positive transformation has already been noticed. The unique partnership is not only expected to provide a lot of value to Max Healthcare in terms of enhancing the quality of services and reducing treatment costs, but it will also be a great learning experience for Dell, which marked its entry into the Indian healthcare market with this deal.Status update Post its inception in September 2009, the ITO deal will last for 10 years and which, according to Dell, will comprise of three major phases – transition, improving productivity and optimisation.

As one year has passed, the transition phase is almost over. During this phase Dell installed the entire IT infrastructure for Max, by migrating the already existing IT infrastructure to a modern infrastructure. The entire data centre of Max, which was housed in their Okhla office, was migrated to the Dell facility in Noida. To reduce hassles, the shifting work was done during off hours on weekends, so that the work at the hospitals does not get affected. The entire process lasted for a couple of months and currently all Max Hospitals are running from the data centre housed in the Dell facility in Noida. The servers and network devices have been installed with monitoring devices that generate alerts in case a problem arises. There is also a situation management process in place to ensure that even the problems of highest criticality get resolved within a definite period of time.

Original publication for Reference: http://ehealth.eletsonline.com/2010/10/11436/

Summary of outcomes beyond the published article: Max Healthcare was the largest ever full ITO and Clinical Transformation Account of Perotsystems International. $20M deal across multiple years. Total Business Transformation done including technology, process, people and business. This includes Enterprise Architecture, Operations and Projects:

Phase I: Infrastructure Upgrade completed

1. Centralized Service Desk for L1 support and triage to L2 and L3 teams
2. Converted the P2P network to a MPLS private cloud
3. HIS and all other software applications of 7 Max hospitals are now running from the Dell data centre
4. HIS re-engineered and stabilized to take the load of new environment
5. Physical, Network and Data level security established
6. Operations management as per SLAs
7. Governance process for decision making
8. Integration with Medical Devices - ICU, ECG, EEG, LIMS, Lab Analysers, CT, MRI, Modalities, RIS, PACS, Surgery, Scopes etc.
9. Bar Code, Medication Administration and Nursing Devices
10. Computer on Wheels, Mobile CPOE Orders Devices
11. Retail Pharmacy, CRM, Physician Mobile, Remote Monitoring Devices

Phase II:

1. Customization of Opensource VistA Electronic Health Record System. Max Healthcare is the largest VistA implementation outside the VA and anywhere outside the USA.
2. Implementation of CPOE, CDSS, BCMA, ePrescription
3. Developed standard master data e.g. Service master, Lab master, Drug master, etc.
4. Order sets, Notes Templates
5. HL7 based Enterprise Application Integration using Mirth.
6. Clinical transformation as per ADOPTS methodology

Business Benefits realized by Max Healthcare:

1. Private Cloud IT Infrastructure: plug-n-play environment for new facilities
2. Business downtime due to infrastructure and HIS outages is history
3. Process Re-Engineering -- 1000 beds in 7 Hospitals; expanded to 1500 beds in 11 Hospitals.
4. Standardized operations without disruptions reduced the waste and improved the topline.
5. Near paper-less, > 95% Adoption in Clinical.
6. Achieved full NABH and HIMSS Stage 6 accreditations later.
7. Hospital was able to attract FDI investments.

The institutional memory of the grand success was lost in the merger of Perotsystems with Dell Services further merged with NTT Data. Though the success achieved in Max is unprecedented and still largely unmatched.

Read the details

Key Note Address @ Science and Technology Week JWTC GE Bangalore

I got a rare honor: I was invited by GE to deliver a Key Note Address @ the Science and Technology Week in JWTC GE Bangalore on 16th May 2016. I spoke about the New Healthcare Aggregators: SMAC and IoT.

The era of hierarchical command and control is over. Now is the time for horizontal networking across Communities of Practice [CoP]. Whatever gets the maximum likes becomes the In Thing. Whatever is the In Thing gets used the maximum. Students are learning more from the online networking than from the formal classroom and professors. Research will reach the point of use as soon as it gets published. Primary care Providers in semi-urban and rural areas will have access to latest therapeutic recommendations. The old Adage that 'Knowledge is the only form of power that is not expendable but grows when shared' has become true.

There is a huge Vacuum in Indian Healthcare-IT space. Large Healthcare-IT vendors have exited the market. Either they lost interest and exited or got bought out. Also the market is moving from client-server to cloud and from Capex to Opex models. New cloud based players are small in size and yet to reach enterprise class. Existing players are not able to shift out to cloud because of their long term negotiated contracts in client-server model. The time is now when full conversion of Enterprise class to SMAC will happen anyways. Healthcare CIOs can keep eyes closed or tighten the belt and ride the Digital wave.

https://www.linkedin.com/pulse/new-healthcare-aggregators-smac-iot-dr-pankaj-gupta

Medical Tourism Challenges

I had written this list of challenges for Medical Tourism in 2008 from a US perspective. I am revisiting it: Though Medical Tourism from US never happened but the same challenges still remains valid. I am surprised no one have really filled the gaps in the medical value travels yet.

1. A reliable intermediary is missing in the Medical tourism business. Mostly the patient himself/herself or a relative or a clinician friend acts as the intermediary to negotiate a host of things that need to be done for the patient to go offshore and get a treatment done. Will a intermediary agency ever be able to develop the credibility to deliver on Medical Tourism promise? 

Interpreters or better known as healthcare facilitators are becoming the marketing middle-men to strike deals with the Doctors and ferry the patient around. This is not how Medical Tourism was intended to operate! 

2. A host of service providers are required to come together to offer a reliable Medical Tourism service. Service providers such as Hospitals, Insurance, Telemedicine, HIS/EMR, Call centres, Data processing KPO and Travel agencies are so diverse and different that they have nothing in common; yet they have to come together to deliver on Medical Tourism promise. Will this ever happen? I dont know!

3. All the Medical Tourism is coming from GCC and Afghanistan. Patients from Russian union, Europe, US still remains at large.

4. Most of the funding is out-of-pocket cash. Hawala galore! Where are the Insurance payers?