Enhancements

1. Separate Person (P) file.
   1. PERSON and subordinate records will no longer appear in Encounter (4) file.
2. Two new person extensions:  Account and Account Daily Balance.
   1. Discontinue (MJMC) Insured Person Alias and (MJMC) Guarantor Person Alias.  Continue (MJMC) Person Alias.
3. Add Delete (D) file for deleted encounters. Handles automatic deletion of non-surviving encounters in combines, and encounters that change datasets.
4. Add ENCUBVAL, ENCUBCON, ENCUBOCC standard records.
5. Add UDL (MJMC) Billing Entity.
6. Modify field sequence in Medication and Price Schedule UDLs.
7. Fix Service Item HCPCS field to show CPT if no HCPCS code.
   1. Service Item Detail shows both discretely.
8. Add RVUs to Service Item Detail.
9. Add Coding and Abstracting status, date, personnel to Encounter Detail.
10. Add (MJMC) Service Item Reason extension
    1. Replaces ENCSIREA standard record
11. Performance improvement (~40%) over previous code.
12. Allow non-physicians to appear in File 3 (practitioners).
13. Fix Diagnosis-Related Group extension to report DRG Weight.
14. Add pref to exclude historical clinical procedures (e.g. patient history).
15. New custom tables added, begin with “MJM”.  Full extract history now written to logging tables (including Program Run and Qualified).  Improvement to performance tracking (time to extract, number of records, size of encounter).
16. Master program object renamed to “MJM_MASTER”.
17. Qualification of encounters for extraction now require a pft_encntr record to exist and be active.
18. Extraction from Encounter and Person tables are no longer required to be active or effective.  (Qualification of encounters and persons must still be active and effective.)
19. ADT Transactions can be used for qualification again.
20. Added functionality to support qualifying encounters based on database activity using the Millennium+ Database Architecture model (aka txn_id_text). This provides an alternate method for qualifying activity occurring in the database, in addition to last_utc_ts.  This functionality is for future use should it be required.  We do not recommend turning this on unless it becomes necessary in the future.
21. Screen echoes and program naming / numbering improved.

(MJMC) Health Plan Detail

• Field 39:  indicates how ENCPAYH-3 field was manipulated
  • -1 – COB Numbering in progress (should not appear in output unless there was an error in renumbering)
  • 0 – COB number not evaluated
  • 1 – No benefit order, no COB.  “1” used for COB.
  • 2 – Keep COB, no invalid (voided) benefit orders
  • 3 – Keep COB, renumber invalid (voided) benefit orders
  • 4 – Complex renumbering
• Field 40:  sequence of letters representing how the COB was processed.  One letter for each benefit order for same plan.
  • Letters used for debugging process.  Log support ticket if detail needed.
• Field 41:  Multiple COBs found for same plan.  This means that the same plan had multiple active benefit orders but did not have the same priority sequence (COB) in each benefit order.  This will cause complex renumbering to occur.
  • 0 – Not a multiple plan occurrence.  Same COB found in all active benefit orders for this plan.
  • 1 – Multiple occurs this plan.  Different COBs found in different active benefit orders for this plan.  Will trigger complex COB renumbering for all plans.
• Field 42:  How the encounter-plan relationship record was found for this health plan.  The encounter-plan relationship record is the insurance information entered by the registration clerk.  Normally, Patient Accounting stores a link back to this information but occasionally this link is missing in Cerner (possible defect?).  Since the encounter-plan relationship record stored the member id and group number, we make attempt multiple methods to locate this record.  This field indicates which method was used (in decreasing order of confidence).
  • 1 – Foreign key on BO_HP_RELTN.  The direct link exists and was used.  High confidence.
  • 2 – Search on EPlR w/ Plan + COB.  The direct link is missing, but a single record was located using the health_plan_id and priority sequence.  Moderate confidence.
  • 3 – Search on EPlR w/ Plan only.  The direct link is missing, but a single record was located using the health_plan_id only.  The COB does not match.  Lowest confidence.

(MJMC) Diagnosis-Related Grouper

• Field 24:  total estimated reimbursement value.  This is what the DRG encoder estimates the encounter is worth.  This is not payor-specific.  Supplied only if the DRG encoder supplies it to Cerner.
• Field 25:  total reimbursement value.  Typically not populated by the encoder.

(MJMC) Service Item Detail

• Field 77:  RVU Match Method.  The RVU is not stored directly on the charge but instead must be looked up against the RVU content in Cerner upon each extraction.  This field indicates how the RVU was matched.  All RVU matches must have at least a CPT on the charge, and the service date must fall within the effective dates of the RVU.  A CPT modifier is optionally used to further hone the RVU match, but is not required.
  • -1 – Charge has CPT, no modifier, and matched RVU on CPT, no modifier (direct match).
  • 0 – Charge has no CPT, or has CPT but no match in RVU + service date (no match).
  • 1 – Charge has CPT, with modifier, matched an RVU on CPT + modifier (direct match).
  • 2 – Charge has CPT, with modifier, matched an RVU on CPT only; no RVU existed with that CPT + modifier (indirect match).