Burke: two different solutions for (a) free-text concept, versus (b) brand name, e.g.
(a) DrugOrder.concept = "Drug Other", drugNonCoded = "Amoxicillin 5mg tablet" (JT is suggesting that this is really "conceptNonCoded", not "drugNonCoded")
(b) DrugOrder.concept = "Amoxicillin", drug (this is coded) = "Amoxicillin 5mg tablet", brandName = "GlaxoSmithKline"
Jonathan: we also should have
(c) DrugOrder.concept = Amoxicillin, drugNonCoded = "Amoxicillin 5mg tablet" (this is the non-coded formulation) or else "Joecillin 5mg tablet" (this is the branded formulation)
Vivek (on Talk) says:
"I do not see the users putting that extra effort in giving a free text name as well as choosing a concept name for it. This is what I think as of now, but once we have it rolled out in the hospital we can explore further with the users."
Concept (generic drug) / Brand name-synonym field / Formulation field
1. If I type in a name, the software should try and find the string in the concept dictionary, whether it is a concept or a synonym (which includes brand names) --
a. If it recognizes the typed string as a brand name and finds the matching concept, fill in the Concept and BrandName-Synonym fields
b. If it doesn’t find a match, ask the user to try again and re-enter the name [maybe it was misspelled] or enter a generic concept
i. If they choose one, that will be the Concept and the original string will go in the BrandName-Synonym field (uncoded)
ii. If they don’t choose one, this is a unknown-concept drug. Store as DRUG OTHER concept and store the typed string in the concept.noncoded-text field
Current approach (per TRUNK-4761):
Introduce the idea of a DRUG OTHER concept (which is configured by a global property)
Introduce a DrugOrder.drugNonCoded which represents a non-coded concept or drug
only* allow this to be used in conjuction with the DRUG OTHER concept
* = Darius's proposal is to remove this constraint, so drugNonCoded and drug are mutually exclusive, but you can have concept=DRUG OTHER, or concept=AMOXICILLIN and specify drugNonCoded in either case.
Burke is (now) agreeing with this
Jonathan: need to be able to specify "perfectly normal concept with odd formulation"
It leaves us with the following types of results, based on what the user originally types:
1. Known concept [generic specified] -- "amoxicillin"
Stored as concept: amoxicillin [coded]; synonym: none (in the UI: amoxicillin)
2. Known concept / known synonym-brandname -- "Prozac" (recognized by the dictionary)
Stored as concept: fluoxetine [coded]; synonym: Prozac [coded] (in the UI: Fluoxetine [Prozac])
3. Known concept / unknown-freetext synonym -- "foocillin" (not in the dictionary, but orderer knew it was ampicillin)
If user responds to challenge with 'yes, it's really ampicillin', then store concept: ampicillin [coded]; synonym: drug.noncoded synonym-text: "foocillin" [ (in the UI: Ampicillin [Foocillin])
System needs to recognize and offer the "amoxicillin" as a concept. If accepted, then concept: amoxicillin [coded]; synonym: drug.noncoded synonym-text: "amoxicillin 520 mg capsule"
Or, you avoid this problem by requiring the user to just specify the name [not the strength] and the system returns the available drug formulations. A separate part of the UI would possibly allow the user to put in unusual strengths/forms
The actual strength and form really ought to be specified as a separate field... otherwise when you want to specify an odd strength you wind up having to specify it as an unknown drugname