Skip to main content

Electronic prescription enrollment (eRX)

Komodo Care Connect supports integrations with third-party vendors to facilitate the creation of care plans. With the electronic prescription enrollment (eRX) feature, vendors can pass in a JSON payload to the eRX API (PJN_ErxApi) to enroll a patient into a care program and submit any required or relevant enrollment information. There are specific key-value pairs that are allowed in the JSON payload out of the box, but you can configure additional objects and fields to be keys in the request body. The JSON payload that is passed and the status of the care plan that is created from the eRX API call are both stored in an eRX Request (mvn_­_­PJN_­eRX_­Request_­_­c) record. When the Care Plan (Case) record is created, all of the information in the JSON payload will be stored in related records. Any files in the JSON payload will also be added to the Care Plan record. The files roll up to the care plan via the eRx Request (PJN_eRx_Request) File Rollup Setting (mvn__PJN_File_Rollup_Setting__mdt) metadata record, which is triggered by the After Update: File Rollup - eRX (PJN_After_Update_File_Rollup_eRX) Trigger Handler Setting (mvn__PJN_Trigger_Handler_Setting__mdt) metadata record. To help prevent eRX from creating multiple records with the same information or with information that already exists, deduplication logic are available out of the box, but custom deduplication logic can also be created.

Warning

To call the eRX API, integration users must have the following permission set licenses and permission sets. For more information on how to set up an integration user, reference Create a new integration user.

  • Health Cloud permission set license

  • Health Cloud Platform permission set license

  • Salesforce API Integration permission set license

  • Health Cloud Foundation permission set

  • Health Cloud Member Services permission set

  • Health Cloud Permission Set License permission set

  • Health Cloud Standard permission set (cloned without Visualforce Page Access)

  • KCC - Feature - eRx Integration User (PJN_KCC_Feature_eRx_Integration_User) permission set

Configure additional JSON payload keys

The JSON payload to be passed into the eRX API allows several key-value pairs out of the box. For the list of required and optional keys and values, reference Table 168, “JSON payload attributes”. You can configure additional key-value pairs to be allowed in the JSON payload.

To configure additional keys in the JSON payload that vendors can use to submit more information in a care plan enrollment:

Note

You do not need to perform the following steps for the key-value pairs that are available in the JSON payload out of the box.

  1. Create an eRX Vendor (mvn__PJN_eRX_Vendor__mdt) metadata record for each care program that the eRX feature can enable enrollment for.

  2. Create an eRX Object (mvn__PJN_eRX_Object__mdt) metadata record for each object that the eRX feature can create records for upon a patient's enrollment into a care program.

  3. Create an eRX Field (mvn__PJN_eRX_Field__mdt) metadata record for each field that the eRX feature can populate values for upon a patient's enrollment into a care program.

Example 7. Configuration to track the closest city to a patient

To check for the closest city that a patient lives near when enrolling a patient into a fictitious care program called Kalytex (KTX), you can configure the following sample metadata records and values. The JSON payload in the Sample request body uses the following configuration.

Table 158. Sample mvn__PJN_eRX_Vendor__mdt record for Kalytex

Field label

Sample value

Name

MVN_KTX_VENDOR

Program

Kalytex

Note

This looks up to an existing Program (mvn__PJN_Program__mdt) metadata record called Kalytex.



Table 159. Sample mvn__PJN_eRX_Object__mdt record for closest city

Field label

Sample value

API Name

mvn__PJN_Contact_Information__c

Record Type API Name

PJN_Address



Table 160. Sample mvn__PJN_eRX_Field__mdt record for closest city

Field label

Sample value

API Name

mvn__MVN_eRx_Closest_City__c

Note

This references a custom field on the Contact Information object.

JSON Key

closestCity

Type

string

Length

30

Vendor

The eRX Vendor metadata record created in Table 158, “Sample mvn__PJN_eRX_Vendor__mdt record for Kalytex” above.

Object

The eRX Object metadata record created in Table 159, “Sample mvn__PJN_eRX_Object__mdt record for closest city”

Personas Record Types

PJN_Patient;PJN_Caregiver





Example 8. Configuration to gather information for PAP

To gather information about a patient's eligibility for a Patient Assistance Program (PAP) when enrolling a patient into a fictitious care program called Kalytex (KTX), you can configure the following sample metadata records and values. The JSON payload in the Sample request body uses the following configuration.

Table 161. Sample mvn__PJN_eRX_Vendor__mdt record for Kalytex

Field label

Sample value

Name

MVN_KTX_VENDOR

Program

Kalytex

Note

This looks up to an existing Program (mvn__PJN_Program__mdt) metadata record called Kalytex.



Table 162. Sample mvn__PJN_eRX_Object__mdt record for PAP

Field label

Sample value

API Name

mvn__PJN_Assistance_Program__c

Path To Care Plan

PJN_Care_Plan__r

Record Type API Name

PJN_Patient_Assistance_Program



Table 163. Sample mvn__PJN_eRX_Field__mdt record for household income

Field label

Sample value

API Name

mvn__PJN_Estimated_Household_Income__c

JSON Key

householdIncome

Type

integer

Length

8

Vendor

The eRX Vendor metadata record created in Table 158, “Sample mvn__PJN_eRX_Vendor__mdt record for Kalytex” above.

Object

The eRX Object metadata record created in Table 162, “Sample mvn__PJN_eRX_Object__mdt record for PAP”



Table 164. Sample mvn__PJN_eRX_Field__mdt record for household size

Field label

Sample value

API Name

mvn__PJN_Estimated_Household_Size__c

JSON Key

householdSize

Type

integer

Length

2

Vendor

The eRX Vendor metadata record created in Table 161, “Sample mvn__PJN_eRX_Vendor__mdt record for Kalytex” above.

Object

The eRX Object metadata record created in Table 162, “Sample mvn__PJN_eRX_Object__mdt record for PAP”





Deduplication logic

A general deduplication logic and a patient deduplication logic are available out of the box to help prevent eRX from creating multiple records with the same information or with information that already exists. You can configure the records that should be checked and/or updated by the default deduplication logic, and you can create custom deduplication logic to be used in place of the default deduplication logic.

Configure general deduplication logic

The default general deduplication logic defines a record as a duplicate if there exists another record in Komodo Care Connect of the same record type with the same value on a given field. If a duplicate record is found, the existing record can either be overwritten or be left as is. In both scenarios, the existing record is related to the new Care Plan (Case) record created by eRX.

There are two parts to configuring the records that should be checked and/or updated by the default general deduplication logic.

Note

The deduplication of patient accounts requires a different set of configuration steps. For more information, reference the Configure patient deduplication logic section below.

  • For every field on an object that should be checked for an existing record with the same value, set the Is Deduplication Field (mvn__PJN_Is_Deduplication_Field__c) field on the corresponding eRX Field (mvn__PJN_eRX_Field__mdt) metadata record to true; if a field's value does not need to be checked, set the Is Deduplication Field checkbox to false.

  • For every record type of an object that should be updated if an existing record with duplicate information is found, set the Overwrite (mvn__PJN_Overwrite__c) field on the corresponding eRX Object (mvn__PJN_eRX_Object__mdt) metadata record to true; if a record should not be updated with newly submitted information, set the Overwrite checkbox to false.

Create custom deduplication logic

To create a custom deduplication logic for all records other than Account records of the Patient (PJN_Patient) record type:

  1. Create a duplicate handler implementing the eRX Dedupe Interface (PJN_ErxDedupeIntf). The class should implement the getMatches(erxObject, fields, data, conditions) method, which returns a list of duplicate records based on a set of provided criteria.

  2. On the eRX Object (mvn__PJN_eRX_Object__mdt) metadata record of the object that should be checked for duplicate information, set the Dedupe Interface (mvn__PJN_Dedupe_Interface__c) field with the name of the duplicate handler created in step 1.

    Note

    The handler for the default deduplication logic is PJN_ErxMatchingService. If the Dedupe Interface field is left empty, then the default PJN_ErxMatchingService handler is used.

Configure patient deduplication logic

The patient deduplication logic does not have a default configuration that defines a patient account as a duplicate, so matching and duplicate rules must be created for the patient deduplication logic to determine when a patient account is considered to be a duplicate. If a potential duplicate patient account is found, a patient merge request is automatically initiated, and users can use the Patient Merge Tool to merge the records. (Since the patient merge request has already been created, users could immediately continue from step 2 when using the Patient Merge Tool.)

Warning

Keep in the mind of the following special considerations when configuring and using Komodo Care Connect's patient deduplication logic:

  • The patient deduplication logic uses Salesforce's matching and duplicate rules that do not work with probabilistic encryption. (This will be addressed in the prerequisite step below.)

  • The patient deduplication logic runs all duplicate rules on the Account object via the PJN_After_Update_Patient_Duplicate and PJN_After_Insert_Patient_Duplicate trigger handlers. If a duplicate rule has been configured on the Account object for functionality unrelated to patient deduplication and is inadvertently used for the eRX feature, you may deactivate the triggers on the Trigger Handler Setting (mvn__PJN_Trigger_Handler_Setting__mdt) custom metadata type and create custom triggers instead.

  • The patient deduplication logic uses Salesforce's FindDuplicatesResult class that has an input array limit of 50 elements. This means that the PJN_After_Update_Patient_Duplicate and PJN_After_Insert_Patient_Duplicate trigger handlers will only run the deduplication logic on the first 50 patient accounts that are detected and ignore any additional patient Account records.

To configure the patient deduplication logic and add criteria for defining a duplicate patient account:

  1. (Prerequisite) Ensure that the Account fields to be used to check for duplicate patient accounts are either unencrypted or deterministically encrypted case insensitive. For more information, reference Salesforce's documentation on how to Apply Encryption to Fields Used in Matching Rules.

  2. Create a matching rule for patient accounts. For more information, reference Salesforce's documentation on Matching Rules.

  3. Create a duplicate rule for patient accounts. For more information, reference Salesforce's documentation on Duplicate Rules.