Stream: Da Vinci PDex
Topic: PDex server - expected resource support
Frank McKinney (Feb 11 2022 at 20:52):
Leaving aside regulatory or other drivers, what resource profiles would a PDex server need to support in order to conform to the PDex IG?
The STU1 CapabilityStatement includes this statement:
"The PDEX Server SHALL:1. Support the US Core Patient resource profile.1. Support at least one additional resource profile from the list of US Core and PDEX Profiles."
But in the CapabilityStatement resource, there are capabilitystatement-expectation extensions with "SHALL" at the CapabilityStatement.rest.resource level of most or all of the listed resources, which suggests that the server is expected to support all of the listed resources and profiles--which seems at odds with the statement above.
If I was a payer and I wanted to be sure I was conformant with PDex, would I be conformant if I supported US Core Patient and some but not all of the PDex profiles?
Thanks!
Michele Mottini (Feb 12 2022 at 00:15):
Not 100% sure about PDex but the regulation says that as a payer you should share all the USCDI data you have, so if (for example) you have allergies and conditions implementing only allergies won't cut it
Frank McKinney (Feb 13 2022 at 17:06):
Thanks Michele
I guess my question is more about PDex conformance specifically, separate and apart from the regulations that payers also need to consider.
The IG's server capability statement includes...
- a pretty explicit statement that a PDex server must support US Core Patient and at least one other US Core or PDex profile
- but also resource-level capabilitystatement-expectation extentions with a value of SHALL on many or all of the resources.
Maybe this is a question for @Mark Scrimshire or @Lloyd McKenzie ... specific to the server CapabilityStatement and how to interpret those aspects bulleted above
Lloyd McKenzie (Feb 13 2022 at 20:12):
I'm going to leave it to @Mark Scrimshire or @Robert Dieterle to respond to this one.
Frank McKinney (Feb 16 2022 at 14:13):
Hi @Mark Scrimshire @Robert Dieterle
Just following up on the question above. Thanks!
Robert Dieterle (Feb 16 2022 at 15:40):
To be compliant with PDex, a payer will need to support all of the required profiles (almost all are US Core) defined in the capability statement. To be compliant with the CMS rule, a payer will need to exchange all information they maintain on a member that is covered by USCDI V1 -- the FHIR implementation of USCDI is embodied in US Core. PDex add a few additional profiles to cover, for example, dispensed medications and devices that are not implantable.
Daniel Venton (Feb 16 2022 at 16:23):
How can a payer comply with a profile, when they don't maintain any data for the profile?
Why would a payer collect data for which they have no use (from other payer) just so they could store the data and have to exchange that data with the next payer?
Frank McKinney (Feb 16 2022 at 17:23):
Thanks Bob
Couple quick clarification questions...
- Are "all of the required profiles ... defined in the capability statement" the ones with resource-level capabilitystatement-expectation extentions with a value of SHALL? (I think that's all of the resources except for Coverage)
- How does this statement in the server capability statement relate to your answer? ... "The PDEX Server SHALL:1. Support the US Core Patient resource profile.1. Support at least one additional resource profile from the list of US Core and PDEX Profiles."
And to Daniel's question, if a payer determines it isn't required by regulation to share a kind of information for which there's a US Core or PDex profile, would they be conformant with PDex?
Frank McKinney (Feb 17 2022 at 23:17):
Hi @Robert Dieterle @Mark Scrimshire
Sorry to badger. Realized I neglected to tag you...
Just hoping to get clear on the couple points in my last note
Thx!
Robert Dieterle (Feb 18 2022 at 02:20):
If you do not maintain data for a profile, then you most likely do not need to support it. However, CMS (in the interoperability and patient access API rule, require payers, at member request, to exchange and maintain all USCDI (US Core based on FAQs) information. I do not believe that it is up to the receiving payer to determine if they have a "use" for the data. Frank -- that is the minimum requirement, however, a payer must support all profiles for which they maintain such data, including any data received from a prior payer.
Frank McKinney (Feb 19 2022 at 00:15):
Thanks @Robert Dieterle To put into my own words, to be sure I'm clear...
For a payer to be PDex-conformant:
- if the payer determines it must share a kind of information for which there's profile identified in the PDex capability statement—it must use that profile
- and at minimum, it must support the US Core Patient and at least one other US Core or PDex profile
Sound right?
Mark Scrimshire (Feb 22 2022 at 11:01):
@Frank McKinney The CaabilityStatemnt was largely adapted from the US Core Server statement. If you have recommendations on improvements please let me know. We can log as a Jira ticket and incorporate into the post ballot reconciliation
Frank McKinney (Feb 22 2022 at 11:35):
Hi @Mark Scrimshire . I'm really just interested in understanding the intent... what the IG means to require of a server.
Does my last post above yours state it correctly?
Thanks!
Mark Scrimshire (Feb 22 2022 at 16:16):
@Frank McKinney The intent was to support the CMS Interoperability Rule for patient access to US Core Clinical data plus some payer-specific clinical resources on a read only basis.
Frank McKinney (Feb 22 2022 at 16:21):
OK. I guess I was thinking that it might be possible to state IG conformance expectations separately from the regulatory requirements.
Frank McKinney (Feb 22 2022 at 16:24):
(I might be the only one who thinks that way)
Last updated: Apr 12 2022 at 19:14 UTC
