What Is the HEDIS® Implementation Guide?
NCQA’s HEDIS IG is published as web pages that include both human-readable and machine-readable versions of the data model constraints. The IG also contains a narrative description of the rules and background on the challenges the IG addresses.
The implementation guide will allow implementers to understand exactly how to source and prepare data (clinical and administrative) in FHIR® to ensure it is a fit for digital quality, more specifically for digital quality measures for the HEDIS measure program.
Stakeholders may be familiar with the concept of the implementation guides as they are used in other use case domains around FHIR®. However, if you are new to IGs the following sections are intended to introduce you to use in the HEDIS IG.
The HEDIS IG structure diagram depicted below highlights the components of the HEDIS IG web page and represents the items that compose the IG (e.g., page, concepts).
How to Read the IG
NCQA’s HEDIS IG is published as web pages that include both human-readable and machine-readable versions of the data model constraints. The IG also contains narrative descriptions of the rules and background on the challenges the IG addresses.
To read the IG, start with the home page, which contains important information. Next, examine the computable content: The artifact page provides the technical definition of all the profiles published in a specific version of the IG. Each profile has its own pages in the IG, where you will find conformance rules specified by the profile.
Each profile, extension, value set and CodeSystem has a unique canonical URL:
The IG comprises different menus. Navigate through the menus and submenus to access content.
Profile elements may be nested; for example, Patient.telecom
The HEDIS IG is composed of both US Core and HEDIS Core principles.
Conformance resources in the HEDIS Core IG derive from and extend the US Core IG v3.1.1(USCDI v1) profiles and CARIN IG for Blue Button v1.1.0 profiles for clinical data and payer data, respectively.
A profile allows for simplification or inclusion of elements (constraints, extension) to a standard data model. The differential between the parent profile and the derived profile can be viewed via the diff view tab.
View of Profile Content Tabs
The Differential Tab shows only the rules added by a specific profile. The tab compares the profile you are viewing with its parent profile.
The Hybrid Tab shows all the rules in the profile. Parent profile rules are grayed out.
The Snapshot Tab shows all the rules in the profile, including those inherited from the parent profile.
Profile Definition Concepts
Cardinality flags
The cardinality of an attribute within a profile is in the format {minimum}..{maximum}
For instance :
0..*: Optional array(multiple codes, different systems)
0..1: optional element (zero or one)
1..1: Required element (one and only one)
S: Must support
?!: Modifier element
I : Invariant
Σ: Summary set
C: Constraints
Value set bindings
required: You SHALL use the specified codes
extensible: You SHALL use the specified codes
preferred: You SHOULD use the specified codes
example: You MAY use these codes—suggested, but not required
The annotated screenshot below shows a profile’s key components:
FHIR® Resources Used in the HEDIS IG
What are the FHIR® Resources (and definitions) used in the HEDIS IG (i.e. Observation, Resource, Result, Coverage, etc.)
| Resources | Definition |
|---|---|
| Claim | A provider-issued list of professional services and products which have been provided, or are to be provided, to a patient which is sent to an insurer for reimbursement. |
| ClaimResponse | This resource provides the adjudication details from the processing of a Claim resource. |
| Condition ( Condition Encounter Diagnosis, Condition Problems Health Concerns ) | A clinical condition, problem, diagnosis, or other event, situation, issue, or clinical concept that has risen to a level of concern. |
| Coverage | Financial instrument which may be used to reimburse or pay for health care products and services. Includes both insurance and self-payment. |
| DocumentReference | A reference to a document of any kind for any purpose. Provides metadata about the document so that the document can be discovered and managed. The scope of a document is any serialized object with a mime-type, so includes formal patient-centric documents (CDA), clinical notes, scanned paper, and non-patient-specific documents like policy text.
This is a basic constraint on DocumentReference for use in the US Core IG. |
| Encounter | An interaction between a patient and healthcare provider(s) for the purpose of providing healthcare service(s) or assessing the health status of a patient.
This is a basic constraint on Encounter for use in US Core resources. |
| ExplanationOfBenefit ( Inpatient Institutional, Outpatient Institutional, Pharmacy, Professional NonClinician ) | This resource provides: the claim details; adjudication details from the processing of a Claim; and optionally account balance information, for informing the subscriber of the benefits provided. |
| Immunization | Describes the event of a patient being administered a vaccine or a record of immunization as reported by a patient, a clinician or another party.
The US Core Immunization Profile is based upon the core FHIR® Immunization Resource and created to meet the 2015 Edition Common Clinical Data Set ‘Immunizations’ requirements. |
| MedicationAdministration | Describes the event of a patient consuming or otherwise being administered a medication. This may be as simple as swallowing a tablet or it may be a long-running infusion. Related resources tie this event to the authorizing prescription and the specific encounter between patient and health care practitioner. |
| MedicationDispense | Indicates that a medication product is to be or has been dispensed for a named person/patient. This includes a description of the medication product (supply) provided and the instructions for administering the medication. The medication dispense is the result of a pharmacy system responding to a medication order. |
| Observation | Measurements and simple assertions made about a patient, device or other subject. |
| Organization | A formally or informally recognized grouping of people or organizations formed for the purpose of achieving some form of collective action. Includes companies, institutions, corporations, departments, community groups, healthcare practice groups, payers/insurers, etc. |
| Patient | Demographics and other administrative information about an individual or animal receiving care or other health-related services.
The US Core Patient Profile is based upon the core FHIR® Patient Resource and designed to meet the applicable patient demographic data elements from the 2015 Edition Common Clinical Data Set. |
| Practitioner | A person who is directly or indirectly involved in the provisioning of healthcare.
This is a basic constraint on the provider for use in US Core resources. |
| PractitionerRole | A specific set of Roles/Locations/specialties/services that a practitioner may perform at an organization for a period of time.
This is a basic constraint on PractitionerRole for use in US Core resources. |
| Procedure | An action that is or was performed on or for a patient. This can be a physical intervention like an operation, or less invasive like long-term services, counseling, or hypnotherapy.
The US Core Condition Profile is based upon the core FHIR® Procedure Resource and created to meet the 2015 Edition Common Clinical Data Set ‘Procedures’ requirements. |
| QuestionnaireResponse | A structured set of questions and their answers. The questions are ordered and grouped into coherent subsets, corresponding to the structure of the grouping of the questionnaire being responded to. |
How Claims Flow Through Health Plans
The medical billing process begins when a consumer schedules an appointment. If the provider needs to verify eligibility, coverage, or benefits, they can initiate an Electronic Data Interchange (EDI) 270 transaction to the health plan. The health plan responds with an EDI 271 transaction containing the requested information.
After the consumer receives medical services, the provider prepares and submits a claim. Many providers use a clearinghouse to facilitate this process. Acting as an intermediary, the clearinghouse transmits the claim to the appropriate insurance payer using the EDI 837 transaction format—standard for professional, institutional, and dental claims.
Once received, the payer acknowledges the claim with a 277CA transaction and conducts an automated review for accuracy and completeness. If needed, the claim may be escalated for manual review by a claims examiner.
Clearinghouses and payer portals offer real-time claim status updates. Providers can track claim progress using an EDI 270 query, which returns an EDI 271 response with the current status. Upon approval, the payer issues an EDI 835 transaction, detailing payment information and documenting the electronic funds transfer.
Processed claims are stored in a data warehouse. These claims can be converted into Fast Healthcare Interoperability Resources (FHIR) format to comply with the CMS Interoperability and Patient Access Rule. This enables patients to access their claims and select clinical data via a patient-facing API, and allows providers to retrieve member information through a provider access API.
