Stream: implementers
Topic: Encounter data for claims
Noam Kurtis (Feb 19 2021 at 13:45):
As part of the federal interoperability mandates, will EHR’s be required to share the patient encounter data with a third-party app for use of this data to prepare claims submission to the carriers, at the providers/patient’s request of course?
Lloyd McKenzie (Feb 19 2021 at 14:19):
@Robert Dieterle
Michele Mottini (Feb 19 2021 at 15:11):
Not in the currently mandated USCDI v1, it appear that they are being added to USCDI v2 (https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi)
Noam Kurtis (Feb 19 2021 at 17:34):
@Michele Mottini Thank you, I see that encounter data might be part of USCDI V2. Are you familiar with the current process of how providers source their encounter data to send to the their billing processors? Are they taking the data from their EMR or are they maintaining a separate database?
Michele Mottini (Feb 19 2021 at 18:06):
Sorry, don't know
Noam Kurtis (Feb 19 2021 at 18:13):
Ok thanks again for your help
Cooper Thompson (Feb 19 2021 at 19:00):
I do want to point out that there are two different meanings of the word "encounter" in the context of 21st Century Cures. There is the clinical Encounter, which as Michele pointed out is what is included in USCDIv2, and is not currently required (but is supported by a bunch of EHRs anyway). There is also encounter data from capitated providers, which is required for certain payers by the CMS rule.
It sounds like you are talking a bout the clinical encounter, but since you are talking about claims, the CMS rule may apply. I think typically the CMS-required encounter data actually gets represented as ExplainationOfBenefit.
Cooper Thompson (Feb 19 2021 at 19:01):
Noam Kurtis (Feb 19 2021 at 19:23):
@Cooper Thompson thank you very much. So if I understand correctly: clinical encounter data would be required to be shared by EHR’s if/when this resource will be included in USCDIV2; Interestingly, as you pointed out, some EHR vendors currently support encounter data to be transmitted out of the EHR to third-party apps. Capitated providers encounter claims are required to be provided by the *payer. Did I understand this correctly?
Cooper Thompson (Feb 19 2021 at 22:31):
Yup. That is my understanding. Normal disclaimer: for the regulatory stuff, you'll need to make sure your own interpretation aligns with what we discussed.
Lin Zhang (Feb 20 2021 at 15:30):
Someones call them as clinical/billing encounters.
Noam Kurtis (Mar 01 2021 at 13:39):
As USCDI V1 does not include a “claims encounter” requirement (noted that proposals for USCDI V2 may include this encounter info) what are my current workarounds to extract encounter info information (for claims processing) from the various EMRs in the market?
Cooper Thompson (Mar 01 2021 at 19:22):
EHRs are not required to share claims encounters. Payers are. Payers are often not going to be using EHRs for claims processing (though some may use products created by the same company that makes an EHR).
I don't think USCDIv2 covers the concept of "encounters" as defined by the CMS rule. Though maybe it is more ambiguous. "Claims encounter" will be the ExplainationOfBenefit resource (not Encounter). So if the payer you are looking at choses to use FHIR EOB for their claims encounter data, you can look for their EOB API.
I believe the current CMS rule on the books doesn't require EOB for claims encounter data, but the interim rule that came out in January does. But I think that rule is currently in review by the new administration, so... ¯\_(ツ)_/¯
Noam Kurtis (Mar 01 2021 at 22:25):
@Cooper Thompson Thank you. You are bringing up an interesting point, I may be confusing two distinct rules/proposed rules that reference “encounters”? In reference to the ONC inter-operability rules mandating that stakeholders share USCDIV1, am I correct in understanding that this requirement to share the all classes within a specific version of USCDI applies to all stakeholders? You seem to have a clear handle on this information, thanks for your responses.
Noam Kurtis (Mar 01 2021 at 23:12):
(ie In reference to the “information blocking” rule, I am under the assumption that all covered actors will be required to share the set of data classes from USCDI)
Noam Kurtis (Mar 01 2021 at 23:14):
Which makes me realize that the better way to phrase my question is, can the provider request/require their EHR vendor to allow an outside application to access the encounter information entered into the EHR by the provider?
Michele Mottini (Mar 01 2021 at 23:23):
Encounters are not part of USCDI v1 - but providers can request / require whatever they like from their EHR vendors of course
Noam Kurtis (Mar 02 2021 at 01:21):
@Michele Mottini of course a provider can request from their EHR anything they input, otherwise that would not be a very good EHR :) My question was in regards to whether providers can request/require their EHR to connect to a third-party app of their choosing to transfer their encounter/ claims data, or what are the current workarounds to connect to the various EHR‘s via third-party apps to collect claims and encounter data (for billing purposes)
Michele Mottini (Mar 02 2021 at 01:53):
Sorry, I don't understand what you are asking.
Some EHR system already support getting encounters via FHIR, see fhir.cerner.com, fhir.epic.com, and I am sure there are other ways. Do not know any way to get claims data out of EHRs, but I know only about FHIR.
(I did not write 'from their EHR', I wrote 'from their EHR _vendor_': providers buy systems from EHR vendors - they are the customer, they can request whatever feature they like, and if they pay enough they'll get it)
Noam Kurtis (Mar 02 2021 at 11:23):
Thanks Michele, I appreciate the links to the fhir cerner and epic pages, that is very helpful. Noted your comment about EHR vendors vs EHR’s. Do you have any knowledge of what, epic for example, will charge for sandbox and registration of third-party apps for their FHIR access?
Michele Mottini (Mar 02 2021 at 13:48):
Registration is free. There are charges for apps that wants more than the mandated data (eg if they want encounters) but I do not know what they are
Cooper Thompson (Mar 02 2021 at 14:23):
@Michele Mottini in Q4 2020 we expanded the FHIR APIs that are available on fhir.epic.com to be more than what is mandated. Encounter is available for apps created on fhir.epic.
Noam Kurtis (Mar 02 2021 at 14:49):
Thanks. On fhir.epic.com, is “Condition (Encounter Diagnosis)” the data class that can provide CPT and ICD10 codes ? Also will cpt and icd10 codes be consistently available via API or will these codes availability depend on what the provider inputs into their EMR?
Michele Mottini (Mar 02 2021 at 14:58):
Oh cool, thanks @Cooper Thompson
Cooper Thompson (Mar 02 2021 at 14:58):
The relevant USCDIv1 data classes are "Problems" and "Health Concerns". Those are represented in "Condition (Problems)" and "Condition (Health Concern"). We also provide encounter diagnoses (that you referenced) as a non-USCDI FHIR API. All of those APIs support ICD-10 codes. However, whether a given health system's API will return ICD-10 codes depends on that health system (though ICD-10 is probably one of the most consistently available code sets).
I don't think CPT makes sense to return for Condition. CPT is a procedure coding system. Also, while ICD-10 will be pretty reliably available for Conditions, ICD-10 is not the applicable standard per USCDIv1 for Problems and Health Concerns. Health Concerns does not have an applicable standard, and Problems lists SNOMED CT.
Noam Kurtis (Mar 02 2021 at 15:09):
Thanks for correlating the uscdi classes to those at epic’s. Sounds like icd10 codes should be easy to obtain via the api’s. Does epic have a cpt element available via api?
Noam Kurtis (Mar 02 2021 at 15:10):
Noted that ICD10 is not a standard in USCDIV1.
Noam Kurtis (Mar 02 2021 at 15:17):
Helpful to know that epic’s api will offer more than the USCDI minimum.
Cooper Thompson (Mar 02 2021 at 15:28):
If ICD-10 is one of the more reliable code systems, CPT is probably one of the most un-reliable. However CPT is for procedures, not diagnoses. Normally I expect folks to ask about the data types first, then get in to the code sets.
But if you want CPT on procedures, you'll mileage will vary. CPT is a billing-related code set. Typically organizations have CPT codes configured for their billing systems. Often, Epic is used for both clinical care and billing, but there are also many organizations that use an external billing system. In that case, CPT codes may not be used in Epic at all. And even if they are using Epic for billing, often times, the CPT won't be (discretely) associated with the clinical procedure, so while we have the CPT for the billing process, we don't have a way to send it for the clinical procedure. Now all that said, in many cases we do have the CPT link to the clinical procedure, and in that case, we will send it. But like I said, your mileage will vary.
Noam Kurtis (Mar 02 2021 at 15:54):
Ok this adds a lot of clarity, thank you. When CPT codes are available in EPIC, is this a result of a billing process that has been initiated or can the cpt code populate in epic ( when it is available) before a billing process is initiated ? In essence, would one be able to use an epic api to share cpt and icd10 codes (from pt encounters) via epic’s fhir app
Noam Kurtis (Mar 02 2021 at 16:06):
I am looking for the the cpt and icd10 code sets, and I guess I am working backwards to correlate this to their appropriate data class
Cooper Thompson (Mar 02 2021 at 17:26):
I guess I should back up a little. ICD-10 has two different types of "codes". There are "code" and "term" type codes. For clinical purposes, typically you'll have the ICD-10 code for the "term" type. For billing, you'll use the "code" type. I don't have any idea what your use case is, so I don't know if you'd want the term or code type ICD-10 codes. (This whole thing is confusing because the term "code" is used in two different ways").
For CPT codes, I can't really make any promises for what you will see operationally. Organizational and end-user practices for CPT vary a lot.
Noam Kurtis (Mar 02 2021 at 18:09):
Ah I was not aware that there are different types of ICD10 codes , ie “term” and “code” types. Thanks for clarifying. In billing use cases, “code” type ICD10, is this/will this be available via epic fhir api?
Noam Kurtis (Mar 02 2021 at 18:19):
Is ICD “code” type (billing use case) identical to ICD-10-PCS , and is the clinical reporting “type” the ICD-10-CM ?
Cooper Thompson (Mar 02 2021 at 18:57):
Our clinical APIs (e.g. Condition) would typically use term-type ICD10 codes. Both code and terms are both in the ICD-10-CM set. Billing related APIs (e.g. ChargeItem) would use the codes (but we don't support any billing APIs yet).
Also, I guess I should clarify that the term/code distinction is based on the IMO clinician friendly term structures. The point I was trying to make is that you may get different ICD-10 codes for clinical use and billing purposes.
Noam Kurtis (Mar 02 2021 at 21:37):
Thanks for clarifying the varying ICD10 codes and how Epic supports the clinical sets. If I am a physician entering patient/ clinical information into Epic, and I want my billing vendor to get info from Epic that they can then translate into claims submissions, what are my options? Am I able to share data classes from Epic that include both clinical diagnoses and procedures terms via api, (that billers can translate into billing codes?) Ot does Epic support any third-party apps that translate diagnosis and procedures terms into billing codes?
Last updated: Apr 12 2022 at 19:14 UTC
