Workflow Notes/Opinoin Gathering

saikensf wrote on Tuesday, June 22, 2010:

This is kind of an open topic on the workflow through OpenEMR with regards to CCHIT certification and ease of training/using for users new and old.

Starting with the mini-topic … record deletion. 

Right now delete links on clinical forms are wrapped in a check for administrator access.  Arguably, they should not be permitted for any level of access because HIPPA data retention requirements demand that all medical records be retained for 6 years.  Enabling a person to do this raises the question of shenanigans.  We could not, for example, be sure that all relevant information was being turned over if requested by a court of law.

An automated process could remove patients from the system that had registered no activity for 6 years without raising the question that it was removing data for any other motive.

Thoughts?
Impacts on folks not subject to HIPPA legislation?

bradymiller wrote on Tuesday, June 22, 2010:

But an admin could also simply drop data directly from the database.

tmccormi wrote on Tuesday, June 22, 2010:

The ‘Delete’ feature does not actually delete the records.  It moves them from the normal location to the ‘audil log’ entirely.  I submitted a contrib utility the will completely restore the ‘deleted’ records back into their normal tables and forms.  So it’s not as bad as you think it is.   There could be better ways and Brady is correct, the only thing removing the delete feature does is forces the db admin to do legit cleanup using tools that don’t log that fact.

Plenty of times duplicate patient demographics could be entered and then discovered and need to be deleted as it is not a medical record, just a  user error, typo.

-Tony

saikensf wrote on Tuesday, June 22, 2010:

In a remote hosting situation … the admin still could drop tables/rows.  But the admin has no potential conflict of interest and greater skill so is far less likely to.  Well, remote hosting with internal sql admin removed, which is why we are going to do that and my ears perked up when it was mentioned on the call. 

It is a different way to look at the program when you think of it in terms of software as a service rather than as something you configure and release.  When you do subscription based hosting you become responsible for compliance to HIPPA directives like the 6 year retention mandate.  You can’t pass the buck on to the physicians.

Although the delete flags are a comfort.  The window that pops up with dire warning about how this step can not be reversed led me to assume it was a physical rather than logical delete.  And when one assumes … That will let us fold it into versioning a lot easier.

Although with regards to demographic, CCHIT wants versioning of it.  At Healthtrans we interpreted this requirement to include the typos. 

AM 02.02 Manage patient demographics The system shall provide the ability to maintain and make available historic information for demographic data including prior names, addresses, phone numbers and email addresses.

This did take us to ridiculous lengths admittedly, one guy with dual coverage had over 3,000 demographic records … because in one system he had a middle initial and in the other he didn’t so their uploads kept overwriting each other.  But the average joe had less than a dozen.

drbowen wrote on Tuesday, June 22, 2010:

I don’t particularly like having a “delete” feature but am fine with having a logical delete to remove really egregious errors.  For HIPAA compliance these “deletions” should be accompanied by an explanatory comment as to why the change is being made.  Common reasons include the currents “lists” allow the user to add medications to the “Problem List”, “Allergies,” and “surgeries”. This feature would likely be less error prone if there were separate buttons to open the appropriate item type.  Currently, if your forget to change the type the items ends up on the default problem list. 

Another common problem is entering medical information into the wrong patients chart.  It would a little nicer, instead of “delete,” if you could change the pid of the misplaced information to the correct patient pid.  Again this type of change needs to appear in the HIPAA audit log with an explanatory comment.  I like the fact that Tony’s “delete” method is only a logical deletion but the change needs to be documented in the HIPAA log as to why the change is being made.

In the old paper charts it was necessary to make “deletions” by making a single strike-through so that the medical information was still legible.  This had to be signed by the person making the change with the date and time of the change.    The electronic analogy is to make the misplaced data change to the correct chart pid and log the change.  In the case of just really egregious errors, just make them not visible, without a true deletion but log the reason in the HIPAA log.  In the case of patient requested corrections, it is doubly important to make sure the information is still available, because sometimes the patient is making this request for secondary gain.

This is why the phpMyAdmin needs to go.  It makes it far to easy for inappropriate changes to be made without controls and without appropriate logging.

Sam Bowen, MD
http://openmedsoftware.org

tmccormi wrote on Tuesday, June 22, 2010:

PhpMyAdmin should not be used to make those kind so changes you talk about, ever.  ON the we agree.  PhyMyAdmin, however, it not the culprit just a tool.  Removing it from “inside” OpenEMR does not change the fact that anyone admin right to the system can login and do the same operation using the mysql command binary, a peri program with DB access.

The designated OpenEMR administration rights should just not be given to anyone that does not need them, period.

Adding a super-admin level that is allowed phpMyadmin rights to the ACL by default while keeping "normal’ admin rights for things like list additions but not PhyMyAdmin would be a good thing, however.

saikensf wrote on Wednesday, June 23, 2010:

Tony,

In a software as a service setup it does have a real effect.  I am belatedly realizing that this is very foreign to the ethos of open source but lets have a go at it.  The arguments above …

1 - For local installs it is trivial for a knowledgable user to get around the lack of phpMyAdmin. 

This is the situation where we don’t care.  Local install means its their neck.  If they use it to subvert versioning or data retention controls they are committing the crime.  Not us.  Meanwhile, the fact that they knew how to get in is a good indication that they know enough not to mess things up accidentally.  And if they do they can either fix it themselves or contract help.  So its no liability and slight chance of revenue.  Let em at it.

2 - Only Admins have access to phpMyadmin.

Admin access is pretty broad, no?  There are cases where someone will be granted admin for, say user creation purposes who can’t be trusted with raw db access for whatever reason … correct?  Pull it out into its own optional module and it can be locked down in its own right.  You know the DB passwords or you take a hike. 

3 - Removing it from “inside” OpenEMR does not change the fact that anyone admin right to the system can login and do the same operation using the mysql command binary, a peri program with DB access.

But some of us are looking at offering OpenEMR in a SAAS model.  It is on our servers somewhere, they know not where.  They have no login to our boxes.  They don’t know the DB passwords.  They couldn’t get into the cage even if they found the building.  They have a url and a login to a web site.  Everything else is magic that their monthly subscription fee takes care of.  As far as they know we are doing IP by carrier pigeon and flipping bits with a magnetic needle and a steady hand.

Because we have taken responsibility for their security keeping them out of the database makes our lives a lot simpler.


That said, it is easy enough to rip out by hand.  And those of us who will do so can script it easily enough.  But if a lot of people are doing so why not make it a supported deployment option?

tmccormi wrote on Wednesday, June 23, 2010:

If you are offering to host multiple clients then it IS your responsibility to add protection that keeps each clinic/business unit from messing with each others database installation.  But it would still not be your  liability if a client messed up their own data.  Unless you have a very poor lawyer. :-)  Even the data retention is the responsibility of the clinic, not the hosting service.

I think the database tools are too easy to get to, but PhpMyAdmin does not need to be removed by default to protect it, just better ACL controls.  By all means if it scares you (as a business) remove it, it’s not hard to do and you are the admin.  So I don’t see that there is any issue here.

Personally I’d be fine with PhpMyAdmin externally or separately installed (I use it that way a lot).  But It is not a “the solution”.

-Tony

-Tony

bradymiller wrote on Wednesday, June 23, 2010:

hey,

Regarding decision of phpmyadmin, probably best to base the decision on what the community wants and what will provide the largest increase in userbase. I’d argue this is a very useful feature, of which the majority of the users whom are testing this software out would not be able to install themselves.  This program is downloaded 100 times a day, and one of our main goals should be to keep that user.  In order to do this, the install should be easy (which it is), and include all main features (including phpmyadmin) turned on with the initial admin user.  When I was first learning openemr, this was an extremely useful module (it helps a user transition from running a black box proprietary program to a fully customizable open source program; ie opens their eyes to the benefits of open source).

Playing “big brother” by removing useful features so they don’t injure themselves does not seem congruent with an open source transparent project.  Tools are provided by openemr to further secure phpmyadmin and include (among many others):

1) In Administration->ACL create a new ACL group (Pseudo Administrator), and don’t give them the database aco (this can even be scripted by following functions in the acl_upgrade.php script).

2) Remove the database aco from the Adminstraiton ACL in the Administration->ACL->Advanced gui.

3) Delete the phpmyadmin folder.

-brady

drbowen wrote on Wednesday, June 23, 2010:

Yes, any of the developers and SysAdmins that participate in this project can and do install their own versions of phpMyAdmin for the increased utility of the more recent versions.  This is desirable from a development viewpoint.  I personally am very adept at the mysql cli.

When it comes to federal entities, state entities, and attorneys, trusting us “to do the right thing” is not in their nature.  They assume we are liars and cheats.  Leaving a tool of this magnitude as part of the standard install always draws a lot of valid criticism from users that are outside of this project.  I keep hearing reports from medium to large clinics that they won’t touch OpenEMR because of this issue.

This is a huge security hole that makes security professionals think we are not serious about our security.  From the federal government viewpoint, the Office of the Inspector General (aka OIG) will be prosecuting violations of this law.  Before the ARRA of 2009, the OIG has tripled their attorneys on staff to go after violators.  The ARRA of 2009 further increased the scope of the HIPAA regulations including the OIG budget and substantially increased the fines that could come out of unintentional releases. Under the HIPAA law all changes to the database have to be logged and all administrative changes have to have an explanation of the change to be logged as well. 

Our defense is “Oh. The user knows they are not supposed to use this tool to subvert the law so we trust them to do the right thing.”  This is an area of intense federal regulatory oversight. To intentionally release a such a powerful tool as a standard part of our production release that allows such easy subversion of this law seems foolhardy on our part.

Sam Bowen, MD
http://openmedsoftware.org

saikensf wrote on Wednesday, June 23, 2010:

I have not researched the law in detail, but Healthtrans firmly believed that it would be our liability if a client messed up their own data and I am assuming they did research it in detail. By ‘messed up’ I don’t mean typoed or put in the wrong values, I mean removed history or altered audit records for who changed what.

The issue comes down to the auditing HIPPA requirements.  As a HIPPA certified entity we have to comply with the 6 year history and the audit controls.  The data is, legally, ours because we have physical possession of the servers.  We just aren’t authorized to look at it.  This is really really weird, how can we own data we can’t look at?  But that is how the obligations work out as I was trained.  We had to work diligently to protect and maintain from our own clients the data’s history and audit trail.  Its content was their business. 

If Kaiser had demanded physical access or logins to the servers containing their data we would have refused and instead offered to provide them with a full data dump.  If they altered audit trails or whatnot in the dump we’d still have the pristine data in our boxes to provide for CMS arbitration if needed.

-Simone Aiken

tmccormi wrote on Wednesday, June 23, 2010:

My suggestion is to automate what Brady suggests as part of the installation/setup questions.  If the installer chooses the “Include Internal Database Administration” option it’s installed with ACL for ‘super admin’, other wise it’s it’s not (or visa-versa) …
-Tony

saikensf wrote on Wednesday, June 23, 2010:

That said, I totally agree that phpMyAdmin is a really useful feature and I’m not advocating removing it entirely.

I’m not even going to remove it entirely.

I’ve made a separate project internally and moved the database admin stuff to it.  So alters, loads, perl scripts, that awesome sql_update.php heads up alterer … you won me over with that btw.  I’ve used re-runnable in order scripts to manage upgrades for half a decade but on reflection I like yours better.  These tools tweaked to be able to connect to any local DB instead of being sealed to a specific one can be released on their own schedule.  An OpenEMR Management suite, if you will.

Anywho, this thread wasn’t really intended for this topic.  I’m need to finalize our suggestions for left nav tweaks and get them up here.

drbowen wrote on Wednesday, June 23, 2010:

I think that if we get a real legal opinion on this matter there all kinds of creative things that attorneys can do with this to cause this organization a lot of discomfort.  I don’t think that this is a matter of opinion or philosophy, but a realistic assessment of risk.

The liability of leaving this tool in place is huge.

Those who need this tool can easily install phpMyAdimin as post installation add-on.  We can post instructions on the wiki.

Sam Bowen, MD
http://openmedsoftware.org

bradymiller wrote on Wednesday, June 23, 2010:

Sam,

Good luck convincing the community to remove this useful feature, which btw is not just a developer tool. If it gets removed, it will just be demanded back. Also, good luck finding an attorney that says we are liable.  If you feel strongly that phpmyadmin needs to be admonished for MU, then we can then remove it for a specific MU version or change around the default security as Tony suggest (however, I am pretty sure the community would demand making the admin access for phpmyadmin default if we tried this).

“easily install phpMyAdmin”, nothing is easy.

Also, regarding the practices that have not chosen openemr because of phpmyadmin. They are simply misinformed on this feature (ie. easily removed), and for free, I’d happily describe for them how to further secure or completely remove phpmyadmin from the package.

-brady

blankev wrote on Wednesday, June 23, 2010:

Sam,

this is taking a stand!

I fully support your statement!

If you don’t want it, delete everything after installation, and remember to NOT give the MySQL password to anybody!!!!!!!!!!! The only way to be more secure is to delete also the Installation of OpenEMR, keep on using the paper version of the files and protect them from viewing eyes, by schredding them every evening.

Pimm

blankev wrote on Wednesday, June 23, 2010:

Please read Brady where I wrote Sam

Pimm

sunsetsystems wrote on Wednesday, June 23, 2010:

You guys crack me up.  :slight_smile:

It would be very simple to manually delete the phpmyadmin directory at installation time, or to distribute a version for certification purposes that does not include it.  The only software change I’d suggest is to have the navigation menu check for its existence, and omit the “Database” menu item if it’s not there.

This is probably easier than having to explain to a certification body why it’s there, or figuring out how to give someone “full access” to OpenEMR administration without including that part.

Rod
www.sunsetsystems.com

saikensf wrote on Wednesday, June 23, 2010:

Aye that on the simple.  We just did it. It adds a little layer of annoyance for patching but, eh. 

Now to move on to a problem that may not have a simple answer.  This is the results of my focus groupy training sessions with volunteer doctors filtered through us talking to decide how best to address user complaints about left navigation.  We though we’d tackle it first as the right side of the screen has the 2-pane vs 1 pane question and that will be more contentious I think.

But alas requests for the left nav spill over to the right in places.  Ahh well.

#1 - Combine Calender and Messages link into a new item called “Home”.

Provide a combination of the two pages in question in either the top and bottom frame or spaced out in a single view on the right when clicked.  Have it be the default page when logging in and basically be a familiar, secure, starting point for practitioners.

#2 Patient/Client

- - Remove the subfolder ‘Management’ and move its contents up a level.
- - Split New/Search into two menu items, New and Search.  Produce a new page for the search directive that is more oriented to that task.  Strip the search functionality out of the new Page.
- - Remove the ‘Current’ link entirely.  This should be omnipresent either loose in the left nav or in the top bar.  And instead of saying ‘Current’ it should name the active patient and be clickable to move to the patient management screen.

- - Rename ‘New Visit’ in the ‘Visits’ folder to ‘Create Visit’ or ‘Create New Visit’.
- - Rename ‘List’ in the Visits folder to ‘Visit History’.  ( yes it will still show current/future visits, but even though list was a submenu under ‘Visit’ a remarkable number of people didn’t immediately assume it was a list of visits ).

Now for the Chart Tracker … can someone tell me what it is intended to be used for?  Is this a killer feature, or a dusty add on?  The point of OpenEMR is to get away from paper charts, no?  Does it make sense being under visits?  Should it be inside the encounter screen instead?

- - Change folder name, ‘Visit Forms’ to just ‘Forms’.  Apparently the descriptor implied that there were different kinds of forms or something somewhere else and caused people to go looking for the non-visit forms instead of looking to activate additional forms.  I’m a little fuzzy on the reasoning here cause I wasn’t there for that one.

Optional Add on:

- - Remove the early escape for ‘English’ from the translator and make it attempt to look those strings up under lang_code 1.  If something is found, use it.  Then the changes that are just labeling could be configured per install without adding a new language ( English ( your clinic ) ). 

If we submitted a patch doing this would it be accepted?

Hoping this is agreeable because if this is contentious our proposals for improving workflow on the right side of the screen are gunna be tough to agree on.

saikensf wrote on Wednesday, June 23, 2010:

Oh, another optional add on:

Make the left nav tree database driven.  tables to put the tree together and tables to map nodes in the tree to roles so the code can be generic including acl calls.  That would also allow individuals to rename nodes to suit for picky customers without touching code.

That wouldn’t take much longer so could do that as well.