ALERT: Centralized Immunization Module now required for MEDITECH facilities at MU3 – we can help with your conversion – contact us now!
Categories
Archives
▸ December 28, 2016

The new JW Modifier regulation is explained and issues discussed in this short screencast from one of our consultants and Meditech subject matter experts.

Contact The IN Group for additional information or questions?


▸ October 28, 2016

Voice Recognition software can be a powerful tool to augment current or planned EHR provider
documentation solutions. For providers that currently use a dictation device/system for documentation,
voice recognition can provide a familiar and almost seamless solution. For providers using a point‐and‐
click and/or free text solution, voice recognition can save significant amounts of time. While voice
recognition software can be an effective and efficient tool, a host of potential problems associated with
adoption can come along with it such as:

  • Provider resistance
  • Lower than expected baseline recognition
  • Insufficient baseline training
  • Insufficient go‐live/post support
  • Insufficient training/understanding of advanced features
  • Hardware availability and/or location

Overcoming these potential issues requires a clear understanding of the needs of the Providers, Medical
Records/Coding staff, as well as the capabilities and limitations of the system(s). It is key to strike the
most effective balance between software use and human needs.

Provider resistance can feel like the biggest obstacle to implementation. Early communication and
involvement in each step of the process will combat resistance as well as increase adoption rates. Steps
to take may include:

  • Voice recognition demos and/or site visit
    • When providers can see the software in action, especially during a site visit, they are
      more able to ‘visualize’ its use in their own daily workflow
  • Thorough analysis and understanding of current system(s) in place and workflow(s) surrounding
    those systems
    • Communicate these findings directly to providers to discuss:
      • Where they see issues and how voice recognition can be incorporated into
        current systems
      • How to translate voice recognition capabilities from current workflow into the
        design/build process of new systems/workflows
  • Continued step‐by‐step provider involvement in the design/build process to increase buy‐in

Medical Records and Coding staff may have requirements and/or initiatives in place to improve current
documentation. These must be taken into account during the design/build process.

  • Discussions of how voice recognition could mirror or improve documentation should occur early
    in the process.
  • Post Go‐Live audits that include both the I.T. and Medical Records department to review records
    for content, completeness, and regulation/policy compliance will provide the team with further
    insight into potential optimization of design/build as well as further provider training and
    support.

Hardware availability and location can be a major roadblock to adoption in certain areas. While in an
Emergency Department providers will typically have their ‘own’ workstation, this is typically not the case
in inpatient areas. Each area should be reviewed for:

  • Number of current workstations/computers
    • Current documentation system may not require fixed workstation
    • Number of providers typically on a specific unit should be investigated
  • PC vs Virtual environment
    • These environments require different consideration and/or hardware
  • Is there a need for remote usage
  • Provider training is the next key to success. Provider training should consist of 3 different phases:

    • Pre‐Implementation
      • 1‐on‐1 provider training for voice‐file creation, basic functionality and use, as well as
        quick discussion of more advanced features
    • Go‐Live support
      • Shoulder support and ‘refresher’ training during implementation will reinforce skills
        learned by applying those skills in a ‘Live’ environment as well as a reminder of skills
        s/he may have forgotten
      • Observation of actual use and dictation in a ‘Live’ environment provides the opportunity
        for the trainer to teach new tips and tricks as well as the ability to ‘curb’ bad dictation
        habits
      • Real‐time discussion/fix of provider issues and/or concerns is invaluable
    • Post‐Live support
      • Continuing education should be provided for all providers that want it
        • To reinforce and/or refresh on basic usage
        • To teach more advanced functions
        • To help increase recognition through tools and/or dictation training
      • Continuing education via ‘tips and tricks’ papers distributed in as many ways as possible
      • Regular rounding and medical department meeting attendance to discuss usage and/or
        issues

    Finally, a Change Control Management process must be in place to prevent new issues or conflicts. Two
    distinct and separate Change Control policies should be considered:

    • Go‐Live policy should be used during a pre‐determined period during and after the official Go‐
      Live for:

      • Provide a stream‐lined process for changes deemed to be of high priority which may
        include:

        • Patient safety issues
        • Issues preventing use of the system
        • Issues significantly affecting normal/standard workflow
      • Prevention knee‐jerk reactions and/or changes which may not be to the long term
        benefit of the user
    • Long‐term policy to govern:
      • How requests are communicated
      • Review and/or approval process of requests for design/build in Test environment
      • How those changes are communicated
      • Final approval process
      • Implementation in Live environment process
▸ October 7, 2015

Y2K – The Test

The elevator doors opened on the dark corridor. The concrete floor and pink walls told me that I was in the West wing of the Basement. I proceeded down the hallway, and unlocked the door of B2, the Information Systems training room. As I turned on the light the room came to view. Tables that were usually in neat classroom rows had been re-arranged haphazardly. Extension cords lay on the floor like causalities of war. A Net work hub sat along with connections to nowhere hanging to the floor. A lone printer with spent paper lying next to it sits on the counter. The dry erase boards are covered with notes relating to test patients, modules, MEDITECH personnel, telephone extensions, printer designations, etc. At the top in BIG LETTERS the words TODAY IS : March 2, 2000. On a large section labeled “Identified problems” is curiously blank. This is where it happened. We would all like to be capable of travelling into the future, yet nobody has. This is where a group of testers had become VIRTUAL TIME TRAVELLERS. Warping into the future to determine the Y2K compliance of the MEDITECH Environment.

It started with the MEDITECH 4.6 upgrade. Loaded into our initialized test directory in early March of 1998. As part of our upgrade we received the Y2K enhancements. After standard testing and DTS changes we went LIVE with what we thought to be our Y2K compliant version of MEDITECH on June 17, 1998. Some quick checks of the database showed some minor problems. We had patients with negative ages in the system! We had inadvertently discovered the FOUNTAIN OF YOUTH. Further inquiry into the system showed the patients with negative ages had birthdates before the current date in 1898 and the age was the difference between today’s date and the actual birthday shown as a negative number. Luckily these patients were in the MPI database but not in the hospital. We had made a mistake in not entering patients into the test system with ages over 100, before loading the 4.6 upgrade. We did not test the functionality of the system converting these birthdates. It accepted new patients with ages over 100 and treated them fine. MEDITECH was able to correct this problem with DTS#XXXXXX. After some minor cleanup we were off and running with the Y2K compliant MEDITECH system.

Our facility had volunteered to be the Test site for the CHW MEDITECH Hospitals.

▸ August 14, 2015

This slideshow could not be started. Try refreshing the page or viewing it in another browser.

▸ July 23, 2015

Hi –

We wanted to express our sincere gratitude for the assistance and support provided by Chuck and Jose during our ED pyxis profiling go-live implementation.

This project go-live was successful in part due to the flexibility, teamwork, issue resolution, troubleshooting, attention to detail, build, understanding of workflow considerations, and continuous support that both Chuck and Jose provided throughout the week of implementation.

We are so grateful to have assistance provided by individuals who care so deeply about our institution and who are willing to go above and beyond to achieve successful implementations of projects.

We want to say Thank You for the outstanding and excellent work demonstrated by Chuck and Jose. And, thank you, for the immediate review and adjustment to the engagement scope for Jose, which allowed him access to the pyxis.

We look forward to continued partnership with your Team.

With gratitude,

Amber and ED Pyxis Project Team

Amber McGreevy, RN, BSN
Clinical Applications Manager
Information Services
Henry Mayo Newhall Hospital
23845 McBean Parkway, Valencia, CA 91355

▸ July 12, 2015

PCM FORMATTED DATA DICTIONARY CHANGES IN 5.67

Several changes have been made to the PCM Formatted Data Dictionary in which current fields have changed and new fields have been added to the LAB and MIC components. Below are the changes along with explanation of those changes.

LAB COMPONENT CHANGES
5.66
5.67
Result Timeframe: Is a radial button field where you select the number of hours or last available result.

1 - LAB_Component_Result_Timeframe_5.66
Result Timeframe field has been broken into 2 separate fields:

• Laboratory Results Within: This field allows the user to tell the system to pull results based on the previous number of H(ours), D(ays), M(onths), or Y(ears).
• Last Number of Results: This field allows the user to define how many results to pull for each test identified. This can be used in conjunction with the above field or by itself.

2-LAB_Component_Resutls_Timeframe_5.67
Include field is a radial button field for selecting whether to include Normal, Abnormal, or Both types of results.

LAB_Component_Include_5.66
Include field has been broken into 2 separate fields:

• Result Type: This field is now a lookup to enter Normal, Abnormal, or Both.
• Results From: User can select to show results from Current Visit or All Visits.

LAB_Component_Include_5.67
Include field allows user to select the All Panels radial button or enter a specific Laboratory Panel. If All Panels is selected, the Laboratory Panel field is disabled.

LAB_Component_Include2_5.66
Include field is now called Include EMR IDs From.
• If you select All Panels, all lab test results with EMR IDs will be pulled in.
• In order to pull results from a specific panel, you must select Selected Panel to enable to Laboratory Panel field.

LAB_Component_Include2_5.67
Results Diagram Circle Abnormals field is a radial button

LAB_Component_Results_Diagram_5.66

Results Diagram Circle Abnormals is a look-up. Enter Y(es) or N(o). Left blank assumes No.

LAB_Component_Results_Diagram_5.67
MICROBIOLOGY COMPONENT CHANGES
5.66
5.67
Include field is a radial button to select either Last Microbiology Results or Use Number of Hours.

Microbiology_Component_Include_5.66
Include field has been broken into 2 separate fields:

Microbiology Results Within: This field allows the user to tell the system to pull results based on the previous number of H(ours), D(ays), M(onths), or Y(ears).
Last Number of Results: This field allows the user to define how many results to pull for each test identified. This can be used in conjunction with the above field or by itself.

Microbiology_Component_Include_5.67
Other field has an Option to select Include Preliminary Results.

Microbiology_Component_Other_5.66
Include Preliminary Results is now a separate field. Enter Y(es) or N(o). Left blank assumes No.

Microbiology_Component_Include_Prelim_Results_5.67
Other field has an option to select Text Format.

Microbiology_Component_Other2_5.66
A new Format field has been created allowing you to show data in either Table or Text format. This field is required.

Microbiology_Component_Format_5.67
The Microbiology component pulls in ALL Microbiology results based on the Number of Hours entered.

Microbiology_Component_Number_Hours_5.66
A new Include field has been created allowing the user to select All Tests, Selected Tests, or All Except Selected Tests. This functions in the same manner as the Lab Component.

Microbiology_Component_Include2_5.67

 

 

 

 

 

 

 

 

 

 

 

 

 

 

syringe
▸ March 23, 2015

The Universal eMAR enhancement you may have missed

When an upgrade happens, like the upgrade to Client/Server 5.66 Priority Pack 8, there are countless enhancements. It is easy if other projects are happening concurrent to the upgrade that some of these enhancements may go un-noticed.

I have found that many sites were so focused on Meaningful Use in the past 12 months that one of the better enhancements in Priority Pack 8 went unrealized. This enhancement is incremental dosing.

Read More ▸