I am designing a new feature to associate problems with encounters for any given patient. Here is what I have come up with so far:
-----
From a patient summary or from an encounter you can click a button to pop up a new "Problems and Encounters" window.
This window has the following components:
* The patient’s name and chart number
* A list of all problems, medications, immunizations and allergies for the patient
* A list of all encounters for the patient
* An Edit button below each of the two lists
* A Save button
* A Cancel button
Once onscreen, the window does not interact with the web server until the Save button is clicked. All of the other actions listed below are programmed with client-side JavaScript. Actions are:
* Clicking a problem highlights the associated encounters.
* Clicking an encounter highlights the associated problems.
* Clicking an Edit button invokes Edit Mode for the associated list. In this mode clicking an item highlights or un-highlights it, and the other list does not change and is disabled (will not respond to clicks).
* The Save button is enabled if any changes have been applied.
Clicking it saves the new associations and closes the window.
* The Cancel button discards any changes and closes the window.
So this would make it so you could see on what date a medication was prescribed, a diagnosis made, an immunization given, an allergy noted? Or the other way around, click on an encounter and see what of these events on the list occurred within that encounter.
I think it’s a good idea, but I don’t see how it could be done with the way that the way that problem list data is entered and encounter data is entered currently. How would you do it?
Well this window would not only be where you see what the associations are, but also the means by which you make them. That’s what “edit mode” is for. Obviously you will have to tell the system what all the encounters are for each problem, or vice versa.
It is also reasonable to add stuff into the encounter forms to support this more directly, but I was not planning to mess with that initially.
On the back end, a new table would be created and maintained that keeps track of the associations.
I think it sounds good. Sorry I took so long to answer, I have been thinking it over and over. This sort of thing leads one to question the structure of the program and then leads to crazy ideas about rewriting and restructuring OpenEMR to the point where it won’t be the same program at all anymore and that leads one to ask what makes OpenEMR a unique entity and what changes would turn it into something else entirely. I suppose that one might define a program’s identity as such that any changes will allow users to continue using their data or at least to migrate their data to the new version. One might argue that the interface should remain somewhat consistent also. That being said, it really has nothing to do with this thread. Sorry for being so long winded.
I think it’s a cool idea. Would it be possible to implement by querying existing tables without adding a new table? Either way, your idea to make a form using javascript to help visualize relationships between data quickly is a great idea.
That being said, I think that we will come to a point where the underlying structure will be changed. I’ve been thinking about the database in particular and see a need for some changes to make it more structured (3rd normal form…). I guess the sooner these changes are made the better, but that would have to include data migration scripts from the current database to the future database structure. After this next version is released (i.e. after RC1 becomes 2.7.2 or whatever the version) we should make a list of things for the next version and/or branch to a new one all together for a future release down the road three or four versions from now.
It seems that standardizing the entry of diagnoses in a particular encounter from would facilitate this matching process.
In the ankle_injury and the bronchitis forms I had a way of filling in the diagnoses using drop down boxes. Using a ICD find function, similar to what Rod created in his fee_sheet, would standardize the naming of the diagnoses. This would allow more automated integration of this function and improve the data mining capabilities.
I think a new table would be required. The only other relevant link I can think of is that of the diagnosis codes attached to the encounters, but those are chosen with billing in mind and are probably not adequate from a clinical perspective.
I think "justification" of ICD codes with CPT could be handled inside each encounter form.
A find CPT button/function for the diagnosis and then a matching find ICD button/function. This would be an easy way for practiitioners to match ICD to CPTs in a line item fashion.
This would standardize diagnosis and CPT entry and allow linking between encounters easier. There would’nt have to a separate “justification” process.
Of course, the procedures (CPTs) and the (ICDs) should be inserted into the billing function (single data entry).
Forms for encounters would then start taking advantage of the relational nature of the databases that we are using. They would also become more modular (and hopefully easier to build).
Adding the code for the fee_sheet.php to the bottom of each new form would do this nicely. (Though I would want to see the CPTs matching the ICDs so I could verify correct datta entry.)
What do you think of the notion of using ICD9 diagnoses instead of the current problem list to identify problems? As noted above, I am figuring that they would be “polluted” by billing considerations and so a separate problem list is desirable. But you’re a doctor and I’m not…
Using ICD codes would make the billing process cleaner and the tying together of encounters much easier.
ICD codes are really just a simplified subset of the full range of potential medical diagnoses. For the the life of me, I can’t always find an ICD code for the medical diagnoses that I am using. And sometimes these searches get time consuming.
An example: hypernatremia, hyponatremia, hypokalemia, hyperkalemia are all valid medical diagnoses with distinct and separate medical causes and management plans. They all are coded as: "fluid and electrolyte disorders, 276.9".
After spending the better part of an hour looking under h, n, k, sodium and potassium and other variations, my office manager told to me look under "f" (with a devilish grin on her face").
While we all strive to normalize a database as much as possible, This is a situation where some controlled denormalization may improve functionality. We could use a text field for the practitioner to enter what he/she feels is the approppriate diagnosis and then a ICD choser to fill in the closest ICD code fit in a separate field. This amounts to a 1:1 join.
The billing and the actual matching of encounters would use the ICD as the the key. The practitioner would fill in the text box to his/her delight.
While we’re on to ICD-9 codes… the search function for the ones that are already in OpnEMR sucks because the written words that go with them in here are only several letter snippets… well, sometimes.
For example, type in aller (the beginning letters of allergic). When the possible matches come up, it has some as Allergic and others abbreviated as Allerg… which means every time you do the search, you have to use aller and then look through the list…
What all this boils down to is a usability problem and I would not suggest having sometimes impatient and already computer-wary doctors looking up diagnosis codes in their current form.
The AAFP web site at http://www.aafp.org/ offers a file icd9_long.txt which is a subset of the ICD9 codes having descriptions that supposed to be more doctor-friendly.
Another solution may be to adapt the fee_sheet form and/or others to include some drop-down lists of your more commonly used ICD codes.
I’ve been thinking about this all day and I think it would be easiest on doctors of this was done through a form that looks like a superbill. I have several reasons for this; 1)They’re used to a superbill format already. Things aren’t broken just because they’re “traditional.” 2) A superbill is used for billing- and it’s also used to show clinical assistants what they should be doing for each patient. It’s a communication device.
I think the best way to do this would be to use checkboxes for CPT codes and pulldown boxes for modifiers. Then have search boxes that automatically come up as the CPT is entered so the practitioner can search for the diagnosis, select it and not have to worry about hitting “justify” eighteen million times. That’s an exageration, but you get the point. Doctors want things to be simple, clean and easy to use.
The fee_sheet was designed as a replacement for the superbill. It would be reasonable for someone to do a variation of it in the way you suggest. I.e. substituting checkboxes for the drop-downs and making other changes for the modifiers and ICD9 searches.
Perhaps the diagnosis searching can be simplified with an awareness of what works with the given CPT code. Not sure where you’d get that information though.
I don’t know if private insurance companies have a list or not, but we have a Medicare list for certain CPT codes, including ECGs, some labs, etc… I would think thath other insurance companies would fall along roughly the same lines with respect to diagnosis codes.
It’s still tentative and wide open for comments and suggestions. The new table is defined as:
CREATE TABLE problem_encounter (
list_id int(11) NOT NULL,
pid int(11) NOT NULL,
encounter int(11) NOT NULL,
resolved tinyint(1) NOT NULL, – if problem appears resolved as of this encounter
PRIMARY KEY (list_id, pid, encounter),
KEY pid_encounter (pid, encounter)
);