Are covered_services object information 'required' for Capitation Arrangements or optional?

[tdfow]

For the In-network Rate File, for a capitation arrangement, is the covered_services object info required, as some capitation arrangements would not have the information included in the covered_services object. The schema indicates it as not required, but also mentions it as being needed for the capitation arrangement. Can someone clarify this?

[tdfow]

The capitation examples and the in-network schema seem to be in conflict. Can someone provide clarity regarding the capitation example?

[tdfow]

Any date or timeline to obtain feedback on some of these open items? Will CMS providing any updates to the schema in the near future? @shaselton

[clovis517]

@shaselton we could use your input on some questions about using the Capitation Arrangement Covered Services Array.

I have the inverse question to @tdfow's "for a capitation arrangement, is the covered_services object info required?" : If the in network rate's covered services array is reported, is its billing code required? If so, what value should be reported? The In-Network Rates object schema indicates "Billing Code" is required, but it is not clear what value should be reported in a Capitated PMPM scenario with a Covered Services array. Perhaps a new "CSTM" value such as "CSTM-CAP : All Serviced Covered under a Capitated Service Arrangement" could be justified in this situation, but in the MRF example of a Capitation Covered Services array, the In-Network object's required Billing Code element is absent. Can you confirm that the Billing Code is not required or expected when the Covered Services array is used?

This discussion about how to report a member cost share basis on capitation arrangements does not describe the more common scenario by which a single PMPM amount is applicable to multiple codes reported within a covered services array. This could perhaps be addressed by adding an optional out_of_pocket_basis_amount element to the covered services array.

Not having a presumed unit of measure on capitation amounts makes it difficult to interpret or compare them. In discussion referenced above, couldn't both the PMPM and the out of pocket basis be "negotiated"? It feels like use of the additional information is needed but these are difficult to automate. I think these scenarios could be better handled by introducing new negotiated type values of "PMPM : per attributed member per month", "PMPY : per attributed member per year", and "Out of Pocket Basis: Separate Amount used for calculation of member out of pocket on bundled or capitation arrangements".

Lastly I question the need for both a Covered Services array and a Bundled Services array. They are mutually exclusive, have the same structure, can be differentiated via the negotiation arrangement, and combining them could be accomplished with a minor re-definition of Covered Services array. I think the horse is out of the barn on this but if future significant (non-backward compatible) changes are made this might be a consideration to simplify the schema.

Thanks!