Choose language:
Accessibility tools
Text Size
Zoom In / Zoom Out
  • General
  • SNOMED CT
  • FHIR
  • LOINC
  • HL7
  • DICOM
  • CCD
  • The Electronic Health Record (EHR) is a longitudinal electronic record of patient health information generated by one or more encounters over a lifetime in any care delivery setting which includes patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, radiology reports, etc.; and can be accessed instantly and securely by authorized users.

    The Electronic Medical Record (EMR) is an electronic record of patient health information generated by one or more encounters in a particular health care facility/delivery setting which includes patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data and radiology reports; and can be accessed instantly and securely by authorized users from that healthcare facility.

    EMR is not accessible by other healthcare facility.

    EHRs are patient centric and comprise of longitudinal patient health record which can be accessed across healthcare facilities. EHR is a collection of all EMRs.

    EMRs are healthcare provider centric and comprise of episodic patient health information accessible within a healthcare facility.

    NRCeS is a single point of contact for assistance in developing, implementing and using EHR standards in India. NRCeS provides the knowledge base for EHR Standards and associated resources and facilitates acceptance of and adherence to EHR standards.

    Ministry of Health & Family Welfare (MoHFW), Govt. of India has established a Centre of Excellence named as National Resource Centre for EHR Standards at C-DAC, Pune to accelerate and promote adoption of EHR standards in India.

    • Paperless medical treatment.
    • Reduced cost of care.
    • Right treatment at right time.
    • Evidence-based medicine.
    • Accelerate research and build effective medical practices.
    • Ease of maintaining health information of patients.
    • With proper backup policies increase lifespan of EHR.
    • Better safety with access, audit and authorization control mechanisms.
  • SNOMED Clinical Terms (SNOMED CT) is the most comprehensive, multilingual clinical healthcare terminology in the world. It is owned, maintained, and distributed by the SNOMED International, United Kingdom. It is a widely used terminology and contains comprehensive active concepts with unique meanings and formal logic-based definitions organized into hierarchies.

    Incorporation of such a comprehensive terminology in EHR requires understanding of the underlying concept model, various levels at which clinical information can be effectively represented, and cross-mapping to other international vocabulary standards

    SNOMED CT provides a standardised, core terminology for EHR. When implemented in software, SNOMED CT represents clinically relevant information consistently, reliably, and comprehensively as an integral part of the EHR. It provides a standardized way to represent clinical phrases captured by the clinician and enables automatic interpretation of these. Use of an EHR improves communication and increases the availability of relevant information.

    If clinical information is stored in ways that allow meaning-based retrieval, the benefits are greatly increased. The added benefits range from availability of more easily accessible and complete information regarding medical history, illnesses, treatments, laboratory results, etc., increased opportunities for real time decision support, improved patient outcomes and treatment. It can also facilitate research and analysis based on coded information from clinical IT systems.

    SNOMED International is an international not-for-profit organization based in United Kingdom.

    SNOMED International is a product and service organization. It owns and administers the rights to SNOMED CT and related terminology standards. The SNOMED International is responsible for ongoing maintenance, development, quality assurance, and distribution of SNOMED CT.

    SNOMED International is an association governed by a General Assembly that contains one representative of each of its national Members. Several countries including India across various continents are members of SNOMED International. For more details, refer SNOMED International Members section of SNOMED International website.

    The SNOMED International Members pay a fee, based on national wealth, to the SNOMED International which gives them the right to a seat on the General Assembly. SNOMED International does not charge Affiliate Licensees for use of the SNOMED CT International Edition within Member countries.

    SNOMED International members undertake a range of activities related to their involvement in the SNOMED International and their role in distributing, extending and supporting the use of SNOMED CT in their country. The Organisation or agency that coordinates this role in each country is referred to as a NRC.

    NRC provide a single point of contact for communications with SNOMED International and other SNOMED International Members. Within their own countries, NRCs manage the use of SNOMED CT and communicate with a range of stakeholders, including SNOMED CT Affiliate Licensees, healthcare institutions, clinical groups and end users.

    The Ministry of Health and Family Welfare (MoH&FW) has designated C-DAC, Pune to run the NRC for distribution and management of SNOMED CT within India.

    India became a member country of SNOMED International in April 2014.

    SNOMED CT content can be browsed using freely available online browsers

    • Suggested browsers

      1. SNOMED International SNOMED CT Browser

      2. C-DAC's CSNOFinder

    Reference sets (Refsets) are a flexible standard approach used by SNOMED CT to support a variety of requirements for customization and enhancement of SNOMED CT.

    These are purpose, domain or utilization specific SNOMED CT codes targeted towards one or more medical domain. E.g. Refset for Opthalmology.

    These also include the representation of subsets, language preferences for use of particular terms and mapping from or to other code systems. Every reference set has a unique numeric concept identifier.

    NRCeS will be publishing refsets relevant in India in phases. Requirements may also be submitted to NRCeS for new refset development and publication. Vendors, clinicians and researchers are encouraged to submit refsets prepared by them for consideration as nationwide standard.

    30 SNOMED CT Simple Refsets covering common diseases under National Public Health Programs and Medical Specialty / Department-wise refsets on which National Health Programs are run by the Ministry of Health and Family Welfare (MoHFW), Government of India have been released.

    SNOMED International's SNOMED CT Starter Guide is a good place to begin with. Thereafter more technical and advanced features of SNOMED CT can be studied in the Technical Implementation Guide.

    For more details, refer SNOMED CT Standards section of our website.

    SNOMED CT code set access is available after getting Affiliate License from

    • 1. NRCeS for use within the jurisdiction of India

      2. SNOMED International for international use

    Affiliate licensees have to report usage for the period declared during Affiliate registration. The usage has to be reported before the declared period ends

    Usage of SNOMED CT requires license. This license is called as Affiliate License. The Affiliate License is in accordance with the Affiliate License Agreement.

    For more details, refer the SNOMED CT Standards section of our website.

    The end users who use the SNOMED CT enabled software (or service) developed by Affiliate licensees need a sublicense to use SNOMED CT content.

    Each system deployment requires a sub-license.

    Yes you still need to procure license for SNOMED CT as it is an intellectual property of SNOMED International and there are certain terms and conditions for usage of SNOMED CT as mentioned in Affiliate License Agreement.

    For more details, refer Get SNOMED CT section of SNOMED International website.

    MLDS is provided by SNOMED International for organizations and individuals to request use and access to the International Release of SNOMED CT for use in non-Member countries.

    NRCeS agreed upon to use the same tool for licensing so the users from India are also redirected to MLDS.

    The different types of Affiliate License Agreements are:

    • Affiliate - Normal

      Offered for the use of SNOMED CT by vendors/developers/users.

    • Affiliate - Research

      Offered to encourage the use of SNOMED CT in research that contributes to broadening the collective understanding and knowledgebase.

      The qualifying research project requires formal approval from SNOMED International.

    • Affiliate - Public Good

      Offered for charitable use. The product/service requires formal approval from SNOMED International.

    For more details, refer Get SNOMED CT section of SNOMED International website.

    Yes, an Affiliate License is required for use of SNOMED CT in India. The Ministry of Health and Family Welfare (MoH&FW), Government of India has made SNOMED CT freely available for all use within India.

    Yes. An Affiliate License is required for use of SNOMED CT in India.

    Yes. The Affiliate Licensee should ensure the software is sublicensed to end user.

    For more details, refer Affiliate License Agreement

    For shipping/selling a software in other country you may require an affiliate license from that country. Contact NRC of that country for licensing details.

    Yes. If the SNOMED CT enabled application/program (including web-based application) or mobile app is deployable in India, usable within India, or in a closed network within India, the Affiliate License issued by NRCeS would suffice. Licensee has responsibility to ensure that sub-licenses or general use meets this criteria.

    In case the web-based or mobile application is deployed outside India or may have users outside India, then a special International Affiliate License need to be obtained from SNOMED International. For this purpose, please raise appropriate request through MLDS

  • Health Level Seven International also called as HL7 International is not-for-profit, ANSI accredited standard developing organization which is founded in 1987. It works towards providing Comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.

    In Health Level seven, "Level Seven" refers to the seventh layer which is Application Layer of the International Organization for Standardization (ISO) seven-layer communications model for Open Systems Interconnection (OSI).

    HL7 provides standards for the exchange, integration, sharing and retrieval of electronic health information. These standards specify how information is packaged and transferred from one system to another by setting the structure and data types required for seamless integration between systems. In short, these standards are the language to make health systems interoperable.

    The standards provided by HL7 are HL7 Version 2, Version 3, CDA, C-CDA, and HL7 FHIR.

    HL7 has defined large number of messages which covers almost every event in hospital information systems. So hl7 has categorized these messages into different systems. In HL7 v2.8.2 (the final release of version 2 standards), total 15 systems are stated, namely Patient Administration, Observation Reporting, Medical Records, Order entry, Application Management, Scheduling, Patient Referral, Financial Management, Master Files, Patient Care, Clinical Laboratory Automation, Personnel Management, Claims and Reimbursement, Materials Management.

    A message is an atomic unit or block of data transferred between systems. It contains multiple segments in defined sequence which categorize data being transferred. Each message has message type that defines its purpose. For example, ADT (Admit Discharge Transfer) is a Message Type for messages which are used for transferring data related to patient administration. For every real-world event which initiates the data transfer is called as Trigger Event. Trigger Event is three-character unique code. For example, A01 Trigger Event notifies that patient has been admitted.

    A Segment is logical grouping of data fields. Segments may be required or optional and may repeat or not for particular message. Each segment contains specific information and are identified by unique three-character code like, PID is a segment carrying the information related to the patient identification.

    A data field is string of characters. Fields may be required or optional and may repeat or not. Each field has assigned a data type to constrain the data in it. There are two types of data types such as Primitive Data Types and Composite Data Types. Primitive Data Types are simple string of characters, but Composite Data Types are made up of combination of Primitive as well as Composite Data Types.

    Any healthcare providers, government agencies, implementers and patient.

    Download the specification documents from HL7 International.

    • To download the specification documents HL7 members need to use their usual login and non-member need to create an account.
    • Then find the standard which you want to download and accept the license to start downloading.
  • FHIR® – Fast Healthcare Interoperability Resources (hl7.org/fhir) – is a next generation standards framework created by HL7. FHIR combines the best features of HL7's v2, HL7 v3 and CDAproduct lines while leveraging the latest web standards and applying a tight focus on implementability.

    The standard is maintained and owned by the Health Level Seven International (HL7) health-care standards organization.

    There are a number of FHIR key concepts, including:

    • Resources
    • Extensions
    • Data types
    • Bundles
    • Profiles

    A resource is the smallest unit of exchange that 'makes sense' in interoperability. E.g. – an Observation, a Patient or a Condition. A resource is made up of elements, each of which is a particular data type.

    The resources can be exchanged in the following formats: XML, JSON and Turtle.

    FHIR specification defines a set of data types that are used for the resource elements. Each element within a resource is of a particular data type. There are four categories of data types:

    • Simple / primitive types, which are single elements with a primitive value
    • General-purpose complex types, which are re-usable clusters of elements
    • Metadata types: A set of types for use with metadata resources
    • Special purpose data types - defined elsewhere in the specification for specific usages

    Bundle is one of the resource in FHIR. There are many situations where a collection of resources is required. Such collection of resources is represented using Bundle. The situations include:

    • The results of a search
    • The collection of versions of a particular resource
    • A FHIR document
    • A FHIR message
    • A batch of resources to be processed

    FHIR is designed as an interface specification - it specifies the content of the data exchanged between healthcare applications, and how the exchange is implemented and managed. FHIR defines the following methods for exchanging data between systems:

    • RESTful API
    • Messaging
    • Documents
    • Services
    • Database / Persistent Storage

    Each of these approaches can be used to exchange information, and each has its own strengths and weaknesses and applicability. Note that applications are allowed to use any other method to exchange resources; the methods described in this specification are the common methods that are used enough to justify the effort to describe or standardize their use.

  • LOINC (Logical Observation Identifiers Names and Codes) is a common language (set of identifiers, names, and codes) for identifying health measurements, observations, and documents developed by Regenstrief Institute, a non-profit medical research organization. For more information on LOINC: https://loinc.org/

    Regenstrief Institute distributes LOINC free of charge. In obtaining and using LOINC, you agree to the terms-of-use that are outlined at https://loinc.org/license. No extra approval from Regenstrief Institute is necessary for use consistent with these terms.

    LOINC is available as a Microsoft Access (.mdb) database file and also a comma delimited text file (.csv). Download LOINC and other accessory files at: loinc.org/downloads.

    LOINC codes have a fixed-length field of 7 characters within the LOINC database. Current codes are from 3-7 characters long. The last digit of the LOINC code is a check digit and is always preceded by a hyphen (dash). Implementers are advised to allow up to 10 characters (or at least 8 characters) to allow for further expansion.

    A LOINC term is defined as the combination of the LOINC code and the Fully Specified Name (FSN). The FSN is composed of five or six main Parts: the name of the Component or Analyte measured (e.g., glucose, propranolol), the Property observed (e.g., substance concentration, mass, volume), the Time Aspect of the measurement (e.g., is it over time or momentary), the type of System or sample (e.g., urine, serum), the Scale of measurement (e.g., qualitative vs. quantitative), and where relevant, the Method of the measurement (e.g., radioimmunoassay, immune blot).

    The FSN is the combination of the main parts and the colon character, ":", which acts as a separator:

    <Analyte/component>:<kind of property of observation or measurement>:<time aspect>:<system (sample)>:<scale>:<method>

    LOINC creates several different text labels (names) to represent each concept. They are called the six-part formal name, as the Fully-Specified Name (FSN). There are more clinician-friendly display called the Long Common Name (LCN) and a Short Name that can be handy when you need a column header in a report. Here are the names for LOINC code 806-0:

    Fully-Specified Name (FSN) - Leukocytes: NCnc: Pt: CSF: Qn: Manual count

    Long Common Name (LCN) - Leukocytes [#/volume] in Cerebral spinal fluid by Manual count

    Short Name - WBC # CSF Manual

    LOINC Panels are collections of LOINC terms that represent specific sets of information, such as a laboratory battery of tests, a group of findings from a procedure such as an EKG, and forms or assessments related to health that are completed by patients and/or providers.

    LOINC Panels contain a specific structure, and depending on the type of panel, can include attributes such as form coding instructions, skip logic, and nested panels.

    For more information on modeling of Panels in LOINC, refer to Chapter 7 of the LOINC Users' Guide.

    RELMA (Regenstrief LOINC Mapping Assistant) is software that helps users map their local terms or lab tests to universal LOINC codes. RELMA contains many tools that will help you search for the correct LOINC codes to map to your tests.

    RELMA is available as a desktop mapping program for the Microsoft Windows operating system. You can download RELMA from: https://loinc.org/relma/.

    New versions of RELMA and LOINC are released twice a year, in February and August.

  • Digital Imaging and Communications in Medicine - is the international standard for medical images and related information. It defines the formats for medical images that can be exchanged with the data and quality necessary for clinical use.

    DICOM is formed by American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) in 1983 for promoting communication of digital image information, regardless of device manufacturer.

    DICOM is used digitally in many hospitals worldwide. It ensures the interoperability of systems used to Produce, for image Storage and Display, to Send, Query, Retrieve and Print medical images and derived structured documents, as well as to manage the related workflow.

    Physicians for making faster diagnosis. Patients to get assistance of faster and more effective care. Health care facilities such as Hospitals, clinics and imaging centers can use it for interoperability and to manage and distribute images in standardized format. Manufacturers of imaging equipment to ensures compatibility of their equipment at every medical imaging facility.

    DICOM will be required by all EHR systems that include imaging information as an integral part of the patient record.

    DICOM is used in radiology, breast imaging, cardiology, radiotherapy, oncology, ophthalmology, dentistry, pathology, surgery, veterinary, neurology, pneumology and many other specialties.

    The current version of DICOM Specification is available at DICOM Standard organization(current version). Download previous versions from DICOM Standard organization(prior version)

    A joint DICOM/HL7 working group has existed for many years for Contributing to the development of the HL7 Reference Information Model, Propose extensions to the DICOM and HL7 standards where appropriate and to Develop information linkages between the DICOM and HL7 standards.

    DICOM is also an integral part of Integrating the Healthcare Enterprise (IHE).The DICOM Standards Committee has an active liaison to ISO's TC 215.Wherever possible, DICOM utilizes relevant parts of other mature standards such as LOINC, SNOMED, JPEG, MPEG, BI- RADS, TCP/IP and other Internet Standards.

    PACS stands for picture archiving and communication system which facilities storage of medical images and operations like storage and retrieval over those images for distribution of medical images between healthcare facilities. Where as DICOM provide protocol for distribution of medical image and standardized format for digital image related operation.

    DICOM file are most like to have file extension of .DCM or .DCM30 format. The DICOM File Format provides a means to encapsulate in a file the Data Set representing a SOP Instance related to a DICOM IOD.

    A DICOM file can be viewed using DICOM Viewer. A DICOM Viewer can be a desktop application like RadiAnt, Adobe Photoshop, and GIMP or any free web tool like DICOM Library.

    An Information Object Definition (IOD) is an object-oriented abstract data model used to specify information about Real-World Objects. An IOD provides communicating Application Entities with a common view of the information to be exchanged. An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real-World Objects that share the same properties. An IOD used to generally represent a single class of Real-World Objects is called a Normalized Information Object. An IOD that includes information about related Real-World Objects is called a Composite Information Object.

    Normalized IOD represents a single, real-world entity just as our Patient IOD represents a patient. The DICOM Study IOD, for example, is Normalized and contains only inherent study properties such as study date and time.

    Composite IODs are combination of several real-world entities or their constituent parts. For Example: Consider a CT image IOD, in DICOM this IOD will contain some of the patient attributes (name, ID, and so on to identify the patient this image belongs to) along with attributes of the CT scanner, patient study, and more. These related Real-World Objects provide a complete context for the exchanged information.

    A Service-Object Pair (SOP) Class is defined by the union of an IOD and a DIMSE Service Group. The SOP Class definition contains the rules and semantics that may restrict the use of the services in the DIMSE Service Group and/or the Attributes of the IOD.

    The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction.

    There are 5 C-Services -

    • C-STORE Service: The C-STORE service is used by a DIMSE-service-user to store a composite SOP Instance on a peer DIMSE-service-user.
    • C-FIND Service: The C-FIND service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user.
    • C-GET Service: The C-GET service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user, and retrieve all composite SOP Instances that match. It triggers one or more C-STORE sub-operations on the same Association.
    • C-MOVE Service: The C-MOVE service is used by a DIMSE-service-user to match a set of Attributes against the Attributes of a set of composite SOP Instances maintained by a peer DIMSE-service-user, and retrieve all composite SOP Instances that match. It triggers one or more C-STORE sub-operations on a separate Association.
    • C-ECHO Service: The C-ECHO service is invoked by a DIMSE-service-user to verify end-to-end communications with a peer DIMSE-service-user. It is a confirmed service.

    There are 5 C-Services -

    • N-EVENT-REPORT Service: The N-EVENT-REPORT service is used by a DIMSE-service-user to report an event to a peer DIMSE-service-user.
    • N-GET Service: The N-GET service is used by a DIMSE-service-user to retrieve Attribute values from a peer DIMSE-service-user.
    • N-SET Service: The N-SET service is used by a DIMSE-service-user to request the modification of Attribute Values from a peer DIMSE-service-user.
    • N-ACTION Service: The N-ACTION service is used by a DIMSE-service-user to request an action by a peer DIMSE-service-user. It is a confirmed service.
    • N-CREATE Service: The N-CREATE service is used by a DIMSE-service-user to request a peer DIMSE-service-user to create a new managed SOP Instance, complete with its identification and the values of its associated Attributes, and simultaneously to register its identification.
    • N-DELETE Service: The N-DELETE service is used by an invoking DIMSE-service-user to request a peer DIMSE-service-user to delete a managed SOP Instance and to de-register its identification.

    Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services. Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services.

  • Continuity of Care Document - is an XML-based standard which provides a "snapshot in time" constraining a summary of the patient’s clinical, demographic, and administrative data.

    CCD is formed by HL7 International and ASTM for sharing patient summary using the HL7 Version 3 Clinical Document Architecture Release 2.

    Allows applications / systems to send medical information to other healthcare providers without loss of information.

    Supports the ability to represent professional society recommendations, national clinical practice guidelines, standardized data sets, etc.

    CCD document is not intended to be a complete medical history for a given patient. Instead, it is intended to captures the information that is critical to effectively continue care.

    The medical data within a CCD document is encoded using XML and can be readable using any standard Web browser.

    Specification document is available on HL7 International.

    • To download the specification documents HL7 members need to use their usual login and non-member need to create an account
    • Then find the standard which you want to download and accept the license to start downloading

    CCD document is in XML format.

    Any healthcare provider, software and hardware device manufacturer, that deals in capture or transmission of clinical information for continued care of patients should implement the CCD standard into their product for interoperability.

    CCD contains Patient Summary and includes different sections (Header, Summary Purpose, Payer, Problems, Advance Directive, Social History, Alerts, Medical Equipment, Immunizations, Procedures, Encounters, Plan, Functional Status, Medications, Family History, Vital Signs, Results and footer) to arrange patient’s medical information.

    The CCR Header contains the document parameters (unique identifier, version language, date/time), brief details of the patient (whose data it contains), details related to author (who has generated the document) and the purpose.