Medication QR codes are unworkable with the current database format

[circuitfox]

QR codes for medications have (from the sample documents) one of the following
formats:

(1) <dosasge> <units> <name>
(2) <dosage><units> <name>
(3) <dosage><units>/<dosage><units> <name>
(4) <dosage><units> / <dosage> <units> <name>
(5) <name>
(6) <dosage> <units> <name> <dosage> <units>
(7) <name> <dosage> <units>/<dosage> <units>
(8) <name> <dosage> <units>
(9) <name> <dosage> <units> in <dosage> <units> <name>

Where:

name   = the name of a medication or substrate, can include percentage
         e.g. 0.9% Sodium Chloride, distilled water
dosage = the amount of a medication or substance. Always a number, can be
         decimal
units  = the units a quantity is in e.g. mg, mL, units/mL.
         May contain any practically any kind of character.

This represents a problem: the format of these medications is very irregular. Fields are ambiguous. For example, medications with formats (3), (4), (6), (7), and (9) have two things that could be conceivable called their dosages and units. One of them is clearly the primary unit, but the other one still needs to be represented. Medications with format (5) have no dosage at all; this would suggest this field is optional. Medications with format (9) have an additional name in addition to an additional dosage, would this go with the units of the second dosage? How should the second dosage be represented? As dosage 1 per dosage 2? As completely separate quantities? Some medications follow each form.

Possible solutions

• Make dosage_amount and dosage_unit nullable to satisfy medications of type (5)
• Add secondary name, dosage_amount, and dosage_unit fields, all nullable. This satisfies the medications of types (3), (4), (5), (6), (7), and (9)
• Add a field for what the secondary values represent. Possible values could be combo (as in e.g. Tylenol 300mg/30mg where the 30mg quantity represents Codeine), amount (as in e.g. 10mL insulin 100 units / mL), and in (e.g. Ancef 1 g in 50mL normal saline).

These are by no means final solutions and I'm open to different ones.

@carlgoshert you may have thoughts on this.

[carlgoshert]

If there is a need for a code change, we should tackle it first. Personally, I still think the excess info should be dumped into 'comments'. If a code change is not needed now, then we should get on reformatting the QR codes.

[circuitfox]

The extra info isn't 'comments', though. It's information about the medication, such as information about the dosage of another drug included in the medication. Dumping it in a comments field would be even more semantically broken than leaving it as it is now. Reformatting the QR codes won't fix this issue unless we want to drop this extra information from the codes. I'll drop the reformatting into a different issue if you want to tackle that first.

[jameson-beretta]

I think Chris is right, we can't simply dump this info into comments. They have more meaning and deserve appropriate fields in the database

[carlgoshert]

So to solve the issue of some medications being made up of two different medicines, we could merge the 'dosage_amount' and 'dosage_unit' into a single string attribute 'dosage' since I can't find any requirements stating they need to be separate and have a nullable 'dosage2'. I.E. - "Tylenol #3; 300 mg Acetaminophen; 30 mg Codeine; by mouth; Tylenl".

The problem is that this will require huge changes throughout the project.

[circuitfox]

So the plan for this is as follows:

• add two new nullable fields, second_amount, and second_unit to represent a second, optional dosage, unit count, or medium.
• add a new nullable field, second_type, as a tag to communicate what the second_amount and second_unit represent. These will be one of combo, amount, or in to represent a combo drug, a drug with a specific amount per dosage unit, and a medium the initial dosage is in.

I'm open to other names but I think these communicate their meaning well enough. I want everyone to sign off on this before I write up issues for it.

@carlgoshert @jameson-beretta @kschick02

[carlgoshert]

I agree with this solution.

[jameson-beretta]

I concur

[kschick02]

I agree as well.

[circuitfox]

Okay. Then that's the solution we'll do. I'll write up issues for it.

[circuitfox]

To deal with names required for the secondary information (in the case of combo elements) the name will be encoded in the database as primary|secondary as | is unlikely to appear in the name. This will simply be parsed in the controller.