On FOCUS

MEDITECH supplies the FOCUS, we supply the perspective on Client/Server 6.x

On FOCUS header image 1

Report Designer Part 6:Download Reports and Final Remarks (for now…)

March 30th, 2010 · 1 Comment

by Joe Cocuzzo
Creating a download report is streamlined in the Report Designer, although it was not that difficult in the NPR Report Writer. If you designate a report format as Export rather than Standard on the General page, the Regions and Layout Pages become unavailable and the Fields page has a setting for download:

Adm Sample Download

Click to enlarge.

Rules and the Rule Wizard
If you need to retrieve selected queries, custom format a date, sort patients into custom age buckets, or do other things that required a computed field using the NPR Report Writer, you will need to create a Rule with the Report Designer rule wizard. This tool is not nearly as user friendly or intuitive as the rest of the Report Designer. The basic process is to point and click to generate lines of pseudo code.

Rule Wizard

Click to enlarge.

The process is very cumbersome and slow. The field lookups require you to include the object and field name and specify subscripts.

Overall impression – bugs encountered so far
The Report Designer is much improved since the original release. However, it is still has a way to go.

The Rule editor is very cumbersome and not intuitive.

Adding fields once you are in the layout page with the Add button is clumsy. It is hard to tell whether you can add fields and prompts and how to control which ones get added.

If there really isn’t a way to convert a printed report to a download, this will be a significant limitation. It is very common to build a complex printed report, then be asked to strip it down to a download. If you have just spent days beating on the rule wizard to produce 31 columns of data via 31 computed fields, you will not be happy having to repeat the process for the download version of the report you thought you just finished.

At Doylestown, currently, I experienced the following bugs:

If you go into the Notes section and then use Go to Page to go to the Fields page, the program crashes.

If you add a computed sort, there is no way to delete it. The delete X remains grayed out no matter what you do (deleting it from field list and layout does not change this).

The field list and the layout section can become confused and then you may end up having the fields from one record jump to the other or having the page header appear at the bottom of the report in the layout as you change things in the report. Sometimes the only cure is to abandon the bad version and begin again.

Did you miss an earlier part of this series?
Part 1: A first look
Part 2: A Detailed Tour
Part 3: Why can’t I delete or edit the field that is highlighted????!!!!
Part 4: Much More Convenient Field Selection and Entry
Part 5: Regions and Layout

→ 1 CommentTags: FOCUS · MEDITECH · Report Writer · report designer

Will MEDITECH Expose Programming Code in 6.x?

March 25th, 2010 · 1 Comment

by Frank Fortner

Recent concerns on the L-list had to do with the inability to write custom code, attributes and computed fields within various screens and reports in 6.x.  Now, in MEDITECH’s defense, I feel the need to clarify.  In 6.0, more than half of the applications are still running on the NPR side and still support code within the various areas that have traditionally accepted it. Therefore, with version 6.0, it is only the few Advanced Technology applications where this is true.  On the down side, PCS and OM are some of the most attribute-laden applications.

Of course, it IS true that once you embark down the 6.x path, eventually (version 6.2 or 6.3) all applications will be written in the new Advanced Technology platform.  At that point, unless MEDITECH changes their position, there will be no access to these kind of ‘programmer-level’ features.  If you’re waiting around for that to happen, you might not want to hold your breath.

Frankly, I don’t see it happening, at least not in the traditional sense.  It’s a very different environment that simply isn’t as end-user friendly as MAGIC, and it’s not just the code.  While the MEDITECH Advanced Programming Language (MAPL) is a more difficult language than MAGIC, there are also dramatic differences in how data is retrieved.  New services, protocols, database construction and retrieval methodologies have made the Advanced Technology environment resemble a modern automobile engine compared to MAGIC, which is more like an engine found in the vintage cars of the 60s and 70s and worked on by backyard mechanics.  Advanced Technology requires advanced training.

At the end of the day, I wouldn’t look for MEDITECH to expose programming code within 6.x, but time will tell.

→ 1 CommentTags: FOCUS · MEDITECH

Report Designer Part 5: Regions and Layout (Report Designer speaks for the picture)

March 23rd, 2010 · 2 Comments

by Joe Cocuzzo
The Regions Page allows you to activate different regions, and to create count and statistical fields for your trailer regions. Rather than creating a computed field with a VAL and an FNC, you can create a counting field per record (so count at the detail level or at a child segment level or both) or a statistic for a numeric field.

Admissions Report

Click to enlarge.

When you create a count or statistical field, an “m_” type field is automatically added to the field list on the fields page:

Automatic M Field
Once you have your data fields, statistical fields, and count field or fields in the field list, you can go to the layout page and the nifty “AUTO FORMAT” button will place them all at once on the layout (think “the picture”).

This feature has been significantly enhanced since the first release of the Report Designer. The earlier version would just plop the fields and labels vertically, and you would have to drag them one at a time to the appropriate spot.

Now you get a choice of:
Nicely Done

After you pick your option, you have a chance to put the fields in better order, or to delete some fields:

Auto Format Layout

After the auto format, you can arrange fields by selecting and dragging with the mouse, you can add additional fields, you can draw boxes and lines…

Boxes And Lines

Click to enlarge.

To add or remove blank lines for a region, you can drag the region line up or down with the mouse. To see the number of lines, click the Rows button at the bottom of the layout page:

Rows

Click to enlarge.

The right and bottom menu buttons of the Report Designer related to filing/translating and running are a bit confusing. If you use the Save Final or Save Draft buttons at the bottom, you save as draft or final, but then exit the report you are in and go back to the process reports screen with no report selected. If you use the Run button without first using Create Report, you’ll run the last saved/last built version. So, the most common action will be to use Create Report, then Run Report. A Create/Run button would be nice.

Create Report, Run Report

Here is sample output of a slightly different layout:

Sample Output of a Different Layout

Click to enlarge.

Coming soon, the last post in this series: Download Reports and Final Remarks (for now…)

Did you miss an earlier part of this series?
Part 1: A first look
Part 2: A Detailed Tour
Part 3: Why can’t I delete or edit the field that is highlighted????!!!!
Part 4: Much More Convenient Field Selection and Entry

→ 2 CommentsTags: FOCUS · MEDITECH · report designer

We Ain’t Afraid of No Mice

March 19th, 2010 · No Comments

by Mike DeVoe

I’m surprised at how many times I’ve been asked how scripting FOCUS applications is possible since it is so mouse-driven.  I get this question from seasoned script programmers as well as non-programmers.  I’m sure they’ve conjured up visions of counting pixels to deliver a mouse-click to a particular dot on the screen and hope their target is somewhere under that dot.

Let’s see how this nightmare would play out.  First, we need to know which FOCUS child window to look at as well as its coordinates within the main FOCUS window.  Then we need to count the pixels inside the window to our target click location, subtract the width of the window border and the height of the window’s caption bar, and then… and then…  and then… and finally… click.   I suspect if this is how we had to script mouse activity in FOCUS, we would all become musophobic and stand on our chairs.

The good news is you should expect your scripting tool to manage all this complexity for you.  Let’s consider what kind of stuff we usually click in a FOCUS window.  Buttons immediately come to mind but we also click in text boxes, check boxes, tabs and a variety of other Windows objects.   In FOCUS, we can even click on words such as the names of menu items.  Your scripting tool should give you an option to say something like “click the HOME button” or “click on the text that says Process Account.”   This way you can write your script in a way that makes sense to you and let the scripting tool do all the nasty math to deliver the mouse click.  For those rare times you have to click somewhere on the screen that isn’t a button, text box or other typical Windows object, your scripting tool should give you a recording feature to collect all these details and still do all the behind-the-scenes math on your behalf.

When I explain this to programmers, many ask what happens if the window is under another window.  Won’t the mouse click hit the wrong window? While there is a way to simulate a mouse click to the screen, your scripting tool should deliver the mouse click directly to the window and not the screen, eliminating this and many other issues.

With the right scripting tool, writing scripts for mouse-driven applications can be very intuitive and just as reliable as more traditional scripting methods such as sending keystrokes.  Secure in this knowledge, it is time to step down from our chairs and proudly proclaim “We Ain’t Afraid of No Mice.”

→ No CommentsTags: FOCUS · MEDITECH · scripting

The ForUpdate Mutex

March 17th, 2010 · 1 Comment

by Ed Bishop

The ForUpdate mutex defines a mutex record only when the data is updated, thus limiting the amount of time that the record is locked. Examples of ForUpdate mutexes are OM Clinical Data entry, OM Order entry, and PCS Assessment edits. The key difference with a ForUpdate mutex is that the cached data value at import time (the time the user initiated the update) is compared with the permanent data value on the server prior to updating. If the data value on the server is newer than the value that was imported by the user prior to the edit, the user cannot update the record.

For example, user one imports a PCS Assessment record and proceeds to edit. User two imports the same PCS Assessment record and proceeds to edit and file. User one then attempts to file the edit and gets a warning that data on the server is newer than the data in the local cache, and therefore the edited values cannot be filed. In this case, the user must throw away the edit and begin again.

There are also instances when no mutex is obtained. If the application determines that the data being filed is not in jeopardy of being interrupted, then a mutex is not assigned at all. As an example, new assessment documentations do not require a mutex because the data is fresh and free from editing that would cause data integrity issues.

So besides changing the name to a more techy sounding word, MEDITECH has made some significant logic changes to their locking mechanism in the new technology. While these algorithms may lead to less frequent locks in general, who wants to be in IS when that call comes in from a user who has been documenting away and is now told she must discard her changes?

Previous post:  The Mutex

→ 1 CommentTags: FOCUS · Learning More · MEDITECH