Order Management and Ancillary Modules
Integrated Similar to prior versions of Meditech ordering is integrated with other modules PHA ITS LAB PCS Most of the Order build in OM happens in the other modules, so subject to build decisions and progress are dependent on other teams. We had a weekly meeting that involved the leads from each of these modules and brought ad hoc attendees as needed for particular topics. It is important to note is that PHA LAB ITS are still in NPR while OM is MAT code.
PHARMACY
PHA CMS issues PCS integration moved out of PHA Order strings Incremental dosing, cumulative dosing
Differences Incremental Dosing- Next update Cumulative dosing (acetaminophen on MAR)-Next update FDB Cloud API for interaction checking Dosing sets are at the initial look up level in OM
Comparison
CMS issues Drug dictionary and NDC maintenance Dosing sets Order string/Order sets Drug Type PHA utility Multiple pushes -.1 or .STD Ghost meds and duplicated strings
PCS integration outside PHA Assessments attached in Med Doc Workload, a PCS dictionary. Pros: Location or facility specific build Cons: Location or facility specific build Weight based route additions to the IV spreadsheet
Order Strings Build the premix , no more dummy Our decision to utilize more in pharmacy Cons: protocols are built in a dx for OM, not integrated with pharmacy Pros: lookup more consistent with OM
Wins One FDB load! Fresh start Order strings IV spreadsheet
LAB/MIC/BBK/Pathology INSERT PICTURE BELOW OF MICROSCOPE OR SOMETHING
LAB Standard Content Timing of build and testing Integration with OM different Collection process- PCS/LAB Locations and label printing, pre-collection labels
Standard Content Determine which tests work/don’t work for you (non-editable fields) Department Test Type (panel vs individual result) Alpha/numeric May need to expunge to free up print number ranges. Determine which standard content should be expunged, then expunge rather than inactivating tests first. Once there is a custom flag, expunging will not work correctly.
Map out Test Build in Advance Decide which standard content tests you can use, and map print numbers accordingly for build Develop a master spreadsheet to be used during and after build for mapping current and future build Include print #s, mnemonics, test names, departments, test type, alpha/numeric, EMR IDs on the spreadsheet As much as possible, test name should match EMR ID
Loaders and Utilities Use loaders and utilities as much as possible. This will be a time saver. LAB test loader – phase 1 builds tests in Standard if copying from 5.6 Phase 2 copies reference ranges to target MIC Procedure Prompt Loader MIC Organism Loader Meditech can customize loaders
Timing of Build and Testing Dependent on access Dependent on CMS decisions Timing of Lab to OM push – lab dictionaries should be cleaned up as much as possible prior to push Build was still in progress when we did integrated testing
Shared Build in Standard Coordination of test build is necessary between lab builders in target rings Recommend building new tests as active in Standard, but set CMS to propagate as inactive to target. Do this at beginning of build, to avoid confusion due to active tests which do not pertain to that target ring This will minimize problems when the Lab to OM push takes place
Lab Build must be Closely Coordinated with OM Determine responsibilities for each group (who builds Customer Defined Screens) OM Order Sets – setup process, differences in ordering from Order Set versus individual tests, future editing policies OM Categories (Lab Departments) - ordering by test name or category in PCS
Differences in Integration to OM Biggest benefit of 6.1 for Lab is that lab test build flows to OM & AMB. In CS, we built tests three times (Lab/OE/AMB) Custom flags & other issues can cause OM orders to not cross to Lab, or to allow orders of tests which should not be orderable Standard vs Target – what is built where LIS only field
LIS Only/OM/AMB Interactions
Collection Options in OM
Collection Process Nurse to collect Send phlebotomist to collect Has been collected Can default in response at category and test level Pre collection label - determines timing of order crossing to lab and printing label This build is all on the OM side
Education for Nursing on Lab Ordering and Collection How to order lab tests Marking as collected When orders will and will not cross to Lab Workflow is different if using Pre-collection labels
Locations and Label Printing Label printer setup in IT and LIS In LIS dictionaries, can set label printers by location or by PC Pre-Collection Label functionality set in OM Toolbox Parameters
BBK and PTH Conversions Conversions available for BBK and PTH historical data Validation process is labor intensive Allow several months or longer to complete Workaround in interim is access to histories in CS
Gaps & Wins Gap - Lost some client billing functionality which was available in 5.67 Win - Pathology now orderable from OM Win - Lab test build flows to OM and AMB
Imaging & Therapeutic Services Reports
Imaging Procedures Charging only procedures Outpatient Departments Wound/Ostomy EEG Nutrition Services Reports
CMS / Standard content Shared content with affiliates for Imaging procedures, Naming convention used for Reports which involves Document building for both PDoc and dictated Reports Radiologists read at multiple facilities Mammography = MM MR = MRI and MRA
Campus query Don’t need for acute Do need for ambulatory – Performing Site Performing Doctor Rule broke – started showing weird meds that shouldn’t have been there
Ambulatory billing One procedure built for all facilities Using ‘sites’ to assist with ordering in Web Ambulatory ITS Site references Revenue sites/Performing Location can use different billing numbers per site Preference is to send information to the Coder Worklist as Clinics do not want direct billing
Tracker Available in Priority pack 33 We will review this new feature when testing our next Priority Pack update Will need to evaluate space and a large monitor will work best in the Tech areas
Order Managment
OM
CMS Implications Timing of ancillary build/decisions Zynx Order sets integrated How to share updates? Mapping PHA entries using the PHA Utility Map items that are formulary at one facility but not others? Similar decisions in ITS/LAB
Set build In 5.67 added by mnemonic In 6.15 standard ordering lookup Kal in standards –all orders Which test/med to choose? Personal Target only Update
Differences Suggested sets Embedded sets No substitution Embedded sets Can’t embed collapsed Select all on orders on order sets Understanding and communicating the differences in ordering Tomorrow AM Could service time substitute Time was an issue with identifying gaps.
DME Durable Medical Equipment: partial list supplied in FDB data DME field in Amb drug dictionary, but doesn’t change required fields Web Amb drug concept- not modifiable No separation of output format
Dietary Clinical print screens
Home Med List
Home med conversion Dose ranges didn’t convert correctly-Resolved Zero dose v. See dose instructions-Resolved Have to dig to identify audit Pros: not starting from scratch Cons: bad data Recommendation: if proceeding, use caution
Allergy conversion A smoother conversion NKDA in Ambulatory wasn’t mapped properly Delay in recognizing and resolution
Discharge Document v Discharge Plan Provider view v Ancillary View Workflow decisions-which access point Signing of the ‘orders’/document Provider view v Ancillary View Same core components Customizable for provider Convert routine Consider highlight/required carefully
Discharge Transfer Swing Bed Multiple facilities New functionality Used at St Lukes Multiple facilities Used at Kalispell New functionality Better than restorable orders Code order issue Does not cross accounts.
Discharge Transfer
Recommendations Never have too much training Departments list- Make sure no one gets left behind! Assign HIT contact to each department Turnover can bite you (Meditech and internal staff)