As implementers get closer to the regulatory deadline, new voices have been joining the project calls and submitting feedback via Jira that call into question some of the foundational assumptions made in the implementation guides. The project has been holding special calls to discuss these issues, looping in a larger portion of the community to engage in the discussion. However, at the time the content of this specification was being prepared for ballot, resolution had not yet been reached on most of the topics. Postponing the ballot until these topics were landed would mean the updated specification that corrects errors in the original specification and makes other useful clarifications and enhancements to the specification would be released too late to be useful to most implementers working to meet the CMS January 2027 regulatory deadline. For this reason, the ballot will be occurring while these issues are still unresolved.

However, there remains a possibility that some of these issues could be addressed before final publication of the balloted specification. To ensure balloters have an opportunity to evaluate the potential options and to express their opinion on the issues, they are laid out here. If you are uncomfortable with any of the candidate resolutions to any of the issues laid out here, feel free to vote negative on the issue(s) in question. You can consider withdrawing your negative votes when final resolutions are landed, provided you are comfortable with the resolution.

NOTE 1: It is unlikely that all of these issues will be addressed in the CRD 2.2.0 release, and it's possible that there will be no changes to the specification from any of these issues and that they will either be deferred to some future (possibly post 2026) release, or they might be closed by the submitter or otherwise resolved with no change.

NOTE 2: If there is a resolution to one or more of these issues that involves making a change to the specification that is substantively different than any of the proposed dispositions, there will be an announced public review period of the specification with the proposed change applied to give the community an opportunity to evaluate and provide feedback on the new option prior to publication.

Synchronous CDS Hooks vs. Asynchronous Operation

There are three tickets that either explicitly propose replacing the current CRD real-time CDS Hook-based architecture with an asynchronous architecture or that indicate that the real-time requirement established by the guides are untenable:

• FHIR-42697 - Requirements to only allow CDS Hooks
• FHIR-46170 - Allow Async OperationDefinition
• FHIR-49125 - Unrealistic Processing Time for Da Vinci CRD

Relevant quotes from the CMS final rule

1. "All payers must identify relevant prior authorization coverage criteria and rules and program these criteria and rules into the appropriate format for the API in accordance with the IG." link
2. "Subsequent programming and testing for the questionnaires within the API must take place to ensure functionality. To accommodate these development efforts, CMS is finalizing 2027 compliance dates for the Prior Authorization API. The compliance timeframe should enable industry to establish a strong technical framework to support the development and scalability of the API-based solution. We anticipate that this timeframe will provide more time for development and testing to enable the integration of the Prior Authorization API between payers, providers, and EHR developers." link
3. "Use of the Prior Authorization API will enable automation for the prior authorization request and response within the clinical workflow of the provider." link
4. "Use of this IG improves the transparency of specific coverage rules specific to the patient and the provider based on the payer's prior authorization policies, and, when implemented, provides decision support to providers when they are ordering services." link

Assessment and discussion

1. The language from the regulation implies, and a CMS representative has explicitly stated that the expectation of the regulation is that information about coverage rules be provided to the clinician and patient at the time of decision-making.
2. The Da Vinci Clinical Interoperability Council has reaffirmed that they believe it is essential to get coverage information and data collection requirements in front of providers and patients at the time decisions are being made, and that if a provider decides they don't care about the coverage rules in a particular circumstance, especially if they're complex, clinicians are free to ignore the information.
3. The regulation recognizes that pre-existing payer systems may not be able to provide coverage information and data-collection requirements in real time and the implementation timeline for the regulation was extended specifically to ensure sufficient time for payers to extract their rules and represent them in computable form that would allow them to be surfaced in APIs that meet the requirements. I.e. Where existing systems can't meet the need, the expectation is that systems will be adjusted or built to meet the need.
4. CMS recommended CRD based on its current design and other states have mandated implementation of CRD based on its current design. Several implementers have also rolled out production solutions based on the existing IG requirements. Changing design would not remove existing regulatory requirements and would break interoperability with existing implementations.
5. A significant refactoring of the implementation guide at this point could not be done without a great deal of group discussion as well as returning to ballot. Even if it was appropriate to redesign the specification, it would not be possible to do so in a timeframe that would allow for implementation by the regulatory deadline.

Based on the above points, there is no reasonable possibility of changing the architectural approach from a 'real-time CDS Hooks response as part of clinical workflow' in this next ballot release. Given the regulatory requirement and direction from CMS, it's difficult to envision even a longer-term architecture that would be asynchronous as once implementers have modified their systems to meet the real-time requirement, there'd be little incentive to switch to an asynchronous solution.

Options

1. Find these tickets 'not persuasive' - i.e. the requirement will remain real-time CDS Hooks responses to clinical users
2. Mark some or all these tickets as 'considered for future use'

Support for additional data

There are several tickets noting that information needed by payers' existing prior authorization processes is not provided as part of the CRD inputs and/or that the inconsistency of how information is represented in clinical resources (in CRD and DTR) and how it's represented in financial resources (PAS) is problematic:

• FHIR-45673 - Need to express Prior Authorization "Case" concept
• FHIR-50791 - Prior-Authorization Groupings
• FHIR-46171 - Define common model that is shared across CRD/DTR/PAS IGs
• FHIR-48946 - ServiceRequest.reasonCode and reasonReference, requirement to use ICD-10 CM
• FHIR-49129 - Support sending Inpatient/Outpatient flag for requested service
• FHIR-49982 - Communicate service specialty
• FHIR-50669 - UM System Required Attributes
• FHIR-50892 - Add dedicated element/slice to capture location taxonomy code

Assessment and Discussion

• The objective of the CRD interface is NOT to return real-time authorizations. Doing so is permitted but is not required to be supported at all. Even when supported, it will not necessarily be common. The requirement of CRD is to document the coverage 'rules' for a particular product or service. It should always be possible to return rules for a given item, irrespective of how much additional information is known. Knowing more information simply allows filtering which rules are relevant meaning the expression of the rules will be simpler (e.g. 'covered' as opposed to four paragraphs describing the situations where the product is or is not covered).
• As discussed in the previous issue, there is no expectation that CRD responses will be provided without either modifying existing systems or building new ones.
• Also as discussed in the previous issue, responses must be provided at the time of ordering to clinicians and patients and therefore must function based on the information that is known at this time.
• The CDS Hooks workflow presumes that clinicians and other users are performing their workflow "as normal" without capturing additional data elements beyond what they've historically captured. Clinicians have reiterated the importance of not imposing requirements to collect additional data.
• In some cases, EHRs MAY be able to infer data elements they will later include on a claim or prior authorization. It is more realistic for this to occur in situations where the ordering system and performing system are the same.
• There is already support for conveying billing codes if they are known (either as translations, or if there are multiple conflicting codes, via extensions).

Options

Potential resolution of these issues can include some mixture of the following:

1. Add additional optional data elements for the requested concepts with must support rules indicating that they must be populated when an EHR is able to determine a value, but it is acceptable if an EHR isn't able to ever determine a value.
2. For some elements make their inclusion mandatory (provided EHRs are confident values can always be known at time of ordering).
3. Mark some or all of these tickets as 'Considered for future use'.

Expectations for interoperability

There has been discussion about the use of 'supplemental' guides and general interoperability expectations for both CRD client and server implementations. This is manifested in a couple of tickets:

• FHIR-49974 - Need to be tighter about client and server hook support expectations
• FHIR-50216 - Need guidance on supplemental guides

Assessment and Discussion

1. If requirements can vary between communication partners in a manner that requires software to be written differently based on which system is being connected to, it will be impossible to scale interoperability to ensure that all clinical systems can talk to all payers.
2. Some implementers have expressed an intention to only support interoperability with a limited set of 'large volume' partners based on this scaling issue. This will result in an imbalance in the marketplace where large volume partners will have interoperability capabilities not available to smaller organizations and may impede the ability of smaller payers to meet metrics, as well as disadvantaging patients with such coverage.
3. There is concern that strict interoperability requirements may mean that requirements discovered late in the process will not be able to be met without breaking conformance, which could create a no-win situation where metrics can't be met because compliance prohibits successful interoperability, or successful interoperability results in non-compliance.

Options

Potential resolutions of these issues

1. Leave the specifications loose like they are, meaning that implementations can impose additional requirements necessitating code changes for interoperability with that partner.
2. Tighten the specifications to prohibit requiring data elements beyond the specification or other otherwise not properly handling conformant instances, while still allowing exceptions where interoperability requirements have been approved through a change request and continuous integration build update process.

Handling of multiple coverages

This issue relates to the fact that the specification currently requires EHRs to limit CRD invocation to passing a single (presumed primary) Coverage instance.

• FHIR-49738 - CRD lacks support for coordination of benefits
• FHIR-49825 - Create or update coverage should be limited to 'update'
• FHIR-49826 - How do coverage-informations with different Coverages work?

Assessment and Discussion

1. The rationale for restricting to a single Coverage includes:
   • In situations where multiple coverages are in-play, the determination of coverage by payers is often influenced by whether they're primary or secondary, as well as the decision of the primary payer.
   • Coverage determinations are invoked in parallel, meaning secondary payers can't consider decisions of prior payers in their assessments.
   • Providing coverage expectations for secondary coverage adds additional complexity to the work for payers as well as the information returned to providers, as there's now a need to convey assessments from multiple payers. Given that payers are concerned about meeting response timelines, simplifying things, at least for now, is reasonable.
   • It's less common for there to be authorization decisions or additional data requirements associated with secondary coverage.
   • Multi-coverage situations are best addressed through a formal prior authorization process where payers can be communicated with in order and results from previous payers are visible to subsequent payers.
2. The challenges involved with restricting what coverages are exposed include:
   • If only the primary payer can respond, secondary payers don't have an opportunity to return other useful information, such as contraindications.
   • Because only one coverage is exposed, payers can't confirm that they *are* the primary payer because they can't see what other coverage instances might exist.
   • There's no ability for a payer to add missing coverages (because they can't tell if a coverage is missing because they aren't allowed to see all coverages the EHR is aware of. Similarly, there's only an ability to update a single coverage.
   • The specification allows for the possibility that a payer could return information about multiple coverages if they're aware of more than one, but they wouldn't know how to link to any coverage other than the primary.

Options

Potential resolutions of these issues

1. Update the specification in all places where there's conflicting language to make clear that only one coverage is exposed, only that coverage can be updated, no coverages can be added, and responses are limited to a single coverage. Mark the request to support multiple coverages as 'Considered for Future Use' as something that can be explored in a future version of the specification once everyone is handling the primary coverage well.
2. Add explicit support for multiple coverages, including mechanisms to flag which coverage is presumed to be primary, and extend standard response codes to support dealing with multi-coverage scenarios.

Miscellaneous issues

These issues don't stem from any specific theme and the fact they're not yet resolved is generally based on issues other than disagreements around the basic premises of the implementation guide architecture. They're listed here only to call attention to the fact that they're outstanding and they might be resolved as part of the balloting and publication process. Each of the remaining issues is discussed individually.

FHIR-49757 - No guidance for CRD intermediaries wrt. access tokens

Da Vinci requires that there be a single endpoint per payer (or if HRex Endpoint Discovery is supported, a single endpoint per Coverage). However, in practice, there may be multiple systems that manage coverage rules for different types of services and or different types of decision support behind that endpoint. Some of these delegated systems may have a need to access the EHR's FHIR endpoint.

At present, CDS Hooks does not define a standard mechanism for managing authorization in this delegation situation, and sharing tokens is not considered good practice (and may be technically prohibited if tokens are certificate-bound or IP-range constrained).

Industry has not yet settled on best practices here. If balloters can recommend an approach the implementer community can agree with, we could include at least 'draft' guidance in the published IG.

FHIR-49871 - NutritionOrder MS backbone type elements are all optional

Some types of nutrition orders have associated coverage requirements, including prior authorization. However, NutritionOrder is not defined by US Core and there is no agreement on what data elements must be supported or which terminologies should be used for those data elements in the U.S. space. As a result, the CRD data model for NutritionOrder is under-constrained and is unlikely to be interoperable.

Implementation experience is required to identify which data elements systems are actually capable of populating, and what terminologies they will use. Possible alternatives for the next release include:

1. Removing the NutritionOrder profile from the current specification and adding an STU note seeking feedback and indicating it may be reintroduced in the future. Implementers are free to experiment with the NutritionOrder outside the interoperability constraints of the specification.
2. Keeping the NutritionOrder profile in place but add a 'Dragon' warning noting that the profile is underspecified and that implementations who wish to interoperate with the resource will need to reach site-specific agreement on which data elements to exchange. (And that such site-specific agreements are acceptable from an interoperability expectations perspective.
3. Update the profile to add additional must support data element and terminology constraints to support reasonable interoperability, provided that the community can agree on what those elements and constraints should be.