News

CODING SEPSIS: KNOWING THE SIGNS & SYMPTOMS

Posted by Samantha Serfass on April 16, 2019 in Blog, News

Coding Sepsis:  Knowing the Signs and Symptoms

Sepsis is the body’s extreme response to an infection. It occurs when an infection you already have in your skin, lungs, urinary tract, or somewhere else triggers a chain reaction throughout your body. Anyone can get an infection, and almost any infection can lead to sepsis including bacterial, viral or fungal infections.

Globally, an estimated 20 million to 30 million cases of sepsis occur each year. Hospitalizations for sepsis have more than doubled over the past 10 years, and the incidence of sepsis developing after surgery tripled from 1997 to 2006. Mortality from sepsis is estimated to be greater than mortality from AIDS and breast cancer combined.

Common signs and symptoms of sepsis:

  • Altered mental status, drop in urine output, and decreased capillary refill of nail beds or skin
  • Fever (temperature greater than 100.4 degrees) or hypothermia (temperature less than 96.8 degrees)
  • Leukocytosis (white blood cell count greater than 12,000) or leukopenia (white blood cell count less than 4,000 or greater than 10% bands)
  • Hypotension (systolic blood pressure < 90 mm Hg or fallen by > 40 from baseline, mean arterial blood pressure < 70 mm Hg)
  • Lactate >1 mmol/L.
  • Tachycardia (greater than 90 beats per minute)
  • Tachypnea (respiratory rate greater than 20 breaths per minute or a pCO2 of less than 32 mmHg)

Coding a patient’s record with sepsis can prove challenging for medical coders. For example, the ICD-10 Official Coding Guidelines tell us signs and symptoms that are associated routinely with a disease process should not be assigned as additional codes, unless otherwise instructed by the classification. If the patient is admitted with a localized infection and sepsis, the code for the systemic infection should be assigned first, followed by a code for the localized infection. If the patient is admitted with a localized infection, and develops sepsis after admission, a code for the localized infection is assigned first, followed by a code for the sepsis.

A systemic infection can occur as a complication of a procedure or due to a device, implant or graft. This includes systemic infections due to wound infections, infusions, transfusions, therapeutic injections, implanted devices, and transplants. 

When sepsis is complicating pregnancy, childbirth, or the puerperium, the obstetrical code is sequenced first, followed by a code for the specific infection.  When a newborn is diagnosed with sepsis, a code from category P36 Bacterial sepsis of the newborn is assigned.

Both the coding guidelines for sepsis as well as ambiguous provider documentation often mean coders require an extended length of time to review a record – only to place it on hold for a physician query. It is up to the physician’s clinical judgement to decide whether the patient has sepsis.  The coder cannot assume the patient has sepsis based on criteria being met – they must rely on the physician’s documentation. Coders should emphasize to physicians the importance of capturing patient severity which will be reflected in accurate coding and correct facility reimbursement.

From a patient’s perspective, there are ways to help prevent sepsis.

  • Get vaccinated. According to a recent CDC study, 35% of sepsis cases stemmed from pneumonia. Annual flu shots can also prevent respiratory infections that often turn septic.
  • Treat urinary tract infections promptly. A quarter of sepsis cases resulted from urinary tract infections. It is important to see a healthcare provider if you have warning signs of those infections including a painful burning feeling when urinating and a strong urge to ‘go’ often.
  • Clean skin wounds properly. About one in 10 sepsis cases follows a skin infection. It is essential to care for wounds and scrapes properly – washing with soap and water, cleaning out any dirt and debris, and covering wounds. 
  • Avoid infections in hospitals. Insist that everyone who comes into your hospital room, including doctors and nurses, wash their hands before they touch you.

Knowing the signs and symptoms of sepsis is a medical coder’s first step towards accurately coding what can be a life-threatening illness. Coders should take the time to thoroughly review and learn from these records rather than be overwhelmed by them. 

It is also important to review how to apply sequencing guidelines and to query the physician for any ambiguous or conflicting information present in the patient’s record.

Cynthia Alder-Smith RHIT, CCS

Auditor/Coding Educator

Epic Community Connect: Planning the Right Approach

Posted by Samantha Serfass on April 3, 2019 in Blog, News

Epic Community Connect: Planning the Right Approach

Epic Community Connect: Planning the Right Approach

The need to extend EHRs to affiliates is increasing along with the integration needs of ACOs.  Epic Community Connect is a methodology and approach to extend EHR systems to partners and clients.  Community Connect can be licensed to both clinics and hospitals typically working with smaller budgets.  It’s crucial to understand the impacts of offering Community Connect as a host so no surprises arise in the process.

UNDERSTANDING THE COSTS

Identifying the cost to license Epic and its 3rd -party applications is an important factor to consider before offering Community Connect to providers.  Cost models for Community Connect can be very complex.  In the outpatient area, the costs are typically identified per physician.  A common price might be $15,000 per physician, but what might be a surprise is the complex costs of the 3rd parties.  For each 3rd– party application, health organizations need to revisit the contract. Every contract can be priced out differently for example:

  • SureScripts may have little to no costs for outpatient, however inpatient is based on the number of beds
  • For OBIX Electronic Fetal Monitoring, the cost is based on the number of births per year along with a one-time fee and a yearly support cost
  • For Patient Education & Discharge instructions from Elsevier, it may be based on the number of AVEs (Epic’s calculation of volume licensing)

Each hospital system has a different contract with not only Epic but with the many 3rd-party supporting applications, which have to be considered again before offering Community Connect to the community.  Health systems offering Community Connect without considering all the costs could end up with budget cuts, program delays and staff layoffs.

Excite’s Community Connect cost model includes the quadratic equation to help identify an accurate per physician cost and support needed to purchase Community Connect. Once a health system has implemented the EMR and its 3rd parties, each physician moving forward will require less support.

DEVELOPING A GO TO MARKET APPROACH

The amount of effort required by the receiver of Community Connect also depends on how the host organization packages the service offering to the market.  For example, if the receiving client is going to need to increase their IT security infrastructure to meet the hosts standards, additional resources will be needed.  However, if the host packages the offering to include the security services to ensure it is completed accurately, then that will also impact the effort for the receiving party.  Security is just one example but there are many others, such as:

  • Reporting
  • Training
  • 1st Level Support
  • Informatics

Smaller hospitals and clinics often don’t have additional staff to assist with an EMR implementation.  It’s vital for the health organization to recognize the Community Connect receivers time, effort and resources needed during implementation, especially if customization to the system is required. The key questions that host health organizations need to consider are:

  • Where can customization occur, and what will it impact for the implementation and support?
  • What is the cost and how much time and effort will be required?

SETTING EXPECTATIONS

While there is no one single method in setting expectations, the most important tool is a Detailed Project Plan. The plan should identify activities for the host, as well as the foreseen activities for the recipient.  Incorporating resources and estimated times of effort for activities can help assist in identifying the overall time the client will have to spend to implement the new system.

Developing a governance structure where Community Connect clients have a voice will help support the partnership. Expectation setting also requires guiding principles that both parties can embrace during the implementation and support phase. Strong communication is key to help reduce anxiety and concerns. When issues or concerns are escalated up through governance, guiding principles will need to be looked at and leveraged regularly.

Finally, when considering being a Community Connect host, it’s important to conduct a pilot first.  Conducting a practice run (or pilot), is where a host organization can identify the challenges they may face.  As a host, the health organization will now be a vendor providing a service, which is new to many organizations.

These elements all contribute to a successful Community Connect implementation. It’s important to consider all aspects of the project before offering Community Connect.

Todd Klein

VP EHR Services & Digital Solutions

Breaking Down Denials: CC/MCC Denials

Posted by Samantha Serfass on March 19, 2019 in Blog, General, News

BREAKING DOWN DENIALS: CC/MCC DENIALS 

When someone in the healthcare industry hears the word “denial”, many things can come to mind.  There are many different types and kinds of denials; what could be said about denials could fill a book. To narrow the conversation, let’s touch on one specific type of denial that has become more prevalent for hospitals in recent years. 

A documented and coded diagnosis acting as a CC or MCC for the DRG is denied by the payer with the claim that the clinical picture does not support that it is a true and valid diagnosis.  By removing the diagnosis code, the DRG is reduced, resulting in a reduced payment to the hospital.

This type of denial has been called various things which can create confusion when assigning the appropriate person to address it.

A few examples are:

  • “clinical denials” which could also mean denial of admission to an inpatient bed stating the patient’s clinical picture does not warrant inpatient care
  • “DRG denials” which could also mean the entire admission was denied, not just a denied diagnosis changing the DRG
  • “Coding denials” which tends to sound like this is a coder issue when in fact it is not a coding issue at all

Payers have learned how to target the types of inpatient discharges that lend well to this type of challenge.  Common targets include DRGs with a single CC or MCC where the CC or MCC is acute renal failure/injury, acute respiratory failure, encephalopathy, malnutrition, or sepsis.

If this is not a coding specific issue, then where does the problem lie?  The Center for Medicare and Medicaid Services (CMS) has not stated any one criterion as the official clinical criteria for all to follow.  As a result, many payers including the RACs have created their own criteria or adapted existing criteria in the industry such as AKIN (Acute Kidney Injury Network), RIFLE (Risk, Injury, Failure, Loss of kidney function, and End-stage kidney disease), or KDIGO (The Kidney Disease: Improving Global Outcomes).  Providers most often do not know what individual payer criteria is being used.  Physicians have not been educated on when additional documentation is needed to support certain conditions that they diagnose and document. 

The coding teams are stuck in the middle.   Facilities can trend what different payers are targeting and the basis of their denials.  Armed with this information, coders still cannot diagnose the patient.  Even with outlined criteria to follow, conditions documented in the record and not ruled out cannot be ignored by the coder.  The coder cannot make the determination that a documented diagnosis is not valid and choose not to code it. 

What’s a hospital to do?  Hospitals should create a team to review these types of denials and fight back whenever possible.  Some hospitals have taken the extra steps to create internal clinical guidelines to give direction and promote consistency; however, payers may still deny diagnoses based on their own criteria.  Offer as much education on the issue as possible to physicians, CDI staff, and coders.

Who should review and argue the cases? The best person to review these denials and write up an appeal letter would be the very person that documented the diagnosis in question, the physician.  However, it is a rare hospital that has a medical staff member with the time and willingness to do so.  So, the task should fall to someone with strong writing skills with a clinical background that can create a strong argument in support of a documented diagnosis by outlining the patient’s clinical picture in detail.

From a different angle: Coding was initially created for the primary purpose of statistics and research.  Coded data can play a key role in value-based care and other programs based on patient care outcomes and quality of care indicators.  While Official Coding Guidelines offer clear direction on when to assign a secondary diagnosis code, the guidelines could be a part of the problem.  The guidelines state additional conditions are coded when they affect patient care by requiring clinical evaluation, therapeutic treatment, diagnostic procedures, they extended the length of stay, or necessitate increased nursing care and/or monitoring.  But what the guidelines neglect to include are conditions that create a patient health risk for the future.

One example includes patients with morbid obesity that decline nutritional counseling or any other type of intervention.  Because the condition is not being addressed, some payers are denying it as a secondary code/s.  As patients develop obesity related conditions in the future, there will be limited data for research of obesity related health problems because the condition of obesity is not being coded now.  This also could create a problem with quality of care analysis when patients’ conditions are uncontrolled due to unaddressed obesity such as diabetes, respiratory conditions, joint problems, and cardiac disease.

 Every denial should be reviewed and where possible and appropriate, challenged.  Payers may tend to target facilities that do not argue or fight back.  Do not accept a payer’s denial at face value.  Review the case.  If there is enough clinical support in the record to argue, do so.  The continued challenge is what constitutes “enough clinical support”?  Not even CMS answers that for us.

Lisa Marks

VP of HIM Services

The Importance of Accurately Documenting Workflows

Posted by Samantha Serfass on March 6, 2019 in Blog, News

Importance of Accurately Documenting Workflow

In the mid to late 1990’s, EHR vendors started focusing on workflows– and not just the feature function of the system.  A great example of initial focus on workflows are Flex Orders.  A flex order made it possible for a provider to make another order based on the results with little navigation to other screens.  EHR vendors expanded their solution offerings by developing specialty modules with workflow as the root of the design. The goal focused on targeting the right data, for the right patient at the right time.

As EHR vendors now target smaller hospitals, they pack their implementation services with tighter timelines, while accepting the EHR vendors tools, content and workflows.  Although the hospitals may be smaller, they still have complex requirements to collect and process the data in their unique environment. While an out of the box solution from the vendor is a great start, it may not provide enough focus on workflows.

Here’s one example from an EHR vendor:

  • Five years ago, the hospital employed trainers who would own the workflows. The vendor provided Viso diagrams of workflows so the hospital trainers could modify them as design decisions were made that required the workflow to change.
  • Now the same vendor recommends hospitals outsource training roles allowing the vendor to provide the trainers. However, now they aren’t documenting them accurately, if at all.

The same software company providing the roles that own your workflow is a self-serving offering.  Rather than the software vendor modify the workflow to accommodate a hospital, the hospital is now asked to modify their workflow to adopt the software.  This isn’t always a bad approach.  However, unless a hospital makes a specific focus to evaluate workflow design, it won’t happen on its own.  The vendor is focused on getting their software live as soon as possible.

Here’s an example of the impact on the hospital.

  • Five years ago, when a hospital went live, the Visio diagrams of the workflows would be referenced for training prior to Go-live and troubleshooting after Go-Live.
  • Now based on the out of the box implementation methodology, no one has the workflow diagrams which they have been implemented and trained on.

Many top EHR vendors have implemented their software several times –why not trust the out of the box solution?  When workflows are not properly documented and tailored for the specific health organization, loss in revenue can occur.

Excite Health Partners is currently working to correct a 27-million-dollar issue due to inaccurate workflow design and supporting documentation. During the implementation, the vendor did not document the workflows, and the revenue cycle test scripts weren’t customized to the hospital’s needs.

At Go-Live, the hospital realized the workflows hadn’t been built out (or tested) for one of the modules, pre-collections. They also discovered the Medicaid billing process actually had 2 different workflows the employees were following.  90% of the revenue cycle issues came back to workflow and building the system to support the hospitals processes. Excite is now helping our client resolve these issues. Important to remember to properly design and document workflows to void these types of issues.

Todd Klein

VP EHR Services & Digital Solutions

FLU SEASON’S HERE: CODING RESPIRATORY INFLUENZA

Posted by Samantha Serfass on February 19, 2019 in Blog, General, News

FLU SEASON’S HERE – Coding Respiratory Influenza

Every year, influenza season is considered to stretch from October through May.  The peak occurs between December through February, causing a lot of hospital encounters— whether as inpatients, emergency department visits, or physician office visits.

Within the medical world, there are different types of influenza viruses.  In order to reflect the type of influenza appropriately, the coding professional must carefully examine the documentation provided by the physician in order to assign the correct influenza code.  Within this article, we will discuss the different types of influenza and the documentation/coding nuances for each.

Sometimes the type of influenza will not be identified, but the physician will still document “influenza” and treat it as such.  Within the alphabetical index, this would be considered an unidentified influenza virus (J11.x).  Other times, the physician will order a nasal swab and it will come back positive for Influenza A or Influenza B.  In these cases, the influenza would be indexed as Influenza, identified influenza virus, NEC (J10.x).

Novel A Influenza virus is considered to be an influenza arising from animal origin, and is actually somewhat rare.  Some of the key words the physician must document in order to assign a code for Novel A are: “novel”, “avian”, “swine”, “H1N1”, “H5N1”.  The inclusive list of sub terms can be found within the alphabetical index and are also listed in the tabular index under J09. X.  These codes can only be assigned on confirmed cases of Novel Influenza because these are nationally reported infectious diseases.  If the physician uses equivocal terms such as “possible” or “probable” a code from the J09 section should not be assigned and the physician should be queried for clarification.

There are times when the coder will see documentation of “influenza like illness”.  In the alphabetical index, there is a specific entry for this, which directs the coder back to the main term of influenza.  Because there is a specific alphabetical index entry, this diagnosis is appropriate for assignment on both inpatient and outpatient cases.

Under all specified influenza types, there is a subset of manifestations defined by the word “with”.  Referring back to the Official Coding Guidelines for ICD-10-CM and PCS, the diagnoses listed under the term “with” are assumed to be linked and can be coded as such (i.e., influenza with pneumonia).

It’s important to remember chart documentation is critical when assigning the appropriate code for influenza.  The coder should carefully review the alphabetical index entries and assign the most appropriate code.  Remember that Novel A Influenza and Influenza A are not the same.  Influenza A is most common, whereas Novel A Influenza is rather rare.

Robyn McCoart

Director of Client Services, Excite Health Partners

Revenue Cycle: Increasing Revenue, Decreasing Deficiencies

Posted by Samantha Serfass on February 5, 2019 in Blog, News

Revenue Cycle:

Increasing Revenue, Decreasing Deficiencies 

Revenue Cycle Systems were the first applications used to help mature the Healthcare Industry, and by the mid to late ’90’s Clinical Systems followed. When EHR vendors started “advertising” integrated enterprise systems, most hospitals already had a Revenue Cycle system in place.

Project Directors and Project Managers alike are seeing a common thread when implementing an enterprise system. Often times during an implementation, the Revenue Cycle doesn’t see the full picture of their workflow from beginning to end.

Excite Health Partners’ VP of EHR Services & Implementation, Todd Klein, has seen this first hand. During an installation of a prominent enterprise system, a presentation from order entry to bill being paid was requested. After two rounds of iterations, the vendor provided the presentation. Todd stepped into a Project Director role after re-testing the system allowing for inconsistencies to be found. The re-test corrected charging issues, resulting in millions of dollars saved. The Emergency Department and Laboratory modules were also big contributors to the improvements.

Excite Health Partners has seen an increase in Revenue Cycle issues among new clients. In the later part of 2018, a client upgraded to the latest enterprise wide system incurring several issues costing them well over $25,000 in revenue on an annual basis. Workflows were not properly thought out and systems were not fully configured or tested.  Underestimating the value of testing can be detrimental.

Often times vendors test the new release with little to no issues at their corporate office. It’s important to note that each facility structure, billing rules and payer plans all contribute significantly to the hospital’s financial system. We offered a Revenue Cycle Project Manager as well as several analysts to help correct the issues our client was facing.

While there are several approaches to ensure the Revenue Cycle quality, it’s vital to use rigger in the testing and to know the workflow. Three important testing areas to focus on are:

  • Charge Testing
  • Parallel Testing
  • End-to-End Integrated Script Testing

On average a hospital can leave at least 1.4 million dollars on the table. Although that estimate will fluctuate based on the source of information, the problem is typically capturing charges or poor documentation. The Emergency Department is one of the largest contributors to this deficiency. By providing “At Risk Revenue Cycle Consulting”, Excite Health Partners is committed to combatting Revenue Cycle issues.

Our services increase revenue where deficiencies exist.  The service starts with an assessment, which identifies the amount of revenue we’ll help you increase.  Afterward, we produce an “At Risk Contract” where we partner with your organization with the goal of increasing your revenue.

When implementing an enterprise system or upgrading to a new release, make sure the system has been thoroughly tested.  If you feel dollars are being left on the table, partner with someone who will share the risks.

Todd Klein

VP EHR Services & Digital Solutions

EHR Implementation: Starting with Pre-Configured Solutions

Posted by Samantha Serfass on January 8, 2019 in Blog, News

EHR Implementation:

Starting with Pre-Configured Solutions

Each year hospital IT departments are tasked with more projects on an ever-shrinking budget. Consulting firms, like Excite Health Partners, continue to strive for ways to provide the most value to clients.

Vendors alike are also trying to provide more value.  EHR vendors focus on a “Community Model” which is typically a standard product already “configured”.  As hospitals continue to use a standard, or community model, provider satisfaction issues continue to rise. While often a stronger cost-efficient option, this can lead to a prolonged workflow processes and several user issues.

Today, smaller hospitals are leaning towards a “standard” preconfigured products and services out of necessity. However, downfalls still exist:

  • The system still must be configured for your hospital system
  • Hidden costs
  • End User Satisfaction

Regardless of the alterations an EHR vendor can make to their “standard” package, it still can lack the specifications of the hospital. For example, the system isn’t configured to know what a cardiac surgeons favorite order sets includes. It is not configured to send orders to the preferred lab system. Even by using the “standard” package with modifications, the system overall, still needs to be configured. This leads to hidden costs.

EHR vendors are likely to estimate the scope and size of the project to be lower on the spectrum, with the assumption the hospital’s IT team can handle issues that arise. This frequently means consulting services are needed. Vendor implementation teams tend be stretched thin, often with high amounts of turn over and less experienced resources.  Identifying a 3rd party or trusted advisor to help provide stronger resources can help address the issues that arise. While hidden costs are expected with large hospital IT projects, today vendors offer minimal services due to the ability to preconfigure systems. These systems are rarely an exact fit for the hospital’s needs.

End User Satisfaction also plays an important role. The “standard” package from the vendor is heavily preconfigured meaning less decisions are needed to be made. Hospitals that take this approach are required to alter the workflows to accommodate the software, instead of altering the software to accommodate the workflow. For any given workflow within a large healthcare system, variations for processes exist. Although, a vendor’s “standard” can be a good thing, but not in all cases. Only deviate from the “standard” when needed. Use SBAR (Situation Background Assessment Recommendation) to assess and reason why deviations are needed. Common reasons for deviations are:

  • Patient safety and regulations
  • Financial implication
  • Time savings for End Users
  • The complexity of your systems environment and the way you need to conduct business

For end users with preconfigured system, very few decisions need to be made. Leaving the question what can be changed about the system to improve end user satisfaction?

Chief Financial Officer, Dave MacDougall, from UHS Binghamton NY found a solution. During the EHR pre-implementation planning efforts, one deliverable produced was an End-User Road Map. This allowed the team working on the End-User Road Map to direct focus on items needed to configure to increase end user satisfaction. The team also highlighted not only where configurations could be made within the application, but what from the vendor’s app store could be used in conjunction with the EHR system. The team shifted focused to what can be modified and at what cost.

Don’t take for granted the EHR vendor will get it done- make end user satisfaction a priority during implementation.

Todd Klein

VP EHR Services & Digital Solutions

EHR Implementation: How to Begin the Process

Posted by Samantha Serfass on December 11, 2018 in Blog, News

EHR Implementation:

How to Begin the Process

 

Planning out an Enterprise EHR implementation is a complex process that goes beyond simply working with an EHR vendor.  Identifying the organization’s strategic initiatives and how the EHR application is going to support those initiatives are key factors in any implementation

EHR vendors have extensive experience creating applications, monitoring data needs, addressing user demands, and dispersing real-time information to multiple care providers.

Configuring software, for example, requires modifications to accommodate state regulations. While EHR vendors are compliant with these regulations, the software will only preform as well as it was configured. One major concern faced during an EHR implementation is the level of expertise provided by the vendor’s implementation team. When working with EHR vendors, it’s important to ensure you have the ability to refuse and/or replace resources. This will help to ensure all allocated resources are providing value to the project.

It’s important to remember to focus planning efforts to focus on the system being ready to support the strategic initiatives. Don’t take for granted the EHR vendor will get it done. Here are two examples from different hospital systems each implementing a different vendor’s solution:

  1. A hospital system with multiple outpatient clinics goes live using the vendors approach to reporting.  After completing the go-live phase, M.U reports are compiled. However, the reports compiled do not display the correct data.  Because there was a lack of specific focus at the start of the project, the team and vendor needed an additional two months to correctly compile the reports.
  2. A 5-hospital system with multiple outpatient clinics discovers after their go-live they are losing significant money. The financial loss occurs because the vendor did not configure the billing rules engine, therefore the charges weren’t tested accurately for processing. This hospital system accepted the vendor’s testing approach and did not fully complete parallel testing, when bills are drop so they can be validated.

Unfortunately, a hospital organization must take part in managing the vendor to verify the system can functionally serve healthcare organization properly at go-live.  Below are four key factors to consider when managing an EHR vendor.

In the age where vendors create report cards on their clients performance, hospital systems need to put the vendor in check when the risks are high and the probability for them to become real, exists (as portrayed so many times in the news). How are things different now than in past EHR experiences?

 

Todd Klein

VP EHR Services & Digital Solutions

Obstetrical and Newborn Coding Tips for ICD-10-CM and PCS

Posted by Samantha Serfass on November 28, 2018 in Blog, News

Obstetrical and Newborn Coding

Tips for ICD-10-CM and PCS

 

With the implementation of ICD-10-CM and ICD-10-PCS, some areas of obstetrical and newborn coding have become a little more complicated than we were previously used to.  There were a lot of changes to the diagnosis codes, and new root operations to consider when coding procedures, which continues to cause confusion with coders.

 

Probably the biggest challenge is appropriately assigning the trimester qualifier versus the in-childbirth qualifier when assigning obstetrical diagnosis codes.  Not all codes have the “in childbirth” qualifier, so it is important for the coder to carefully examine all of the options for the particular diagnosis.  The code for anemia O99.0xx) is a good example of a diagnosis that has multiple qualifiers – first trimester, second trimester, third trimester, in childbirth, and during the puerperium.  If the patient presents for delivery and the physician documents she has anemia, then it is appropriate to use the “in childbirth” qualifier.

 

Fetal monitoring is performed on many women during the course of labor.  The typical type of monitoring used is external fetal monitoring, where a transducer is worn like a belt.  Most facilities do not require the coder to assign a code for the external fetal monitor.

Induction of labor has been used more and more frequently since the mid-1990’s.  Over the years, more and more types of induction have been used, but the most commonly used procedures are artificial rupture of membranes (AROM),  IV medication (typically Pitocin); cervical gel insertion (prostaglandin), and foley bulb insertion.  In order to code this procedure correctly, first the coder has to understand the difference between labor induction and labor augmentation.

 

Induction of labor occurs when there is no definitive labor pattern established at the time the medication is given.   Augmentation of labor infers that there is an established labor pattern, but labor may not be progressing well (ineffective contractions).  Sometimes an established labor pattern is given a “boost” by either rupturing the membranes or administering some Pitocin, and should not be assigned an induction code.  Cervical gel insertion requires the placement of a gel-filled capsule containing prostaglandin against the cervix to soften the cervix (often referred to as ripening), thus allowing for dilation.  The last mode of induction is classified in ICD-10-CM as a surgical induction, and consists of a foley catheter bulb being threaded into the cervix.  The saline bulb in the catheter is filled with saline, thus expanding the cervix.

 

The last area to be discussed are codes from the newborn section, specifically P03.X.  These codes are only to be coded on the newborn chart, not on the mom’s chart.  The P03 section are used to reflect a newborn affected by other complications of labor and delivery.  Basically this means that these codes can only be assigned fi the physician specifically states a complication of the labor and/or delivery directly affected the well being of the baby.  A good example of this is when the baby is delivered with a nuchal cord around it’s neck; unless the physician documents an adverse outcome of the nuchal cord (respiratory distress, aspiration, etc), a code from the P03 section should not be assigned.  Many times the presence of a nuchal cord is documented, but there are no untoward event associated with it.

 

Obstetrical and newborn coding has always been somewhat challenging but has become even more so in ICD-10-CM and ICD-10-PCS.  Coders must be aware of the documentation requirements, indexing, and knowledge of the procedures being performed in order to apply the correct diagnosis and procedure codes.

 

 

Robyn McCoart

Director of Client Services at Excite Health Partners

Breaking It Down: Understanding the Classification of Drug Toxicity

Posted by Samantha Serfass on October 16, 2018 in Blog, News

Breaking It Down:

Understanding the Classification of Drug Toxicity

 

It is no surprise as to why many coders are having a problem coding poisoning, adverse effects and under-dosing. There are multiple guidelines to apply when considering the code choices in this category thus making the coding more complicated.   Physicians do not always document the terms poisoning, overdose, adverse effect or under-dosing.

This means the coders really need to understand how to apply the guidelines to the documentation in the record. Intent has to be determined in order to apply the correct overdose code and the correct status code for under-dosing.  To add further confusion, the manifestations are coded along with the poisoning code which contradicts the basic coding guidelines on symptoms.  Finally, sequencing guidelines are not consistent and are based on the type of drug toxicity code being assigned.

In order to simplify the process, there are four main elements to think about when making a decision on how to code in this category.

A poisoning is taking too much of a medication or not administrating the medication by the correct route, whether it was prescribed, over the counter or as a result of substance abuse.  This may be either intentional or accidental   Also falling into the poisoning category is taking prescription medication that was not prescribed with a current prescribed drug or mixing current medications with alcohol.  When sequencing, the poisoning codes are sequenced first followed by any manifestations.

  • An individual poisoning code is assigned for all drugs involved.
  •  Acute conditions as a result of drug and alcohol abuse are also included in this category.

Poisoning intent is the intention of why the poisoning occurred and this is built into the poisoning code as the 5th or 6th character.  Categories include accidental, assault, suicide, and undetermined.  If there is no documentation of the intent in the record the default is accidental.  Undetermined should only be used if documentation in the record states the intent of the poisoning cannot be determined.

An adverse effect is an acute symptoms or condition that occurs as a result of taking medication as prescribed and properly administered.  The manifestations are sequenced first followed by the adverse effect drug code.  Intention is not considered for adverse effects since the drug is taken as prescribed.

Under dosing is taking less of a medication than prescribed or not taking the prescribed medication at all.  This may result in an exacerbation of the condition that the drug was prescribed to treat.  The manifestation is sequenced first followed by the Under-dosing drug code.

Under-dosing Intent: Is the intention of why the drug was not taken as prescribed.  This is a status code that is not built into the under-dosing code. Categories are intentional, intentional due to financial hardship, unintentional, and unintentional due to the patient’s age related debility

A manifestation is an acute symptom, condition, or exacerbation of a chronic condition as a result of not taking medications as prescribed, taking medication as prescribed, or as a result of drug abuse. Note that manifestations are coded in all drug toxicity categories.

 

Case 1

Patient presents with syncope and states he had a couple of beers soon after taking his Metoprolol as prescribed.

  • T44.7X1A Poisoning by beta-adrenoreceptor antagonists, accidental, initial encounter.
  • T51.0X1A Toxic effect of ethanol, accidental, initial encounter
  • R55   Syncope

Rationale: This is a poisoning. Although medication was taken as prescribed, the medication was taken with alcohol resulting in the acute condition of syncope.  The poisoning codes for both the medication and alcohol are sequenced first. The intent was accidental and is built into the poisoning code. The manifestation of syncope is coded last

Case 2

Patient presents with headache and dizziness. He was just started on Metoprolol for his blood pressure and has been taking this as prescribed.

  • G44.40      Drug induced headache, NEC, not intractable
  • R42             R42 Dizziness and giddiness
  • T44.7X5A   Adverse effect of beta-adrenoreceptor antagonist, initial encounter.

Rationale: This is an adverse effect.  The medication was taken exactly as prescribed.   The manifestations are the acute conditions of headache and dizziness. The manifestations are sequenced first, followed by the adverse effect drug code.

Case 3

Patient presents in hypertensive crisis. After questioning, it was found that he was only taking his blood pressure medicine a couple times a week due to the price.

  • I16.9   Hypertensive crisis, unspec
  • T44.7X6A (Underdosing of beta-adrenoreceptor antagonists, initial encounter
  • Z91.120 Patient’s intentional under-dosing of medication regimen due to financial hardship

Rationale:  This is an under-dosing.  The patient was taking less than the prescribed medication. The manifestation is the hypertensive crisis. The intent is intentional due to financial hardship.  In this case, the manifestation of hypertensive crisis is sequenced first, followed by the under-dosing drug code.  The intent is not built into the under-dosing code and is sequenced last as a status code.

 

Mary J. Wood, RHIT, CCS. AHIMA Approved ICD-10-CM/PCS Trainer

Internal Auditor/Educator