Child pages
  • Transcript of 27 07 2007 IRC demo

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Desmond's demo:

Code Block
	<delliott>	I'll call Darius
	<delliott>	And he can merge you guys in?
	<djazayeri>	Past demos have been done over IRC, which is kinda cool.
	<docpaul>	oh, haha.. he just called me and i thought we'd do this on irc
	<delliott>	Ok we can IRC if you like
	<docpaul>	i hung up on him
	<docpaul>	i think that makes more sense
	<djazayeri>	But we could do Skype if someone wants to say something aloud.
	<docpaul>	i'm doing two things at once
	<delliott>	Ok
	<burke>	what's this IRC thing?
	<delliott>	Hi Mum!
	<burke>	howdy
	<delliott>	So I think both Burke and Paul haven't actually seen the drug order entry tool yet
	<djazayeri>	Nobody has but Hamish and I, I think.
	<docpaul>	right
	<docpaul>	admit it to the light
	<docpaul>	:)
	<delliott>	Ok. I've put the most recent draft of it online and the previous 2 drafts so you can see where we came from
	<delliott>	But lets start with the most recent drat
	<djazayeri>	Got links?
	<delliott>	Firefox only please!
	<delliott>	Yes
	<OpenMRSBot> []
	<delliott>	The only things that are interactive-features missing are: ramp up prescriptions and order sets
	<djazayeri>	Perhaps you should tell us what drugs are supported, and what the names of some order sets are.
	<delliott>	We know exactly how we intend to do that but I spent too much time enjoying the Spanish culture this week
	<djazayeri>	'Amikacin', 'Capreomycin', 'Ethambutol', 'Gatifloxicin', 'Isoniazid', 'Kanamicin', 'Levofloxacin', 'Moxifloxacin', 'Prothionamide', 'Rifabutin', 'Sparfloxacin', 'Thiacetazon', 'Ethambutol 300', 'Ethambutol 1000'
	<delliott>	Ok so Amikacin is supported
	<djazayeri>	never mind, I'll say so. :)
	<delliott>	If you select that then you'll see a little row roll down which we want to use as a point of reference for the prescriber
	<delliott>	I don't think it works inside the table
	<docpaul>	drug search... is.. eh
	<delliott>	But I'm not sure where else it could go that would make sense
	<burke>	hehe. end date 34/6/2007. :p
	<delliott>	burke, I know about that!
	<burke>	hehe
	* OpenMRSBot	chuckles
	<djazayeri>	Why is there a default end date put in?
	<djazayeri>	(I picked Gatifloxacin)
	<delliott>	There shouldn't be
	<delliott>	I thought I remove all of those
	<djazayeri>	when I pick today as the start date it gives me 03/08/07 as the end date.
	<delliott>	If you try Ethambutol 1000 and prescribe it then that is a fixed 'problem' drug
	<docpaul>	y not take advantage of the space you have to the right of the input?
	|<--	sarpc has left freenode ()
	<djazayeri>	When I prescribe Ethambutol 1000 mg, it says End Date = Optional.
	<djazayeri>	In the top box.
	<delliott>	FFS
	<burke>	can you explain the interface?
	<delliott>	If you do a hard refresh that problem is solved (darius)
	<djazayeri>	Good idea, how about we all hit shift refresh, and delliott you can talk us through the standard use case.
	<docpaul>	a flow that has always made sense to me is to select the drug, and then have variable interfaces below based upon common uses of that drug
	<delliott>	Ok, so if we go with what Darius suggested then if you type "Ethambutol" - or use the autocomplete feature then the form is populated with 'the usual order'
	<djazayeri>	I meant take a step back and say "this page represents a patient who is currently taking Ethambutol 1000mg 3/day 5/week.
	<delliott>	I've tried to have the form autofill when you finish typing but the code is a nightmare and I'm still lookg for it
	<delliott>	Ok
	<burke>	i'm typing in the search box? and ethambutol is already listed on my screen
	<djazayeri>	(Although actually the end date is in the past.)
	<burke>	oh ok.
	<djazayeri>	Pretend you're talking to people who have never looked at this interface before. ;)
	<delliott>	Which is the case
	<burke>	describe the top
	<delliott>	Ok so the page that you are looking at would allow you to order drugs for the patient Desmond Elliott
	<delliott>	The top table is where you can see a history of the drugs that Desmond Elliott has been prescribed
	<delliott>	The gray row in that table means that Desmond was on Ethambutol but now he is not
	<burke>	so, i usually think of "regimen" as more than one drug.
	<delliott>	The "legend" lets you see that
	<burke>	are we calling each drug a regimen?
	<djazayeri>	I use that term incorrectly, because in our old system the drug_order table is called regimens.
	<burke>	with hiv care, a regimen is often a set of multiple drugs
	<docpaul>	so, details aside... the top section is a list of previous prescriptions
	<burke> "regimen" is really "drug"
	<djazayeri>	so if Desmond says regimen to refer to a single drug, blame me.
	<docpaul>	go on desmond
	<delliott>	Ok so the top part is where the prescriber can look at what the patient has been enrolled in
	<delliott>	Can I move on to the 2nd section of the page and then we can get back to thoughts about the top part later?
	<burke>	sure
	<delliott>	Ok
	<delliott>	The New Prescription section is where the physician would order a new drug or regimen (set of drugs) for Desmond
	<delliott>	I haven't implemented regimen ordering yet because time was constrained but we have spoken about how we could do it ... I digress.
	<delliott>	So Burke mentioned that he loved text driven interfaces and Darius and I agreed that using the mouse was actually inefficient for trying to prescribe a simple, common drug for a patient
	<delliott>	So when you search for a drug by name (for Amakacin, Capreoblahblah, and Ethambutol) the form will autocomplete
	<djazayeri>	Meaning that any drug in the database will have its name autocompleted?
	<delliott>	These auto filled values would let the prescriber perform a standard prescription for a standard patient very quicky
	<delliott>	djazayeri, when hooked up to the drug database then yes it would
	<djazayeri>	Or that anything with a standard prescription in the database will have everything autocompleted?
	<delliott>	djazayeri, that depends on the information stored in the database.
	<djazayeri>	ok
	<delliott>	If you type Etha and look at the autocomplete list there are 3 different 'standard' drugs
	<delliott>	These could be based on different weights of a patient, or something similar.
	<delliott>	Essentially it lets the prescriber quickly order a simple drug for a patient
	<delliott>	If you type in Amikacin then a row unrolls itself to reveal information about that drug. This is information that would be pulled from the database
	<delliott>	Unfortunately it doesn't roll back correctly everytime so you might want to hard refresh
	<OpenMRSBot>	OpenMRS Feed: OpenMRS Changesets: Changeset [2090]: main class for interacting with sync. ->
	<OpenMRSBot>	OpenMRS Feed: OpenMRS Changesets: Changeset [2091]: - Changed all the GET/SET/UPDATE/DELETE fields to an enum and applied that ? ->
	<OpenMRSBot>	OpenMRS Feed: OpenMRS Changesets: Changeset [2092]: DataDeletionModule: Deletes from OpenMRS database: Patient, Form, Obs, ? ->
	<delliott>	That 'metadata' about each drug or regimen would help form part of the data support system
	<delliott>	: s / data / decision
	<delliott>	For a rather annoying reason the start and end dates try to match up with each other but I can pull that out
	<delliott>	Hamish and Darius mentioned that you don't want to have to specify an end date for a prescription
	<delliott>	So that is how it should work. You say when you want the prescription to start and then let it run until you want it to end (I'll talk about that later)
	<delliott>	When you hit prescribe the form is cleared and that order is in an intermediate state called 'pending'
	<delliott>	It enters the Prescription History section of the page and the row is a lovely yellowish colour to help convey a change of stage in the table
	<delliott>	If a patient has many prescriptions this is more likely to be useful
	<docpaul>	burke: i finally got rmrs into mysql!!
	<burke>	docpaul, awesome.
	<delliott>	If you prescribe a drug that is in conflict with the patient's allergies or it conflicts with another drug then you are also informed of that
	<delliott>	So if you try to prescribe Ethambutol 1000 (as an autocomplete) then if enters the table is a reddish colour
	<delliott>	I haven't quite found the right way yet but you will be able to stop a prescription by clicking an appropriate per-drug button in the prescription history table
	<burke>	yeah, i'd like to be able to both stop and edit from the history
	<delliott>	We would like to be able to do that too :-)
	<burke>	many would you like them?
	<delliott>	Whichever way work
	<delliott>	s
	<burke> you have questions/comments?
	<docpaul>	you go first, i want to catch up
	<burke>	okay...
	<burke>	we already discussed using "drug" instead of "regimen" ...
	<burke>	I don't understand the frequency. what is meant by x/day, x/week?
	<delliott>	It is supposed to mean that Desmond receives Drug X 3 times/ day, 5 times/week
	|<--	crazee has left freenode (No route to host)
	<djazayeri>	That's our simplification of bid, tid, qd, etc. Should read 3 times per day, 5 days per week.
	<burke>	which days?
	<djazayeri>	put it in comments. :)
	<delliott>	I can see why you might want that level of flexibility
	<burke>	okay. so should the default x/week be 7/week?
	<djazayeri>	I think so.
	<burke>	or if I take the drug 3/day, is that 21/week?
	<djazayeri>	write it as # days/week.
	<burke>	I'm used to seeing the format: TID QD, or BID qMon, Thurs, Sat. That's way this is hard for me.
	<burke>	TID QD = three times a day each day
	<delliott>	Ok so this is where my domain knowledge really restricts me
	<burke>	BID qMon, Thurs,... = twice daily on Mon, Thurs, ...
	<delliott>	That is something that I think we can talk about so I am using the correct language
	<delliott>	As long as we can agree on some kind of standard
	<burke>	I would rather assume that all medications are daily and then provide a simple means to choose other options like "Mon - Fri" or "every other day" and the like.
	<delliott>	Ok
	<burke>	sure. the main point is x/day, x/week is ambiguous to me.
	<djazayeri>	I think it's going to be something that different implementations customize. But let's put off that discussion for a later date. :)
	<burke>	* is start date when they started taking that drug, or when the current prescription started?
	<delliott>	The start date is when you want the patient to start taking the drug
	<burke>	okay. what if they've been on it for 3 years?
	<delliott>	And they are still on it?
	<djazayeri>	i.e. if you're back-entering a prescription that just wasn't in the computer?
	<burke>	yes.
	<burke>	blood pressure medicine, for example.
	<delliott>	Then the start date will be 27/07/07 and the end date will be empty
	<burke>	no. i just entered it into openmrs 3 years ago.
	<burke>	so the start date is when the last prescription was written?
	<djazayeri>	err...I think the start date should be 27/7/04, and end date is empty
	<burke>	clinically, know how long the patient has been on the medication is more useful.
	<delliott>	Oh shit that was a typo
	<delliott>	I meant to say /04 for the year
	<burke>	ok
	<burke>	after selecting a pre-defined drug order, the form should autocomplete immediately & not wait for the user to leave the search field
	<delliott>	Yes
	<burke>	would like to (in the future) give hints to indications for various orders
	<delliott>	The autocomplete patch that I am using is shocking commented and I'm trying to find that
	<delliott>	So I can enable it
	<burke>	so, if you type metronidazole, you could see "For vaginosis..." (choice) "For C. Difficile..." (choice)
	<burke>	we don't have the data to drive that yet, but would like to evolve there.
	<delliott>	Ok. Do we need to build that into the system now?
	<burke>	just want to push the flexibility & design of the choice lists.
	<delliott>	Or is it something we could build in later?
	<docpaul>	can i make a couple of comments about the autocomplete
	<docpaul>	?
	<burke>	more immediate concern, what if there are two common ways to order a drug, one BID and the other TID?
	<docpaul>	choice lists are absolutely everything when it comes to this interface... and i don't think it a good design decision to relegate those lists to a "autocomplete-like" window underneath the box
	<burke>	i.e., I think the full order (including frequency) should show in the choice list
	<docpaul>	the choice list needs a fixed area on the interface
	<delliott>	docpaul, how would you imagine that would look?
	<docpaul>	well, as you have it designed currently, it could be to the right... i'm biased when i say i like it below, b/c that's what i'm familiar with
	<delliott>	The autocomplete search box allows you to type in what you are looking for and it will tell you what is available
	<docpaul>	dell: right, but there's going to be a large collection of choices based upon the full potential of choices
	<djazayeri>	burke: I've been assuming that the autosuggest dropdown would include:
Metronidazole (custom)
Metronidazole for vaginosis (order set)
Metronidazole for C. Difficile (order set)
	<delliott>	So if there are 7 ways to prescribe something and all 7 should be autocompletable
	<burke>	it needs to show a full order in each row, expect that headers (comments around choices will come in the future) and support paging
	<docpaul>	it's not just drugs... it's regiments
	<docpaul>	er, regimens too
	<docpaul>	whoo.... i got rmrs into dbdesigner
	* docpaul	gets a chum
	* burke	thinks too much information
	<burke>	djazayeri, interesting.
	[INFO]	ChatZilla [Firefox]
	[INFO]	Please visit the ChatZilla homepage at <> for more information.
	<burke>	can date fields support today, tomorrow, & possibly other shortcuts (e.g., thursday or t+7)?
	<delliott>	burke, they could be coerced to
	<djazayeri>	burke: you think that shouldn't just follow the calendar popup?
	<docpaul>	with synonomies and everything else though, i'm not sure you'll be able to do the autocomplete intelligently enough
	<docpaul>	you need to be able to browse a larger selection of choices
	<burke>	i suppose. it's just easier to type something than to reach over and deal with the mouse clicks...but that's not a big deal.
	<djazayeri>	larger than what?
	<burke>	if you type "amp" you could have dozens of possible matches
	<djazayeri>	yeah, so type one more letter. :)
	<djazayeri>	right?
	-->|	rachel (i=user@ has joined #openmrs
	<delliott>	If you typed in Vaginosis then we could make it show you all the drugs that could be prescribed for that condition
	<djazayeri>	(Rachel is a usability expert who's working with us at PIH. I just invited her to take a look too.)
	<delliott>	But that is decision support system and is - as stands - beyond scope
	<rachel>	*blushing*
	<delliott>	Hello rachel
	<delliott>	Thanks for coming
	<djazayeri>	here's the link:
	<OpenMRSBot> []
	<rachel>	happy to be here :)
	<delliott>	docpaul, if you could create some kind of sketch
	<delliott>	For what you mean then we could talk about it more
	<burke>	okay, "amoxicillin for pneumonia", "amoxicillin for ear infection", "amoxicillin 500 ...", "amoxicillin 857...", "amoxicillin/sulbactam for ...", "amoxicillin/clavulantes for ..."
	<delliott>	I just cannot see it so I feel like we are not in sync
	<djazayeri>	burke: when do you think you're going to have all that metadata in the system?
	<burke>	once we have a place for it, we'll get it.
	<djazayeri>	I imagine it's going to be years before we have more than say 100 different order sets in eldoret or rwanda?
	<burke>	it'll be years before our docs are ordering from a computer at the rate the infrastructure is moving in kenya
	<delliott>	docpaul, I'm interested to hear more from you!
	<djazayeri>	I have feedback too, but let's get docpaul if he's ready to talk.
	<burke>	i think the main point is to show the full order "drug, dose, frequency, etc." in the choice list
	<delliott>	burke, ok
	<burke>	docpaul is distracted. he has to build a data model for a meeting in a couple hours.
	<djazayeri>	so if the autosuggest signifies that it's going to auto-fill fields, it should tell you exactly what it's going to auto-fill?
	<delliott>	Building a system around that in terms of the meta data will be a massive massive task
	<djazayeri>	Or could that instead be a short human-written description instead?
	<burke>	yes
	<burke>	how are you storing the common orders?
	<djazayeri>	my thoughts:
	<delliott>	Brutal hack at the moment
	<djazayeri>	* Don't show completed drugs in-line with active drugs
	<djazayeri>	* Legend needs to show white/clear as "active or upcoming prescription"
	<delliott>	Would be something that we could gradually add to underlying database over time
	<djazayeri>	* "Prescription History" isn't the right label. It should say "Active drug orders"
	<djazayeri>	* Have the 'decision support' section for amikacin go out to the right, rather than down.
	<djazayeri>	* When I confirm a 'possible problem drug' it stays red. (Same color for pending-but-problematic, and prescribed-but-problematic)
	<djazayeri>	* Have a [stop] button in the far right column for each active prescription. You click it and it turns into a div/span with a field for date to stop, and a dropdown for reason to stop.
	<delliott>	Ok I can do something about all of those
	<delliott>	I am much more concerned about how we move forward on the large-scale, long-term design issues
	<djazayeri>	burke: I feel like doing "the right thing" to store common orders may take us months to agree on. But we can probably agree on the structure of metadata for a first pass quickly.
	<burke>	yeah. we are building what I hope eventually will be the "fall back" when common orders are not pre-defined
	<burke>	the main things that bother me are the frequency encoding (it's not intuitive clinically) and the lack of frequency (the full information) when I'm selecting an autocomplete order
	<burke>	and it looks like we'll only allow for very brief comments. ;o)
	<djazayeri>	* Make comments a textarea. :)
	-->|	bwolfe ( has joined #openmrs
	=-=	Mode #openmrs +o bwolfe by ChanServ
	<burke>	what about an outlet for complex orders?
	<delliott>	burke, right. So we should sit down and agree on HOW TO DO IT for the frequency encoding
	<OpenMRSBot>	[bwolfe] Crazy like a wolfe!
	<delliott>	The comments issue is on my radar
	<burke>	what about an outlet for complex orders?
	<delliott>	What is a complex order?
	<delliott>	I want to make sure we have the same understanding of the phrase
	<burke>	orders that cannot be a tapering order or warfarin that is given at 5 mg M-F and 2.5 on Sunday and 7.5 on Saturday
	<burke>	or do we want to ignore those for now?
	<djazayeri>	delliott: some background. we have a free-text field in the database to allow the doctor to write things like "give whenever the sky is blue".
	<djazayeri>	in case the order is too complex to encode, as burke says.
	<djazayeri>	Myself, I think we should ignore those for now.
	<burke>	the idea is that the text can be translate to encoded values or vice versa, depending on the system needs/capabilities as we go forward
	<delliott>	burke, do you mean that you just want to be able to write in a text field exactly what you said?
	<delliott>	And that becomes an order?
	<djazayeri>	It's pretty straightforward to add a free text field later. :)
	<burke>	agreed
	<delliott>	Ok it is straightforward but how do we represent that information
	<burke>	and after that, delliott will write a parser that will encode the free text properly anyways. ;)
	<delliott>	HAHAHA
	<delliott>	I'll write a parenthesis matcher for finite state machines while I'm at it ;-)
	<djazayeri>	CREATE TABLE `orders` (
`order_id` int(11) NOT NULL auto_increment,
`instructions` text,
	<burke>	What about putting red asterisks next to required fields like the standard convention? instead of or in addition to the "optional" background text
	<djazayeri>	(That's where we'll store it.)
	<burke>	What about putting red asterisks next to required fields like the standard convention? instead of or in addition to the "optional" background text
	<delliott>	Ok
	<delliott>	There is no validator yet
	<docpaul>	sorry... marc and maria came by
	<delliott>	Because I'll need to build one of those while writing the parser this weekend
	<burke>	also, I'm assuming I won't be able to edit the word "optional" in the future ;)
	<djazayeri>	My big question that I'd like your feedback on burke (and paul if he's around) is about whether we should make everything accessible through the one autosuggesting text box.
	<docpaul>	i dont like ausuggesting box like it is
	<djazayeri>	e.g. should there be one autosuggesting box that suggests to you both drug names and order sets?
	<docpaul>	it's a different interface model than everywhere else on the openmrs app
	<burke>	yes. docs don't care.
	<burke>	but can you define "order set"
	<djazayeri>	Let's pretend that the autosuggesting text box could be replaced by something in the same theme as the OpenmrsSearch widget.
	<docpaul>	burke, i'm a little under the gun here... can you cover this? :)
	<burke>	yes
	<docpaul>	ok, go on darius
	<djazayeri>	Or done as an autosuggesting text box, pending a later decision.
	<djazayeri>	But how do you feel about having a single box where the user types either the name of a drug or of an order set.
	<burke>	define order set
	<djazayeri>	order set = one or more drugs + some auto-fill information.
	<docpaul>	darius: that's how it should work... what desmond is working on now should evolve to a generic order interface
	<docpaul>	and orders often time are drugs + a level check for example
	<docpaul>	having just a pure drug order interface isn't how most CPOE apps work
	<djazayeri>	ah, sorry, i've been completely ignoring anything but drug orders.
	<delliott>	I do what Darius does!
	<docpaul>	but it's a good start
	<docpaul>	design to be generic, but start at something specific so that you dont get overwhelmed in your design
	<docpaul>	start with drugs, but assume it'll ultimately be more than drugs
	<delliott>	That is what we are trying to do
	<delliott>	Design for 80% this summer
	<delliott>	And then painstakingly do the other 20&
	<burke>	my definitions are subtly different...
	<burke>	template = auto-fill text
	<docpaul>	so yes, order sets and drugs would be viewable from the same search box
	<burke>	order set = a set of orders +/- auto-fill text directed to a specific indication or ordering pattern (e.g., diabetic drug menu)
	<docpaul>	if i want to do "infant sepsis antibiotics", i'd like it to help me with orders for ampicillin and cefotaxime
	<burke>	If I represent a template for the most common way to prescribe ampcillin, I don't think of that as an order set.
	<docpaul>	yea, burke and i are thinking of order sets in the same way
	<burke>	just because you've defined a common template for an order doesn't make a set. a set is 1..n drugs that fit a particular indication or workflow
	<burke>	does that make sense djazayeri ?
	<djazayeri>	skimming it, it doesn't make sense.
	<burke>	the history come from paper
	<delliott>	So a set is 1 or more drugs
	<burke>	docs would write individual orders in the chart
	<burke>	but then they'd make "order set" pages pre-filled for ease of use
	<burke>	e.g., a "sepsi workup" order set would be a page filled with common orders for that indication
	<djazayeri>	Okay, but shouldn't we start off with simpler order sets like:
	<docpaul>	darius: the phrase "order sets" implies that other things outside of drugs could be ordered
	<burke>	s/sepsi/sepsis
	<docpaul>	it's a set of orders
	<djazayeri>	"Standard Adult TB treatment"
	<burke>	sure
	<burke>	but there may be "templates" for isoniazid
	<burke>	the auto-fill stuff
	<djazayeri>	So you could have an "order set" that says Isoniazid and has some auto-fill info, but not enough to fill all required fields?
	<burke>	a "template" could i suppose be full or partial
	<delliott>	I just want to make sure that everybody is onboard with the fact that I will not finish this before the end of the summer.
	<djazayeri>	Ah, ok.
	<burke>	within an order set you could optionally just refer to the drug (and force the user to fill in everything) or supply a template specific to that order set
	<delliott>	I suspect that it will not be anywhere near complete - in terms of what we are talking about right now
	<djazayeri>	Just caught up. So you mean "Order Set" to be a menu of things where the doc selects one, many, or all.
	<burke>	but you might also want to provide templates that are not within order sets
	<djazayeri>	Could a template include multiple drugs?
	<docpaul>	des: this is not as complicated as it seems here
	<burke>	e.g., the top two common ways to order isoniazid
	<docpaul>	your work will be a subset of this
	<docpaul>	darius will be doing some of this code as well
	<burke>	it's more semantics at the moment
	<djazayeri>	I'm happy to start using "template" to refer to what I've been calling "order sets"
	<burke>	so, yes, we would want to show order sets, orders, and order templates in the choice list
	<burke>	a template just provides the auto-fill into
	<djazayeri>	If we can agree that the most important thing for this summer is to implement order templates, and custom ordering where you specify the drug.
	<burke>	s/into/info/
	<burke>	yes, define custom. are you referring to just naming the drug and letting the user define the rest manually?
	<djazayeri>	Okay, but I want a way for the user to say "Standard Malawi Adult HIV Regimen" and have that create orders for 3 differnt drugs.
	<burke>	sure. if you have templates defined for each one in the order set.
	<djazayeri>	custom = more or less what des is showing here. Not the single free-text box.
	<burke>	but we may also want to let users edit the list
	<burke>	we've found it very powerful to show the order set to the user and have the ability to control the initial state of each item (whether it will be ordered or not)
	<djazayeri>	That makes sense.
	<burke>	that let's us suggest things in an order set without actually ordering them unless the user intervenes
	<djazayeri>	I think that 95% of the functionality in the next 6 months, though, is prescribing standard HIV and TB regimens.
	<djazayeri>	But we should think about how to have the different elements of an order set be only suggestions, you're right.
	<burke>	so, you select "Standard Malawi Adult HIV Regimen" and then see those orders and either accept them or decide that the 2nd one in the list is unnecessary and delete it before taking the other two
	<burke>	in truth, order sets become much more useful this way
	<djazayeri>	Hamish says "It's unlikely that people would prescribe anything more complex than drug-resistant TB treatment with 7-9 drugs in a developing country"
	<burke>	b/c it's often unsafe to default to ordering something that the computer is suggesting
	<burke>	our HIV patients have other problems, so they may be on blood pressure medicines, diabetes meds, etc.
	<djazayeri>	I think that clicking on "standard HIV regimen" should pre-fill 3 boxes that you then can tweak if you want and click on.
	<djazayeri>	Agree, but you don't need to do all that in the EMR with order sets now.
	<djazayeri>	Hamish: "Diabetes meds wouldn't be in the same order set as HIV treatment"
	<djazayeri>	(this would be easier via voice, no?)
	<burke>	it's just a matter of when the doc asks for that "order set" sheet you auto-dump it into the list of active orders and make them cross things out or you let them check the boxes of what they want from the order set (some boxes pre-checked)
	<burke>	yes.
	<delliott>	Just going to nip to the toilet
	<burke>	i've got to run soon anyway
	<djazayeri>	ok
	<djazayeri>	let me try to sketch something...
	<djazayeri>	burke, i just sent you a static html file.
	<djazayeri>	actually, nm, outlook seems to be crashing, hold on.
	<djazayeri>	okay, sent.
	<djazayeri>	in the text box, type "ethio" and pick the one that says "Ethionamide Ramp to 750mg"
	<djazayeri>	This pops up 3 step doses that you need to click "Add" on individually.
	<djazayeri>	Is that more or less what you're describing?
	<djazayeri>	(ignore that this is an incomplete mockup from our old system)
	<burke>	i get the list, but nothing popups up when i select the first option
	<djazayeri>	sorry, refresh the page and try this:
	<djazayeri>	put in a start date.
	<djazayeri>	27 jul 2007
	<djazayeri>	then in "product" type ethio
	<djazayeri>	then press Enter
	<djazayeri>	then (with the ramp thing highlighted) press Enter again.
	<burke>	oh. enter.
	<djazayeri>	yeah, ignore that, I never finished this page from years ago. :)
	|<--	ruddzw has left freenode ()
	<burke>	yeah. for more complicated orders this is a decent approach. for order sets I'm use to a bit more compact display
	<burke>	but this is nice
	<djazayeri>	so perhaps if the template for the drug is "complete" then it pops up as a single line description, and you'd have to click something to edit it.
	<burke>	it's just a lot more fields & drop-downs than I'm used to.
	<djazayeri>	And if and if the template is "incomplete" then we show all those boxes?
	<burke>	I supposed I'm spoiled.
	<djazayeri>	or you mean you'd prefer a text box that understands your every desire?
	<burke>	yeah. :p
	<burke>	I would use the templates to pre-fill the fields. template or not, it's better to have the interface predictable
	<burke>	so people can habituate to it
	<djazayeri>	Agree.
	<djazayeri>	okay, i've gotta run too.
	<burke>	I guess I'd rather see a much shorter version of the order displayed
	<burke>	with an edit button that expanded to the encoded fields
	<djazayeri>	okay, i like that idea a lot.
	<burke>	and maybe some tricks like you've started with the search box for openmrs, where you see shortcuts as you use the dumbed down dropdowns and can evolve to typing short cuts
	<burke>	like "1am 2pm" as a shortcut for 1 in morning and 2 and at night
	<burke>	anyway...gotta go.
	<djazayeri>	ok, thanks for the feedback.
	<delliott>	thanks for the feedback!
	<burke>	this is helpful and I'm sure we'll all like it by the 50th iteration. :p
	<delliott>	Very very useful
	<burke>	that you, delliott
	<djazayeri>	ah, ok, you're back. :)
	<burke>	thank you, delliott (is what I meant to say)
	<delliott>	I actually translated it itnernally as thank you
	<delliott>	This parser is going to be a breeze
	<burke>	ok...back to other work...thanks guys...looking forward to the next iteration... :)
	<djazayeri>	delliott: I just emailed you the file I sent to burke, so you can follow the text.