Update the urine screening value set with this content:

Opioid urine tests LOINC 2_65.txt

Found in guideline 10 CQL

The CQL for “Missing Opioids” seems a bit fragile in that it relies on specific display names of urine drug tests and how they match up to specific ingredient names from the prescription drugs. This may be the best approach (as it’s a tough problem), but it probably deserves some commentary in the code and/or documentation so implementors understand that tight dependency between the medication code displays and urine drug screen code displays.

This is a nitpick for sure, but the use of "Get" in the function names is a bit distracting. Suggest removing the "Get" from the names here.

Resolve comments that say "Really ought to be an error..." in the GetConversionFactor function. Either throw error in function or in caller.

Review all value sets and remove anything that's not used. Codeine cough syrup, for example.

FHIR Duration and Period units be specified with UCUM. Period.unit has a required binding to UnitsOfTime.

Create a CQL library from the SIG parsing Java library RxSig that the U of U developed.

There are several places in the CQL where only the first code in a concept is tested for inclusion. This needs to be altered to check each code in the concept for inclusion.

The current Opioid calculation logic uses 7.2 as the conversion factor for transdermal patch Fentanyl. This conversion factor is used for research calculations, the clinical calculation conversion factor should be 2.4, per the tables specified here: https://www.cdc.gov/drugoverdose/pdf/calculating_total_daily_dose-a.pdf

Add quick start documentation for recommendations #10 and #11.

Document known maintenance dependencies
Document known plans for future work.

Refresh the OMTK content

What is the value of having these defined as functions? Why not just reference the value sets from the source? Using functions obscures that all we are doing is a value set membership test:

The recommendation distinguishes between two recommendations. These are not explicit represented in the PlanDefinition and should be.

Based on feedback from MITRE (see MIH-47) on all Recommendation Pages: 

Two versions of the OMTK library are listed and it’s not clear what the differences are until the
implementor reads the individual files. At the least, it would be helpful to clearly indicate the
difference in the descriptions that show up in the Content listings. Given that the difference
between the files is how they get data (data source vs library w/ static data), and that they
actually represent two different use cases / implementation options, it seems they should
actually be two different libraries rather than two versions of the same library.

Is the 'POS' here a code from a known terminology? We should at the very least define a code and use that for the reference, a binding in a profile would be good as well.

Commented out code might make readers wonder if the logic really should be there but is commented out for some reason – or if it really shouldn’t be there but was never deleted. If there’s a reason, add a comment why the commented code is left intact, otherwise delete it.

Value Set Scope (from the VSD) is intended to be always and forever a narrative description (not coded) consisting of the Description of the value set, the Clinical Focus, and the Inclusion/Exclusion narrative. We put those elements into description, useContext[clinical-focus] and inclusion and exclusion extensions. For this refresh, the narrative should all be put into description and not usageContext, inclusion, and exclusion.

Purpose will be used to capture the reason the value set was created.

Terminology updates will be provided that we reimport from, and the updates will provide explicit content for each of these elements.

Us Core provides MedicationRequest.medication as a Reference --> Logic assumes a CodeableConcept

Us Core defines ambulatory prescriptions by setting the MedicationRequest.category to "Community" --> Logic assumes "Outpatient"

Us Core does not provide an interpretation for drug screening observations --> Logic assumes an interpretation code of "POS" to be provided

The resolution of this task requires refactoring the logic to use Us Core's modeling.

Several of the expressions in the CQL use explicit terminology paths rather than relying on the model info defaults. Are these intentional, or should they be removed to allow the model info to provide the terminology path for a resource?

Perform a complete Clinical Review of the content

Now that CDS Hooks has released, update to the release version. Specifically:

• Prefetch data in a request no longer uses the "response" wrapper
• User moved to context, not a direct request field
• The applyCql field will need to be modeled as an extension

Gather and document decision points relevant to each recommendation.

This basically involves refactoring the existing logic without the ContextPrescriptions parameter.

Running recommendations 10 and 11 results in 404 errors when attempting to retrieve the following types of resources from the FHIR endpoint:

• ProcedureRequest
• ReferralRequest
• MedicationAdministration
• MedicationDispense

This is consistent with US Core, so the logic should be updated to remove these references, possibly with a configuration option.

From the guideline:
This guideline is intended to apply to patients aged ≥18 years with chronic pain outside of palliative and end-of-life care.

Add Age >= 18 to all recommendations.

Remove the following value sets:

http://build.fhir.org/ig/cqframework/opioid-cds/ValueSet-opioids-codeine-cough-meds.html
http://build.fhir.org/ig/cqframework/opioid-cds/ValueSet-opioids-indicating-end-of-life.html

Remove any reference to these value sets in the logic.

To support continuous delivery pipelines, we should provide some example scripting about how to update the CQL and FHIR content when new versions are published.

Page: http://build.fhir.org/ig/cqframework/opioid-cds/test.html
Need expected results/outputs for each test bundle.

CQL should return null values for “Get Indicator”, “Get Summary”, and “Get Detail” when the patient doesn’t meet inclusion criteria.

The guidelines.gov site is down permanently, guideline links should be updated with the following:

Guideline URL

https://www.cdc.gov/mmwr/volumes/65/rr/rr6501e1.htm

Section IDs

1_Nonpharmacologic_therapy

2_Before_starting_opioid_therapy

3_Before_starting_and_periodically

4_When_starting_opioid_therapy

5_When_opioids_are_started

6_Long_term_opioid_use"

7_Clinicians_should_evaluate_benefits

8_starting_periodically_during_continuation

9_Clinicians_should_review

10_When_prescribing_opioids

11_Clinicians_should_avoid_prescribing

12_Clinicians_should_offer_or_arrange

Specific Recommendation URL (Example)

https://www.cdc.gov/mmwr/volumes/65/rr/rr6501e1.htm#5_When_opioids_are_started

Add null checks to avoid divide by zero exception when validityPeriod is Null.

Guideline Developer review of the content

Found in guideline 10 CQL

The intersection in the CQL below seems unnecessary. “A except (A intersect B)” is logically equivalent to “A except B”.

define "Unprescribed Opioids":
  "Opioids From Most Recent Screening" except
    ("Opioids From Most Recent Screening" intersect "Prescribed Opioids")

The logic for recommendation 10 currently uses string comparison of the contents of the urine drug screening result LOINC codes to determine the missing and unprescribed opioids sets, as well as string extraction of the contents of the illicit drug screening result LOINC codes to determine illicit drugs. This needs to be corrected to just display the results as they were presented in the lab test observation resources. For the missing and uprescribed opioids, these sets need to be collapsed to a single "Evidence of opioids" result that just references all the lab results in the opioid urine drug screening and non-opioid urine drug screening tests, and for the illicit drug results, just to return the results of the illicit drug screening tests.

Found in the Common library.
MedicationOrder.dispenseRequest.expectedSupplyDuration does not constrain units on duration, so it can be any of the valid UCUM duration units. The GetDurationInDays function only addresses a (year) and mo (month) and defaults all others to days. This means a duration expressed in weeks, hours, minutes, seconds, or ms would be calculated incorrectly. Even if those units aren’t likely, it’s safest to either support these units or specifically handle ‘d’ and error out (or null out) on any unsupported units. That said, it seems that a medication supply expressed in weeks could happen.

The language for the valueset query extension is wrong on this valueset:

http://build.fhir.org/ig/cqframework/opioid-cds/ValueSet-illicit-drug-urine-screening.xml.html

Should be TQL http://www.apelondts.org/tql

In the Opioid_STU3_Common library, the 'Outpatient' and 'Referral to Hospice' codes should be switched to value sets and the dependent queries/retrieves modified accordingly.

'Outpatient' -> valueset "Outpatient": 'http://hl7.org/fhir/ValueSet/medication-request-category'
'Referral to Hospice' -> valueset "Referral to Hospice": 'http://fhir.org/guides/cdc/opioid-cds/ValueSet/substance-abuse'

All of the other recommendations have “Get Indicator”, “Get Summary”, and “Get Detail”. This recommendation, however, only has “Get Indicator”. It seems the IG has established a convention, but this is the one artifact that does not follow it. Why?

Found in guideline 10 CQL

The GetDrug function could use some documentation indicating the approach it takes to extracting the drug name. It may also benefit from a more specific name (e.g., “GetDrugNameFromScreeningCode”). Lastly, there are some codes in the screening value set that have the form “DrugName cutoff ...” – those will never match an ingredient name. Should the GetDrug function also test for “cutoff” and truncate there?

How were these code lists determined? Do we have value sets for these? If not we need to get them defined and reviewed:

Found in recommendation #4 CQL

define "Get Detail":
  'The following medication requests(s) release rates should be re-evaluated: ' + Common.GetMedicationNames("Trigger Event Prescriptions")

This isn’t valid as-is, but CQL-to-ELM tries to be smart, so it applies a SingletonFrom to the list (actually, it applies it twice for some reason). The problem is, this means that if multiple prescriptions are passed in, this CQL will throw a run-time error (per spec).

This code should be using the String Combine operator (with a comma separator) on the list before concatenating.

Based on feedback from MITRE (see MIH-47) on all Recommendation Pages:

Two versions of the OMTK library are listed and it’s not clear what the differences are until the
implementor reads the individual files. At the least, it would be helpful to clearly indicate the
difference in the descriptions that show up in the Content listings. Given that the difference
between the files is how they get data (data source vs library w/ static data), and that they
actually represent two different use cases / implementation options, it seems they should
actually be two different libraries rather than two versions of the same library.

Rename OMTKLogic-0.1.0 to OMTKLogicWithData and OMTKLogic-0.0.1 to OMTKLogicWithCQL

Some systems do not include the "system" attribute in the category element of a MedicationRequest. Though this is not explicitly a conformance issue, it is suggested as best-practice to communicate system when known. In the absence of the system, given that the category binding is preferred, using the code only is acceptable. However, we will only introduce the behavior with a configuration setting and document with this rationale.

The broken links can be found in the "url" element in the Library, PlanDefinition, and ValueSet resources. For example: http://build.fhir.org/ig/cqframework/opioid-cds/Library-opioidcds-recommendation-04.html

Because the End of Life Assessment function takes the context prescriptions as a parameter, it implies that those are being used to make the determination. And while technically they are, they are only a small part of what the function is really doing, and most of that has nothing to do with the context prescriptions.

I suggest making End of Life Assessment an expression definition that includes everything but the context prescription check, and create a different function for that aspect that takes the prescriptions as a parameter, perhaps "Prescriptions for End of Life Medication".

Perform an engineering review of the content

The message produced by this expression will be displayed to a user, so it should use a user-friendly description, the medication name at least, rather than the id:

Page: http://build.fhir.org/ig/cqframework/opioid-cds/recommendation-07.html

There are several numbers or ranges in the logic description that aren’t easily found in the
recommendation statement.

How were these ranges determined? How should the information be conveyed to the reader?