Talk:Computer Physician Order Entry

Rod's Comments from SF forum

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.

• I think we need to separate the term 'encounter' and it's data storage from the concept of a patient visit. There are plenty of cases where a clinic might need to place and order or sell a product/service that is not related to a specific visit. Internally, a record, could be added to the encounter tables to create place to hang the order and charges from, that's not a problem.

By "order type panel" are you referring to the GUI for maintaining procedure and result types?

• In this case I'm referring to the code that implements a particular Order Type, such as Quest-Lab, Prescription, Diagnostic, Referral, etc... each of this has unique characteristics and should extend the Orders.class. A well defined interface and "contract" with the develops on what needs to be passed in an out and methods exist for using the extended class is needed.

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.

• Yes, that is desirable, but the type needs to be related to a 'form' for that type.

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

• That's just GUI sugar and we need to do that, of course. But what I'm talking about is the something very similar to what we do for forms. A developer can create a new order-type form and make it available to the CPOE panel. This could work in the old style, ie: drop a set of pre-defined .php scripts (neworder, editorder...) into a predefined dir structure and turn the on in an admin tool. OR it could be model after the form layout tools with the ability to define the hooks (scripts) that need to be called for communication to vendors of those services.

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.

• I think this is solved by creating an encounter table entry even if it's not specifically a visit context encounter.

(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.

• Providing the ability to cross reference the order with the charge/fee sheet is a must to me, but it would, of course, be easy to not configure any service codes or charges, therefore making it optional.