Category: Blog

The healthcare industry saw significant opportunities through the application of technologies like cloud computing and automation in the last decade. Big data applications were developed over cloud-based technology infrastructure mostly over the last five years and brought key advancements in drug discovery, clinical trials, early diagnoses, and customer service.

Today, the healthcare sector is waiting to exploit the opportunities presented by another key technology – i.e., generative AI (GenAI). In fact, the three levers presented by the application of GenAI can help the healthcare sector achieve unprecedented efficiency in care delivery, and mitigate staff and clinician burnout in care provider organizations. Read on to understand these three levers in detail.

Rising administrative burden in care delivery systems

The healthcare machinery operates on a massive scale and serves millions of people through varying frameworks of care delivery. As a result, administrative functions are inevitable in such a system. However, the fraction of time and money spent on administrative functions in healthcare organizations is on the rise and is impacting the quality of care received by the patients as well as the costs incurred by payers.

Key Challenges

In the US alone, administrative spend on healthcare accounts for nearly 25% of the $4tn of total annual spend. This means that 1 out of every 4 dollars spent on healthcare goes into supporting the administrative functions, thus, increasing the cost of care to the patient or the payers.

Moreover, the rising administrative burden is being borne by clinicians and the administrative staff. Clinicians are now spending 13.5 hours/week on documentation on average, and this number has gone up by 25% compared to 7 years ago. Clinician burnout is, therefore, now a crucial challenge that is being faced by most healthcare organizations. In addition, the administrative staff must effectively communicate across multiple channels with different stakeholders like patients, insurers, clinicians, and payers to facilitate care delivery.

All these factors collectively lower the quality-of-care delivery outcomes or raise the costs of processes for each patient. 

Maximizing care delivery efficiency with GenAI

Most of the aforementioned challenges can now be mitigated with GenAI, a technology that leverages large language models (LLMs) to perform text-processing tasks. See its top applications below.

#1. Improving patient engagement and enhancing care delivery outcomes

Call centers, hospital administrative staff, and clinicians play a key role in keeping the patients engaged throughout the span of care delivery. While self-service apps are mitigating some of this burden, follow-up, patient education, and emotional support still take up considerable time for clinicians, nurses, and hospital staff, especially in chronic disease management.

The convergence of conversational and GenAI will now free up a considerable chunk of this effort. Patients are already comfortable with scheduling appointments and selecting care providers via chatbots. The adoption of chatbots can be extended to improve patient awareness of chronic conditions, improve adherence to prescribed care plans, and deliver emotional support through GenAI. GenAI algorithms can be trained to deliver personalized and engaging content based on patient behavior and create adaptive learning experiences for them.

All of these levers can ultimately improve the outcome of care delivery for providers and patients, resulting in a holistic uplift in the quality of healthcare interventions.

#2. Speeding EHR creation and updating procedures to minimize clinician burden

In the modern healthcare organization, electronic health records (EHRs) are crucial in simplifying the clinician and patient experience. However, many workflows involving the creation and updating of EHRs remain manual. Clinicians usually update EHRs through manual entry, which consumes time that could otherwise be directed to the patient and introduces room for human error in EHRs. Moreover, EHRs may have missing data, which impacts the quality of care that the clinicians can deliver.

In this context, GenAI can prove highly useful. It can automatically spot missing data in a patient’s EHR, and fill it in automatically, suggest diagnoses based on natural language queries, and even create summaries of patient-doctor conversations. LLMs are capable of spotting relevant text from such conversations, picking prescription names and dosages, and identifying medical terms to generate contexts of these conversations.

These capabilities are ripe to accelerate clinician productivity and improve the outcomes of care delivery for patients and clinicians.

#3. Enabling faster documentation to mitigate clinician and administrative staff burnout

In the healthcare ecosystem, documentation and correspondence between stakeholders comprise a significant fraction of administrative overheads. Over the years, some healthcare facilities have already moved from paper-based documentation to more advanced digital frameworks. For instance, a UK-based healthcare organization now makes use of speech-to-text services to help doctors, nurses, and healthcare professionals generate detailed notes with their voices.

GenAI is enriching these processes even further. It can synthesize data and information from multiple sources to generate contextual drafts for correspondence (for instance, with patients for disease queries, or with payers and insurers), thereby speeding collaboration between parties. Now, GenAI can also help physicians draft clinical notes, create discharge summaries, and highlight key information using years’ worth of existing clinical notes of patients. This can free up a significant amount of time for clinicians and administrators, reduce their overtime hours, and help direct their expertise to more valuable activities.

---

Next Steps:

GenAI undoubtedly possesses the potential to transform core healthcare processes and elevate the quality of care outcomes while reducing administrative overheads on clinicians and support staff. However, the application of this technology calls for thorough testing before it is activated by care providers.

In partnership with technology experts like Altysys, care providers can rapidly prototype and implement GenAI use cases to mitigate rising clinician burnout. Get in touch with us today and start reaping the benefits of GenAI in your care delivery operating model.

This is our last post in a series of posts on the topic of ‘Data Standards in Health Informatics’. In this post we will go over ‘Current Procedural Terminology (CPT®)‘ and ‘Logical Observation Identifiers Names and Codes (LOINC®)‘ data standards in detail. Before you read this article further, we highly recommend you read Part I, Part II and Part III of this series. At a high level, CPT deals with medical procedures and services data, and it is used for treatment tracking and billing; whereas LOINC deals with lab orders & results data, and it is used for transmitting lab test observations.

Let’s dive into details…

• Link: Data Standards in Health Informatics | Part I
• Link: Data Standards in Health Informatics | Part II
• Link: Data Standards in Health Informatics | Part III

Current Procedural Terminology (CPT®)

Current Procedural Terminology (CPT) is a classification of medical procedures maintained and updated annually by the American Medical Association (AMA). Like ICD, it is required for almost all reimbursement for health care services in the US.

With ICD, CPT is one of the most important code sets for medical coders to become familiar with. CPT codes are used to describe tests, surgeries, evaluations, and any other medical procedure performed by a healthcare provider on a patient. This code set is extremely large and includes the codes for thousands of medical procedures.

CPT codes are an integral part of the billing process. CPT codes tell the insurance payer what procedures the healthcare provider would like to be reimbursed for. As such, CPT codes work in tandem with ICD codes to create a full picture of the medical process for the payer. “This patient arrived with these symptoms (as represented by the ICD code) and we performed these procedures (represented by the CPT code)”.

Like ICD codes, CPT codes are also used to track important health data and measure performance and efficiency. Government agencies can use CPT codes to track the prevalence and value of certain procedures, and hospitals may use CPT codes to evaluate the efficiency and abilities of individuals or divisions within their facility.

CPT codes are divided into three categories:

Category I

Category I codes are five-digit numbers for widely performed procedures and are divided into sections for anesthesiology, surgery, radiology, pathology/laboratory, and medicine.

Here’s a quick look at the sections of Category I CPT codes, as arranged by their numerical range.

• Evaluation and Management: 99201 – 99499
• Anesthesia: 00100 – 01999; 99100 – 99140
• Surgery: 10021 – 69990
• Radiology: 70010 – 79999
• Pathology and Laboratory: 80047 – 89398
• Medicine: 90281 – 99199; 99500 – 99607

Within each of these code fields, there are subfields that correspond to how that topic—say, Anesthesia,—applies to a particular field of healthcare. For instance, the Surgery section, which is the largest, is organized by what part of the human body the surgery would be performed on. Each of these fields has its own particular guidelines when it comes to use. For example, the Surgery section has a guideline for how to report extra materials used (such as sterile trays or drugs) and how to report follow-up care in the case of surgical procedures.

Category II

Category II codes are for the collection of quality and performance metrics and are four digits followed by an “F”. Here’s a quick example: if a doctor records a patient’s Body Mass Index (BMI) during a routine checkup, we could use Category II code 3008F, “Body Mass Index (BMI), documented.” These codes never replace Category I or Category III codes, and instead simply provide extra information. They are divided into numerical fields, each of which corresponds with a certain element of patient care. Here is a list of these fields:

• Composite codes: These codes combine a number of procedures that typically occur in conjunction with one main procedure.
  o Example: 0001F: heart failure assessed (includes all of the following):

• Blood pressure measured
• Level of activity assessed
• Clinical symptoms of volume overload assessed
• Weight recorded
• Clinical signs of volume overload assessed

• Patient Management: Includes patient care provided for specific clinical purposes like pre and postnatal care
• Patient History: Describes measures for select elements of patient history or symptom review
• Physical Examination
• Diagnostic/Screening Processes or Results (Example: 3006F: Chest X-ray documented and reviewed)
• Therapeutic, Preventive, or Other Interventions
• Follow-up or Other Outcomes
• Patient Safety
• Structural Measures (This short section includes codes that describe the setting of the delivered care, and also covers the capabilities of the healthcare provider)

Category III

Category III codes are also four digits, followed by an “I”, and are temporary, to allow for new or experimental procedures . These represent emergent or experimental services, technology, and procedures. In certain cases, you may find that a newer procedure does not have a Category I code. There are codes in Category I for unlisted procedures, but if the procedure, technology, or service is listed in Category III, you are required to use the Category III code.

Category III codes allow for more specificity in coding, and they also help health facilities and government agencies track the efficacy of new, emergent medical techniques.

Logical Observation Identifiers Names and Codes (LOINC®)

Logical Observation Identifiers Names and Codes (LOINC®) is a clinical terminology that is important for laboratory test orders and results and is one of a suite of designated standards for use in U.S. Federal Government systems for the electronic exchange of clinical health information.

In 1999, LOINC was identified by the HL7 Standards Development Organization as a preferred code set for laboratory test names in transactions between health care facilities, laboratories, laboratory testing devices and public health authorities. In the future, LOINC is likely to become a HIPAA standard for certain segments of the Claims Attachment transaction.

Starting in 1994, health informatics pioneer, Dr. Clement “Clem” J. McDonald, organized the LOINC Committee to develop a common terminology for laboratory and clinical observations because of the growth of electronic messaging to send laboratory orders and test results which are often identified using a health system’s internal and typically unique code values. As a result, a receiving care system cannot fully “understand” and properly file the results they receive without considerable effort.

Each code is a number with up to seven digits. While the codes themselves are deceptively simple, their name contains important details in its five or six components. A fully specified LOINC name for a laboratory test indicates the component/analyte, the property analyzed or measured, the time over which this observation or measurement took place, the type of sample, the scale of the result and the method used to obtain it. These components, or parts, are separated by colons.

In the example shown above (Courtesy LOINC and The Regenstrief Institute) the first part—the component or analyte, the substance of interest—is Alpha 1 Globulin, a protein that is a marker for inflammation. The sixth part identifies the method used to determine the level as electrophoresis. The fourth or specimen part indicates that the test was performed on a blood serum or plasma sample. Test results with a unit of measure of mass in the numerator and a volume (like mg/dl) in the denominator have mass concentration (MCnc), as you see in the fifth part. Finally, Pt in the third part indicates that the measurement represents a point in time.

LOINC: Test Order for COVID

LOINC: Test Result for COVID

Sources:

• This article has been inspired by Mark L. Braunstein’s book: “Health Informatics on FHIR: How HL7’s API is Transforming Healthcare (Second Edition)”
• CPT: https://www.medicalbillingandcoding.org/intro-to-cpt/
• LOINC: https://www.accessdata.fda.gov/scripts/cder/ndc/dsp_searchresult.cfm

In our last two posts on the topic of ‘Data Standards in Health Informatics’ we provided an overview of data standards in health informatics, and we covered SNOMED CT and ICD data standard in detail.

Before you read this article further, we highly recommend you read Part I and II of the series:

• Data Standards in Health Informatics | Part I
• Data Standards in Health Informatics | Part II

In this penultimate post (of data standards series) we will provide an in-depth view on ‘National Drug Codes (NDC)’ and ‘RxNorm’ data standards . Though both are used – in a loose sense – to provide data standards for drugs, however there are some subtle (and not so subtle) differences that one should be mindful of.

At a high level, NDC is FDA’s identifier for drugs and primarily used for drug reimbursement; whereas RxNorm is maintained by National Library of Medicine and primarily used in personal health records applications.

Let’s dive into details…

RxNorm

Hospitals, pharmacies, and other organizations use computer systems to record and process drug information. Because these systems use many different sets of drug names, it can be difficult for one system to communicate with another. To address this challenge, RxNorm provides normalized names and unique identifiers for medicines and drugs. The goal of RxNorm is to allow computer systems to communicate drug-related information efficiently and unambiguously through a semantic interoperation between drug terminologies.

RxNorm’s normalized names for clinical drugs and links to many of the drug vocabularies are commonly used in pharmacy management and drug interaction software, including those of First Databank, Micromedex, and Gold Standard Drug Database.

RxNorm includes the United States Pharmacopeia (USP) Compendial Nomenclature from the United States Pharmacopeial Convention. USP is a cumulative data set of all Active Pharmaceutical Ingredients (API). RxNorm contains the names of prescription and many over-the-counter drugs available in the United States.

It’s important to note that non-therapeutic radiopharmaceuticals, bulk powders, contrast media, food, dietary supplements, and medical devices are all out-of-scope for RxNorm. Medical devices include but are not limited to bandages and crutches.

RxNorm provides a unique RXCUI number (of up to eight digits) for each medication. RXCUI can be used to retrieve a great deal of information. Some FHIR Resources reference RxNorm codes. The NLM provides RxNav, a free RxNorm browser. It also provides a free API, for accessing the codes.

Example: if we search for drug trastuzumab on RxNav, we can see all related Brand Names.

National Drug Codes (NDC)

National Drug Codes (NDC) The National Drug Code (NDC) is a US-specific standard for medications maintained by the US Food and Drug Administration (FDA). It consists of a simple 10 digit, 3-segment number. The first segment indicates the manufacturer/labeler/vendor. The second indicates the product name. The third part indicates the packaging. The same medication can have many NDC codes particularly if its patent has expired so it can be produced as a generic drug by many manufacturers.

In the example below ‘50242’ is identifier for Genentech, ‘132’ corresponds to Herceptin and the last two digits correspond to packaging.

It’s noteworthy that you will not find trastuzumab (which is the normalized drug name for the brand Herceptin) in the NDC directory, however, it’s present RxNorm.

Sources:

[1] This article has been inspired by Mark L. Braunstein’s book: “Health Informatics on FHIR: How HL7’s API is Transforming Healthcare (Second Edition)”

[2] NIH: https://www.nlm.nih.gov/

[3] NDC: https://www.accessdata.fda.gov/scripts/cder/ndc/dsp_searchresult.cfm

In our last post on the topic of ‘Data Standards in Health Informatics – Part I’ we provided an overview of data standards in health informatics, and we covered SNOMED CT data standard in detail. In this post we will provide an in-depth view on ‘International Classification of Diseases (ICD) .

The International Classification of Diseases (ICD) is the oldest data standard, dating directly back to the 1800s and more indirectly to earlier centuries when researchers became interested in the causes of human mortality. Traditionally, ICD is a list or classification of medical diagnoses maintained by the World Health Organization (WHO) since 1948 and updated every 10 years. The current version, ICD-10, was adopted in 1994 but was not adopted in the US until 2015. [ICD-11 was rolled out starting Jan 2022 ].

If you look at ICD data then whether it’s ICD-9 or ICD-10, depends on the date of service. If the date of service was before Oct 1, 2014, then ICD-9 was used to code the diagnosis. And for date of service on or after Oct 1, 2014, ICD-10 was used . The switch from ICD-9 to ICD-10 adds complexity in analyzing longitudinal data that spans both ICD-9 and ICD-10.

The switch from ICD-9 to ICD-10 was a substantial effort because ICD-10 is a major quantitative and qualitative expansion over ICD-9. While ICD-9 had 13,000 codes the ICD-10 has some 68,000 codes to represent very specific clinical details.

One of the major differences between ICD-9 and 10 is presence of ‘laterality’ in ICD-10, something ICD-9 did not have. In technical terms, laterality is localization of function or activity on one side of the body in preference to the other, e.g., “Malignant neoplasm of right female breast, left-outer quadrant”. There is almost 50% expansion of the number of codes in ICD-10 (over ICD-9) because of laterality.

The table below shows how one ICD-9 code can map to three potential ICD-10 codes due to presence of laterality in ICD-10:

Beyond size, ICD-10 is an ontology capable of representing clinical relationships not represented in ICD-9. For example, ICD-10 can encode the fact that a patient has gout affecting their right ankle and foot and they have developed a uric acid deposit, called a tophus, in that area. ICD-9 cannot specifically code for gout located in the ankle and foot, much less on the right side.

The figure below shows the various components of the ICD-10 code:

Here is one more example to understand ICD-10 code better:

S52         Fracture of forearm
S52.5      Fracture of lower end of radius
S52.52    Torus fracture of lower end of radius
S52.521   Torus fracture of lower end of right radius
S52.521A Torus fracture of lower end of right radius, initial encounter for closed fracture

In the above example, S52 is the category. The fourth and fifth characters of “5” and “2” provide additional clinical detail and anatomic site. The sixth character “1” in this example indicates laterality, i.e., right radius. The seventh character, “A”, is an extension that provides additional information, which means “initial encounter” in this example. It also demonstrates the use of the full code titles, which was not the format in the ICD-9 diagnosis code set.

The ICD-10 code sets include greater detail, changes in terminology, and expanded concepts for injuries, laterality, and other related factors. The complexity of ICD-10 provides many benefits because of the increased level of detail conveyed in the codes. The complexity also underscores the need to be adequately trained on ICD-10 in order to fully understand reporting changes that have come with the new code sets.

Sources:
[1] This article has been inspired by Mark L. Braunstein’s book: “Health Informatics on FHIR: How HL7’s API is Transforming Healthcare (Second Edition)”

What are data standards and why do we need them?

Data standards – as the name suggests are agreed upon guidelines for recording /storing data elements or datasets. Adhering to data standards makes the sharing and exchange of data easy and streamlined.
Let’s look at an example to understand the value of data standards. Here is a hypothetical case where three hospital systems are following three different “standards” for storing the ‘Gender’ of a patient.

• Hospital A: stores gender as an integer binary value {0,1} where 0 is for ‘Male’ and 1 is for ‘Female’
• Hospital B: stores gender as an integer binary value {0,1} however in this case 0 is for ‘Female’ and 1 is for ‘Male’
• Hospital C: stores gender as a single character {M,F,U} (‘U’ being for Unknown)

Now, imagine you are an IT company that has been tasked to develop a claim adjudication engine which is compatible with all three hospital systems above. Though it’s not impossible to build such a system, however, not having data standards makes the task challenging. Also, lack of data standards is potentially a source for errors when combining data across multiple systems, e.g., if the developer assumes that 0/1 representation in case of Hospital B is same as that of Hospital A then this will lead to a huge systemic issue.

Key data standards in health informatics

There are six key data standards in healthcare:

1. Systematized Nomenclature for Medicine – Clinical Terms (SNOMED CT)

2. International Classification of Diseases (ICD-10)

3. Current Procedural Terminology (CPT)

4. Logical Observation Identifiers Names and Codes (LOINC)

5. National Drug Code (NDC)

6. RxNorm

Briefly, SNOMED CT is the most comprehensive, multilingual clinical healthcare terminology in the world. ICD and CPT are widely used for medical billing. LOINC provides significant details about clinical tests. NDC is a US-specific standard for medications maintained by the US Food and Drug Administration (FDA). RxNorm is US-specific terminology in medicine that contains all medications available on the US market.

Deep-dive into SNOMED CT [Systematized Nomenclature for Medicine – Clinical Terms]

The development of SNOMED Clinical Terms traces its roots to a project begun in the 1960s at National Institutes of Health (NIH) to use natural language processing (NLP) to machine code pathologists’ free text dictated notes. SNOMED CT is the most comprehensive, multilingual clinical healthcare terminology in the world. It is essentially an ontology representing relationships among its concepts. SNOMED CT has 350,000+ concepts with over 1.3 million relationships (a relationship is an association between a source concept and a destination concept). Given its scope it is heavily referenced in FHIR Resources.

Let’s look at SNOMED CT through an example:

Link to SNOMED CT browser:

https://browser.ihtsdotools.org/?perspective=full&conceptId1=38341003&edition=MAIN/2022-05-31&release=&languages=en

If we search for the term ‘hypertension’ in the SNOMED CT browser we get 379 matches. The first match is ‘hypertension’ with an FSN of ‘Hypertensive disorder, systemic arterial (disorder)’.

Now, if we click on ‘Hypertension’ we see the concept has an SCTID is 38,341,003. Below it we see that SNOMED CT recognizes 14 synonyms for this disorder. These synonyms are useful in processing text notes that might contain one or more of these alternative terms.

Further we see the related parent and children concepts for ‘hypertension’ in the right panel – the hierarchical nature of SNOMED CT is quite visible here.

Hypertension is a child of ‘Disorder of cardiovascular system (disorder)’. Hypertension, in turn, has 25 more specific sub-disorders called children. Such a parent-child hierarchy can be useful for grouping patients for analysis.

The browser also provides a diagrammatic hierarchical view (as shown below). It shows how SNOMED CT explicitly reveals important computable clinical relationships. For example: using this hierarchy we can build a computational rule that hypertension is associated with an increased blood pressure.

It is evident that SNOMED CT can be a very valuable tool for usefully grouping and analyzing patients and their medical conditions. Given the importance of SNOMED CT, HL7 has developed a SNOMED CT Implementation Guide for FHIR to show developers, analysts and system architects features of FHIR which can be used to their full potential. The guide also highlights several potential issues that should be carefully considered along with appropriate steps to make to avoid them. The goal the implementation guide is “to maximize both the rich expressivity of SNOMED and the semantic operability when exchanging FHIR Resources between systems”.

Interoperability: FHIR and SNOMED CT

SNOMED CT can be thought of as a dictionary, specifying exactly what medical concepts mean. It does not, however, tell you how to assemble those concepts within a medical record in a way that can be transmitted to another system and understood. An information model is required to achieve this; a standard for how records and messages should be laid out and populated. This role is being played globally by HL7 FHIR.

By combining these two world leading standards, systems using SNOMED CT and FHIR together are able to communicate clear and unambiguous meaning in a standard way that can be automatically understood worldwide.

We shall cover other data standards in subsequent posts!

References:

This article has been inspired by Mark L. Braunstein’s book: “Health Informatics on FHIR: How HL7’s API is Transforming Healthcare (Second Edition)”

https://confluence.ihtsdotools.org

Healthcare consumers and patients have long been suffered from the complexity of the US healthcare system especially when it comes to pricing of services and how they would pay for it and how much they would pay for it. This is because prices can vary by hundreds to thousands of dollars between providers for the same healthcare service, there is no standardization. While patients never know how much they would end up paying out-of-pocket in spite of their insurance coverage or doctors don’t have a clue how much a patient or an insurer is charged for the services they provide.

CMS has introduced certain mandates to tackle this problem and increase the price transparency for the healthcare consumers. CMS and the federal government are taking multiple steps to help reduce the healthcare costs and empower consumers to have access to care cost beforehand, they don’t encounter surprise medical bills and can make informed decision.

Hospital Price Transparency Final Rule

This mandate is into effect from Jan 1, 2021, as per which, hospitals must post their standard charges on a publicly available website, in two ways:

• Single comprehensive machine-readable file with all items and services provided by the hospitable
• Display of at least 300 shoppable services, in a consumer-friendly way, that a healthcare consumer can schedule in advance

The file and the display of shoppable services must include:

• Gross charges
• Discounted cash prices
• Payer-specific negotiated charges
• De-identified minimum and maximum negotiated charges

However, since this does not address what a patient would pay out-of-pocket with their health insurance for a specific service, CMS realized this and also introduced final ruling on transparency in coverage for health plans. Nevertheless, this was a stepping stone in the direction to make healthcare services and procedures pricing information accessible to people.

Transparency in Coverage Rule Final Rule (for Health Plans / Health Insurance Issuers)

This final rule builds upon the hospital transparency rule that the Department of Health and Human Services (HHS), the Department of Labor, and the Department of the Treasury have taken to increase price transparency and empower healthcare consumers with the healthcare price information through their health plans. This will also promote competition in the private health plan industry.

Details and Timelines:

July 1, 2022:
(updated from Jan 1, 2022)
Access to Pricing through Machine Readable Files

Jan 1, 2023:
Personalized, out-of-pocket estimates for 500 services through online self-service tool, print & phone

Jan 1, 2024:
Personalized, out-of-pocket estimates of all services

Jul 1, 2022:
Health plans or health insurance issuers will be required to make three separate machine-readable files available to the public, including consumers, researchers, employers and third-party developers (as per new federal guidance, third file – prescription drug file requirement is deferred)

• First File: includes negotiated rates for all covered items and services between the plan / issuer and in-network providers. It is member cost-sharing liability or fee schedule rates while it should not be confused with rates used to reimburse providers by health plans / issuers.
• Second File: includes out-of-network allowed amounts (OON OOP) including historical payments and billed charges. Historical payments must have a minimum of 20 entries to protect consumer privacy.
• Third File (requirement of which is deferred): in-network negotiated rates and historical net prices for all covered prescription drugs by plan / issuer at the pharmacy location level

Jan 1, 2023:
Personalized out-of-pocket cost information, and the underlying negotiated rates, for 500 services, including prescription drugs, through an online self-service tool, phone and in paper form upon request. Paper based request might be limited to 20 providers per request.

The proposed rules set forth seven content elements that a plan or issuer must disclose,
to a participant, beneficiary, or enrollee for a covered item or service:

• Estimated cost-sharing liability
• Accumulated amounts
• Negotiated rates in dollars
• Out-of-network allowed amounts
• A list of items and services subject to bundled payment arrangements
• A notice of prerequisites, if applicable
• A disclosure notice

Jan 1, 2024:
Personalized out-of-pocket cost information, and the underlying negotiated rates, for all services and items covered by the health plan.

No Surprises Act

Dec 27, 2020, the No Surprise Act was signed into law as part of the Consolidated Appropriations Act of 2021. The act largely focused on protecting patients from receiving surprise medical bills, resulting from gaps in coverage for emergency services and certain services provided by out-of-network clinicians at in-network facilities.

The compliance is supposed to go into effect from Jan 1, 2022. The main components of this compliance are:

• Cost-sharing comparison by phone or internet-based tool for specific items or services
• Enforcement of below compliance is deferred to a later unknown date as per latest guidance from the Department, citing feedback from providers and facilities on the challenges of developing the technical infrastructure to transmit required information to health plans:
  • If service or item is scheduled at least 10 business days before such service or item is to be furnished, the plan or issuer must provide the AEOB within 3 business days of receiving the required notice from provider or facility.
  • Health plans or issuers must provide an AEOB (advance explanation of benefits) to the participant, beneficiary, or enrollee no later than 1 business day of receiving the required notice from provider or facility.
  • If a member, beneficiary or enrollee requests the AEOB, the plan or issuer must provide the AEOB within 3 business days.
• Further, rulemaking of below compliance is deferred however plans are expected “to implement these using a good faith”.

• Health plans or issuers must verify and update provider directory at least every 90 days (or within 2 business days of receiving of notice period).
• Health plans or issuers must respond to individuals inquiring about the network status of a provider or facility within 1 business day and must retain records of the enquiry for 2 years.
• Health Plans or issuers must have a web-based provider directory that includes:
  • Provider or facility contact information
  • Direct or indirect contractual relationship with the plan
  • Digital contact information

Changes in on Grandfathered Health Plan

Earlier grandfathered health plans (health plans purchased on or before March 23, 2010 i.e., before passage of Affordable Care Act) were exempt from Price Transparency Mandate but subject to No Surprise Act requirements. As per latest federal guidance, grandfathered health plans would be required to support price transparency, and AEOB (advanced explanation of benefits as part of No Surprise Act).

References:

• https://www.cms.gov/CCIIO/Resources/Regulations-and-Guidance/Downloads/CMS-Transparency-in-Coverage-9915F.pdf
• https://www.cms.gov/newsroom/fact-sheets/transparency-coverage-final-rule-fact-sheet-cms-9915-f
• https://www.cms.gov/hospital-price-transparency/hospitals
• https://www.federalregister.gov/documents/2019/11/27/2019-24931/medicare-and-medicaid-programs-cy-2020-hospital-outpatient-pps-policy-changes-and-payment-rates-and#p-1030
• https://www.federalregister.gov/documents/2019/11/27/2019-24931/medicare-and-medicaid-programs-cy-2020-hospital-outpatient-pps-policy-changes-and-payment-rates-and#p-1010
• https://www.aha.org/system/files/media/file/2021/01/detailed-summary-of-no-surprises-act-advisory-1-14-21.pdf
• https://www.cms.gov/CCIIO/Resources/Fact-Sheets-and-FAQs/Downloads/FAQs-Part-49.pdf

DCE: Direct Contracting Entities

Recent risk-sharing payment model in Medicare, launched by CMS, to promote value-based and coordinated care.

It differs from ACOs in terms of the requirements and level of risk available (refer to Table 1). Also, CMS would offer monthly Total Care Capitation or Primary Care Capitation (capitated and risk-adjusted) under two models – Professional and Global.

Interoperability is imperative for a DCE to succeed, Why?

• A DCE should be able extract a cohort of patient records or access to patient-level data across a patient population
• Integration of an internal clinical system with an EHR
• Aggregating data from network of physicians/providers
• Combining claims and electronic health record data to calculate quality measures
• Building datasets to develop and tune machine-learning algorithms
• Federated data sharing networks
• Reporting performance metrics to CMS
• Transmission of Claim and Claim Line Feed Reports (CCLF) from CMS
• Alerting the DCE in real-time when their patient is admitted or discharged from an acute or post-acute care setting (monitoring of care path)
• Inclusion of patients in their own care delivery

TIMELINE

QHIN: Qualified Health Information network

Network of organizations working together to share data. QHINs will connect directly to each other to ensure interoperability between the networks they represent. By establishing a network of QHINs, TEFCA (Trusted Exchange Framework & Common Agreement) seeks to provide a single “on-ramp” for nationwide connectivity and ensure the integrity and security of data as it is delivered where and when needed.

Interoperability Play

• Connectivity Broker is a service provided by a Qualified HIN that provides all of the following functions with respect to all Permitted Purposes: master patient index (federated or centralized); Record Locator Service; Broadcast and Directed Queries, and EHI return to an authorized requesting Qualified HIN.
• A Participant is a person or entity that participates in the QHIN. Participants connect to each other through the QHIN, and they access organizations not included in their QHIN through QHIN-to-QHIN connectivity. Participants can be HINs, EHR vendors, and other types of organizations.
• An End User is an individual or organization using the services of a Participant to send and/or receive electronic health info

Further Info on QHINs

Examples of QHINs

How will TEFCA work

Policy mandate on Interoperability, Data Access, HIE

Policy Mandate

• Jun 2020: ONC published the Final Rule for the 21st Century Cures Act, establishing FHIR R4 as the standard required for Health IT Certification
• Jun 2020: The 21st Century Cures Act, the ONC Cures Act Final Rule, and the CMS Interoperability and Patient Access rule have accelerated the ability for an individual to access their personal health information via an application of their choice leveraging HL7® FHIR® APIs

The ONC Interoperability and Information Blocking Final Regulation focus on enforcing aspects of the 21st Century Cures Act (interoperability, data access, and exchange/electronic health information (EHI)) and addresses the consequences of information blocking.

High-level timeline on compliance with the ONC’s Cures Act Final Rule

These rules impact patients, clinicians/providers, payers, ACOs/DCEs, vendors, developers – everybody in a healthcare ecosystem

Patients

• Access all their EHI without charge

Payers

• Implement a patient access API and a provider directory API
• Facilitate data exchange between payers using data identified in USCDI
• Increase the frequency of federal/state data exchanges
• Expose claims data via FHIR so that if a patient changes their health plan, they will be able to move data between the payers

Providers

• Update their digital contact information (in the National Plan and Provider Enumeration System (NPPES)) and/or information blocking. Failure to do so will lead to public reporting, which will affect provider performance metrics
• Improve ADT event messaging to meet care coordination requirements, allowing providers identified by the patient to receive the necessary notifications for treatment and care coordination (although CMS and ONC have yet to identify a standard for content format or delivery)
• Providers will have to send entire patient medical records to patient’s current health plan

Further Details on the Ruling!

There are three main pieces to the Interoperability and Patient Access ruling:

Patient Access API (Required July 1, 2021) – CMS-regulated payers are required to implement and maintain a secure, standards-based API that allows patients to easily access their claims and encounter information, including cost, as well as a defined subset of their clinical information through third-party applications of their choice.

Provider Directory API (Required July 1, 2021) – CMS-regulated payers are required by this portion of the rule to make provider directory information publicly available via a standards-based API. Through making this information available, third-party application developers will be able to create services that help patients find providers for specific care needs and clinicians find other providers for care coordination.

Payer-to-Payer Data Exchange (Required January 1, 2022) – CMS-regulated payers are required to exchange certain patient clinical data at the patient’s request with other payers.

Influencers and community projects to promote Interoperability

Da Vinci Project

Da Vinci stakeholders are industry leaders and health IT technical experts who are working together to accelerate the adoption of HL7 FHIR as the standard to support and integrate value-based care (VBC) data exchange across communities

Gravity Project

To create and maintain a consensus-building community to expand available SDOH (Social Detrimental of Health) core data for interoperability and accelerate standards-based information exchange by using HL7® FHIR®

CARIN

CARIN is committed to working closely with government leaders to enable consumers and their authorized caregivers to access more of their digital health information with less friction

Argonaut Project

Private sector initiative to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for EHR and other HIT based on Internet standards and architectural patterns and styles.