Demographic information including a unique identifier is necessary in a health record system in order to capture identifying information as well as identifiers for linking other medical artifacts logically as well as physically. All health record systems must therefore adhere to the following standards for capturing information related to patient demography and identifiers:

MDDS – Demographic (Person Identification and Land Region Codification) version 1.1 from E-Governance Standards, Government of India

Implementation Guideline: Implementers must insure that health record application is able to capture all data fields as provided in the above two standards for completeness. It should also ensure that the system is able to interoperate (receive/import/send/export) all demographics information as provided in above two standards as per demand, i.e. when requested for demographics data in MDDS compliant format it should generate artefacts (file, message, etc.) as per that standard. Where codes related to location, authority, type of organization etc. are required, they should be taken from the MDDS-Demographic Standard.

A health record system must have provision to include patient identifiers of following types:

1.UIDAI Aadhaar Number (preferred where available)

2.Both of the following in case Aadhaar is not available:

2.1Local Identifier (as per scheme used by HSP)

2.2Any Central or State Government issued Photo Identity Card Number

Implementation Guidelines:

Implementers must ensure that the Aadhaar number, where that is available, be used as the preferred identifier to serve as the unique health identifier. In case the Aadhaar number is not available, the system should allow a user to insert more than one (minimum of two) identifiers for each patient along with its scope and provider (as given in above mentioned patient demography standards) in the system. In situations where identity of patient cannot be obtained or ascertained, temporary identifiers may be used (as per scheme used by HSP) and later confirmed identifiers may be inserted (while making earlier ones as inactive).

Identification of Patient across EHR systems: Due to lack of mandate for use of Aadhaar or any such alternative(s) national unique identifier, it is difficult to match patient records when exchanging them between two EHR systems. This may lead to situations where different combinations of local identifier and photo identity card numbers of the same person are used at different locations and/or in solutions. Thus, a single person may get to have different identities under which his/her records are captured. A conflict resolution process may be required to help resolve such cases. At this time, there is no direct solution available other than to use smart (possibly heuristic) algorithms to attempt to match records without or with intervention/confirmation of a human supervisor. Such an algorithm may use name (phonetic or spelling), address (full or parts), date of birth / age, gender, or other such matching details to mark incoming or searched records as possible or exact match before amalgamation or subsequent use. ISV may additionally need to provide the ability to merge/demerge patients to support this process within their solutions.

ARCHITECTURE REQUIREMENTS AND FUNCTIONAL SPECIFICATIONS

A health record system must meet architectural requirements and functional specifications to remain faithful to the needs of service delivery, be clinically valid and reliable, meet legal and ethical requirements, and support good medical practices. Therefore, a health record system must conform to the following standards:

Implementation Guideline: Above two standards, despite being extensive, do not represent the full set of specifications and requirements that need to be met by a health record system or its many variants (PHR, etc.) or all possible use cases. The above mentioned standards are to be used as minimum set to be used within the scope of implementation as per relevance to the system being developed / deployed.

LOGICAL INFORMATION REFERENCE MODEL AND STRUCTURAL COMPOSITION

A health record system must accumulate observable data and information for all clinically relevant events and encounters. For this purpose, it is important to have common semantic and syntactic logical information model and structural composition for captured artefacts. Unless the data being captured is standardized, its communication and understanding may not be same across systems. Therefore, a health record system must conform to the following standards:

ISO 13940 Health Informatics - System of Concepts to Support Continuity of Care

Implementation Guideline: The ISO 13940 (also known as CEN ContSys) is to be generally used for purpose of modelling and describing concept system and organize information objects. While ISO 13606 set of standards are basic reference model and related specifications, openEHR provides ISO 18308 conformant platform-independent implementation harmonized with ISO 13606 standard. Implementers are free to design internal structures, databases, and user interfaces as per their requirements and preferred technology platforms but structural composition for clinical data/information artefact must be logically similar to Reference Model given in above standards. openEHR Operational Templates (OPT) adopted by an implementation, are to be public and free in required format for other implementers to ensure interoperability among them.

MEDICAL TERMINOLOGY AND CODING STANDARDS

In order to have semantic interoperability between different health record systems, it is necessary to follow a common terminology and coding system standards to express unambiguous meaning of data captured, stored, transmitted, and analyzed. It is also important to have these terminologies and codes in computer process-able format to aid automation and ensure that data is in an analyzable state at all times. Therefore, a health record system must conform to the following standards:

1.Primary Terminology: IHTSDO - SNOMED Clinical Terms (SNOMED CT)

Implementation Guideline: A health record system must use SNOMED CT as the primary internal encoding system for all clinically relevant, including dental, nursing, substance/drugs related information. IHTSDO SNOMED CT code shall also be used while communicating clinical information to other health record systems. SNOMED CT concept codes (as pre-coordinated or as post-coordinated expressions) are to be used for all hierarchies covered under the standard unless otherwise provided in this document. It shall also be the coding system that must be used internally in other information storage and communication standards such as openEHR archetypes, HL7, DICOM, etc. IHTSDO releases SNOMED CT twice annually.

Implementation Guideline: LOINC coding is to be used for processing results and reports with Laboratory and Imaging Information Systems. N.B.: SNOMED CT to LOINC coding interchange map is available from IHTSDO and Regenstrief Institute.

3.Classification Codes: WHO Family of International Classifications (WHO-FIC)

3.1WHO ICD-10: International Classification of Diseases (ICD) and its derivative classifications

3.2WHO ICF: International Classification of Functioning, Disability and Health (ICF)

3.3International Classification of Health Interventions (ICHI)

3.4International Classification of Diseases for Oncology (ICD-O)

Implementation Guideline: WHO FIC codes are primarily used for aggregated information and statistical/epidemiological analysis for public health purposes derived from health records that contain patient care related information as well as information that is crucial for management, health financing andgeneral health system administration. While SNOMED CT is to be used by health record systems for terminology, generated classification-based reports may require the use of WHO FIC codes. Classification based reporting, for statistical or regulatory purposes, may continue to use WHO FIC codes as mandated by the health regulatory, intelligence, and various research bodies. N.B.: SNOMED CT to ICD-10 coding interchange map is available from IHTSDO and WHO.

DATA STANDARDS FOR IMAGE, MULTIMEDIA, WAVEFORM, DOCUMENT

A health record system stores data records and files of various types in support of clinical functions. These data elements serve the purpose of documentary records of various diagnostic and prescriptive data or information generated. Therefore, a health record system must conform to the following standards for such data:

Implementation Guideline: NEMA DICOM PS3.0-2015 is a comprehensive standard for handling and managing image (series or single), waveforms (such as those in ECG/EEG), audio (such as those in digital-stethoscope) and video (such as those in endoscope, ultrasound, etc.) data in medicine. A health record implementation is required to implement relevant DICOM Information Object Definitions (IODs) for supported data types in Part-10 compliant files. Where required and relevant, other features of standard such as services, display, print, and workflow may be implemented.

2.Scanned or Captured Records:

2.1Image: JPEG lossy (or lossless) with size and resolution not less than 1024px x 768px at 300dpi

Implementation Guideline: The above mentioned standards are to be used for documentary data (scan for prescription, summaries, etc.) and data captured through traditionally non-DICOM compliant sources like picto-micrographs, pathological photographs, photographs of intramural and extramural lesions, etc. All data formats that can be converted into relevant DICOM format should be, as relevant, converted and communicated as secondary captured DICOM format. It may be noted that while no maximum image resolution has been prescribed, a sufficiently acceptable limit may be used to avoid unnecessarily large file that do not aid in correspondingly better interpretation or analysis.

DATA EXCHANGE STANDARDS

A health record system has to operate in a larger ecosystem of other components with which it must share or communicate data in order to capture and provide as comprehensible medical information as is practical. A health record system must therefore conform to the following standards:

Implementation Guideline: Implementation of exchange standards is expected to be at least for the scope of data captured or retained by the health record system. To explain further, full implementation of ANSI/HL7 V2.8.2 for each event and message is not required in health record systems but minimum implementation supporting the types of events and messages relevant to the system is required. Similarly, implementation/support of DICOM DIMSE C-Store and/or C-FIND/C-GET service is expected for IODs supported by health record system whereas implementation of WADO could be optional.

OTHER STANDARDS RELEVANT TO HEALTHCARE SYSTEMS

Healthcare record systems need to co-exist within a larger ecosystem with various other systems. It is important for all systems within a healthcare setup to adhere to relevant standards. While standards related to such systems are not within the scope of this document, as a general rule, standards created or ratified by following Standard Development Organizations (SDOs) should be used:

Bureau of Indian Standards and its MHD-17 Committee

ISO TC 215 set of standards

IEEE/NEMA/CE standards for physical systems and interfaces

Implementation Guideline: To help the implementers, an indicative list of such standards is provided in the “Standards at a Glance” section above. Wherever applicable, BIS-approved standards shall be preferred for implementation.

DISCHARGE/TREATMENT SUMMARY FORMAT

Implementers must ensure that the logical information model includes data elements to satisfy requirements of the format for Medical Records as specified by Appendix-3 of Medical Council of India (MCI) Code of Ethics Regulation 2002 (amended up to Feb-2016). The printed reports should meet MCI prescribed formats whenever any discharge or treatment summary is prepared.

E-PRESCRIPTION

Pharmacy Council of India (PCI) has, in its recent regulation (Pharmacy Practice Regulations, 2015 Notification No. 14-148/ 2012- PCI), provided the definition of the term under Section 2(j) that the term ‘Prescription’ includes the term ‘electronic direction’. Implementers must therefore ensure that the logicalinformation model includes data elements to satisfy requirements of the format for Medical Prescription as specified by the Pharmacy Council of India. The printed prescription will need to be in the PCI prescribed format whenever any medical prescription meant for drug dispensing is prepared. For the purpose of e-Prescription, implementers must ensure that the electronic version is digitally signed by a registered medical practitioner, and its non-repudiation is ensured at all times. The pharmacists shall be able to print a copy of e-Prescription in the required format along with other relevant digital authentication details.

PERSONAL HEALTHCARE AND MEDICAL DEVICES INTERFACING

Where not covered under relevant data exchange standards, it is recommended that IEEE 11073 health informatics standards and related ISO standards for medical devices be followed as appropriate whenever any personal healthcare/medical device is interfaced with the EMR system for the purpose of clinical data exchange, retrieval, storage, etc.

PRINCIPLES OF DATA CHANGE

The data once entered into a health record system must become immutable. The healthcare provider may have the option to re-insert/append any record in relation to the medical care of the patient as necessary with a complete audit trail of such change maintained by the system. Alteration of the previously saved data is not permitted. No update or update like command shall be accessible to user or administrator to store a medical record or part thereof. Any record requiring revision should create a new medical record containing the changed/appended/modified data of earlier record. This record shall then be stored and marked as ACTIVE while rendering the previous version(s) of the same record being marked INACTIVE. The data will thus in essence become immutable. A strict audit trail shall be maintained of all activities at all times that may be reviewed by an appropriate authority like auditor, legal representatives of the patient, the patient, healthcare provider, privacy officer, court appointed/authorized person, etc. as deemed necessary.

As-Is Principal:

The data captured through the devices is usually in a certain format whereas the data provided by the doctor as file may be in some different format. These data provided / included in the system are to be treated as sacrosanct. The “As-Is Principal” requires that the data captured in the first instance should be retrievable at any given point of time later in the same format, clarity, size and detail as it was provided during the time of record creation.

It effectively means that the system is not allowed to make any changes either to the data or its format or its nature at any point other than the creation time for any reason. However, if it is required that the data needs to be altered either to carry some additional information at some later point, like annotation on images, or correction of errors of omission or commission, etc., it must be done on a copy of the original data, keeping the original data intact, and marking the updated version as active while marking the previous version inactive. The modified data will then become part of the EHR/EMR.

Informed Format Change:

Whenever, the data, its format or its nature needs to be changed within the system, it must be done with the explicit consent of the doctor / technician / person that is entering or managing the data. This explicit consent can also be taken from a set of preferences already set by the user or the administrator / root of the system. In such preference based consent, there is no need to prompt the user for permission at each insertion point.

Also, in case the system is set to change format or nature of data automatically by setting of preferences, it must be made sure that the rule of conversion is declared in the Standard Operating Procedure (SOP) of site/application.

This Portal is designed, developed and hosted by Centre for Health Informatics (CHI), set up at National Institute of Health and Family Welfare (NIHFW), by the Ministry of Health and Family Welfare (MoHFW), Government of India.