Stream: CARIN IG for Blue Button®
Topic: CARIN BB IG Context
Jason Teeple (May 19 2020 at 10:57):
Hi All, Can someone help me understand the Context for Practitioner? Meaning, is the Practitioner profile data intended to be relevant at the point in time of the claim? The questions comes down to how do you source the Practitioner and PractitionerRole profiles, via claims or provider directory? I intended to have this conversation yesterday during the WG session, though it appeared to be cancelled. Appreciate any guidance that can be offered. @Mark Roberts
Jason Teeple (May 20 2020 at 10:01):
@Ryan Howells would you be able to help answer my question?
Ryan Howells (May 20 2020 at 11:59):
Our tech team can weigh in here. @Amol Vyas @Saul Kravitz @Pat Taylor @josh lamb
Michele Mottini (May 20 2020 at 12:55):
My take would be from provider directory if possible - the more up to date and complete data the better (in our system that's not the case currently, we return the providers data as it was entered together with the claim, but we'd like to get the provider directory data there at some point)
Jason Teeple (May 20 2020 at 13:16):
If sourcing Practitioner Profile out of the directory, couldn't there be a disconnect with Practitioner demographic detail provided on the claim? Or is the intention to use PractitionerRole to represent the practitioner's engagement based on the claim detail with a reference to Practitioner for demographic details?
Josh Lamb (May 20 2020 at 13:23):
@Jason Teeple This has been a topic of debate lately. The guidance that we are proposing is that this will depend upon the source system if they can provide the Patient, Practitioner, and Practitioner role as of the date of service of the claim or if they maintain only the current state of the Provider and Member. Not all payers systems are configured in the same way.
We are currently thinking of ways to make it clear that a referenced resource was communicated as of the date of service or if the current state of the referenced resource was provided. We have considered using the "Active" flag to communicate this. When "Active" is true the referenced resouce is the active version of the resource, otherwise it is a historical instance of the resource.
I agree with @Michele Mottini that when a member is viewing an EOB the provider's current information would be more relevant, especially since the adjudication results would not change over time. Claims information must always be communicated as of the claims adjudication date and the Coverage(insurance) information must always be provided as of the date of service.
Jason Teeple (May 20 2020 at 15:20):
Thank you @Michele Mottini and @josh lamb. Having clarity around the Patient, Practitioner, and PractitionerRole would be helpful when talking with mapping folks. I could see a scenario where Patient and Practitioner are current state and PractitionerRole is date of service. As Patient and Practitioner could be sourced out of eligibility and Provider Repos, respectively. And PractitionerRole is source out of the claim line.
The CARIN BB Patient Profile gets interesting, compared to USCore Patient Profile as it appears there is an attempt at some Master Data Management. The WG might need to address this topic at some point.
Amol Vyas (May 22 2020 at 09:47):
Hi @Jason Teeple . As @josh lamb pointed out, the context of the content of the adjudicated claim/EOB as well as the content of the referenced resources (for example, Coverage, Patient, Practitioner, etc) is currently being discussed. The attempt is to position the IG unambiguously such that Payers are not necessarily burdened with additional implementation complexity and at the same time the 3rd party client app user experience matches as much as possible with that of a Health Plan Member Portal user. An EOB, in the traditional sense, is usually a (paper/pdf) document consisting of static snapshots of adjudicated claim, member, practitioner and coverage information as of the date of service, regardless of when it is printed or downloaded. Moreover, to your point, the 3rd party apps can always have access to the latest/current version of the Patient/Member, Practitioner or Coverage through other existing (FHIR/non-FHIR) APIs (such as Member Directory, Provider Directory or Eligibility/Benefit Lookup). As far as allowing a Payer to express the context (date of service or current) of its response clearly, we're considering a few options including 1) using meta.lastUpdated for all referenced resources, or 2) having the Payer use the document paradigm to return the data as of the service date (or a regular bundle to return the current data).
Regarding the Patient profile identifiers, we've updated the min cardinality of all Identifier slices except memberIdentifier to 0. We will also introduce a new optional slice to capture a master member identifier (i.e. belly button identifier) that Payers might want to convey to the 3rd party apps. This is aligned with similar work being done within DaVinci where they've introduced a new Identifier type of "UMB" (for Unique Member Identifier). We plan to provide clarification around this basic support for mastering within the narrative for the slices/profile.
Other thoughts?
Charlie Filkins (Jul 16 2020 at 15:19):
Hello ... I'm fairly new to all of this, so I don't have much history. However, it seems to me that you're working hard to define something that sounds a lot like a FHIR Person to me. From my perspective, which is that of a payor, we can create Person instances for people who create accounts to access our APIs. From there, we would consider Patients as analogous to what we know as Member, individuals who enroll in a plan of benefits (Coverage), like Medicare or Medicaid. Since we offer both plan types, consolidating information for dual eligible Persons into a single Patient is proving problematic.
I'm not entirely sure how this idea works with bulk transfer of information, but on the surface at least, it makes the Patient Access API much easier to implement.
Comments are appreciated.
Michele Mottini (Jul 16 2020 at 15:25):
It might make it easier to implement, but all the existing implementations (CMS BlueButton, EHRs) and the SMART standard use Patient, not Person - so we are stuck with that
Lloyd McKenzie (Jul 16 2020 at 15:30):
Person is a linking resource. It's never allowed to be directly referenced as a subject or other actor.
Charlie Filkins (Jul 17 2020 at 11:35):
Thank you both for your replies. Maybe someday we can amend the earlier decisions to make life easier.
Sai Valluripalli (Jun 16 2021 at 12:32):
Good Morning Team, Does Blue Button provides any logs for us to track who tried to access the API?
Daniel Venton (Jun 16 2021 at 12:44):
Most of the IG's define the operations to support and the data structure. The logs (audits) you capture are dictated by other mechanisms like HITECH (I think I got that right) etc. It's probably easier to track who did access data as opposed to who tried, as in some cases all you might have about who tried is an ip address.
Sai Valluripalli (Jun 16 2021 at 12:46):
Thank you Daniel.
Last updated: Apr 12 2022 at 19:14 UTC
