kgrid-objects / opioid-collection

This is a collection of KOs for KGrid that can be used to identify and report on certain features of opioid prescribing

Opioid Knowledge Object (KO) Collection

This is a collection of KOs for KGrid that can be used to identify and report on certain features of opioid prescribing. Each KO in this collection uses patient prescription data for its input and provides information about patient prescriptions as its output.

More details.

Note: Integration tests ore disabled until we can specify kgrid component versions with the kgrid CLI.

opioid-collection's Issues

Create Opioid Detector Knowledge Object, regardless of starter status

Convert opioid object to product code

• Download SBD and SCD codes for each relevant drug code
• run the python script to combine by drug class
• update the new-opioid-start-detector and opioid-user-detector objects with the new, expanded list of codes

Move knowledge objects to production library and assign permanent ArkID

• 3 objects have 99999 ark ids (morphine milligram equivalents, new opioid start detector, opioid user detector)
• umich public library isn't set up yet
• check diabetes KO as well

Smart on FHIR Opioid App

• starting with Opioid User Detector objects

Create basic "panel" client app to demo TOC objects

The current bundle of transition of care objects are planned to be part of a back-end pipeline enhancing message in the MiHIN system. The same scenario can also be shown as an public web app.

In order to make clear what resources in the form of knowledge objects are being brought to bear on the clinical documents being processed in that environment we want to show those objects being run against similar synthetic data in a web client with an appropriate range of inputs and personas

• Use a smart app running against our test sandbox patients
• As always, start the sequence of events by launching from a particular patient
• base the patients on the consumer profiles from MiHIN
• provide scripted loading of the test patients/resources so that the demo of the client app can be reliably put through a known sequence
  if possible hook the loading of the test resources into the client app itself ("Reload" button, for example) so that there is less behind the curtain wizardry required.

Publish release versions for current objects

Test/update TOC KOs on MiHIN TOC documents

• Add curl versions of the test operations, PUT, GET, POST etc. Use the code generator in Postman. This makes it easier for quick testing in new environments.
• limit collections to two initial objects
• separate utilities folder, and not-current object
• update docs as needed