sunsetsystems wrote on Friday, January 29, 2010:
Thanks Tony, your responses on the wiki are very helpful. Good idea to go object-oriented - I presume that’s just for the back end. When you have some sort of initial class declaration figured out, let me know. In the meantime I’ll be writing some code with the expectation of rearranging it later and then sharing it with the group.
anonymous wrote on Friday, January 29, 2010:
Please consider the use of a “procedure panel”. This is a pre-configured group of orders commonly placed together.
For example, the following orders can be grouped as a “female physical exam” order:
1. Blood tests
2. Urinalysis
3. Pap smear
Likewise, we need to link CPT Category II codes to their corresponding straight codes for CMS Quality Reporting use:
1. 77057 SCREENING MAMMOGRAPHY BILATERAL - Straight code
2. 3014F SCREENING MAMMOGRAPHY RESULTS DOC&REV - Category II, not billable
When you order a mammography screening, you would always include the corresponding results documentation and review. Category II codes are not billable, but they allow the provider to receive many types of incentive payments from CMS.
sunsetsystems wrote on Saturday, January 30, 2010:
OK listen up. You all need to understand this.
The procedure_type table and the code I wrote to maintain it support an arbitrary amount of categorization/nesting. Each item can be a category name, an order type, a result type, or any sub-component of any of these. Each can independently be flagged as orderable or as a discrete result. Order types could be repeated in different parts of the tree.
So it is easy to create some sub-category that groups order types that are often placed together. I suggest playing with Miscellaneous->Order Catalog in the development demo to see how it looks.
sunsetsystems wrote on Saturday, January 30, 2010:
Now, how many different code types do we need to support in an order? Lab-specific + CPT4 + Category II? Less? More?
anonymous wrote on Saturday, January 30, 2010:
We need a mapping of CPT codes (straight or Category II) to the procedures (lab, imaging, referral). This way, we know which one is billable versus which one is used for CMS/PQRI reporting only.
So add these two fields to procedure_type table:
`code` varchar(10) NOT NULL default ,
`code_type` tinyint(2) default NULL,
We also need a new table field to link commonly placed procedures as a panel:
`procedure_panel` varchar(31) NOT NULL DEFAULT COMMENT ‘physical exam, lipid panel, Mammography+Assessment, …’,
How do we code the panel? Maybe Tony can help answer this question.
sunsetsystems wrote on Saturday, January 30, 2010:
Thomas, read my posting #18 again. Your procedure panel link is the existing column “parent”. Any reason that won’t work?
I will add this field to support CPT or Category II and possibly others:
standard_code varchar(255) NOT NULL DEFAULT ‘’
This can be filled with the existing code selector widget, and so will incorporate the code type as well as the code (e.g. “CPT4:12345”).
OK?
anonymous wrote on Saturday, January 30, 2010:
Thanks for sending me the updated table. Now I can see "parent’. Yes, it can be used to group the commonly used procedures.
As for standard_code varchar(255) NOT NULL DEFAULT ", we will use it as follows:
CPT2:12345 - Straight CPT code
CPT42:1111F - Category II CPT code
We will need to address billing.
anonymous wrote on Saturday, January 30, 2010:
Correction:
CPT4:12345 - Straight CPT code
CPT42:1111F - Category II CPT code
tmccormi wrote on Sunday, January 31, 2010:
That looks like a total kludge, in my opinion.
What is the long term reason for the CPT4: magic coding, why isn’t this just a separate type field, the colon separator makes it a new field regardless. Is the effort to modify the widget to use a new column name instead of a split function that difficult? Is the logic scattered all over the code or is a standard function call? It should be.
CPT5 has been out for years now, by the way.
-Tony
sunsetsystems wrote on Sunday, January 31, 2010:
I suggested that because it’s what the code selector widget currently supports. It does that in order to handle the possibility of multiple codes (e.g. “CPT4:12345;CPT42:1111F”). You can call it a kludge, but it happens to one that is simple and works.
The alternative is to define an additional table that has columns for code type, code and procedure type ID. And you’d have to do that for each table that might reference multiple codes. I understand the academic point of view and am open to just about anything, but is there a *practical* payoff for doing this?
tmccormi wrote on Monday, February 01, 2010:
That was the question I was asking. What was the practical payoff of doing it the way you have done it? And what are the risks associated with changing it? It does look kludgy to anyone looking from outside in. No offense was intended. Is the multiple codes feature documented anywhere? Is the code selector widget just used by the Fee Sheet tool at this time?
I’m not suggesting we change it necessarily, just trying to understand the structure better as we add complexity.
-Tony
sunsetsystems wrote on Monday, February 01, 2010:
No, the widget is seeing a lot of use already:
interface/drugs/add_edit_drug.php
interface/forms/LBF/new.php
interface/super/edit_list.php
interface/orders/types_edit.php
interface/patient_file/encounter/superbill_custom_full.php
interface/patient_file/summary/add_edit_issue.php
interface/patient_file/transaction/add_transaction.php
There is no special user documentation for it that I’m aware of, as it is reasonably intuitive.
sunsetsystems wrote on Friday, February 05, 2010:
This is to mention that I’ve checked in the tables that we have discussed related to procedure orders and results, as well as some associated lists.
M sql/3_2_0-to-3_3_0_upgrade.sql
M sql/database.sql
Some of the lists will need to be refined as we figure things out.