The following tables contain information on the Kipu EMR + Kipu RCM integrated fields including the source of truth for each item.
Patient Information
Patient information is transferred to the RCM in two distinct ways.
- The first is when the initial connection is established. This is the first time the patient is sent from the EMR to the RCM, creating the admitted patient record in the RCM. This connection can be established by: creating the MR Number, clicking Manage Insurance, clicking Manage Review, or clicking Send to Avea.
- The second is when some fundamental demographic information has been changed. The patient demographic information will be resent to Avea when a new Diagnosis Code is added, when a Discharge/Transition Date is added, or when a user clicks Send to Avea.
Patient Information is one-directional (from EMR to RCM), so the EMR will be the source of truth for patient demographic information, and any updates needed should be made in the EMR and sent to RCM.
| EMR Field | RCM Location/Field | When is the info sent to the RCM? | Source of Truth |
| Patient ID | Patient > Profile > Patient ID | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| MR Number | Patient > Treatment Episode > Intake > Patient Profile > Medical Record Number | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Last Name, First, Middle Name | Patient > Profile > Last Name, First Name, Middle Initial | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Date of Birth | Patient > Profile > Birthday | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Birth Sex | Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > Gender | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Address, City, State, Zip | Patient > Treatment Episode > Intake > Patient Profile > Address, City, State, Zip Code | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Phone | Patient > Profile > Phone | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| SSN | Patient > Profile > Social Security Number | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Admission Date | Patient > Treatment Episode > Intake > Admit/Discharge > Admit Date and Admit Time | Upon establishing the initial connection or by clicking the Send to Avea button. | EMR |
| Discharge/ Transition Date | Patient > Treatment Episode > Intake > Admit/Discharge > Discharge Date and Discharge Time | Automatically, once the field is populated in the EMR. | EMR |
| Diagnosis | Patient > Treatment Episode > Intake > Behavioral/Standalone Diagnoses > Admitting Diagnosis & Principal Diagnosis | Automatically, once the field is populated in the EMR. | EMR |
Insurance Plans
Insurance information is added directly into the RCM from a pop-up window in the EMR by clicking the Manage Insurance button on the patient facesheet. The integration for insurance information flows from the RCM to the EMR, so the RCM is the source of truth for insurance information.
| EMR Location/Field | RCM Location/Field | When is the info sent to EMR? | Source of Truth |
| Insurance Information > Company | Patient > Treatment Episode > Intake > Insurance > Payer | When updates are saved in the RCM. | RCM |
| Insurance Information > Policy No. | Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > Insurance ID | When updates are saved in the RCM. | RCM |
| Insurance Information > Effective Date | Patient > Treatment Episode > Intake > Insurance > Effective Date | When updates are saved in the RCM. | RCM |
| Insurance Information > Insurance Priority | Patient > Treatment Episode > Intake > Insurance > Primary, Secondary, or Tertiary | When updates are saved in the RCM. | RCM |
| Insurance Information > Phone | Patient > Treatment Episode > Intake > Insurance > Insurance Set > Payer > Payer Phone | When updates are saved in the RCM. | RCM |
| Insurance Information > Subscriber | Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > (Subscriber) First Name & (Subscriber) Last Name | When updates are saved in the RCM. | RCM |
| Insurance Information > Relationship | Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > Patient Relationship to Insured | When updates are saved in the RCM. | RCM |
|
Insurance Information > SSN (Subscriber) Auto-populated for Self |
N/A if not Self | After clicking the Send to Avea button. | EMR |
|
Insurance Information > DOB (Subscriber) |
Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > (Subscriber) Birthday | When updates are saved in the RCM. | RCM |
|
Insurance Information > Gender (Subscriber) |
Patient > Treatment Episode > Intake > Insurance > Insurance Set > Policy Holder > (Subscriber) Gender | When updates are saved in the RCM. | RCM |
|
Insurance Information > Subscriber Address Street, City, Zip, State Auto-populated for Self |
N/A if not Self | After clicking the Send to Avea button. | EMR |
Authorizations
Authorizations are added directly into the RCM from a pop-up window in the EMR by clicking the Manage Review button on the patient facesheet. The integration for Authorization information flows from the RCM to the EMR, so the RCM is the source of truth for authorization information.
| EMR Location/Field | RCM Location/Field | When is the info sent to EMR? | Source of Truth |
| Patient > Information tab > Concurrent Reviews > Start Date | Patient > Treatment Episode > Scheduling and Utilization > UR > Start Date | When updates are saved in the RCM. | RCM |
| Concurrent Reviews > End Date | Patient > Treatment Episode > Scheduling and Utilization > UR > End Date | When updates are saved in RCM. | RCM |
| Concurrent Reviews > # of Days | Patient > Treatment Episode > Scheduling and Utilization > UR > Units | When updates are saved in RCM. | RCM |
| Concurrent Reviews > Auth date (auto-populated with Start Date) | Patient > Treatment Episode > Scheduling and Utilization > UR > Start Date | When updates are saved in RCM. | RCM |
| Concurrent Reviews > Authorization # | Patient > Treatment Episode > Scheduling and Utilization > UR > Authorization Number | When updates are saved in RCM. | RCM |
| Concurrent Reviews > Status |
Patient > Treatment Episode > Scheduling and Utilization > UR > Authorization Status Authorized and Authorized - Not Required statuses will appear as Approved in the EMR. |
When updates are saved in RCM. | RCM |
| Concurrent Reviews > Managed |
Will be set to:
|
N/A | EMR |
| Concurrent Reviews > Level of Care | Patient > Treatment Episode > Scheduling and Utilization > UR > Service | When updates are saved in RCM. | RCM |
| Concurrent Reviews > Next review | Patient > Treatment Episode > Scheduling and Utilization > UR > UM Follow-Up Date | When updates are saved in RCM. | RCM |
| Concurrent Reviews > Days of week (auto-populated from EMR Level of Care configuration) | N/A | N/A | EMR |
| Concurrent Reviews > Insurance | Patient > Treatment Episode > Scheduling and Utilization > UR > Payer | When updates are saved in RCM. | RCM |
Charges
The majority of charge data that appears on the Billing Report is not transferred to the RCM. This information is instead used to match the charges between the two systems. This allows the RCM to apply billing service profiles and claim rules more accurately, making it simpler to submit clean claims.
Because no demographic data is transferred with the billing report transmission, you must have transmitted the patient's complete profile to the RCM and added in the patient's insurance and authorization information (if required) before submitting charges to the RCM from the Billing Report.
| Data on the Billing Report | Transmitted to RCM? | Function |
| Date of Service | Yes | Appears on the Attendance Calendar |
| Admit Date | No | Used to match the patient's treatment episode between EMR and the RCM |
| Location | No | Used to match the patient's treatment episode between EMR and the RCM |
| Insurance | No | Used to match the patient's treatment episode between EMR and the RCM |
| Level of Care | No | Used to match to the Level of Care configured in the RCMwith a unique ID for that LOC shared between the two systems. Unlike ancillary codes, LOC can match based on the unique ID instead of service name. However, if the system cannot match based on the unique ID, the default code-matching process will occur. This means that the systems will look at the Service Description in the EMR and match that to the Service Name in the RCM so the best practice is to have them match exactly. If an exact match is not found, the system will attempt to match based on Revenue Code, Procedure Code, Modifier, and Claim Format (Institutional/Professional). |
| Codes | No | Codes are matched to the the RCM Service using the Service Description in the EMR and match that to the Service Name in RCM so the best practice is to have them match exactly. If an exact match is not found, the system will attempt to match based on Revenue Code, Procedure Code, Modifier, and Claim Format (Institutional/Professional). Additionally, the RCM will first look at insurance pay codes before attempting to match Private Pay codes. |
| Modifiers | No | Modifiers are not imported and are used as part of the charge-matching process. They are typically built directly into the code's profile and will be ignored if sent from the Billing Report if they don't match a particular service in the RCM. The best practice is to add the modifier in the RCM using a claim rule or directly on the service if needed. |
| Units | Yes | Every service comes into the RCM with a single unit (1) associated with it. If you transfer over multiple of the same services in a day (uncommon) each will have a single unit attached (e.g., 3 charges for OP Group Sessions transmitted will result in 3 units). |
| Claim Format | No | This is part of the charge matching logic and can help identify the claim format in the RCM but this field is not used to determine whether the claim will be billed as Institutional or Professional. This is determined within the RCM. |
| Rendering Provider | Yes | The Rendering Provider configured in the Konnector will be the Rendering Provider sent on most claims. Any charge with a blank Rendering Provider field on the Billing Report will automatically use the Konnector Rendering Provider. To bill a different provider as the Rendering Provider, they must be configured as the Rendering Provider on the Authorization (or Standalone Authorization for Ancillary Services) and selected on the Billing Report to transmit to the RCM. This is true for both Level of Care and Ancillary services. If the provider is not present in both places, the charge will not transmit. |
| Diagnosis Codes | No | These are included in the Patient Demographics and are only used to match charges. For Ancillary services, if you need to add an additional diagnosis code, please make the update on the patient record in the EMR and re-transmit the patient to the RCM before sending the charges from the Billing Report if you want those diagnosis codes to appear on the claim for that charge. |
| Place of Service | No | This field is used to map the charge to the correct service profile in the RCM as described in the Codes section. |
| Duration Met/Required Duration | No | This field is not mapped as all services come into the RCM with a single unit. Even if the required duration was not met and the charge was sent to the RCM, the service will be mapped with a single unit. |
| Program | No | Used to match the patient's treatment episode between EMR and the RCM. |