Stream: Da Vinci DTR
Topic: Deferral and Relaunching of DTR app
Keeyan Ghoreshi (Sep 29 2021 at 16:19):
I'm curious as to what relaunching the DTR app looks like for the user when using Task to defer the process to a later time, or using Task to save context so that a session can be paused and resumed later with all the information included. Currently the RI uses a QuestionnaireResponse to store information about the answered questions. Saved incomplete questionnaire responses can be reloaded to populate previously answered questions. Further saving of DTR context currently would only add on the ability to redo the pre-population using CQL.
Say the DTR app is launched and the user wants to save progress for relaunching later. Presumably they click a save button, or click out of the app, and a Task resource is created for the incomplete DTR session and saved to the EHR. How does this user then relaunch this session? What is the mechanism by which they select which session they want to reload?
Is the Task resource accessed by the EHR, and thus no authentication is required? Is CRD the one that accesses the task, and then constructs a SMART link to be sent to the EHR for launching? If so, does CRD need to go through a SMART authentication to get a token in order to access the Task resource? Or is DTR supposed to be the one keeping track of open sessions for itself? Does DTR go through a standalone launch process and then use the Task resource to replace the lack of app context?
I'm confused as to how this process of relaunching looks like from the point at which one saves the context to the point where the app is relaunched from that saved context. I would assume the EHR would need some sort of mechanism to launch the DTR app from the Task resource, in which case it's the responsibility of the EHR to keep track of Tasks and provide the user some way to select which one to launch.
@Larry Decelles
Lloyd McKenzie (Sep 29 2021 at 21:25):
Short answer is - we don't know the answer yet. We're discussing options, but we need more feedback from the EHR community about where and how the SMART app can save its state in a way that will allow the user to re-launch. Task is our proposed mechanism, but it's not yet confirmed and the details are still to be worked out.
Vassil Peytchev (Sep 30 2021 at 04:51):
Is it possible that requiring a SMART app in this case may not be the best fit for the deferred purpose?
Lloyd McKenzie (Sep 30 2021 at 14:08):
The design is based on enhanced SDC questionnaires with dynamic behavior and auto-population capability that uses CQL. Thus far, we haven't seen any EHR uptake of those aspects of SDC, so a SMART app is the only option. If/when EHRs are capable of performing those functions internally, there's also the question of how a CDS Hooks card can trigger the launch of such an internal function (and the CDS Service is made aware that the function is both present and enabled in the triggering EHR). We need more guidance about how the EHRs would like that to happen. Obviously it should be done in a standardized way so that the mechanisms aren't different from one EHR product to another.
Matt Varghese (Sep 30 2021 at 16:58):
I think the part that the CRD/DTR Specs miss is that EHRs have data-models and workflows for prior authorization. So the App that collects prior authorization information, results of CRD check (explicitly saying is prior authorization required, rather than there is a card or not), and identifier(s) for the prior authorization requirement(s), etc. needs to be captured in the EHR data-model.
And as the Original Post calls out, the App needs to be able to resume from where it was left off upon relaunch. Note that, even if CRD had deferred a task with DTR, the user might not use it to launch DTR, but could use the standalone DTR flow to launch the App. So saving off App's "last state" in the EHR in a Task etc. isn't really a viable solution here.
Lloyd McKenzie (Sep 30 2021 at 17:20):
How should the app save its state? What resource(s) would you recommend?
Sreekanth Puram (Oct 03 2021 at 06:17):
we should leave it to the app implementer/EHR to decide on how to save the state of the app. Since this will not affect the interoperability, the standard should not really worry about how this happens at the EHR end. There can be some information in the supplemental guide as to what the best practice could be. However, this should not get into the IG.
Lloyd McKenzie (Oct 03 2021 at 14:44):
If the app is being written by one party and is supposed to run on any EHR and needs to store its data in the EHR in a manner that allows the EHR to know how to re-launch the app, I don't think we can leave this unspecified. If we do, we don't have a standard. Interoperability means any EHR can launch whatever app a payer chooses to work with, and any app can reliably store their information within a compliant EHR.
Lloyd McKenzie (Oct 03 2021 at 14:45):
The whole point of SMART is to ensure that apps don't have to custom negotiate their interfaces with each EHR.
Josh Mandel (Oct 03 2021 at 14:51):
This would be a great set of requirements to bring back to SMART. So far, we certainly haven't mandated any EHR write back capabilities, although this is something we are looking at in Argonaut this year (writing observations from patient apps, not general State Management) -- and if it was possible to reach consensus on general app State Management, that would obviously be a benefit for the platform. In the meantime, we have always expected that apps will manage their own state.
Josh Mandel (Oct 03 2021 at 14:54):
One example of the kind of thing we've talked about for a general purpose app state solution would be asking ehrs to support "POST /Basic" with an object up to a certain small size (say, 100kb) specifically identifying the app and possibly the user + patient with standardized properties inside, and everything else being up to the app to determine. Apps would be able to read their own state but not necessarily anybody else's.
Josh Mandel (Oct 03 2021 at 15:01):
(Even something this "simple" requires extensive evaluation, discussion, connectathon experience, etc.)
Lloyd McKenzie (Oct 03 2021 at 15:10):
There's actually a bunch of different pieces here:
- How does an app persist saved state to an EHR? (Agree that Basic might be an appropriate option here)
- How does an EHR write the results of its completed 'work' to the EHR for subsequent use? DTR has jumped the gun on Argonaut Write by presuming an ability to write Bundles to the EHR that contain QuestionnaireResponses and other resources needed to pass to subsequent PAS invocations - though we've been more than a little hand-wavy about how the EHR recognizes what a given Bundle is for to allow it to be used for the app
- If an app only completes part of its work, how does the EHR know that, understand in what context (and by whom) it should subsequently be restarted, and provide the relevant context on re-start
- When re-started, how does an app use that context to go retrieve saved settings?
- What are the security considerations around access to, and possibly eventually deletion of those saved settings
Josh Mandel (Oct 03 2021 at 16:28):
My rough impression is that this is way too much to tackle all at once. We should try to find a subset of this functionality that gives everyone a common base to build on but also allows individual implementers to explore.
Sreekanth Puram (Oct 04 2021 at 04:20):
@Lloyd McKenzie I feel that we need to take a step back and look at the CRD, DTR and PAS IGs once again to check for burden reduction and the practical problems that they may pose. The initial versions of the IGs have been designed in such a way to get the ball rolling fast on these and we get payers, providers and EHR vendors implement the idea at connectathons and other trade shows. Now that it needs to get into production, I think we need to have a relook at the way things are and make modifications as needed.
Lloyd McKenzie (Oct 04 2021 at 04:30):
Absolutely. The notion of being able to save work in progress and re-start a DTR app is one of those things that's being driven by implementer feedback - which in turn means that, in order to deliver that functionality, we need to come up with a proposal for how to standardize it. Where we land won't necessarily be final, but it needs to be something that both the EHR and payer community agree to try - at least if we're going to put it into the standard.
Josh Mandel (Oct 04 2021 at 04:33):
Why can't DTR apps manage their own state? This is a pattern that works extremely well without interoperability concerns.
Sreekanth Puram (Oct 04 2021 at 04:40):
For example, if we look at CRD, the goal of CRD is to check if there are any documentation requirements, prior authorization requirements, or any other coverage requirements for the service/medication/device that I am ordering or for the patient that I am going to see, etc. The goal here is to send a request to the payer, ability to provide them with a FHIR handle with appropriate scope as needed, prefetch data if possible and get information from the payer. If this information exchange happens in the CDSHooks format, it would easily fit into the workflows of many EHRs through their order-select, order-sign, encounter-begin etc. However restricting the functionality in such aa way that it runs with a select EHRs which support CDSHooks will cause the system to break with others. So I bring back the old topic of discussion here. Why should a payer define the SMART application that the provider needs to use? The payer should focus on passing the information (Documentation requirements, Templates for these requirements, rules to extract the data in FHIR format, and the rules to prefill the Templates provided) and leave it to the EHR on how to handle this information. We can standardize the DTR format by using FHIR questionnaire, using CQL, etc. The EHRs may invoke their native functionality or invoke some smart apps to handle these or have a smart app to take care of CRD/DTR and PAS in one go. In that scenario, the negotiation of how data gets saved is something which is dealt by the SMART APP developers and EHR just like how it is done for several other apps. For example, if the app vendor is a business associate or a release of information vendor, it is okay from a HIPAA point of view to store the app state in an external database.
Lloyd McKenzie (Oct 04 2021 at 05:06):
@Sreekanth Puram We're not designing CRD so that it works with select EHRs. We're designing it so that it leverages an existing standard mechanism so that EHRs don't need to invent something new. EHRs that don't support CDSHooks can, if they choose, simply emulate the CDSHooks mechanism only for CRD and accomplish the same end if they choose, or they can fully support CDSHooks - that's up to them. But it makes no sense to introduce a proprietary mechanism to invoke CRD when there's an existing standard mechanism available.
DTR uses SMART because, at the time we started creating DTR (and to my knowledge, this is still true), no EHRs support filling out 'smart' Questionnaires that include flow-control logic and are able to retrieve existing data using CQL. And this was the most logical mechanism to share payer-specific rules in a 'standardized' manner. A SMART application was a solution that could run in most major EHRs and is a relatively small lift for any EHRs that don't yet support it. (A much smaller lift than supporting a full-blown CQL engine.)
I don't understand why we would ask each developer of a DTR SMART app to negotiate their own EHR interface, especially if we want to make the apps swappable so that providers can choose their preferred app and use it across a variety of payers. For that to work, the interface between the SMART app and the EHR needs to be standardized.
@Josh Mandel The SMART app could write its state back to the payer, but the question then is - how does the EHR know to re-launch the SMART app, and how does the SMART app know which session's data to re-initialize with?
Sreekanth Puram (Oct 04 2021 at 12:41):
@Lloyd McKenzie I am not saying we should introduce a proprietary mechanism to invoke CRD. I am just saying that CRD system on the payer side can still support requests in CDSHooks format but not restrict the request only from CDSHooks. Regardless of whether they are invoked by CDSHooks work flow in the EHR or through any provider side utility which sends the response in that format, the payer should respond back with same response. That way we are not restricting the usage of the CRD system. There are DME vendors, clinical pathway vendors, release of information vendors etc who have practice management systems that can integrate to the Burden reduction flow using this mechanism.
Josh Mandel (Oct 04 2021 at 13:50):
how does an app know which session data to re-launch with?
It will have access to context including the patient, the practitioner; plus any data available through the fhir api. If this is not enough to pin down a specific session, the app can always provide a list of ongoing workflows for the user to choose among
Lloyd McKenzie (Oct 04 2021 at 14:19):
The directory approach might be viable. We'll discuss.
@Sreekanth Puram What do you think would be different than how the specification is defined now? We definitely want the hook services to be invoked according to the same workflow - i.e. according to the same workflow timing points. And the invocation and behavior of what gets sent and what gets displayed to end users would be the same. So long as that happens, I think implementers would conform?
Sreekanth Puram (Oct 04 2021 at 18:03):
@Lloyd McKenzie Today, the callers of the CRD request are forced to specify the reason why they want to know the prior auth or documentation requirements for a particular Device/Service/Medication as they need to specify the type of CDSHook which is immaterial to the payer. Moreover, the response they get is going to be a link to an application that would interpret the required information instead of the information itself. That way you are preventing non-EHR users from using this functionality. We are preventing the usage of CRD/DTR within non-GUI-based workflows and integration at other clinical workflow points which may not be a part of the CDSHook invocation points. One other inconsistency in the spec is that we say that the payer would pass on the link to the SMART app as a response to CRD in the CRD spec and we say that the DTR can be opened by a SMART app or by the EHR natively. How can an EHR open the application natively if the response to CRD is sent as a Link to a SMART app launch URL? My point here is that in CRD and DTR, we are focusing on the EHR workflow more but I think the focus should be more on passing the appropriate information between payer and provider. We should leave the interpretation of the information ad workflows to the payer or provider software.
Lloyd McKenzie (Oct 04 2021 at 20:49):
Needing to say it's an "order select" or "order sign" is not immaterial - the payer needs to know whether the orders are deemed to be 'complete' or not so it knows whether to yell if it deems the order insufficient. (You don't want to yell about missing stuff when the order is being drafted, but you do want to yell when the order is complete.) Client systems can hardcode one or the other depending on where they're invoking the service. And yes, we're going to provide a link to a SMART app because, so far, no EHR has the capability to do it themselves. It's a much lower bar to implement CDS Hooks and SMART than it is to implement CQL-aware Questionnaire rendering. If we have real client systems that want to get back a rules package, we can discuss how to pass that back (and how EHRs can recognize what they've got once it's stored) - but that's something we can do within the CDS Hooks framework. We need to ensure that the workflow between payer and EHR is standard. Payers and EHRs shouldn't have to negotiate how the workflow will behave. If they do, we haven't done our job. Also, keep in mind that payers may not want their rules packages stored on the EHR where they might be read by something that isn't a SMART app they trust. Their rules may be proprietary and sensitive, so it's possible that some payers will indicate that rules aren't allowed to be persisted within the EHR environment.
Sreekanth Puram (Oct 05 2021 at 03:16):
@Lloyd McKenzie Valid point about payers that may not be comfortable sharing their proprietary and sensitive rules. This was discussed several times as a part of the DTR discussions and we determined that the actual adjudication rules are sensitive and proprietary but the data requirements and the rules to extract those data requirements from the EHR are not. Lets assume for a moment that they are sensitive, we should come up with some information exchange format that would solve this problem rather than passing on a program that would interpret the information sent back. Somewhat similar to the $next-question operation in adaptive questionnaires. We could have some operation that can process the data and send the response back. This should take care of the CQL-aware questionnaire rendering problem too. I think the concerns that EHRs/Providers show with unverified payer applications running on their systems are than what the payers have sharing their proprietary data requirements, which have some workarounds (personally I don't think either of them should have any concerns).
Lloyd McKenzie (Oct 05 2021 at 03:28):
One of the things on the table is indeed to support 'next-question'. However, that can only take care of CQL rendering if the $next-question operation also include a token that allows the payer to directly query the EHR for data. Otherwise, the CQL to do population still needs to be inside the questionnaire returned, even if it's only one question at a time.
Sreekanth Puram (Oct 05 2021 at 03:33):
Recently I was getting one of our SMART app approved through an EHR's app approval system so that we can run DTR, we had to go through a stringent procedure of evaluation. The EHR does not allow the invocation of any random link to a smart application on the fly. So every payer needs to do this with every possible EHR/practice management system or need to pick an app that is already registered with all possible EHR/practice management systems. This creates an anti-competitive environment. If you are looking for a real client system, looking for a rules package from the payer I have one.
Sreekanth Puram (Oct 05 2021 at 03:36):
Lloyd McKenzie said:
One of the things on the table is indeed to support 'next-question'. However, that can only take care of CQL rendering if the $next-question operation also include a token that allows the payer to directly query the EHR for data. Otherwise, the CQL to do population still needs to be inside the questionnaire returned, even if it's only one question at a time.
I was talking about "$next-question" as an example. On similar lines we can have a "$data-extract-rules-evaluate" operation if the payer is not comfortable with sharing their data extraction rules or "$lib-evaluate" to evaluate the CQL rules (I think the DEQM IG supports this operation but I am not 100% sure)
Lloyd McKenzie (Oct 05 2021 at 03:58):
Can we get concrete? Who, specifically, is asking for an invocation mechanism other than CDS Hooks/SMART and what, exactly, do they want instead?
Sreekanth Puram (Oct 05 2021 at 04:09):
One of the payers that we are supporting needs prior authorization for Ambulance Transport, Home Health services, prosthetics and Durable Medical Equipment. None of the providers dealing with these practices use standard EHRs. They use specialized practice management systems which have custom APIs. We are working on creating FHIR interfaces for these custom APIs so that the data can be extracted without impacting their current flow as we use just the read-only capabilities for the practice management system. so it's a win-win situation so far. To incorporate the CRD process or DTR process, we need to meddle with their workflow. We can probably convince one or two vendors to do this. But I am not sure if we can do it with all the vendors.
Sreekanth Puram (Oct 05 2021 at 04:16):
If you feel that these providers are not "Ordering" providers but "rendering" providers and there should be a different workflow for burden reduction in the case where the payer mandates prior auth requests from rendering providers only. Probably we may defer the discussion on this particular example. However, I am still concerned about the logistics of getting apps through at all provider's systems.
Lloyd McKenzie (Oct 05 2021 at 04:32):
The objective of CRD is to intervene in the workflow of the ordering provider. We haven't talked much about the utility of CRD and DTR for 'performing' organizations. The ideal is for most of the prior authorizations to be in existence before the performing organization gets involved - because much of the key decision-making happens before the patient ever reaches these organizations. However, we can certainly talk about those situations where prior authorization might only be able to be addressed at that level.
Sreekanth Puram (Oct 05 2021 at 04:49):
I agree but the payers have their requirements which we don't have much control on.
Matt Varghese (Oct 05 2021 at 19:27):
Can we get concrete? Who, specifically, is asking for an invocation mechanism other than CDS Hooks/SMART and what, exactly, do they want instead?
I for one have been having this strong question, is CDS Hooks the appropriate invocation mechanism for CRD.
I have suggested using a similar model to CoverageEligibilityRequest/CoverageEligibilityResponse, that allows for discrete capture of data.
https://jira.hl7.org/browse/FHIR-33963
Matt Varghese (Oct 05 2021 at 19:30):
The objective of CRD is to intervene in the workflow of the ordering provider.
The objective of CRD / DTR / PAS is to make the determination of whether prior authorization is required, collection of what documentation is necessary for prior authorization, and the acquisition of prior authorization itself easier.
Intervening in the workflow of the ordering provider should NOT be an objective. It should only be a necessary step IF it makes the above objective easier - whereas if it serves no added value to the above objective, it is not useful to intervene at that point.
Matt Varghese (Oct 05 2021 at 19:33):
Also, as @Josh Mandel also mentions earlier, Apps can determine last state from the context of the SMART on FHIR App launch.
And writing existing FHIR resources back to the FHIR Server is possible in the context of a SMART on FHIR launch. So it is possible with just a plain SMART on FHIR app to allow for repeated launches in the DTR flow, as long as the EHR knows the App as the DTR app. As I see it, it is that part, of the EHR knowing that a specific app is a DTR App, that is missing from the CRD & DTR spec.
Matt Varghese (Oct 05 2021 at 19:40):
Anyhow, I think we agreed on one of the last Da Vinci calls that Da Vinci should catalog both the common models of prior authorization including inputs into the algorithms determining if prior authorization is required, as well as, the existing EHR workflows around prior authorization. I would like to see that information, before I say more on what the ultimate model around this should be. I know that within EHR workflows I am aware of, the proposed models risk being insufficient and burdensome for providers..
Lloyd McKenzie (Oct 05 2021 at 19:44):
@Matt Varghese CRD is NOT just about "is this covered". Coverage is one of the sets of information that can be returned, but the intention is to put any information a payer has that might influence the ordering and other decisions a provider makes in front of the provider at the time they're making those decisions. CDS Hooks is the standard way of doing that. Also, even when collecting additional information is necessary, it's not always about prior authorization. Perhaps prior authorization is not necessary, but additional information must be collected to be submitted as part of the eventual claim. Sometimes the information won't need to be submitted at all, but is required to be retained by the provider for audit purposes. CRD and DTR satisfy those use-cases too.
The EHR will not always know when launching an app to capture additional documentation (for prior auth, claim or other purposes) will be necessary. CDS Hooks is what provides that information to the EHR - by triggering any time the provider performs any action that could result in payers having useful information to contribute.
Matt Varghese (Oct 05 2021 at 19:45):
@Lloyd McKenzie, that part is pure CDS Hooks. CRD doesn't add anything new to CDS Hooks and so is redundant with CDS Hooks on that front. So to me, that is a bad precedent in an IG to be redundant with another spec?
Matt Varghese (Oct 05 2021 at 19:46):
Only the prior authorization is really unique to CRD as I see it.
Matt Varghese (Oct 05 2021 at 19:47):
Perhaps prior authorization is not necessary, but additional information must be collected to be submitted as part of the eventual claim.
Also, what do you mean by additional information needing to be collected without prior authorization? Isn't this collection of additional information itself and its review what prior authorization means? Yes, sometimes it can be auto authorized, but even that is prior authorization as I understand it..
Lloyd McKenzie (Oct 05 2021 at 19:49):
It's not redundant. It profiles CDS Hooks. It provides guidance about specific types of cards to be used in specific spaces. It sets expectations around pre-populate. It sets expectations around actions that involve multiple resources. It does a lot of things. The prior authorization bit isn't handled any differently than any other hook/card. Coverage is conveyed as text messages to the user and/or an invitation to launch a SMART app - standard hooks behavior.
Lloyd McKenzie (Oct 05 2021 at 19:51):
When I'm talking about "additional information", some payers require a provider to keep certain records when ordering particular therapies. There's no requirement to submit those records as part of a prior authorization or a claim. However, the payer may occasionally audit and request to see the records - and if they do, the records need to exist and be complete.
Matt Varghese (Oct 05 2021 at 19:51):
@Lloyd McKenzie, I'm sorry, I don't see where in the CRD spec we are doing any of that.
All that it does that I see unique is the prior authorization requirement determination.
Matt Varghese (Oct 05 2021 at 19:52):
When I'm talking about "additional information", some payers require a provider to keep certain records when ordering particular therapies. There's no requirement to submit those records as part of a prior authorization or a claim. However, the payer may occasionally audit and request to see the records - and if they do, the records need to exist and be complete.
A good example of that would be PAMA guidelines adherence for Radiology. And that is an example that counters the CRD spec, because in that case we are actually contacting a different service rather than the payer CDS service - a dedicated Radiology CDS service in this case.
Matt Varghese (Oct 05 2021 at 19:53):
And so that was actually one of my reasons for thinking CDS Hooks isn't the best way to do CRD.
Lloyd McKenzie (Oct 05 2021 at 20:14):
I'm not following. The fact you sometimes contact a different service rather than a payer service doesn't mean that the payer might not offer the same service, nor that the payer service might not sometimes convey information that isn't available elsewhere. The whole architecture of CDS Hooks is that a wide variety of services can be notified simultaneously and you get the information back from all of them.
Matt Varghese said:
Lloyd McKenzie, I'm sorry, I don't see where in the CRD spec we are doing any of that.
All that it does that I see unique is the prior authorization requirement determination.
Let me help with some references:
- "It provides guidance about specific types of cards to be used in specific spaces." - see section 4.3.4 which defines specific profiles on the 'card' structure, when each should be used, and conformance expectations for which profiles need to be supported. The only one of these that is vaguely specific to prior-authorization solicitation is a side reference about DTR in the SMART launch hook.
- "It sets expectations around pre-populate" - see section 4.3.5.1 - also not at all specific to prior authorization
- "It sets expectations around actions that involve multiple resources" - see section 4.3.2.4 - this is actually focused on asking people to fill out questionnaires and other things that have nothing to do with prior authorization
Matt Varghese (Oct 05 2021 at 20:40):
"It provides guidance about specific types of cards to be used in specific spaces." - see section 4.3.4 which defines specific profiles on the 'card' structure, when each should be used, and conformance expectations for which profiles need to be supported. The only one of these that is vaguely specific to prior-authorization solicitation is a side reference about DTR in the SMART launch hook.
I really don't see what is specific to CRD in this section, nor why this is in the CRD IG. I would say that the content here applies (except where specific to prior authorization) to all CDS services, and so is the jurisdiction of the CDS Hooks spec rather than a CRD IG. It is not even specific to a payer stood up CDS service.
"It sets expectations around pre-populate" - see section 4.3.5.1 - also not at all specific to prior authorization
It is noteworthy here that this IG modifies the CDS Hooks prefetch in a fashion not compatible with CDS Hooks as written.
Otherwise, beyond giving examples of what a hypothetical payer CDS service might require for prior authorization, this really doesn't add anything significant to CDS Hooks. And the question remains, is this sufficient for the needs of prior authorization determination.
"It sets expectations around actions that involve multiple resources" - see section 4.3.2.4 - this is actually focused on asking people to fill out questionnaires and other things that have nothing to do with prior authorization
Again, this section is generic CDS Hooks, and applies beyond just payer CDS Services. So this too is the jurisdiction of the CDS Hooks specification, and it too is bad practice to be included in a CRD specific IG.
Matt Varghese (Oct 05 2021 at 20:47):
And so, in my way of looking at this, some of this undermines the CDS Hooks specification, because it is no longer enough that the EHR has a CDS Hooks implementation. The EHR has to have a generic CDS Hooks implementation conformant with the CDS Hooks standard, and another CDS Hooks implementation accommodating the changes introduced by CRD for the purposes of supporting the CRD specification. To me, that is not optimal either.
Lloyd McKenzie (Oct 06 2021 at 02:39):
It's absolutely content that applies to other CDS services - because CDS Hooks is a set of payer-provider CDS services of which only one deals with prior authorization. It profiles CDS Hooks because we identified a number of deficiencies in the specification where it didn't meet payer needs and/or we wanted to set specific guidance for conformance.
The areas where we explicitly violate the CDS Hooks specification, we made clear. None were made solely because of (or sometimes even at all because of) prior authorization requirements. And for every one we submitted a Git issue against the CDS Hooks specification.
Let me say again in a very clear manner: The scope of CRD is now, and always has been far more than just prior authorization. (The same is true of DTR.) So we're not going to remove content that's essential to CRD's requirements just because it's not related to prior authorization.
Last updated: Apr 12 2022 at 19:14 UTC
