A Tech Writer's Review of 4.0

OpenEMR Development
1

infinitecreatur wrote on Friday, December 10, 2010:

A Tech Writer’s Review of 4.0

Documentation Status & Formatting

The new user documentation for 4.0 is nearing completion.  The plan thus far is to release the documents in two formats: The usual PDF format (possibly divided into separate files for each relevant section), and a MediaWiki version (instead of the old HTML format).  This would allow for the same level of portability and ease of use, while making it much simpler to maintain and update.  Users would be encouraged to post comments and feedback on the Discussion page, and make minor updates where necessary. 

The following supplementary documentation is also planned and in development:

-  Feet sheet/service code entry & customization
-  Procedure configuration & order process
-  LBV Form customization & layout
-  Globals options

Suggestions for additional supplementary documentation are welcome.

Notes & Questions

While going through the existing documentation and making the relevant updates for 4.0, I wrote down any questions I had, and took notes on some of the things that stood out to me as inconsistencies or issues/bugs within the program.  Here is a somewhat lengthy list of my questions and notes.

-  Are the Traditional & Radio button navigation schemes still available in 4.0?  And are they still relevant enough to be included in the user documentation?
-  Users / Group Administration - What purpose do groups serve in the current system, and how do you edit them?  I see nothing in this section for administering groups at all.  ALSO (from Tony):  “Turning on groups is supposed to prompt for a group at login and it did not, so there is either a bug or a configuration step that is undocumented … “
-  I assume there is not yet a system in place for creating multiple insurance plans under a single insurance company?
-  Under ‘Practice Administration – Documents’ the Edit Categories page needs a “back” / “done” button to return to the document list.
-  What does the ‘Update Files’ button do? 
-  The 4.0 development demo is configured with all 50 states.  (and many many languages, etc.)  Does 4.0 come pre-configured like this as well?
-  If so, what is another commonly used list that clinics will need to populate that could be used as an example instead?
-  For consistency’s sake, I think that all pop-up dialogs (such as the address book) should appear as lightboxes.  Also they look nicer.  : )
-  Search /  Add patient - After clicking “create new’ it pops up an empty search list & dialog saying “no entries were found.  Create new?”  Is this to prevent duplicate entries?  If so, maybe it should only pop up if it DOES find one?  Otherwise it’s just a redundant action that’s kind of jarring.
-  Should the “Uploading Documents” section include a discussion of how to move files between categories and patients?
-  **There should be some discussion about the use of the words “Encounter”’ vs. “Visit” within the system.  **
-  Visit History – There is currently no discussion of the “Billing View” vs. “Clinical View” here. What is the difference between the two, and under what circumstances would you use each one?
-  Issues List - Linking to the old issues page is redundant, and regardless of what issue you click ‘edit’ next to, the ‘add issue’ dialog is still defaulted to ‘problem’.  Clicking ‘edit’ next to an issue type should go directly to the add issue dialog, AND automatically select the desired issue type.
-  Links to the ‘Issues & Encounters’ association dialog could be added to each issue in the expandable issues list on the patient summary page?
-  Issues list should update automatically when you’re done associating encounters.  You should not have to click the refresh button.
-  Is there a way to make the lightboxes appear over the entire browser window, rather than just within the current frame?
-  I’ve never quite understood this one:  Is there a clinical difference between “Medications” & “Prescriptions”?  Do they serve different functions within the program, etc.?  Why the redundant lists?
-  Patient Notes & Transactions – The descriptions here are holdovers from the old old documentation: “Patient notes store patient information that is unrelated to the patient’s medical condition… Transactions are somewhat similar, but record events that have already occurred.”  The phrasing here sounds odd (or at least unclear).  These definitions seem wrong, and they seem to overlap strangely.  Other than referrals, which are fairly straight forward, what is the real difference between a Note & a Transaction, and when is each appropriate to use? Notes can be anything? Transactions are an exchange of information between parties?
-  What does ‘Active’ mean in the context of patient notes?
-  “Displaying the following number of most recent notes:” on patient summary page says 3, even when there is only 1 or 2.
The text links on the Billing Reports page should be changed to buttons for consistency and readability.
-  The ‘Explanation of Benefits’ window (and subsequent windows) open in a new tab.  This is OK, but they start to stack up as you’re working, and could be confusing to the user.  Would a lightbox be better here?

Feel free to add additional notes / questions and discuss any of the issues I have included here.  This is by no means an exhaustive list, and it is written from the perspective of someone who is not 100% familiar with the use of OpenEMR in a real clinical practice.  I apologize for any misunderstandings or misinterpretations on my part, and welcome any incites into the workings of a real medical facility.

Thank you,
~Sara McCormick

2

aethelwulffe wrote on Saturday, December 11, 2010:

My humble apologies to the self-sacrificing  developers that have built this application up from nothing.  I am about to (hopefully) constructively bash your handling of terminology within the EMR, as well as it’s organization.

  “Visit”, use of, and all incidents of the word should be thrown out of the program with the (possible) exception of use in scheduling nomenclature.  I would guess that this whole system started with a scheduling application, so “visit” has crept in.  “Encounter” is the correct term and most descriptive.  Other  phrases that include  “Encounter” should include words from the Place of Service list.  A patient “presents”.  They do not “show up for a visit”.

  I am not sure what a “Feet Sheet” is.  Perhaps the result of a blind spell-check or perhaps dyslexic fingers.  :)  Perhaps I am being a smarty 'cause I just want to “incite” you 8~)   Just goes to show that this process of documentation will be some real work.  Peer review, redress and editing (within limits) is all very necessary.  Documentation must be beta tested just like any computer executable.  You gotta go find some N00bs to try to use the documentation, and see how they can get side-tracked.

    Seriously, I think “fee sheet” should be the name of a database table that describes charges, not the document that you enter billing data on. “Fee sheet”,“Coding sheet”, “Billing Form” are all descriptions of the little pieces of paper that doctors scribble and circle on, then stuff into the ends of used up exam rolls for the Billing Grandma to hunt up later and fill in CMS forms with.  “CMS form”, or “Claim data” is an example of what should be used.  “Fee Sheet” gets mixed up with other things.

_Example:  _  If asked “Did you fill in the Claim Data for your last encounter?”  Everyone will understand specifically that you mean that you added the billing codes, units etc… and added it to an encounter in the EMR.  Personally, I wish that you could not save an encounter unless you put claim data in, or hit a magic button that sends a note to the listed billing P.O.C., and a supervisor that says "(PROVIDERNAME) has not completed claim data for encounter (date/control number). 

“Groups” different from ACL groups, are a really great idea that was never implemented at all.   Cleaning house is hard work.  I would not be surprised if this and plenty of other junk code will be included. This type of group would be useful if clients could also be assigned to one or more groups.  Then VIP status, multiple mental health program data restrictions etc… could be implemented.  This should be an expansion of the ACL, or at least use the same interface as it.  It should not require a different logon.  Your logon should differentiate what group your are in, and what content you can see, and what write permissions you have to the database.  As it is, the ACL is pretty darn weak.  You just have to get used to the idea that anyone on the system can see anything else…in some way.  If you can’t display demographics, well, just use the client search and there they are!

Globals options:  OK coders, YOU know what Globals, strings, locals, privates, publics, and bools are, but that isn’t what they are called in ENGLISH.  Call this “Global Options” if you must, but really other terms would be more meaningful to “Two-Thumbs Tammy” the Practice Manager.  Just by rule of thumb, if you are someone who knows what a gloabalvar is, you SHOULD NOT name anything in the interface.  You describe what the item does in three-letter words to your wife, mother or daughter and get THEM to name it.  They would probably call it something like “Program Options” or just  “Options”.

Not only should the globals.php tweaker interface be documented, but it should be documented in the PRIMARY documentation.  This is integral to the program.  OEMR documentation currently has junk from multiple versions, a walk-through with that horrible radio button view, and some out-of-date add-on documentation here and there scattered across the web.   This and other items should not be part of supplementary documentation, it should be sectional primary documentation.  This should include an in-depth explanation of every entry and display item in the EMR, and how it interacts with other things.  Example:  Call Availity.  Ask them if Loop 000B GS02 should be a Duns and Bradstreet number or not.  They can tell you "Uh, it should say “01”, but they have no idea of what a DUNS number is.  OpenEMR documentation can smooth over many pains if it is extensive, detailed, yet also includes “Walk-through for Dummies” type information in nice segregated chapters.

50 States?  Yeah, if anything is configurable, having options to get rid of unneeded stuff.  I am sure globals.php settings handle language and the like, though I have not looked closely at the options interface in the demo.  You SHOULD see the languages/translation options there, or they should be working to put it there if the language options are standard with the release.

Uploading Documents:
    First, you should be able to associate imported documents with encounters.  This is not hard to implement, and is very useful.  Next, despite verifying no permissions issues existed, moving a file from one patient to another always results in a disaster.  To actually MOVE the file, you must save, delete, and then re-upload or it hoses up the database.  I have seen this in three installations of 3.2.0.  YES, handling documents should be documented.  Big time.  Discussion of naming conventions for documents should be addressed in the manual as well.
  REAL BIG ISSUE HERE:   Naming options for uploaded documents should be configurable options!  The system currently SUCKS.  When uploading a document, it would be nice to not just choose the category, but have some radio buttons or lists for sub-categories that allow you to apply naming conventions to the file.  Date of upload should be in the database and displayed somewhere.  It should NOT be part of the document name.  Restricting names to the options pre-ordained by the administrator makes things easier to find, is often easier for the person naming the file, and makes the documents directory more searchable.

Billing view and clinical view selection should be handled with a cookie, or better yet be made a thing of the past.  if you select a billing list, you should get the billing view, if you hit client list (another indifferently named item) you should get the clinical view, which BTW includes billing info……Seems like they just need both at the same time, and only display the billing note box for encounters with billing notes.

On Med lists:
  Prescriptions- should be scripts/changes/orders that a local provider is writing.
Medication List- Verified or unverified lists of medications or other substances that the patient reports as; taking; prescribed by other providers; and compliance history.
There should be an interactions pop-up widget here that checks scripts against med list with every new script written.

Patient Notes:  Oh Gawd! 

Active:  Should mean that while we do not delete the notes, they are made “inactive” or have been addressed.  There is a view setting to display active vs. inactive I hope.

Buttons:  Appearance should be configurable.  I will >happily< create 3d buttons or any other needed graphics for the various styles.  We need lots of buttons.  Lots and lots of buttons.  It’s in style now you know.

3

klassy wrote on Saturday, December 11, 2010:

lots of quick minds here!

i’m feeling real dumb right now! tried everything!

Here’s what i have now……

i’m started everything from scratch!

i have a macBook Pro running OEMR 3.0.0.1. everything is working ok.

i need to move all my data from this macbook pro to an iMac that will work as
a dedicated server.

Please give me a step by step guide how i could do that AND update the EMR version
on the iMac to 3.2.

i have downloaded the 3.2 patch zip file.

4

aethelwulffe wrote on Saturday, December 11, 2010:

May I suggest posting in the Help section here:https://sourceforge.net/projects/openemr/forums/forum/202505

5

jcahn2 wrote on Sunday, December 12, 2010:

Ahoy Sara and aethelwulffe,

The importance of your suggestions cannot be overstated.   The clunky, techy user interface of OEMR unfortunately sets it apart from its commercial competition.  This is a “turnoff” during a demo as docs who have already had to endure the dead language of Latin, are not anxious to learn techspeak.   What does globals mean?    In medicine, globus, is the sensation of having a lump in the throat, and we are trying to avoid that ;^)   Developers here know that I love OEMR and will not be offended by my kibitzing*.  This must be incorporated into 4.0 prior to the next official release.

Jack Cahn MD
kibitzer
*(from Yiddish kibitzen, from German kiebitzen to be an onlooker)

6

tmccormi wrote on Sunday, December 12, 2010:

Just so people know.  Sara will be back on your suggestions (for documentation) after Christmas, she has to work full time at her art sales during the shopping season.

Changes to the on screen wording are up to the developers and the community.  Suggestions should be posted separately from this thread so that they can be discussed and perhaps turned into feature requests and maybe even delivered in the future.

The suggestions that Sara needs are things like how to explain the existing OEMR wording and use in ways that the users get.  She is not a medical person or a programmer, so she actually has no predetermined views of either and is interested in clarity only, the way a novice user would be, a good thing I would say.

Tony

7

sunsetsystems wrote on Saturday, December 25, 2010:

To respond to a few of the original questions without editorializing as to what “should be”…

Traditional and radio button navigation are still in 4.0, and the current failure of Traditional to work properly is considered a bug.  I’d say it’s likely we’ll get rid of Traditional at some point.

Use of groups is discouraged.  It’s an interesting concept that was never fully implemented and currently doesn’t do anything very useful.  If you enable it, and if I remember correclty, you won’t get the group selector dropdown unless there is more than one group in use.

You can have multiple plans for one insurance company in that the plan name is a text field in the patient-specific insurance information.  But there’s no list of plans.  I expect that maintaining such lists would be an unpleasant and error-prone job.

Looks like all 50 U.S. states are now in the 4.0 database.sql.

“No entries were found. Create new?” was done just for consistency, so you always get a confirmation prompt instead of sometimes.  That could easily change if it’s not popular.

Encounter and Visit are the same thing.  Which is better I’m not sure.  Generally I try to use Encounter because that’s the traditional term in OpenEMR.  I had a client complain about that once, saying “an encounter is what I have with a woman.”  :slight_smile:

Billing View is designed for billing and administrative users, Clinical View is designed for providers.

The issue Edit buttons on the patient summary page are a bit confusing.  May be better to have just one, called something like “Manage Issues”.  You edit a particular issue by clicking its name in the issue management page, and in that case the existing issue type cannot be changed.  The “old issues page” is not redundant, it is the core of issue management.

Lightboxes are restricted to their frame.  That’s their primary disadvantage.

I think there is some work going on to integrate medications and prescriptions.  Currently, prescriptions are only those medications prescribed from the clinic.

Patient Notes are like an interoffice messaging system where the messages are effectively part of the patient’s record.  I guess Transactions where invented for things that don’t fit well anywhere else.

I’m not sure offhane what the best use is for the Active flag of a patient note, since it can be “closed” to indicate that nobody needs to do anything further with it.  Perhaps someone else can comment on that.

Rod
www.sunsetsystems.com

8

aethelwulffe wrote on Saturday, December 25, 2010:

“Active” is a very important feature (or will be).  Active will allow you to have folks updating insurance info for “active” clients, and never having to see data for inactive patients in a search etc…  I have had to add this flag and add it to the search filter for us, as we have 900 clients in our database, with only about 160 “active”.  It was a real problem.  I still want to convert it to only search for active patients unless specifically asked not to, everywhere but in the “add patient” interface.
  Patient notes is a real good concept.  it does confuse people with the nomenclature.  “chart notes” or better yet “Contact Log”, with the interface clearly stating what patient it is talking about, and a date added in the text might be a good idea so that people really know that they are creating a note in the chart.  The submit button should be labeld “Add to patient record”.
  I have not been able to see the demo of 4.0 for a while, but 3.2 seems to lock some folks into a billing view, and others into a clinical view, with no selector switch in a cookie.  That is a pain some times.
My vote: “Encounter” is an encounter, and an “office visit/home visit/school visit” is a type of appointment in the calender.  That distinction is VERY important to us, and less so to most medical clinics where everything is an office visit.  Other times, a “visit” will be during rounds, or a procedure done at a hospital for which the practitioner has privileges…hardly a "visit really.  It is an encounter from what I know of medical terminology.
  “Issues”…dunno about this one.  I thought that sort of things was called History of Present Illness, or HPI.  No-one in our office got what “issues” even were.  They still forget.  They also assume that when you select an issue for the encounter, it will be added as a diagnosis in the fee sheet, and are confused/pissed when it is not.  They are not really even sure what selecting an issue even does for the record.  I am not sure either.
  I think “office mail” with clearly identified “in-boxes” like a wee messaging interface should be included, and away from the “chart note” type message.

9

sunsetsystems wrote on Sunday, December 26, 2010:

I plead guilty to inventing “Issues”.  There does seem to be some confusion about them.  This is an all-inclusive term encompassing medical problems, allergies, surgeries and some other things such as pregnancies or continuous use of a contraceptive.  I wanted something to hold information that spans multiple visits (oops, encounters), and to make them customizable so that imaginative uses could be included.  Especially since the design was to put them all into one table, this term seemed desirable.

Tying an issue to an encounter simply notes that the encounter was at least in part about the issue.

I’m very open to discussing ideas with anyone who is seriously interested in actually working on improvements to this area or sponsoring such work.  We can talk all day about the way things ought to be, but that by itself doesn’t accomplish much.  :slight_smile:

Rod
www.sunsetsystems.com

10

aethelwulffe wrote on Sunday, December 26, 2010:

No, of course not.  I don’t have any money, but I am more than willing to put my time and sweat where my mouth is.  It would be pretty asinine of me to whine and run.  Unfortunately, I have to get up to speed with 4.0, as well as get some syntax under my belt to be of real use.  Hopefully, I can get some direction from my coding elders here (in short order) that says “You want X_4.0? Well here is X_4.0A.  Get to work and don’t go breaking our code!”
  I seriously doubt that I will ever earn any money working on OEMR.  I just see that it is a real need.   My current aim is to help folks that really don’t have an EMR they can ever afford and don’t find a purely medical one really useful or intuitive anyway.  Therapists (especially the 501c medicaid types) will never have enough cash coming in to really pay for any “extras”, and they have as much need for an EMR/EHR as anyone else.  Their job is very labor intensive, and doing all their business via e-mail exchanges and truecrypt container files is VERY inefficient.  I aim to help them, and everyone else sort of by default.

11

aethelwulffe wrote on Sunday, December 26, 2010:

…adding also that without discussing the way things ought to be, it is hard for any one person to really understand what should be done in the first place.
  I write a program, see it get downloaded 20,000 times with absolutely no feedback.  I think it must be a total flop.  Then two years later, folks are on some site discussing uses/problems/bugs/likes/dislikes in the program that no-one ever bothered to report using the link right in the darn program or the dev site.  AAARRRRGH!

12

sportsdoc wrote on Sunday, December 26, 2010:

Hi all Issues I think I asked Rod to dev these the term may be confusing however the concept is key to medicine.
Basically issues are like an episode of a group of encounters to explain if someone has an injury or a chronic illness it lasts for a period of time in that time the person will probably see the doc for several encounters, during these encounters the doc will possibly perform lab tests scans and carry out some treatmemt. Each issue will carry the diagnosis of the injury or illness. Of course if its a one off encounter its not needed to create an issue or episode may be better term.

Best Doc B SOMETHING HERE