HealthDecember 03, 2020

Patient access to payer healthcare information and FHIR API use

Healthcare providers have been tasked by the federal Office of the National Coordinator for Healthcare IT (the ONC) to institute programs and implement changes to comply with new legislations such as Meaningful Use.

In March of 2018, the Centers for Medicare & Medicaid Services (CMS) enacted an initiative called MyHealthEData, affecting federal healthcare insurance payers. It focused on driving interoperability and patient access to health information by liberating patient data using CMS authority to regulate Medicare Advantage (MA), Medicaid, the Children’s Health Insurance Program (CHIP), and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs). The initiative included a new policy for Patient Access API use focused on claims and encounter data. And most recently, CMS and the ONC released on March 9, 2020, two new companion rules on interoperability and patient access. Both rules include the requirement to provide a patient access API, meaning that payers and providers alike will need to share to clinical data with their members and patients.

Driving toward easier access for patients

These two new interoperability rules represent a coordinated effort to allow patients and their designated representatives to access their health information electronically from both their healthcare providers and their insurers using common consumer technologies and without special effort. CMS finalized the Patient Access API and Provider Directory API policies for MA, Medicaid, CHIP and the QHP issuers on the FFEs effective January 1, 2021. Wolters Kluwer Health Language is uniquely situated to assist with the technical requirements of meeting these requirements.

The specifics of the Patient Access API policy require the CMS-regulated insurance payers to implement and maintain a secure, standards-based (HL7 FHIR Release 4.0.1) API that allows patients to easily access their claims and encounter information, including cost, as well as a defined sub-set of their clinical information through third-party applications of their choice. The stated rationale from CMS for the policy is that “Claims data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the healthcare system, leading to better decision-making and better health outcomes.”

Two of the healthcare standard terminologies used in electronic healthcare information, specifically SNOMED and LOINC, have been working together since 2013 to link their respective global healthcare terminologies, with the goal of improving patient safety and interoperability for the exchange of health data contained in electronic medical records.

What are LOINC and SNOMED?

Logical Observation Identifiers Names and Codes (LOINC) is a database and universal standard for identifying medical laboratory observations, as well as other health measurements, observations, and documents. First developed in 1994, it was created and is maintained by the Regenstrief Institute, a US nonprofit medical research organization. LOINC has a rich data model for representing collections, data elements (questions), and their answers. LOINC contains 10,000+ terms for patient reported outcomes measures. LOINC maintains concept maps to external terminologies:

  • SNOMED CT
  • RxNorm
  • RadLex RPID (radiology)

SNOMED is the standards body for SNOMED CT, the terminology set that is mandated by CMS to identify diagnoses and conditions on the integrated problem list in the patient’s medical record. SNOMED CT is considered to be the most comprehensive, multilingual clinical healthcare terminology in the world. It is designed for use in clinical documentation in the Electronic Health Record (EHR). The SNOMED-LOINC collaboration is aimed at linking LOINC term codes to post-coordinated SNOMED CT concepts. An example is the LOINC code for “Bacteria identified in Blood by Culture” (600-7) being linked with the SNOMED CT concept of “Staphylococcus aureus” (organism) [761983013] to convey the clinical finding of “Blood culture positive for Staphylococcus aureus.” This year, the two organizations have worked together to create new COVID-19 and SARS-CoV-2 codes and concepts to allow for public health tracking and healthcare provider use in identifying infections and rapidly transmitting that information in the EHR.

How the FHIR API requirements come into play

The National Library of Medicine (NLM) creates maps from the SNOMED CT terminology to CMS-mandated ICD-10-CM billing code terminology set for use in reimbursement and statistical analysis. Healthcare payers use ICD-10-CM code terminology to identify patient diseases, conditions, and findings. The new FHIR API CMS requirement will need to integrate the patient’s clinical information with the associated billing code data in a user-friendly product that will no doubt have a unique appearance from each payer.

Health Language is uniquely situated to assist insurance entities grappling with designing a fully functional patient portal FHIR-based API that will meet all CMS requirements. Most payers are busy working towards setting up that patient-access API. What they will soon learn is that the clinical data inside of each FHIR Resource is messy and not generally codified to the recommended standard terminology. For those payers wanting to provide an excellent member experience and to achieve true interoperability, the data will need to be normalized to the standards as identified in the FHIR specifications.

Health Language offers the solutions and expertise to help you meet the new interoperability rules. In addition to being a provider of standard terminology sets that are continuously maintained and updated, Health Language offers multiple ICD-10-CM-related products designed to improve coding and billing accuracy. These products include a terminology map set that maps from ICD-10-CM to SNOMED, as well as clinically-oriented and consumer-oriented term description synonyms that can assist with the building the FHIR API functionality and conveying information that patients will be able to understand.

Watch this video for an overview to see how Health Language’s solutions can help you comply, or, contact us if you’re ready to get started!

ONC and CMS Interoperability Rules
Watch Video
Watch this video to see how Health Language’s solutions can help you comply.
Holly van Kleeck, RN, BSN, JD
Clinical Content Analyst, Health Language, Wolters Kluwer Health
Holly supports Health Language solutions through content creation and maintenance related to ICD-10-CM and SNOMED, PFT, ICD-O-3, DSM-5, ICD-10-CM to SNOMED mapping, drug mapping, and data normalization for LOINC laboratory and radiology codes.
Back To Top