Procedure_type / configuration

OpenEMR Development
1

mdsupport wrote on Thursday, July 18, 2013:

Couple of observations about procedure_type table that could turn out to be major future problems:

  1. Real ‘primary key’ for this table is procedure_type (the column within table of same name!), lab and proc code. A quick review of the code shows the access is not always enforced in that manner. A quick example would be to load identical compendium orders files in same container but different vendors.
  • More important issue is current table implements parent->child relationship in a single table. This by definition precludes child record with multiple parents. We can see situations where we would want to define multiple panels containing same individual orders.
  • This design will also make it complicated to define aliases for vendors specific codes. Aliasing will be key in presenting trends based on results from various vendors.

Usually table(s) describing parent-child relationship(s) specific values handles these situations. However with current code base, incorporating any changes is big effort. At the same time, future development using current structure will make it even harder to make the changes…

Has anyone implemented classes to make future changes bit easier? Any thoughts?

2

sunsetsystems wrote on Thursday, July 18, 2013:

Not sure I understand #1. Primary key for this table is procedure_type_id, no?

Yes the table effectively supports a tree structure. Other ideas are welcomed, the more specific the better!

Rod
http://www.sunsetsystems.com/

3

mdsupport wrote on Thursday, July 18, 2013:

procedure_type_id is the primary key from db perspective. From business logic perspective specific to the labs, isn’t the ‘ord’(proc_type) record supposed to reflect (e.g.)TEST-1 (procedure_code) of vendor-1 (mapped to lab-id)? Otherwise when two vendors have assigned numeric sequential codes and some user decides to put them under a single group called ‘Labs’, they will have data issues.

Current setup does and will support trees but cannot enforce referential integrity by itself. This would not be much of a problem (except #3 above), if there is a single vendor. But as it starts accepting data from others, we have to keep their data in a separate table. A relatively simple (conceptual) fix would be :

New table ‘compendium’

  • id
  • vendor_id - 0/null = config or key from proc_vendor
  • type - grp, ord, res, alias, xyz…
  • code
  • description
  • other values as needed/provided by vendors

change proc_type table to mean

  • id (a meaningless key)
  • parent = compendium.id
  • proc_type_id = another compendium.id
  • other values ‘owned’ by this package

Now user can construct any and all of following structures:

  1. Vendor catalog(s) - could be default
  2. Top 20 tests
  3. Lab choices for a specific test
  4. Test Panels

You would also easily enforce relationship rules such as :
tree : (grp,’’), (grp,grp), (grp,ord)
orders : (ord,’’), (ord,res), (ord,qry)
panels : (ord,ord)
questions : (qry,’’), (qry,ans)
answers : (ans,’’), (ans,val)
results : (res,’’), (res,val)
values : (val,’’)
alias : (same types)

From our experience with other situations, there are gui challenges in guiding users with complicated structures. But most of these structures are relatively simple to implement.