Rehab Terminology

AROM: Active Range of Motion
PROM: Passive Range of Motion

OE Order Status (CS)

C - Complete
I - In Process
L - Logged
R - Resulted
S - Transmitted
T - Taken
U - Unverified
V - Verified
X - Xcancelled

National Provider Identifier (NPI)

NPI Website: http://www.cms.hhs.gov/NationalProvIdentstand/

MEDITECH Field: npi.number

MIS Query Types - CS

B - Blood Pressure
C - Comment
D - Date
G - Group
L - Label
M - Money
N - Number
O - Optional
P - Pointer
Q - Quantity
R - Result
S - Several
T - Time
V - View
X - Text
Y - Yes/No

Thank you to Randy Suinn @ Poudre Valley Health for pointing out the following:
C - does not word wrap; will F5
E - will word wrap, does not F5

EDM TidBits

Assessments are found under 'Patient Triage / Documentation' in CS EDM.

CS - NUR, PCS

Assessments are stored in the MIS Assessments Dictionary.

Abbreviations:
INT - Intervention
OTCM - Outcomes
PROB - Problems
POC - Plans of Care
ORD - Orders
SOC - Standard of Care

Variance Statuses:
JR - Justified Resolved
R - Resolved
U - Unresolved

Intervention: action taken to care for the patient.

If more than 1 Plan Of Care (CP, POC) is entered on a patient; then the duplicating interventions look like this in the NUR.PC.WORK occurrences structure:

$(N1)NPCW[aa]I[intv.no]O[1]
$(N1)NPCW[aa]I[intv.no]O[2]
$(N1)NPCW[aa]I[intv.no]O[3]

Spool Files

MIS Spooling Menu:
Download to PC: Transmit File
Send to FTP: FTP Menu -> Copy Spool File to FTP Index & Send

To print a report to a spool group, print to: SPOOL.

Pharmacy Sig Times – MIS Directions

Pharmacy Sig Times are usually keyed of the MIS Directions Dictionary (\GGW):

1) \GGW[sig code]F[facility most often .DFT]T

2) \GGW[sig code]F[facility most often .DFT]M[PHA or .DFT]T

US Doctors Need Records at time of Patient Visit?

"Once in the health-care system, 32% of U.S. patients suffered medical mistakes, the highest rate of the seven nations. That could be because the U.S. ranked last when it came to their doctors having access to their medical records at the time of an office visit."

Link: Business Week Web Reference

Personally, I wonder where the medical mistakes data is coming from and whether it was obtained from all patients or a sampling; it would be nice if Business Week made that clear. However, I have personally seen a huge effort to get physician's offices ramping up to get their patient's data integrated with local hospital health information systems. So ... maybe things are looking up for US?

ADM Tid Bits

Patient Type:
IN = A patient who has been assigned a room and bed (assumed overnight stay).
INo = An outpatient who is assigned a room and bed (room charge not automatic).
CLI = A clinical outpatient who registers for a single appointment (not a series).
ER = An outpatient who receives treatment in the ER.
POV = A patient who is entered into a Provider's EMR and visits the Provider's office.

Demo Recall Parameters of Interest:
If Pt's Addr Is Edited, Prompt User To Update Nok's Addr?
If Pt's Addr Is Edited, Prompt User To Update Ptn's Addr?
If Pt's Addr Is Edited, Prompt User To Update Guar's Addr?
If Pt's Employer Is Edited, Prompt User To Update Guar's Employer?
If Guar's Employer Is Edited, Prompt User To Update Employer Name/Loc?
If Pt's Addr Is Edited, Prompt User To Update Subscriber's Addr?

ADM Parameters of Interest:
- XQ Delete Days
- Midnite Run Start
- Reinstated Acct Log Purge
- Earliest BackDate Date

CS Account Index: ?(A)AAAI["acct.number"] = "aa.number"

CS Staffing & Scheduling

Schedule Status: DRAFT, HOLD, POSTED & CLOSED.

A draft schedule is auto created for each scheduling location by the system. The manager reviews the schedule using Change Schedule Status to HOLD while reviewing it. Once the manager's edits are done, the manager uses Change Schedule Status to POSTED. When the schedule is ready for purging, use Change Schedule Status to CLOSING. The system uses a purge delay before purging them. You can archive CLOSED schedules during the purge delay.

Printing MARs

0) PHA
1) Process Orders
2) Patient
3) Function = MAR

RAD Tid Bits

RAD Requisitions are the primary tool used to communicate image study information between clinical staff and radiology staff.

A typical requisition will have the patient name, medical record number & ordering clinician's information.

Example of modality types: X-Ray, Computed Tomography (CT), Ultrasound, and MRI Scanners. In Meditech, these are stored in the 'Exam Type' Dictionary.

Enabling a requisition:
0) RAD Dictionaries ->
1) UDF Form Modes -> Requisitions = U
2) User Defined Formats -> Requisitions -> Mnemonic & RW Format
While you can multiple (UDF) formats. The RAD Parameters determine which one is in play.

Changing Report Formats:
0) RAD Dictionaries ->
1) UDF Form Modes -> Requisitions = U
2) User Defined Formats -> Results -> RW Report Format
While you can multiple (UDF) formats. The RAD Parameters determine which one is in play. You can also define exceptions in the Exam Type Dictionary.

Report Entry: 13
Bolding: right control

Reprinting Requisitions:
0) ZCUS Menu
1) Front Desk
2) Print Duplicate Forms

UDF: User Defined Formats are defined in the User Defined Formats Dictionary under Dictionaries.

ACR: American College of Radiology

Problem: Printer prints for Meditech modules except RAD.
Resolve: Set printer up in the Meditech Destination Dictionary; using the same name as the printer.

Barcodes not printing on Requisitions? Are you using a dot matrix printer?

RAD Report Status Options: H (Held), D (Draft), F (Final), S (Signed)
Printing RAD Reports: Batch, Routed, Individually (ad hoc)

Looking up a patient:
- LastName,FirstName
- R# (Rad Number)
- Unit Number or MRN
- Accession (Exam) Number
- SSN (Social Security Number)
- Account Number

Changing a report to H (Held) status: enter N at the 'Advance Status to Draft' prompt after report text has been entered.

ACR Codes: this code is made up of an anatomy code and a pathology code. 10.3 for example.

Report Statii:
- "S" "Signed"
- "D" "Draft"
- "C" "Cancelled"
- "H" "Held"
- "F" "Final"

Accessing current rad report text: O(?,$MAC[$MAC]_:RAD.RPT[@report]).

BAR Tid Bits

@number in BAR is the ABS.PAT.account.number

Transaction Reminder Active (F9):
Data Element: BAR.PAT.txn.reminder.active
O = Open
R = Resolved
D =

PFS: patient financial billing services
CBR: client billing record

Patient Type:
CS 5.5 - I, O

Patient Status:
ER - Emergency Room
IN-OTHER - Inpatient Other
INP - Inpatient
NPR - Non Patient Account
OBSERV - Observation Pts
OUT - Outpatient
OUT-OTHER - Outpatient Other
POV - Physician Office Visit
PRE - Pre-admit
REC - Recurring Outpatient
SDC - Surgical Day Care

BAR Batch Item Types:
CHG - charge
RCP - receipt
ADJ - adjustment
REF - refund
BIL - bill
BLV
XFR - transfer
m - manual bill edit
v - reversed bill
p - prorate bill
q - prorate account

BAR Status:
BD - bad debt
CL - client
CR - client's patient
FB - final billed
IB - interim billed
UB - unbilled

BAR JOURNAL TYPES:
CASHIER
COLLECTION
GUAR COLL
REGULAR
GUAR CASH
CL COLL

Acronyms:
UR - Unbilled Receivable
AR - Accounts Receivable
UCR - Unique Reference Claim

UCR: Each transaction in a patient's file could theoretically have a different UCR.

:[BZ,xxxx,UCR,VAE123456789] = ^SAID^1^DATA^20050712^63.45
:[BZ,xxxx,UCR,VAE223456789] = ^SAID^1^DATA^20050712^63.45

BAR.(D OR M)STATS.ls.type:
1 - cash
2 - interim payments
3 - unbilled receivables
4 - accounts receivable
5 - bad debt
6 - client receivables
7 - refunds
8 - year end adjustment
9 - revenues
10 - expenses
11 - intercorporate transfers

BAR Transaction Class:
C appears to be dedicated to Charges
O appears to be everything else.

BAR Transaction (TXN) Codes
A - adjustment
B - bill print
C - charge
E - edit
F - claim
M - bill marker
P - refund
Q - ins bal edit between bills
R - receipt
S - statement
X - xfer
b - balance forward
c - comment
l - letter
m - manual edit of a bill
p - prorate a bill
q - prorate an account
r - reminder
s - summary of charges for client
t - client billing xfer from pt to client
u - total pt amount xferred to client
v - reversed bill
x - not used (aborted or deleted)

Insurance Claim Status:
D - dropped
F - failed
H - on hold
I - ineligible
P - printed
Z - zero

DRG Status:
A (admit) BAR.PAT.drg.status = 1
I (intermediate) BAR.PAT.drg.status = 2
F (final) BAR.PAT.drg.status = 3

Patient Balance: amount of self pay owed by patient.

Receipts = dollar amount insurance company paid.

Charity: can be applied as an adjustment after insurance payments have been received. Patient applies for charity and then the charity adjustment is applied. Charity Adjustments are located in the B/AR Procedure Dictionary (Non Charges). The insurance will most likely by Self Pay (SP) or STE. The Collector for Insurance will probably be a vendor like ACS; but collector for Charity could be something like Charity.

Collector codes can be looked up in the B/AR Collector Dictionary. The Collector Dictionary is where you can restrict collectors to specific insurance codes and account types. All patients have insurance of some kind. All insurance will have a collector. So you can use the BAR.PAT.bar.acct.collector.index and be assured that you are not skipping accounts due to an account not having an assigned collector.

View B/AR Account Transactions: Process Account -> Inquiry / List Formats -> All Collection Txns.

Use 2 indexes to improve report performance WHEN selecting on bar.status, insurance order, insurance & insurance collector.
- bar.acct.insurance.index ?BZIN[ggm,bzIO,bz]
ggm = insurance, bzIO = insurance.order, bz = account
- bar.acct.collector.index ?BZC[bc,bz]
bc = insurance.collector, bz = account
- bar.acct.bar.status.index ?BZS[bzST,bz]
bzST = bar.status, bz = account
*** It appears not all BAR accounts are included in the collector index.
*** So I'll be using the ins.collector in my select. ;-(

Typical Third Party Administrator (TPA) functions include gathering information, analysis, document preparation & conducting financial transactions.

Current Procedural Technology (CPT) Code Catalog: https://catalog.ama-assn.org/Catalog/cpt/cpt_search.jsp

Late Charges: a late charge is a charge made after Final Billing.

PHA Tid Bits

MAR: Main Menu / Dictionaries / Report

LABEL: Other Dictionaries / System Maintenance / Order Type

PHA Site Dictionary:
- Restrict to Facility
- GL Corp
- Rx Prefix

PHA Cus-Defined Params By Site:
- Default Inventory
- Default Access Group
- Drug ID Form Comment Lines
- Default GL Corporation
- BKG Transaction Limit
- BSA Calculation Definition
- Drops Per ML
- Mini Drops per ML
- Stop Time Offset
- Warning Messages
- Label Parameters
- eMAR Parameters

PHA Rules

The Pharmacy Rules are stored in: PHA.RX.zcus.rx.rule.

Abstracting

CMG: Case Mix Group
IRF: Medicare Inpatient Facility Assessment Instrument

Financial class is determined by a patient's insurance. Medicare, Workers Comp, Blue Shield, etc. These classes are maintained in the MIS Financial Class Dictionary. M might denote for Medicare for example.

ABS Status: INPROCESS,NONE,FINAL

DRG Status:
A (admit) BAR.PAT.drg.status = 1
I (intermediate) BAR.PAT.drg.status = 2
F (final) BAR.PAT.drg.status = 3

PAT Status: IN, CLI, ER, RCR, REF, SDC & POV.

BAR Status for an account: BD (bad debt), FB (final billed), IB (interim billed, UB (unbilled).

Lookups: DRG (diagnosis related group), CMG (case mix group), MCC (major clinical categories), APG (ambulatory patient grouping), APC (ambulatory payment classification)

OSHPD: http://www.oshpd.ca.gov/mircal/index.htm

A coder uses the ABS module to summarize important or necessary data elements for the purpose of charging, stats (required by various agencies) & archiving.

Meditech 6 & Focus

Does FS require more robust hardware? Read Cindy's post to the Meditech L on the subject: http://mtusers.blogspot.com/2008/01/meditech-l-no-subject_03.html.

FS stands for Functional System. The growing list of apps:

- POM
- PCS
- PCM
- EMR

Holyoke, MA & Doylestown, PA are the first 2 sites to beta Meditech Advanced Clinicals.


MagicFS Language From http://www.99-bottles-of-beer.net/language-meditech-magicfs-1045.html:

@OW,
100@XV@FV
@[@{@(@IF{=0 "No more"}," bottle",IF{~=1 "s"}," of beer on the wall, ",
@IF{=0 "no more"}," bottle",IF{~=1 "s"}," of beer"),
@IF{=0 "Go to the store and buy some more, 99 bottles of beer on the wall.";
@("Take one down and pass it around, ",
-1@IF{=0 "no more"}," bottle",IF{~=1 "s"}," of beer on the wall")},
""}]
@MV@Av@Wb@TW

Meditech Local Variables

Common parameters: A - Z

- XX, XXX
- ANS (pointer)

View Field NPR Information - Client Server

To identify the DPM, Segment, Field & Data Type for a Meditech Client Server field: SHIFT+F9.

Menus: Desktops & Sub-Menus

Desktop menus fill the screen. They present other desktops, sub-menus and NPR routines.

Sub-menus display their items as a list. The items on a sub-menu can be desktops, sub-menus and NPR routines.

Meditech Screen Attribute Dictionary

AFI: After Input Field Check
BFI: Before Input Field Check
CH: Choices
CHILD: Child of a multiple
DAT: Data Type
DFT: Default
DFTC: Control Field Default
DIS: Display
EDI: Edit Key Field
ERF: Erase Field Check
ERP: Erase Pre Field Check
FCL: Field Check
FCP: FCP Field Check
HLP: Help
ID: ID Lookup
IDT: ID Lookup Title
ID.ARG: ID Argument
ID.SEL: ID Select
IFE: If Expression
JFY: Justify
KEY: Special Function Key
LAB: Label
LABF: Label Field
LEN: Length
LNUM: Multiple Loop Number
MAP: Map Internal to External
MBVSKIP: Multiple By Value Skip Key Field
MUL: Multiple-by-Queue
MULSQN: Multiple-by-Queue Suppress Queue Number
MULV: Multiple View Only
NEXT: Next Section of a Multiple within a Multiple
PARENT: Parent of a Multiple within a Multiple
PRE: Pre Field Check
PREV: Previous Section of a Multiple within a Multiple
REQ: Required
REQI: Required Immediately
SAM: Sample Documentation
VAL: Value:
VALX: Value at Translation Time
ZSUP: Suppress Data Definition Printout

Meditech Filer

Calling the Meditech screen filer: @Screen(*,Z.file(^@main))

Patient Centered Systems PCS are used to assess the patient.

The assessment has query links to interventions so that the patient is treated for all problems instead of the chief complaint.

Diagnosis based systems treat the main problem first. PCS assesses the patient and then determines the plan of care.

A plan of care is your plan to care for a patient. A standard of care is a standard grouping of interventions that a particular unit provides for all patients on that unit.

Patient specific interventions are based on problems.

NUR - Add Problem vs Add Intervention

The ADD A PROBLEM intervention and screen is used to update the plan of care and plan eval screen.

If you AI ADD INTERVENTION instead of ADDING A PROBLEM, your plan of care won't get updated.

NUR - Screen Attached to Intervention

+ next to an intervention indicates that a screen is attached to that intervention.

NUR - Select Intervention by Status

SI from the NUR Process Interventions allows you to SELECT INTERVENTIONS by STATUS.

Branching Attributes on Screen Title

The idea of branching attribute code based on a screen title came about based on the need to execute attribute code on a NUR Document Now screen and not execute attribute code on a NUR Edit Screen. We reviewed the /SLASH file for each screen and found that the screen title variables contained the information needed.

Identify the text in /[.SCRN.TITLE,1] that you want to gate on.

Set up an IF{} statement to process code based on the absence or presence of code in these variables.

Sample attribute code:
-/.SCRN.TITLE[“”]^/EDT,
IF{(/EDT#L(/EDT,"Edit Previous")) ;
}

Meditech Variables

&[Z,@.appl] = /.APPL
&[Z,@.copy] = /copy
&[Z,@.country] = /.CNTRY
&[Z,@.db] = /.DB
&[Z,@.device] = /.DEV
&[Z,@.dir] = /.DIR
&[Z,@.exit.nks] = /exit.nks
&[Z,@.facility] = /.FAC
&[Z,@.gui] = /.GUI
&[Z,@.itn] = itn
&[Z,@.job] = /.JOB
&[Z,@.job.id] = /.JOB.ID
&[Z,@.line] = IF{/.LL-1^/.LL<1 %[/R.NEW.PAGE.PGM](0)}
&[Z,@.lines.left] = /.LL
&[Z,@.logical.device] = /.LOC
&[Z,@.lookup] = /.LK
&[Z,@.menu.arg] = /.MENU.ARG|0
&[Z,@.menu.tm] = /.MENU.TM
&[Z,@.mis] = /.MIS
&[Z,@.mouse] = /G.MSE
&[Z,@.mouse.argc] = /.mouse.argc
&[Z,@.mouse.col] = /G.MSEC
&[Z,@.mouse.dbl] = /G.MSEDB
&[Z,@.mouse.itn] = /G.MSEI
&[Z,@.mouse.last] = /G.MSEL
&[Z,@.mouse.row] = /G.MSER
&[Z,@.mri.pfx] = /.MPX
&[Z,@.new] = B
&[Z,@.new.ext] = A
&[Z,@.new.page.pgm] = /R.NEW.PAGE.PGM
&[Z,@.no.page.num] = /no.page.num
&[Z,@.no.page.save] = /no.page.save
&[Z,@.no.tbar] = /no.tbar
&[Z,@.now] = %Z.time.out(S(0)+/.TZO)
&[Z,@.nref] = /nref
&[Z,@.old] = D
&[Z,@.old.ext] = C
&[Z,@.on.device] = /.PRT
&[Z,@.pc] = /.PC
&[Z,@.response] = /S.A
&[Z,@.response.old] = /S.C
&[Z,@.row.offset] = /.P
&[Z,@.scrn.page.num] = /scrn.page.num
&[Z,@.scrn.tm] = /.SCRN.TM
&[Z,@.sd] = (S(0)+/.TZO)
&[Z,@.signon.tm] = /.SIGNON.TM
&[Z,@.sn] = S(0)
&[Z,@.system.base.year] = /.SBY
&[Z,@.time.zone.offset] = /.TZO
&[Z,@.today] = /.DAT
&[Z,@.update.today] = IF{""^/.DAT;%Z.date.in("T")^/.DAT}
&[Z,@.urn] = urn
&[Z,@.use.disk.temp] = /use.disk.temp
&[Z,@.user] = /.USR
&[Z,@Abs] = 1
&[Z,@Add] = 1
&[Z,@Bell] = 5
&[Z,@Blank.all] = 5

CDS Cursor Positioning

To do this on the same page, the basic idea is to put the cursor on the coordinates for that query.

IFE=/VAR^/[ANS%0,QUERY MNEMONIC]|0,P(R,S,/VAR)^#,""
/VAR^/[ANS%0,QUERY MNEMONIC]|0 populates the field behind the screen.
P(R,S,/VAR)^#,"" puts the cursor and data in the correct position on the screen.

I'm not sure on a solution that involves multiple screen pages.

Check String For Value

"TEST"^STRING,IF{STRING#L(STRING,"E") 1;2}

The first expression returns 1. STRING does contain an "E".

"TEST"^STRING,IF{STRING#L(STRING,"D") 1;2}

The second expression returns 2. STRING does not contain an "E".

Moving Customer Defined Screens

I noticed an interesting phenomenon while moving a screen from LIVE to TEST. There was a difference in the queries between LIVE & TEST. I moved the LIVE version back to TEST overwriting the one in TEST. When I checked the screen in the TEST MIS Screen Dictionary, LIVE & TEST were now in synch. When I ran a report against the mis.screen.fields segment in the MIS.SCREEN dpm TEST did not match LIVE. After refiling the screen from TEST, they matched.

It would appear that it is necessary to refile a screen after it has been moved for changes to take affect when the move overwrites another screen in the destination directory.

Prevent MediTech Screen Crashing

When programming screen attributes you can use the local symbol table or the /slash file to store data. The local symbol table is limited to 1K of data. The local symbol table will overflow and crash the screen if you exceed the 1K limit. Since MediTech uses the local symbol table, you have no idea how much data will be stored in the local symbol table.

Best Practice: Do not use the local symbol table for arrays. Using the /slash file is the preferred storage area for your values. The /slash file is allocated 1K at a time as needed.

Testing for Nil Values

In MediTech Magic, we have Nil values which are like Null values in the relational database world. A nil value is the absence of a value. If a variable has a nil value, it doesn't even exist.

To test for a Nil value you cannot perform the following logic:

IF{/SOMEVALUE="" DO SOMETHING}

To test for a Nil value in a variable, you can concatenate a known value like a period to the variable and then check to see if the period and variable are equal. If they are equal, the variable had a Nil value. If the equation is not equal you know that the variable was not Nil. The following logic is one valid way to check for a Nil value:

IF{/SOMEVALUE_.=. DO SOMETHING}

Introduction

Interesting problems and their solutions will be posted as they arise.