Stream: Da Vinci
Topic: General Measure raw data delivery architecture
Lloyd McKenzie (May 24 2018 at 17:23):
I've been doing some thinking about how to create a "generic" architecture for push-based delivery of measure-relevant data that could scale to a variety of measures without requiring measure-specific custom coding by each EHR vendor.
I'm wondering if the solution is CDS Hooks. The notion would be that a hook-based solution could monitor for the creation of data that is potentially relevant to one or more measures. The hook would then verify relevance (e.g. this is a patient that should be reported to a particular payor/aggregator). It could then normalize the information to be delivered according to an agreed measure-specific profile regardless of how the data happened to be represented in the EHR. The CDS solution triggered by the hook would have the responsibility of dealing with EMR and site-specific variations in data representation and dealing with how to normalize that information for a specific measure. So we'd still have a situation of measure-specific custom coding. The degree of coding involved would depend on how much variation there was between EMR instances. But it would mean that the custom coding would live outside the EMRs and would also live outside the aggregators. This should enable much more timely support for new measures
This approach also means that, from a payor perspective, the scope remains the same as it always was. "The EHR" would push the relevant data to the payor in a standardized way. The only shift might be that the data pushed might include some indication of what measure the data is intended for, rather than having that hard-coded in the operation called.
It also means that we're not pushing a bunch of complex processing into the EHR. The complexity lives in the CDS Hook. And the complexity there is managable because you don't need to create one hook that does everything. You could have different hooks for different measures or different families of measures or different regulatory regimes. EMRs could ensure appropriateness of the hook behavior, including data access rule adherence through their normal certification/registration process.
Lloyd McKenzie (May 24 2018 at 17:23):
Thoughts?
David Hay (May 25 2018 at 05:26):
So the 'trigger' in CDS hooks is a general notification that something has happened - it's up to the configured service to decide what to do with the event - eg return a card, or something else as you suggest...
Lloyd McKenzie (May 25 2018 at 05:45):
Right. This would be a hook that wouldn't return anything to the user, but would fire an external notification after querying to determine whether a notification was necessary and who it should go to.
Lloyd McKenzie (May 25 2018 at 05:46):
I suppose it could return a card with a notification that the payor had been informed if there was a need/desire for the clinician to know that.
Josh Mandel (May 25 2018 at 14:38):
@Kevin Shekleton for visibility. My take is: there's likely a good use case for some kind of hook-based pattern here, but it doesn't sound like the UI-oriented CDS Hooks problem space to me.
Lloyd McKenzie (May 25 2018 at 14:52):
It's certainly not a "traditional" hook from a UI perspective, but given that hooks don't have to return UI content, it would still work. The hook points would be the creation of a record indicating completion of reconciliation, so it would still be a user-invoked hook.
David Hay (May 26 2018 at 18:19):
and if the service did send on data relevant to measures, then a card informing the user that that has happenned seems entirely appropriate....
Lloyd McKenzie (May 27 2018 at 05:12):
Card is certainly appropriate if the user would care to see it. I don't know whether any would care or if it would just be noise
David Hay (May 27 2018 at 06:27):
true...
Last updated: Apr 12 2022 at 19:14 UTC
