Stream: cds hooks
Topic: Appointment scheduling
Josh Mandel (Mar 07 2019 at 19:52):
In this github comment @Lloyd McKenzie you mentioned that:
[for] the solicitation for care step - i.e. finding an appropriate cardiologiest to see Patient Jones... most typically Task will be involved. Separate Task instances would exist for each cardiologist asked and would reflect who said "no" and eventually who said "yes".
Is this based on how systems today behave, or a newly envisioned FHIR workflow-based approach? The concept of actually tracking referrals in this way is pretty foreign to me.
I was thinking more about the use case of "I want this patient to see a cardiologist", and getting immediate feedback from the system about which practices I should consider referring the patient to (rather than providing a complete in-band accounting for tracking the creation of appointments etc). The goal here is to give health systems a clear place to plug in logic about which specialists to recommend, in terms of fit/value.
Lloyd McKenzie (Mar 07 2019 at 19:59):
The "I want someone to do this" activity in FHIR could be done using Task or one of the request resources. It depends on where in the workflow process the decision about "who should do it" is made. If it's tied into the authorization process such the at the authorization is strictly tied to a particular service provider (and if they can't/won't do it, a new authorization is needed), then that workflow could be triggered on the order-select hook as the ServiceRequest is authored. On the other hand, if the authorization is 'generic' open to anyone and there's a separate step where the practitioner (or a member of their staff) tries to find an appropriate practitioner to ask to fill the authorization, Task would be appropriate.
In either case, there's an authorization followed by an ability to say yes/no.
If no referral (i.e. authorization) is needed and you're just trying to book a patient - e.g. checking to see when there's a slot available to get their blood drawn or something, then you can just book an appointment in one of the open slots. Obviously you can also book appointments for the patient to come see you again in the future.
Lloyd McKenzie (Mar 07 2019 at 20:02):
In terms of "how systems behave now", there are some types of services where the authorizations are targeted and others where they're generic and someone else (sometimes even the patient) decides how to get the authorization filled. Quite often this involves phone calls or faxes or in-patient visits. However, some authorization can exist at this level. In v2, the status of the "request for fulfillment" is conflated with the status of the "authorization" so the order itself is given a status of "accepted/refused", even though the authorization isn't changed by a refusal. If one lab or pharmacy can't fill an order, you can always try another.
Josh Mandel (Mar 07 2019 at 23:32):
In either case, there's an authorization followed by an ability to say yes/no.
In my scenario, this isn't the case; it's a referral, i.e. a handoff to an outside clinical practice that's not going to be seeing or responding to "Tasks" in the source system.
Lloyd McKenzie (Mar 07 2019 at 23:36):
The target system doesn't have an ability to say "no" to your desired hand-off? (Whether the request is handled with Task or out of band or by some other mechanism is secondary)
Josh Mandel (Mar 07 2019 at 23:44):
It's not exactly a "target system"; it's advice to a primary care doc like "If you need a cardiologist, your top choices are Dr. A, Dr. B, and Dr. C" Maybe with some deep links into a separate referral management system, or a system that pushes the info to a patient who can review the recommendations and make their own choice.
Josh Mandel (Mar 07 2019 at 23:45):
In other words, some lightweight way to layer on a set of "preferred providers for specific situations", where the recommendation engine can know details about the patient (like, home zip code would be a small critical example!), the referral indication, etc.
Lloyd McKenzie (Mar 08 2019 at 00:15):
Well, CDS Hooks are only going to get triggered if you're doing something inside a system. Creating a ServiceRequest, creating a Task and creating an Appointment are all situations where it might make sense to hit a service that provides a list of candidate practitioners.
Lloyd McKenzie (Mar 08 2019 at 00:15):
But each of those would be distinct workflow locations within an EMR.
Lloyd McKenzie (Mar 08 2019 at 00:17):
(Note: the listed hooks don't currently support Task - there's an issue on the Hooks tracker that asks for this to be fixed)
Josh Mandel (Mar 08 2019 at 00:25):
But each of those would be distinct workflow locations within an EMR.
Is anyone on the EHR side able to shed light on this?
Brendan Keeler (Mar 08 2019 at 03:31):
I think Lloyd already sorta answered the question.
The doc places a referral order. When he or she signs, CDS hook for servicerequest fires off to the recommendation server and returns possible improvements or changes before it's marked as signed.
Lloyd McKenzie (Mar 08 2019 at 03:40):
The "help me pick a provider" service would probably fire on the order-select hook rather than the order-sign hook (now that they've been split)
Matt Varghese (Mar 08 2019 at 06:51):
Are we expecting that it is actually a clinician/physician who books the appointment?
Matt Varghese (Mar 08 2019 at 06:52):
what happens if the patient is scheduling the appointment themselves on a self-service portal?
What happens if it is front desk staff / a receptionist who is booking the appointment?
In these cases, would it be appropriate to show Clinical decision support to someone who is not a clinician?
Lloyd McKenzie (Mar 08 2019 at 08:25):
In some cases, certainly. If a patient is booking a dental cleaning, it's legitimate for a decision support app to say "the proposed date is less than 9 months since your last. The earliest date that would be covered by your plan is X". Similarly, if a receptionist is booking an appointment, it's appropriate for CDS to say "the window for the next visit as part of clinical trial Y must be between A and B".
Lloyd McKenzie (Mar 08 2019 at 08:25):
(as examples)
Josh Mandel (Mar 08 2019 at 18:51):
Are we expecting that it is actually a clinician/physician who books the appointment?
These are the critical questions IMO, Matt. I want to make sure we have a solution that works even in the relatively loosely coupled world where we just hand a set of recommendations to a patient and say "go for it".
Matt Varghese (Mar 08 2019 at 21:38):
My understanding is that providers would never really be booking appointments. It will usually be a receptionist/front desk person or patient themselves over self-service web portals. Remember that anything we do should be in the direction of reducing provider burnout and not aggravating it.
Lloyd's original message read:
Services could do a range of things - check if a patient will be due for certain tests or other interventions (based on registration in a clinical trial, general care protocol, etc.) and, if so, recommend adjusting the appointment to allow time for them; proposing orders that should be issued so that certain diagnostic tests can be completed before the appointment occurs, identify if a scheduled follow-up is deemed to be "too soon" based on the patient's coverage, etc.
-
checking if patient will be due for certain tests or other interventions
If this is a scheduling system and not an EHR, there isn't a clear way this can be done. -
proposing orders that shoudld be issued so that certain diagnostic tests can be completed before the appointment occurs
Patient / Front desk staff are the wrong recipient for this. They cannot sign orders. -
identify if a scheduled follow-up is deemed to be "too soon" based on the patient's coverage
Coverage based identification may be possible. However, clinical identification is not appropriate at this point.
Some additional thoughts:
1. The software that books the appointment can be a registration and scheduling system, which may or may not be an EHR, that schedules the appointment. Sometimes just an Outlook calendar.
2. While decision support itself is okay in that situation (merely by definition of decision support), how clinical can we get?
- For example, let's say condition X usually/99% of the time needs diagnostic order A. However, if condition Y is also present, then diagnostic order A is contraindicated and diagnostic order B is to be performed. Now if a clinician, knowing all this, places an order B, but at the time of booking, a decision support algorithm comes to the patient/front-desk person and just says - you have condition X, why are you booking for exam B, do A instead? What do we expect to happen here? Essentially the danger of providing Clinical Decision Support to someone who is not a Clinician.
3. Unlike in the above example, lets say that the CDS system is right when it asks for change order P with order Q. What can front desk staff / patient do about it? The appointment is not the place to correct this; rather the physician has to change the order so that the right hook to use would have been on the order-sign hook with the med/proc request resource.
Yes, there is value in giving Coverage related advise to the patient/scheduler at the time of appointment booking. However, there are no guardrails to prevent vendors implementing actual clinicial decision support, once a hook exists.
So this also becomes a question of what is the scope of CDS Hooks.
Brendan Keeler (Mar 08 2019 at 21:45):
The question as I read it was about referrals, not appointments, despite the title.
Brendan Keeler (Mar 08 2019 at 21:50):
Referral workflow would be something along the lines of:
Physician decides patient needs to see someone else (specialist, for instance).
Physician places referral order.
- CDS hooks could be used for selection or signing, per Lloyd.
- CDS hooks return suggestions about who to refer to, given the content of the referral order (this is functionally similar to X12 pre-auth workflow, but instead of approval, it's just recommendations).
Referral order is created.
It's then a scheduling workflow. The request for service is created.
Someone (scheduler, patient, etc) picks when and where the patient will be seen.
- Maybe there's CDS here too to advise on that scheduling.
Matt Varghese (Mar 08 2019 at 22:03):
@Brendan Keeler order-select and order-sign hooks are perfectly fine. No concerns from me on them; in fact I will gladly advocate for them :)
It's the appointment-book hook where I have concerns. Nor am I saying there is no value in it - there is. Rather the non-clinical nature, and the clinical concerns are what I am trying to highlight.
Lloyd McKenzie (Mar 08 2019 at 22:39):
Regardless of who books the appointment, there's CDS that's useful to have. If a pre-auth is going to be needed, letting the booking person know (be they a receptionist, provider or even patient) is a useful thing. The same goes for an appointment doesn't meet the timing needs of a clinical trial, an alert that certain tests should be booked for before the appointment, etc. In some practices, it may well be that a clerk or clinic manager will get all of those. Some of those they'll be able to manage on their own. Some they can do most of the legwork for and just present to the clinician for approval. Others they'll route to the practitioner to look at when they have time.
Josh Mandel (Mar 09 2019 at 00:08):
Does anyone think the scope of this project should be limited exclusively to "Clinical"? I wouldn't know how to draw the line, and I'm not sure we would want to.
Lloyd McKenzie (Mar 09 2019 at 02:36):
Da Vinci CRD is using it for a mixture of clinical, administrative and financial. Clinical research is going to need it for both clinical and administrative purposes. My experience with "lets limit the scope to just clinical" is that that's what they chose to do with CDA - and it ended up just causing pain and both conformant and non-conformant work-arounds.
Matt Varghese (Mar 09 2019 at 19:09):
In Decision Support, there is the idea of the 5 rights of decision support.
The five rights include:
* the right information,
* to the right person,
* in the right intervention format,
* through the right channel,
* at the right time in workflow.
Essentially, my concerns are that,
- decision support risks being presented to someone other than the right person
- if any clinical advise gets presented, it could often not be at the right time in the workflow / could often not be in the right intervention format
Lloyd McKenzie (Mar 09 2019 at 19:26):
The decision support engine would know who it's presenting to and could make the decision on what to present (or not). However, if follow-ups are typically booked by administrative staff and the clinician is not involved, there's still a need for decision support to be provided. We can't change the business process of how appointments get booked. If relevant information provided to the booking individual needs to be shared with someone else, that's still better than the information not being shared at all.
Brendan Keeler (Mar 09 2019 at 19:58):
Yeah, we should be assuming the decision engine (the product) isn't flawed and is making the right choices.
Brendan Keeler (Mar 09 2019 at 20:00):
CDS hooks only convey the information to that product. As long as it's conveying the appropriate information when it's supposed to, we're good on the interfacing front.
Matt Varghese (Mar 09 2019 at 20:01):
@Lloyd McKenzie , yes, software can do the right thing. However, software often does not.
This is a hook that is almost exclusively never presented to a clinical user. That means, from a patient safety viewpoint this terrifies me. I would venture to guess EHRs wouldn't be likely to implement this. In the first place, it is not in the "medical record" but in the "scheduling system" that this hook falls, and in the second, the risks to the patient seem significant.
Is there no way we can gain the same value you are looking for in CRD using a different hook which presents itself to a clinician?
Lloyd McKenzie (Mar 09 2019 at 20:03):
We can't present the hook to a clinician if they don't actually do the appointment scheduling. If the clinician's workflow is "stop with the receptionist on your way out and book a follow-up for 2 months from now", there's no way for decision support to get in front of the clinican except by working through the receptionist.
Brendan Keeler (Mar 09 2019 at 20:04):
Analogously, those creating HL7v2 ORM and ORU messages didn't assume the lab system would send back incorrect information
Lloyd McKenzie (Mar 09 2019 at 20:05):
If they're making a referral, then we can catch that with order-select/order-sign. But if they're just booking an appointment, none of the order-x hooks will fire - and if it's not a clinician that books the appointment, then a clinician won't see it.
Matt Varghese (Mar 09 2019 at 20:05):
Lloyd, even if this hook is made, if it doesn't get implemented, do we gain anything?
Lloyd McKenzie (Mar 09 2019 at 20:05):
Nope. Implementation is needed. But I expect we'll see demand for this because clinicians (and clinician offices and patients) are going to care about things like pre-auth requirements when booking appointments.
Lloyd McKenzie (Mar 09 2019 at 20:06):
EMRs certainly have scheduling/booking interfaces. Argonaut is working on that end of things right now.
Lloyd McKenzie (Mar 09 2019 at 20:09):
I don't really understand the "risks to patient" side of things. Most of the decision support with this sort of hook will relate to "is what's happening covered", "are you scheduling too soon/too late", "are you scheduling with someone appropriate". It's certainly possible that failures here could result in payment harm, but most typically it's just going to mess up payment or cause an exception to a clinical trial protocol or reduce a clinics metrics on some scoring mechanism.
Matt Varghese (Mar 09 2019 at 20:11):
Ok, I've expressed my concerns. I'll defer to others to chime in.
I'm especially curious how other EHRs as well as clinicians feel about this.
Lloyd McKenzie (Mar 09 2019 at 20:32):
Can you expand a little bit on the risks you see?
Matt Varghese (Mar 09 2019 at 21:34):
I mentioned a few examples in my second post on this thread. They are of the nature of what happens when the CDS system's recommendation is poor or does not consider all clinical information (maybe because all clinical info is not available in the scheduling system), of the non clinical nature of the recipient making them not necessarily the best judge of the CDS, and of the inability for many types of interventions to be actionable at this point. Brendan above points out HL7 allows bringing lab info to the EHR even if there is possibility of software error, but that is a poor analogy because the lab info is reviewed by clinicians before filing in the origin system, and the origin system has all info necessary to determine the lab result, which may not be the case with CDS. And I agree that your use case has value, but when we make a hook, we should also think about what other use-cases can people build on top of it, and is it possible they might turn out in the adverse interest of the patient. There is nothing limiting this hook to your CRD use case.
Matt Varghese (Mar 09 2019 at 21:37):
Also, the confidence a patient has in their physician is important. In my example, where usually condition A needs exam X, but because condition B is also present, the physician knowingly ordered Y; here if a patient is shown CDS by a system at the time of appointment booking saying your indication is A, why are you scheduling Y - use X because that is what is used 95% of the time - not only is that a bad CDS system, but it is harmful for patient confidence in their physician who was actually right. So all of these kind of things make me generally worried about showing CDS to a non-clinical user. And this hook is one that almost exclusively shows to non-clinical users.
Matt Varghese (Mar 09 2019 at 21:38):
I hope that is a good summary of all my concerns. Perhaps I am over-worrying. I will leave it to you all to evaluate whether these are serious concerns or not..
Lloyd McKenzie (Mar 09 2019 at 22:01):
Agree that if you're going to be raising clinical-related issues to a non-clinician, you'll need to be careful. The key is that each user acts within the authority they have. A receptionist scheduling an appointment may have leeway in who it's scheduled with or when it's scheduled, but not what it's for. If the decision support makes suggestions for the first two and it fits within the overall parameters the receptionist is allowed to change, great. But if it's outside that space, then the receptionist is going to have to talk with the clinician. It's really no different than a receptionist phones to make an appointment now and is told "I'm sorry, but Dr. Smith is on a 1-month vacation. We could do it 1 week sooner or 1 month later". In some cases, the receptionist will have the flexibility of making the decision themselves. In other cases, they'll check with the clinician.
The same actually happens during order entry. It may well be an intern who's "manning the EMR" and seeing the decision support issues. Some they might manage themselves, others they'll check with the clinician about. If the prescriber signs the printed paper form, it's possible they might never see the EMR-raised decision support at all. That doesn't mean we wouldn't share decision support just because the user is an intern and not a licensed physician.
Brendan Keeler (Mar 10 2019 at 02:07):
Great points @Lloyd McKenzie
Brendan Keeler (Mar 10 2019 at 02:10):
Ultimately, a lack of trust in the capabilities of computer decision support isn't a reason to disable the integration points. It's a reason for purchasing parties to choose wisely. As integrators, we should be aiming to enable as many possible integration points as possible with standardized data exchange to further innovation.
Brendan Keeler (Mar 10 2019 at 02:12):
CDS hooks is just a paradigm of modern synchronous exchange for augmenting human choices, built on mostly pre-existing event driven triggers (although some new, for order select).
Brendan Keeler (Mar 10 2019 at 02:15):
Build the right decision engine for each hook. For orders, it should factor in clinical criteria as well as some authorization. For scheduling, the engine should optimize scheduling in mostly terms of adminstrative capacities like resource utilization and predicted fulfillment.
Brendan Keeler (Mar 10 2019 at 02:17):
With the growth of AI and machine learning, CDS hooks is the most important data exchange architecture of this decade. If a certain hook is not defined in FHIR, some one else will certainly invent a proprietary version
Brendan Keeler (Mar 10 2019 at 02:19):
</rant>
Brendan Keeler (Mar 10 2019 at 02:45):
One further point regarding "what if it's not used": existing HIT standards (HL7, IHE, DICOM) are absolute bibles of unimplemented formats. We've crossed this metaphoric Rubicon before
Matt Varghese (Mar 22 2019 at 16:00):
Another thing came up on this front. Folks who are more familiar than I am with how appointment booking happens informed me that the Insurance that will be applicable for an appointment may not be known at the time of appointment booking.
To me, this means the EHR wouldn't even be able to know with certainty which payor's CDS Service to call at the point of evaluation of this hook, or what insurance resource to send. So @Lloyd McKenzie , I am concerned that this hook may not be able to meet the requirement you present / what I understand is necessary for CRD.
If a pre-auth is going to be needed, letting the booking person know (be they a receptionist, provider or even patient) is a useful thing.
Brendan Keeler (Mar 22 2019 at 17:19):
There could be a middleman product or service to facilitate that
Brendan Keeler (Mar 22 2019 at 17:19):
Assuming the other party in the exchange is a payer seems like a faulty assumption
Lloyd McKenzie (Mar 22 2019 at 17:40):
The reality is that payers can only advise you of requirements if you have enough information to be able to ask. There will certainly be situations where you don't - and therefore don't get any advice. The hook will still be useful for the many cases where you do know the information.
Matt Varghese (Mar 22 2019 at 19:37):
So what is the value proposition of the hook? That it can do things like?
an appointment doesn't meet the timing needs of a clinical trial
Way I am seeing it, all the other use-cases seems to have serious caveats; especially the violations of the 5 rights.
I am leaning towards - I don't see this hook being usefully leveraged, and I see risks of this hook being unwisely used.
Lloyd McKenzie (Mar 22 2019 at 19:43):
The appointement hook can do a number of things:
- you're booking the appointment sooner than will be covered
- you're booking outside the clinically recommended follow-up window (too soon/too late)
- the next appointment should also include these additional activities (driven by clinical protocol and/or study protocol)
- while you're booking appointment X, you should also be booking appointment Y
Lloyd McKenzie (Mar 22 2019 at 19:46):
I don't see how it violates the 5 rights. It's presenting information relevant to booking appointments to the person who's booking the appointments. If that person isn't a clinician, then that person either has the experience needed to make adjustments or they bring the clinician into the discussion when necessary. We're not changing the workflow. The people who book appointments are the same as they always have been. And the ramifications on compliance with coverage requirements, clinical trial requirements, CPG recommendations, etc. are the same now as they would be with the hook enabled. We're just providing better information to the person making the decision.
Lloyd McKenzie (Mar 22 2019 at 19:46):
There aren't any other "hook points" that we could leverage that I'm aware of for these sorts of decisions that could meet the 5 rights any better.
Lloyd McKenzie (Mar 22 2019 at 19:47):
(including new ones we might define)
Matt Varghese (Mar 22 2019 at 20:13):
- you're booking the appointment sooner than will be covered
Relies on coverage info, as discussed above. What if DSS tells a patient who had a workplace injury to schedule later based on primary coverage?
- you're booking outside the clinically recommended follow-up window (too soon/too late)
Follow-up appointments are booked based on After Visit Summary recommendation. If patient deliberately wanted earlier, this alert is likely noise.
- the next appointment should also include these additional activities (driven by clinical protocol and/or study protocol)
Again follow-up appointment. Also, the right person to receive this would be a clinician. Plus simple situations already have rules in the scheduling systems. A synchronous CDS Web Service call should only happen for non-trivial cases.
- while you're booking appointment X, you should also be booking appointment Y
This will almost definitely have rules in the scheduling system.
I am really trying to see a good clinically valuable non-trivial use case where consulting an external system can actually make a difference and which has few caveats or significant risks.
Matt Varghese (Mar 22 2019 at 20:27):
Also, to your point about the five rights: to me, presenting the info to the right user in an actionable fashion is not same as presenting to another user who can go talk to the right user. Perhaps I am holding a higher bar, but for me, if the CDS Hooks alert shows to me, I myself should be able to decide on it.
Matt Varghese (Mar 22 2019 at 20:28):
Otherwise, why even consider this in the five rights? The alert can be shown to any one at the organization, if it is enough that they be able to go talk to the right person?
Brendan Keeler (Mar 22 2019 at 22:29):
You are overthinking this a bit.
Is there a decision being made at a certain point in the workflow?
If so, is it feasible that another entity has information to help enhance that decision making?
If so, the hook is valid.
Lloyd McKenzie (Mar 22 2019 at 22:37):
Relies on coverage info, as discussed above. What if DSS tells a patient who had a workplace injury to schedule later based on primary coverage?
DSS could very well say that - as could a phone call to the primary insurer. Decision support with incomplete information carries risks - but that's no different from any of the decision support we offer now
Follow-up appointments are booked based on After Visit Summary recommendation. If patient deliberately wanted earlier, this alert is likely noise.
It might be noise. But if the alert says "This visit is shorter than the minimum visit interval and will not be covered by your insurer", then that's something the patient will probably want to take into account. As with any decision support system, there'll be a need to adjust the types of alerts and who they go to. But knowing that a small change could impact whether something's covered or not, whether someone gets booted out of a clinical study or not, or will impact whether you meet quality assessment metrics (which in turn drive funding) are all things that are going to be seen as "non-noise" to a significant proportion of service providers (and their patients). The after-visit recommendation is a "recommendation" and front-line staff can and do make adjustements within their purview to deal with things like coverage limitations, etc.
Again follow-up appointment. Also, the right person to receive this would be a clinician. Plus simple situations already have rules in the scheduling systems. A synchronous CDS Web Service call should only happen for non-trivial cases.
If there was a way to get it in front of the clinician, sure. But if the alert is tied into the timeframe being scheduled and the clinician isn't doing the scheduling, then the alert is going to need to show up in front of the user doing the work. If you're booking an appointment 6 months out for a follow-up and an alert comes up saying that the patient is due for their routine physical at the same time, it's pretty easy for the assistant or receptionist to book a block that will cover both - but they can only do that if they know. And that sort of thing wouldn't generally require a consult with the GP.
This will almost definitely have rules in the scheduling system.
It depends. If the "you should also be booking appointment Y" is driven by a clinical trial protocol or other protocol that isn't "baked into" the scheduling system, it's entirely possible that the linkage won't be there. If it is, then you wouldn't be hitting a service that's intended to provide such integration. There are certainly lots of scheduling systems out there that don't have the capability of integrating third-party rules, particularly not on a patient-specific basis.
The "right" person to present decision support about booking an appointment is the person who books appointments. This is the same person who right now has to worry about payer rules, evaluation metrics, clinical trial requirements, etc. It's just that they do it with phone calls, sticky notes on the side of their monitor, guidebooks in their desk drawer and often just via phenomenal memories. Alternatively, they don't do it and problems result - or at least inefficiency results. If the clinician interacted with their system at the time they were 'recommending' an appointment timeframe, it'd be totally appropriate for the "appointment-book" hook to come up then too. But, the most common workflow is a verbal instruction to the patient when they're leaving the exam room. If the staff encounters concerns based on payer rules/whatever that they can't handle on their own within the discression the clinician has given them, then they come and ask. They do that now in a non-CDS Hook world and they'll continue to do it in a CDS Hook world - just with better information. If the need to ask questions is sufficiently frequent, then perhaps the workflow will change. But that's not a reason to avoid putting the information in front of the people who are making the decisions now.
Matt Varghese (Mar 22 2019 at 22:54):
@Brendan Keeler
You are overthinking this a bit.
Is there a decision being made at a certain point in the workflow?
If so, is it feasible that another entity has information to help enhance that decision making?
If so, the hook is valid.
I disagree. We are talking of exchanging patient information including confidential information to another entity. We are talking of the trade off between performance considerations vs actual value add in the workflow. We are talking of safety of the patient, and ensuring a good outcome to the patient, as well as not allowing a badly built piece of software to detract from the relationship a patient has with their provider. We are also talking of the -ve impact on the scheduler's system use experience by making many synchronous web service calls to possibly poorly designed CDS Systems which could take a while to respond, and not provide anything useful. In fact, what you are saying comes across as rather lackadaisical and so is actually adding to, and not subtracting from my worry.
Matt Varghese (Mar 22 2019 at 23:01):
@Lloyd McKenzie Can you furnish a non trivial clinically useful example of an intervention an external CDS System could do using this hook that might be hard do within the scheduling system, and which has few possibilities of "going wrong", and can be acted upon by the scheduler/patient?
Matt Varghese (Mar 22 2019 at 23:02):
For example, with the order-sign hooks, there's the whole PAMA use-case. A good EMR can do it within the EMR itself, but the build involved would be really complex in that case. And the value-add is really high, both in avoiding harm to the patient and reducing cost.
Some example use case like that, which can show real value with the appointment scheduling hook. A use case like that can settle this question.
Brendan Keeler (Mar 22 2019 at 23:03):
The exchange of information has happened for four decades. The only difference is CDS hooks are synchronous.
Brendan Keeler (Mar 22 2019 at 23:05):
CDS hooks lets smart people innovate in new ways. It's on the implementation side that organizations choose to buy and configure the right products, not on us at the standards level
Matt Varghese (Mar 22 2019 at 23:06):
@Brendan Keeler you're going off topic. I have nothing against CDS Hooks, and have in fact championed it wholeheartedly. It is that very reason which makes me want to have good hooks with reasonable certainty that they will facilitate good outcomes.
Lloyd McKenzie (Mar 22 2019 at 23:17):
My purpose isn't to avoid any possibility of things going wrong. They go wrong now. My objective is to make them go right more often. It's also not a question of whether it's "hard" to do within the scheduling system - it's a question of whether it is done within the scheduling system. The reality is that very few scheduling systems support integrating payer rules, clinical trial rules or even rules that drive formal evaluation measures. In the case of payers, the rules are often proprietary and aren't necessarily always shared and may be driven by information the scheduling system has no access to. The same can be true of clinical trials (at least in terms of lack of data access).
As a very simple use-case, the patient is booking a 4-week follow-up after a procedure and asks the clerk if they can book their annual physical at the same time. The receptionist says sure and fills in the information. An alert comes back and indicates that the proposed booking time is one week short of the 10-month minimum the payer has for doing an annual physical. Based on the type of follow-up being done, the receptionist determines that a 5-week followup will be fine and, after checking with the patient, shifts the booking for both events to meet the minimum interval requirement. That's not something the scheduling system can do on its own right now because every insurer has different rules and, in some cases, the most recent prior annual physical might not even have been done with this provider.
Matt Varghese (Mar 22 2019 at 23:27):
@Lloyd McKenzie Thanks. That is definitely a better use-case than ones I've seen here so far. There is certainly value. It is not something that can be natively computed in the scheduling system natively unless it is privy to a lot of intricate detail about the insurance plan. It is shown to the right recipient in an actionable fashion. So yes, that is a good use-case to justify the hook with.
Matt Varghese (Mar 22 2019 at 23:28):
Perhaps then what I am worrying about can be rephrased as, what CDS Hooks needs is some way to make sure that we can do scoping so, for example, a place order suggestion doesn't get sent back in an appointment-booking hook?
Last updated: Apr 12 2022 at 19:14 UTC
