FHIR Chat · DetectedIssue Rules

We have a system which generates DetectedIssues based on various configurable rules that are executed and can details of the rules can be configured at an Organization, Location or Patient level. The default rule definitions for our system are set to the various published clinical standards but each level of care can change the rule thresholds, periods, etc to match their standard of care or specificity to deal with alarm fatigue. For example, there is a defined Asthma Control Score for asthmatics which indicates an asthmatic's current asthma health in Red, Yellow or Green and as data changes we recompute the score per patient. Providers are able to configure and override the thresholds for red, yellow and green all the way from their entire population down to an individual patient based on how they operate. We then dynamically recompute the rules differently based on any rules changes and create DetectedIssues to match.

We're not seeing how we would model these rules in FHIR r4 or r5 so providers can manage them nor are we seeing how to indicate on a DetectedIssue how to reference or snapshot the rule settings that generated the DetectedIssue. Would we need to create custom resources and attributes here or are we missing where FHIR supports both rule management and indicating the rules used in generating a DetectedIssue?

Lloyd McKenzie (Jan 13 2022 at 23:17):

@Bryn Rhodes, what's the best advice around storing decision support configurations?

Bryn Rhodes (Jan 14 2022 at 03:22):

So I imagine the configurable aspects of the rules represent parameters to the rule execution, and there is some setup somewhere where you can specify how to determine what those parameters are given the level the rule is executing, right?

Bryn Rhodes (Jan 14 2022 at 03:24):

If you want to make sure that you capture what those parameters were that resulted in the calculation of any given detected issue, you will need to capture the values of those parameters with the detected issue (or provide a way to reconstruct what those settings were when the detected issue was generated, a much more difficult thing to do I would think).

Bryn Rhodes (Jan 14 2022 at 03:24):

We typically capture this type of information (the parameters to the evaluation) using a contained Parameters resource and an extension that references that contained resource.

Bryn Rhodes (Jan 14 2022 at 03:25):

Here's an example in a MeasureReport: https://build.fhir.org/ig/HL7/cqf-measures/StructureDefinition-cqfm-inputParameters.html

Bryn Rhodes (Jan 14 2022 at 03:36):

As far as the rule itself, if the rule is represented using a FHIR conformance resource, you can use the "authority" element to reference the canonical URL of the rule (with version as appropriate). If it's not a FHIR resource, I think the same approach applies, you would use the "authority" element, it would just be to a URI identifying the rule and version using a scheme appropriate to your rule system.

Mike Lohmeier (Jan 14 2022 at 16:56):

Yes, the configurable aspects of the rules represent parameters to the rule execution like thresholds, periods, metrics, communication actions, etc.

Apologies, by "using a FHIR conformance resource" do you mean we use Organization, Location and Patient's "authority" element to reference the rule(s)? What would the actual rule configurations be modeled as though to allow clients to read/write?