Creating MEDITECH Doc Tool Templates for the Physician Practice
Creating templates in the MEDITECH’s Documentation Tool (Doc Tool) can be a pain. Utilizing the pre-built templates that you can purchase from Zynx isn’t much better. You’re going to spend a lot of time in these dictionaries regardless of what option you choose. However unfortunate, no matter how much time you slave away, pouring blood, sweat and tears into this part of the build you’ll still hear the dreaded complaint of “Too Many Clicks!” It’s unavoidable. The goal in building these templates should always be to create them in a manner that the user can document what they want to and be forced to document what they have to.
Some things to establish up front:
- Keep the total number of templates as limited as possible. Reuse templates between similar practices if allowed and maintain the mental attitude that you will only begrudgingly expand the number of templates if absolutely necessary.
- If the provider already uses paper templates, duplicate them as close as possible. If the provider does not already use them, create paper templates with the provider and then duplicate them. The Doc Tool can only duplicate what is on paper. It is a very “Inside the Box” bit of software. Don’t forget to add in queries relating to Meaningful Use!
- If you decide to purchase and use Zynx pre-made templates, copy everything right down the group responses to its own custom version. First off, the output of query responses is terribly inconsistent between mixed-case and all caps and their are some weird abbreviations and misspellings (Who missed that in the QC process?). Second, if you are recalling a Zynx group response and they update it in one of their quarterly loads, you run the risk of the group responses being changed and thus Live data being changed and inaccurate on the patient record. I discovered this the hard way with a client using the Zynx query and group response for Smoking Status. A patient that never smoked was suddenly considering quitting.
Keeping all that in mind, let’s start with the hierarchy of the Doc Tool set up because everything in the MEDITECH world is in a hierarchy. I’ve boiled everything down and put it into this infographic:
Please feel free to print off and use this chart. It will help! Everything has to be built from the bottom up when thinking about the hierarchy. Group Responses have to be built before the queries, queries before Multiples or Groupings, those before Sections and Sections before Templates. E/M Codes need to be set up on pg. 5 of the PB/R Procedure dictionary so they can be added to the templates. And the rest of the components have a few options specific to them that are pretty self-explanatory.
Two tricks:
- When in the Template dictionary, you can move the headers around with Shift + Up/Down Arrow. This was discovered accidentally and is not applicable to any other dictionary.
- Trick’s on you! If you create a group response type query you cannot change it from not being allowed to accept multiple responses to allowing it and vice versa. You have to create an entirely new query if you decide it needs to allow multiple responses.
The resulting Progress Note which is produced by responding to the queries is in a strict ‘query: response’ format. In other words, there is an excessive amount of whitespace in the final document and your notes will end up being pages longer than they were in the past. In the pre-Doc Tool era, you could do all sorts of things if you knew the confusing nomenclature behind the scenes, but the Doc Tool allows none of that. You can’t even calculate values.
Think that table you put into a Text component looks pretty neat? Be careful how wide it gets. If a user enters information that is more expansive than what can be seen on the screen, it won’t be seen again unless some characters are deleted back out. There aren’t any system restrictions in place so it’s all about user training. If you do end up using tables and have an uncertain amount of columns that will be entered, train the users to create a new table when they reach the edge of the screen. Also, take a peak at what the progress note looks like once it gets sent over the hospital side if you have them flowing over. Tables don’t transfer. The data that was put into each cell pulls over, but in a messed up (technical phrase) format.
I typically create a single, all-encompassing template for Family Practice physicians. The initial learning curve as to finding where they want to document information on the template is high, but it ends up being a lot fewer clicks than having them add what customized sections they want on the fly depending on the patient they are seeing. The same can go for an Internal Medicine practice. Speciality practices can be easier to create templates for, but only if they have a set number of templates they use in the first place. See my initial considerations above. One of the biggest complaints users have about the system is the incessant need to “Drill-down” to find the information they want when they want it. For instance, if they want to look at a previous radiology result, they have to stop documenting, go over to the hospital side, take a look at the result and then hope they don’t get distracted on their way back to documenting so they don’t forget what they just saw. Well, not much can be done about that right now, but information such as Health Maintenance details can be brought on to the template so they just have to scroll up or down to find it instead of exiting out. Keep these things in mind as you are designing the template. A little extra documentation pulling in automatically onto the progress note that may be unnecessary on the visit is worth the hassle of not having a quick source for that information.
Also, train users to drive the template, not let the template drive them. A lot of times, people get wrapped up in seeing what is the next item on the template and wondering what they are supposed to put there when generally the answer is nothing at all. Make sure they first determine what they want to document and then find the appropriate place to document it. I would also recommend putting a “Details” Text box in various places throughout the template as a catch-all and teaching users that the moment they get frustrated trying to find something, just put it in the Details section.
History of Present Illness is best left as a free text area along with the Assessment/Plan. The A/P will have the Orders and Medical Problems components to add that information in automatically though. The Review of Systems and Exam sections will be more of the point and click areas.
The auto calculate feature in E/M substantiation is great in theory, but you have to include the patient’s recallable history queries AND do something more than free text the HPI for it to truly work. If you do recall the patient’s history onto every progress note, make sure you have a required query that asks if the history was reviewed for the visit so you don’t risk a billing fraud error by having that history count towards a higher billing code when it wasn’t reviewed.
Lastly, and certainly the most important is about one button in particular: The Quick Save button. Especially if you use laptops/tablets, have users learn to love this button and click it as often as possible. If a wireless connection drops in the middle of documenting and the Quick Save button hasn’t been clicked yet, chances are that most everything will be lost. The component information (Allergies, Medical Problems, Orders) won’t be lost because those are stored upon filling, but the responses to the queries and text boxes will be. Unlike most modern document writing software, MEDITECH’s Doc Tool leaves the common and well-loved Auto-Save feature suspiciously absent. The Quick Save button has the annoying habit of exiting the user out of the Documentation Tool so they can preview their progress note, but it could save some cursing if a MEDITECH session goes bust, which they are prone to do.
Aaron Berdofe, MHI - Health Informatics 