Stream: CARIN IG for Blue Button®
Topic: CMS / CPCDS and Encounter Data
Christopher Marchand (Apr 25 2020 at 17:13):
Hi team - trying to make sure I understand something. The CMS Patient Access rule talks about encounter data being made available through the CPCDS IG - is the idea that this encounter data will come over on one of the EOB resources and NOT leverage the encounter resource?
Michele Mottini (Apr 25 2020 at 17:56):
No, should use (US Core) Encounter resource
Christopher Marchand (Apr 25 2020 at 18:31):
I don't see this outlined anywhere. The CMS ruling doesn't mention it (that I see), nor does the CPCDS IG. Is there any additional context you can give me, @Michele Mottini ?
Michele Mottini (Apr 25 2020 at 21:39):
The rule does not mandate a standard but lists:
o FHIR 4.0.1
o US Core IG STU 3.1.0
o SMART IG 1.0.0
o FHIR Bulk Data (Flat FHIR)
o OpenID Connect 1.0
Michele Mottini (Apr 25 2020 at 21:39):
So US Core for clinical data
Josh Lamb (Apr 27 2020 at 16:14):
The final rule references the CPCDS IG. If you adhere to this IG (still under development) you will meet the requirements of the Patient Access API final rule. My understanding is that the encounter mentioned in the context of the CMS final rule was not meant to imply the FHIR encounter resource. The FHIR encounter is optional within the CPCDS IG. It not marked with "Must Support" and the minimum cardinality is 0 within the ExplantionOfBenefit resource.
Michele Mottini (Apr 27 2020 at 16:44):
The patient access API should expose all clinical data that the payer has, not just claims
Isaac Vetter (Apr 28 2020 at 00:48):
In my unfortunately minimal understanding, it's a bit of a mistake to consider a claim encounter as equivalent to a clinical encounter. For example, here's Anthem's publically available X12 837 Professional Health Care Claim—Encounter. This isn't a "clinical encounter" and forcing it to masquerade as such is simply poor data modeling. Note that even CMS's BB2 didn't profile/use Encounter; they represented the claim/encounter as EoB.
Isaac Vetter (Apr 28 2020 at 00:48):
If there actually is clinical data (meaning originating from the patient or from a provider, not from administrative processes), that's when it makes sense to use US Core.
Isaac Vetter (Apr 28 2020 at 00:48):
@Michele Mottini - whaddya think?
Josh Mandel (Apr 28 2020 at 00:55):
The final rule references the CPCDS IG. If you adhere to this IG (still under development) you will meet the requirements of the Patient Access API final rule.
This doesn't make sense to me given that the IG wasn't even close to complete at the time the rule was drafted, and given that compliance with the IG is optional
Any important definitions must be in the rule, not in the IG.
John Moehrke (Apr 28 2020 at 13:37):
Provenance is so important. Even a .meta.security tag of integrity would be helpful (clinician asserted, patient asserted, payer asserted, etc) http://build.fhir.org/v3/SecurityIntegrityObservationValue/vs.html
Michele Mottini (Apr 28 2020 at 14:35):
@Isaac Vetter yes, I was talking about 'clinical' encounters - and all the potentially associated clinical data. We do not have separate 'claim encounters' but we have encounter-like data like caregivers and date ranges in claims that we map to ExplanationOfBenefit (and not to Encounter)
Josh Lamb (Apr 28 2020 at 16:25):
@Josh Mandel , are you saying that the CPCDS IG will not ensure that payers meet the patient access API requirements? I can see that the CPCDS IG will not address clinical data but it is called out in the final rule as a way to adhere to the requirement to communicate claims data.
The final rule says that payers need to communicate clinical data that they maintain. A payer will not be able to communicate clinical data that they do not posses.
Pat Taylor (Apr 28 2020 at 18:30):
Hi Josh,
Yes, we’re proposing the statement, ‘The Interoperability and Patient Access final rule provides that CMS-regulated payers are required to implement and maintain a secure, standards-based (HL7 FHIR Release 4.0.1) API that allows patients to easily access their claims and encounter information, including cost, through third-party applications of their choice.’ be added to the Chapter Titled Consumer-directed exchange.
Pat
Josh Mandel (Apr 28 2020 at 18:33):
Sorry for the confusion: I wasn't trying to say anything about what the CARIN Blue Button IG will or won't ensure -- just saying that compliance with the IG is not directly related to compliance with the CMS final rule.
MaryKay McDaniel (May 14 2020 at 01:39):
Hi all,
I didn't see this earlier, so if this has been discussed elsewhere, sorry for the duplication. Any time I see the words "Claim and Encounter" in the same sentence I think encounter = a zero paid claim. I went back to confirm that rule did use the words claim and encounter in the same sentences and they did indicate an encounter is a zero paid/pay claim. (AND because I don't think you all were thinking of the Medicaid/care Encounter reporting process I'm not going down the path of the Medicaid/Medicare term encounter which in some instances means a post adjudicated claim sent in a post adjudicated claim data reporting message, a mishmash of claim and eob in one UberClaim Layout.)
Encounter in this context is:
"42 CFR 422.119, 431.60, 457.730, and 45 CFR
156.221. Specifically, we are requiring that the Patient Access API must, at a minimum, make available adjudicated claims (including provider remittances and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results (when maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. We are requiring that beginning January 1, 2021, impacted payers make available through the Patient Access API the specified data they maintain with a date of service on or after January 1, 2016. This is consistent with the requirements for the payer-to-payer data exchange detailed in section V. of this final rule. Together these policies facilitate the creation and maintenance of a patient’s cumulative health record with their current payer."
In this context an encounter is a zero pay claim...
Mary Kay
Bhanu Vemuri (May 14 2020 at 12:36):
MaryKay McDaniel said:
Hi all,
I didn't see this earlier, so if this has been discussed elsewhere, sorry for the duplication. Any time I see the words "Claim and Encounter" in the same sentence I think encounter = a zero paid claim. I went back to confirm that rule did use the words claim and encounter in the same sentences and they did indicate an encounter is a zero paid/pay claim. (AND because I don't think you all were thinking of the Medicaid/care Encounter reporting process I'm not going down the path of the Medicaid/Medicare term encounter which in some instances means a post adjudicated claim sent in a post adjudicated claim data reporting message, a mishmash of claim and eob in one UberClaim Layout.)
Encounter in this context is:
"42 CFR 422.119, 431.60, 457.730, and 45 CFR
156.221. Specifically, we are requiring that the Patient Access API must, at a minimum, make available adjudicated claims (including provider remittances and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results (when maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. We are requiring that beginning January 1, 2021, impacted payers make available through the Patient Access API the specified data they maintain with a date of service on or after January 1, 2016. This is consistent with the requirements for the payer-to-payer data exchange detailed in section V. of this final rule. Together these policies facilitate the creation and maintenance of a patient’s cumulative health record with their current payer."In this context an encounter is a zero pay claim...
Mary Kay
We identify the definition for encounter as below from the X12 aspect of encounter claims. This is with the precondition as they are received from capitated providers. Not sure , we need to include claim payment amount as a filter for encounter.
837 received include BHT06 = RP and 2300 CLM05-03 = 1 (Claim Frequency Code )
Last updated: Apr 12 2022 at 19:14 UTC
