Stream: implementers
Topic: CMS implementation
Vibin_chander (Dec 02 2020 at 12:13):
Is there an official rule from CMS that states that payers should use only US Core Data for Interoperability (USCDI) mentioned profiles? for the Patient Access API ?
Vibin_chander (Dec 02 2020 at 12:14):
Can any data standard experts give me a clarification on that?
Cooper Thompson (Dec 02 2020 at 13:58):
Here is the CMS rule section (this applies to MA, but there are two other basically copy/paste sections for other payer types): https://ecfr.federalregister.gov/current/title-42/chapter-IV/subchapter-B/part-422#p-422.119(a)
Vibin_chander (Dec 02 2020 at 14:28):
Im not finding a place where its written to follow which profiles we need to follow or mandatory right?
Yunwei Wang (Dec 02 2020 at 14:38):
Technical requirements. An MA organization implementing an API under paragraph (a) of this section:
(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;
The 45 CFR 170.215 has a list
Cooper Thompson (Dec 02 2020 at 14:38):
In the rule itself, 42 CFR 422.119(c) is probably the best you'll get. It points to the standards defined by ONC, which includes a list of FHIR R4, US Core, SMART, Bulk FHIR, and OIDC. However not all of those make sense for CMS Patient Access. I think there has been various clarification from CMS scattered around, but in terms of the actual rule language, it definitely isn't very clear.
Vibin_chander (Dec 02 2020 at 14:43):
@Yunwei Wang I see that it is only mentioned that we should adopt the US core profiles. But it is not clear if we can do profiling on top of these US core profiles
Vibin_chander (Dec 02 2020 at 14:44):
There are only 26 profiles mentioned in the US core profiles. For the Patient Access APi this is not sufficient to cover all the use cases needed for capturing the Encounter information
Vibin_chander (Dec 02 2020 at 14:45):
But If we do profiling on top of the profile -- then its more like creating our own profile right?
Yunwei Wang (Dec 02 2020 at 15:06):
My understanding is that those are the minimum requirement. Server shall implement at lease what required and can support additional profiles (or more restricted profiles)
David Pyke (Dec 02 2020 at 15:07):
You can re-profile the US Core profiles for your use case but you must use the USCore profiles as a base for information that is relevant to them
David Pyke (Dec 02 2020 at 15:08):
Most of CMS requires the use of the Davinci and CARIN profiles (which also are derived from USCore, where appropriate)
Cooper Thompson (Dec 02 2020 at 15:51):
The for the claims and encounters part of the CMS patient access API, there isn't really any specific profile named since those concepts aren't included in US Core. You can just infer FHIR R4. You may choose to use CARIN or DaVinci profiles, but those aren't named in the CMS rule for Patient Access (yet).
David Pyke (Dec 02 2020 at 15:57):
CARIN and Davinci are specifically called out in the guidance: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index
Vibin_chander (Dec 02 2020 at 16:13):
Thank you all for the comments. I really thank and appreciate it. I understand that I can safely suggest that, we can create our own profiles on top of the US core profiles..
But I have couple one doubt on the comment of @David Pyke when u mean we should use "USCOre profiles as base profile" does it mean we need to use only those 26 resources provided by them? or we can add extra resources as part of r4 too?
David Pyke (Dec 02 2020 at 16:14):
You can use any resource but if you're using the resources that USCore profiled, you have to use the USCore profiles of those resources
Vibin_chander (Dec 02 2020 at 16:16):
got it. Thanks a lot for the clarification. I do see what you have mentioned is correct. In many places they have called out Davin pdex and carin bb. for clinical they're using the US core standards
Cooper Thompson (Dec 02 2020 at 16:22):
@David Pyke That CMS link explicitly says that the use of the IG listed on that site is not required. Using them seems like it would probably position folks well for future rules, but I still don't believe there is any requirement for DaVinci or CARIN IGs for Patient Access API.
David Pyke (Dec 02 2020 at 16:22):
No, there's no hard requirement but they're being built specifically to address the CMS rule. Why reinvent the wheel?
Vibin_chander (Dec 02 2020 at 16:24):
@Cooper Thompson is there a link and line says that we can re-profile a existing US-Core profile in CMS guideline? I'm finding it hard to get that statement in CMS link anywhere
Vibin_chander (Dec 02 2020 at 16:25):
and without that it is hard to confirm anything and we will be doing things under assumption
Cooper Thompson (Dec 02 2020 at 17:03):
You'll have to interpret on your own based on the info provided so far. I'm very specifically NOT providing guidance or interpretation, and the question about re-profiling I think falls into that category. I'm trying to be very careful to only point out what the regulatory language is. Any clarifications or qualifications about what is allowed or not would need to come from CMS, not me. I think you are coming to understand the joys of interpreting regulation :). (I think ONC and CMS did a good job with the rules, but some stuff is really hard and complicated to nail down, especially with some of the targets moving during or soon after the rulemaking process).
Yunwei Wang (Dec 02 2020 at 17:20):
Take a look of FHIR profiling rules which may answer some of your questions: http://build.fhir.org/profiling.html
Lloyd McKenzie (Dec 02 2020 at 17:36):
I think the intent is that you need to use the US Core profiles if they apply. For example, US Core has a profile on Device, but that profile is focused on implantable devices. It's not intended satisfy other uses for devices (e.g. representing a decision support system). If you're using a resource for a purpose that's outside the scope of the US Core profile, it should be ok to not try to comply with the non-relevant US Core profile. However, whether the lawyers will agree with that is a harder call to make...
Vibin_chander (Dec 03 2020 at 04:49):
@Lloyd McKenzie thank you but I have one dumb question. Is this a matter need to be discussed with payer companies legal team ?
Vibin_chander (Dec 03 2020 at 04:49):
I thought it is just a technical team decision
Lloyd McKenzie (Dec 03 2020 at 05:16):
Dunno. I'm not a lawyer. I'm also not extremely familiar with the regulation.
Sai Valluripalli (Nov 10 2021 at 15:30):
Any recommendations on testing tools to validate payer to payer APIs as part of CMS Patient Access API implementation?
Brendan Keeler (Nov 10 2021 at 23:53):
It's delayed indefinitely
Brendan Keeler (Nov 10 2021 at 23:53):
Payer to Payer, that is
Lloyd McKenzie (Nov 15 2021 at 05:27):
@Sai Valluripalli Suggest posting your questions over on #Da Vinci PDex where the implementation guide around payer-to-payer exchange is managed. (While the requirement has been deferred, it's unlikely to be deferred forever, so working to test now isn't a bad idea.)
Sai Valluripalli (Nov 15 2021 at 12:38):
@Lloyd McKenzie Thank you. I am following #Da+Vinci+PDex+Plan-Net group now.
Last updated: Apr 12 2022 at 19:14 UTC
