Release Date: December 31, 2018
- Diagnosis-Related Grouper extension now properly provides DRG Weight. Was previously null in all situations.
- Service Item now provides HCPCS code if no CPT code. Was previously only CPT code.
- Separate Person (P) file.
- PERSON and subordinate records will no longer appear in Encounter (4) file.
- Two new person extensions: Account and Account Daily Balance.
- Discontinue (MJMC) Insured Person Alias and (MJMC) Guarantor Person Alias. Continue (MJMC) Person Alias.
- Add Delete (D) file for deleted encounters. Handles automatic deletion of non-surviving encounters in combines, and encounters that change datasets.
- Add ENCUBVAL, ENCUBCON, ENCUBOCC standard records.
- Add UDL (MJMC) Billing Entity.
- Modify field sequence in Medication and Price Schedule UDLs.
- Fix Service Item HCPCS field to show CPT if no HCPCS code.
- Service Item Detail shows both discretely.
- Add RVUs to Service Item Detail.
- Add Coding and Abstracting status, date, personnel to Encounter Detail.
- Add (MJMC) Service Item Reason extension
- Replaces ENCSIREA standard record
- Performance improvement (~40%) over previous code.
- Allow non-physicians to appear in File 3 (practitioners).
- Fix Diagnosis-Related Group extension to report DRG Weight.
- Add pref to exclude historical clinical procedures (e.g. patient history).
- 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).
- Master program object renamed to “MJM_MASTER”.
- Qualification of encounters for extraction now require a pft_encntr record to exist and be active.
- 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.)
- ADT Transactions can be used for qualification again.
- 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.
- 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).
- Previous audit reports will not query from the new table objects.
- MJM_CANDIDATE will require periodic purge of person candidate records. This can be performed by MJMC via service request (purge program forthcoming).
Scope and Limitations
When upgrading to v4.1 or later, the interface contains functionality to automatically delete encounters that have become inactive or changed dataset. This functionality relies on extraction history. This version also contains new tables to log extraction history. Therefore, a full re-extract and reload into new datasets is necessary to establish this history. This process also ensures all previous encounters that required deletion are not re-extracted.
When upgrading to v4.1 or later, the interface contains modified functions for providing data in text format. While extensive testing was performed to ensure these data are provided the same as before, some slight changes may be observed. For example, monetary amounts may have previously used floating point decimal values that included up to 9 digits to the right of the decimal, and may now only include 2 digits (cents), and vice versa. Where possible, more precision was provided. However, in some circumstances, precision may have been reduced where it previously was not representative of the actual precision. Client is advised to test total charges, payments, and adjustments to ensure the amounts remain accurate to client’s standard.
Reload of Data
- Cerner Millennium
- CHANGE Healthcare Performance Analytics
- Cerner CCL
v18.0 and newer
rev 8.11.xx and later