bradymiller wrote on Friday, January 22, 2010:
Rod,
thanks for doing that. i couldn’t create a message even with a simple GLOBALS variable on the forum last night.
-brady
tmccormi wrote on Friday, January 22, 2010:
Per other emails:
1) This is a Tony issue. It’s time for him to put SF stuff into the SVN (your files erase all the gui refactoring stuff).
Indeed and I will sync of the SF tip and the SVN CCHIT Trunk tonight so Thomas can refresh his branch and give me targeted patches for inclusion.
sunsetsystems wrote on Sunday, January 24, 2010:
I have checked in tentative/initial support for an “Order/Results Catalog”. See this tracker item for details:
https://sourceforge.net/tracker/?func=detail&aid=2938833&group_id=60081&atid=1245239
Comments please!
bradymiller wrote on Sunday, January 24, 2010:
hey,
looks good on quick testing.
-need to place openemr/interface/orders/types.php ‘Add Top Level’ string within xl()
-nneed to place openemr/interface/orders/types_ajax.php ‘Edit’ and ‘Add’ strings within xl()
-brady
sunsetsystems wrote on Monday, January 25, 2010:
Thanks Brady, I’ll fix those in the first round of changes after a bit more feedback.
sunsetsystems wrote on Tuesday, January 26, 2010:
I’d like to add another column to the procedure_type table, to contain codes for follow-up services that are suggested for a corresponding abnormal result (if that is applicable). Any objection?
Also can anyone suggest a more comprehensive set of starting values for any or all of the associated lists? See http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/sql/3_2_0-to-3_3_0_upgrade.sql?revision=1.7&view=markup for the set as of this writing, lines 63-117.
anonymous wrote on Wednesday, January 27, 2010:
Hi Rod,
Diane and I have reviewed your screenshots. Here are our suggestions:
1. Add CPT field to procedure_order table. This is needed for billing and CMS quality reporting.
CREATE TABLE procedure_order (
`procedure_order_id` bigint(20) NOT NULL AUTO_INCREMENT,
`procedure_type_id` bigint(20) NOT NULL COMMENT ‘references procedure_type.procedure_type_id’,
`cpt`
`lab_id` bigint(20) NOT NULL DEFAULT 0 COMMENT ‘references users.id, 0 means default to procedure_type.lab_id’,
`provider_id` bigint(20) NOT NULL DEFAULT 0 COMMENT ‘references users.id’,
`patient_id` bigint(20) NOT NULL COMMENT ‘references patient_data.pid’,
`encounter_id` bigint(20) NOT NULL DEFAULT 0 COMMENT ‘references form_encounter.encounter’,
`date_collected` datetime DEFAULT NULL COMMENT ‘time specimen collected’,
`date_ordered` date DEFAULT NULL,
`order_priority` varchar(31) NOT NULL DEFAULT ‘’,
`patient_instructions` text NOT NULL DEFAULT ‘’,
`order_status` varchar(31) NOT NULL DEFAULT ‘’ COMMENT ‘pending,routed,complete,canceled’,
PRIMARY KEY (`procedure_order_id`)
) ENGINE=MyISAM;
In OpenEMR, I think CPT is consisted of two fields: code and code type.
2. Enhance the display of results as in the example report below:
http://www.thebody.com/content/art14480.html
sunsetsystems wrote on Wednesday, January 27, 2010:
Hi Thomas,
Note that the procedure_order table references the procedure_type table, which in turn contains procedure_code which is the code identifying the procedure. I understand that might very well be a CPT code. Do you want a separate CPT field also, and if so, don’t you think it can go into the procedure_type table instead of procedure_order (note that procedure_type will serve as a template for orders and results)?
Regarding (2), what exactly are you asking me to enhance? As of yet I’ve only presented table definitions and the order/results catalog GUI, not a display of results.
anonymous wrote on Wednesday, January 27, 2010:
Hi Rod,
Putting CPT in procedure_type table is good. I’m trying to remember what we have discussed about procedure_code. Isn’t it the code from Labcorp or Quest? If so, then we would need a separate code for CPT.
For (2), screenshot #3 appears to be the results page, but it’s not. So ignore the comment. The main thing Diane pointed out was to include the reference range when displaying results.
What about using a dropdown to select the different labs (Labcorp, Quest, etc.) and procedure types (imaging, lab, referral, etc.)? Sorting maybe easier if you do it this way.
sunsetsystems wrote on Wednesday, January 27, 2010:
Hi Thomas, as I recall procedure_type.procedure_code was to be the lab-specific order code, and I think Diane mentioned it was commonly a cpt code - I might be wrong about that. There was also talk of a loinc code but that didn’t get very far.
Anyway, how about this: add a field for the “industry standard” code, whatever that might mean (might be loinc or cpt or something else), and keep procedure_code as whatever the lab uses. How does that sound?
Lab and procedure type are already dropdowns. You can go to the 3.3 demo at openmedsoftware.org to play with it.
whimmel wrote on Wednesday, January 27, 2010:
From what I can tell in the compendiums we’ve seen from three different laboratories (Quest, LabCorp and Lifepoint/Axiom) is that there isn’t a industry standard ordering code. At least not in the data they’ve given us. Our approach is to use the codes table to store each lab’s ordering codes and grouping mechanism and present that after the user has chosen the destination for the order.
You can go to https://labs2.phyauraemr.com/ to try it out. You’ll find the order interface with the other encounter forms.
We’ll be posting this soon to our branch but it’s been a bit of work to tease it out of our fork of the code so we can bring it up to date with OpenEMR. We’re a bit behind even though our version number is artificially higher.
tmccormi wrote on Wednesday, January 27, 2010:
I have started the requirements and desing now, I have posted them on the wiki:
http://www.openmedsoftware.org/wiki/Computer_Physician_Order_Entry#Proposed_Solution
And included them here with questions for discussion
Basic Requirements
1. CPOE Order interface should be launch able from various contexts (base, active patient, active encounter). The context should pass as much information as possible and appropriate to prefill the Order will the common fields
2. CPOE Order Interface should only contain fields that are common to all order type.
3. CPOE shall have a specific API standard for calling the order type panels and shall include a framework for plugging in new order types (similar to the forms model).
4. Previously entered orders (and their state) shall be visible from a general - All Orders report that has click thru to the order and in patient context as a collapsible view (like the notes in the new UI)
5. CPOE Order interface shall an authorization routing model based on users role from gacl
6. Order results from CPOE are displayed as messages and authorization, visibility and action is based on user role in gacl
Questions:
1. Should orders initiated from the Active Encounter context be visible within the List Encounter panel, Authorizations pages and perhaps the Billing Report module?
2. Should things waiting to be authorized appear in the ‘senders’ message area until they have been?
3. Should the Orders report be down loadable as CSV?
4. How will billing for orders be handled, ie: does excuting an order create a charge record, how will the service codes, fees be mapped?
whimmel wrote on Thursday, January 28, 2010:
I love it. Most of us are asked to work on private branches for possible inclusion after review. However, Rod gets to check in his order form directly to CVS before Tony even posts requirements and *questions for discussion* regarding that very form’s design? I’m told that I should share my code and discuss designs openly and then…oh by the way, I modified all these files in the tip. And I *know* you guys know we’re nearly done.
I realize that this project suffers from a major case of “not invented here” syndrome and some developers are in a hurry to beat us to the punch for some reason. Perhaps those reasons are above my pay grade.
I opened up our demo prior to my last message and after a quick look at the logs at least 5 IPs from the US have visited (and spent several minutes) but not a peep here on the forums. Seriously? There’s no feedback for us? No questions? I assume there’s just a bunch of angry email flurrying about though.
sunsetsystems wrote on Thursday, January 28, 2010:
Bill, I’ve been committing stuff to SF for the past 5 years and most folks have been happy about that. This particular item (handling non-electronic lab orders and results) is needed independently of the certification project, though I am working with that group so it fits in with their work also.
I encourage them to comment regarding your demo and methods for electronic interfacing, though you guys have held onto it pretty closely until now.
sunsetsystems wrote on Thursday, January 28, 2010:
Regarding Tony’s proposed requirements:
The tables that we developed call for an order to be associated with an encounter. Of course we might plug in an encounter ID of 0 to indicate no association, but is that desirable? Note that any related billing must absolutely be tied to an encounter.
By “order type panel” are you referring to the GUI for maintaining procedure and result types? I do envision that it can be desirable to add new types in the course of placing an order. So my thinking is to enhance this for use as the order type selector when placing an order, in addition to its current functionality of maintaining the types.
I don’t know what a “framework for plugging in new order types” would look like. My style would be to JavaScript the thing to adapt its look according to the order type, but I’m very receptive to other ideas.
Regarding a couple your questions:
(1) If the ordering interface is effectively an encounter form (as in the Phyaura model) then it can be indicated just like other encounter forms in the clinical view of the encounters list.
(4) Automatically creating a charge line item sounds like a nice optional feature. For example some information could be added to the procedure type entry for that.
Finally, I will probably have to write some code for non-electronic order entry and results to meet my client deadlines before we have everything sorted out. This may end up being throw-away code and I’ll keep it out of CVS to the degree we are in limbo, but I hope most of it will be useful.
whimmel wrote on Thursday, January 28, 2010:
Rod, I appreciate your experience and devotion to this project. But if you are developing and committing code specific to your client’s needs perhaps it needs to stay out of the tree until other affected team members have been given a chance to comment on it. Especially when it potentially affects things we’ve already done. Phyaura may no longer be considered the official group developing an ordering interface, according to the wiki, but we have done a considerable amount of work. It feels like my toes have been stepped upon.
As several of you will soon find out, connecting to the laboratories requires various non-disclosure agreements and each has its own specific procedure with frequent communication over the steps. While we’ve had to keep our code separate until now, it hasn’t been a secret that we were doing this.
Regarding (1) in our implementation we allow for both orders on paper (both pre- and post-implementation for a given practice) and allow for orders and results to be stored with or without an encounter number. For instance, if a practice has several lab orders outstanding and then turns on the electronic interface, the lab may choose to result those labs electronically. In this situation the EMR doesn’t have an encounter or an order number. Many times the patient ID won’t match up either, so we are completing a mechanism for the user to hook up these “unmatched” orders.
(2) I’m not sure about other types of orders, but in the case of the labs they often want to see CPT and ICD codes in various HL7 segments. Our form will check and see if coding has been done (among other things) before it can be submitted. The user is given the option to save the order without submitting it. These “saved” orders also appear on a separate screen so they can be submitted after coding is completed.
sunsetsystems wrote on Thursday, January 28, 2010:
The procedure/results type maintenance code is not client-specific, it is a partial implementation of support for a table that was designed in cooperation with members of the certification team. I’ve already said that I’ll hold off on any commits of client-specific parts of this until it can be considered generally useful. The code already in will be improved or replaced as things progress - it’s a starting point.
Bill, I think that any lack of consideration for your work has been directly related to non-availability of the code. If it is subject to NDA then it is not suitable for the project anyway. Do you have GPL code for us to look at, and if so will you be offended if we use parts of it and not other parts?
tmccormi wrote on Thursday, January 28, 2010:
Guys,
It’s very difficult to use this thread for design discussion if you mix it up with politics. I’m going to take Rod’s design comment and put them on the wiki talk page for CPOE.
Bill I did look at your demo and it looked fine for lab orders, in general. What I am trying to build it the overall order entry model. If we do this right and if the order type panels (id: lab, Rx, Diagnositic) are implemented to as components, then the CPOE order screen should be able to call order modules developed by anyone. This is, granted, a step beyond strict Meaningful use. And is part of the UI rework to create work flows instead of ad-hoc jumping around to accomplish things. Phyaura took took long to share any design or coding and you are now feeling the pain of being 2 releases back (it looks like). MI2 had the same issue in the beginning, there is plenty of work we did that is now deprecated because we did get it into the project early on in smallish pieces.
Tony
tmccormi wrote on Thursday, January 28, 2010:
My comment regarding the design are on the wiki at
http://www.openmedsoftware.org/wiki/Talk:Computer_Physician_Order_Entry#Rod.27s_Comments_from_SF_forum Here.
-Tony
whimmel wrote on Thursday, January 28, 2010:
Once I get our code submitted it will give some context to what we tried to accomplish with our design. The UI cues may be geared towards labs at the moment but there’s no reason why it couldn’t be used to order anything else.
I think the reason why we’ve taken so long to share this, at least from the community’s point of view, is because we started working from the ground, up (“How do we connect to a lab?”) instead of the top, down (“How do we make an order for X?”). Our ordering form really has only begun to take shape recently even though we’ve been setting up VPNs and doing connectivity tests with the labs for quite some time.
I’ll get back to bringing our code up to date so that I may share it with you and finally discuss the merits of our design properly.