How to configure for ClaimMD Eligibility Check

Management and Administration
1

Good day to all,

I’ve been scouring the boards and trying to figure out how to create an Eligibility processing format (batch and individual: “Insurance > Update Status”) when using ClaimMD. I’m finding quite a bit of information concerning Office Ally and I see the following Processing format(s) when creating X12 Partners:

  • oa_eligibility
  • availity_eligibility

However, since we’re using ClaimMD, I’m stuck, trying to figure out what I need to do in order to get the eligibility checks to work with a ClaimMD configuration.

I’m able to successfully generate and export X12 files, upload, etc. to ClaimMD without any problems at all. Once manually uploaded to ClaimMD, I can perform eligibility checks as well, viewing a multitude of returned information.

I’ve checked off the: Administration > Globals > Connectors: “Enable Office Ally Insurance Eligibility” … just for starters. However, I don’t know which modifications are needed after that for ClaimMD functionality.

Can someone please nudge me in the right direction regarding what I need to do to get this to work with ClaimMD? Thanks

2

OpenEMR: Version Number: v5.0.2 (1)

I solved my issues regarding single eligibility checks using Claim.MD.

This particular post led me in the right direction:

Eligibility Checks & Clearinghouses

Where Kyle states:

“It did require a few changes to edi.inc and edi_270.php.”

I started with edi.inc. I made several modifications:

First of all, my 270 submission to Claim.MD was failing due to missing an NPI value. Here are the 271 results:

<result>
<error error_code="430" error_mesg="Provider NPI [XX] has not been configured in Claim.MD." />
</result>

I resolved the above error by changing the following line:

From this:

170: $NM1[8] = "XX";

To this:

170: $NM1[8] = $row['provider_npi'];

Next, I stumbled across this stack overflow post:

It was brought to my attention that the:

“Passing in the “body” request option as an array to send a POST request has been deprecated.”

The example code provided in the post led me to modify the following lines:

From this:

826: $response = oeHttp::bodyFormat('body')
             ->usingHeaders($headers)
             ->post('https://www.claim.md/services/elig/', $mime_body); // @TODO put request urls in x12 partner's for versatility.

To this:

826: $response = oeHttp::bodyFormat('form_params')
             ->post('https://www.claim.md/services/elig/', [
                 'AccountKey' => 'XXXxxxClaimMD_APIKEYxxxXXX',
                 'UserID' => 'ClaimMD_UserID',
                 'File' => $x12_270,
         ]); // @TODO put request urls in x12 partner's for versatility.

I also added this line:

now line 838: $xml = simplexml_load_string($formBody);

Because the format of the Claim.MD 271 reply is much different than what was originally expected:

I comment out these lines (formerly starting at line 838):

/**

        if (!$cksum) {
            $errors .= "Error:" . xlt("Request Content Fails Integrity Test");
          }
        if ($response->status() !== 200) {
            $errors .= "\nError:" . xlt("Http Error") . ": " . $response->getReasonPhrase() .  " : " . $response->status();
       }
    if ($formData['ErrorCode'] != "Success") {
        $errors .= "\nError:" . $formData['ErrorCode'] . "\n" . $formData['ErrorMessage'];
    }
    if ($errors) {
        $errors .= $formData['Payload'] ? "\nError:" . $formData['Payload'] : '';
        return $errors;
    }

*/

… and replaced them with these:

if ($response->status() !== 200) {
    $errors .= "\nError:" . xlt("Http Error") . ": " . $response->getReasonPhrase() .  " : " . $response->status();
}
if (!empty($xml->error[error_code])) {
    $errors .= "\nError:" . $xml->error[error_code] . "\n" . $xml->error[error_mesg];
}

if ($errors) {
    $errors .= $formBody ? "\nError:" . $formBody : '';
    return $errors;
}

Since I’m not using the mimeParse function on the 271 response from Claim.MD:

I changed this (formerly starting at line 854):

return $x12_271;

To this:

return $formBody;

With the above changes, I have an acceptable 271 Eligibility response.

However, I’m currently working out an issue with Claim.MD support where their 271 Eligibility Response is missing Subscriber Demographic Information.

Specifically, the following 2 Element IDs:

  • DMG02, Subscriber Birth Date
  • DMG03, Subscriber Gender Code

Because of that, OpenEMR throws the following error:

Error: Unknown Transaction Error Maybe Subscriber Effective or DOB Date

I’m temporarily resolving this problem by appending some logic within this function (formerly line 891):

function parseEdi271($content)

Since we already have a handle on the policy number, I perform a quick lookup to obtain the DOB:

"SELECT subscriber_DOB FROM insurance_data WHERE policy_number LIKE ?";

I store the DOB value in a variable and only use it when DOB is missing from the 271 Eligibility Response.

NOTE: I haven’t even ventured into bulk Eligibility Requests yet. I believe I will have to look a little closer at the edi_270.php.

Maybe these quick modifications might be able to assist those having similar issues.

All the best!

Henry

3

OA doesn’t allow batch request so I set up batch as internal individual requests i.e I do the batching by submitting one after another.

You could go ahead and steal the Availity provider flag in x12 partner setup and use it for ClaimMD workflow. This way you won’t have to keep up with custom.

1 Like
4

Thanks for the heads up regarding the approach to batch requests and the suggestion about using the Availity provider flag.

Everything is looking great so far. I truly appreciate every effort gone into making OpenEMR what it is today. I’ll do my best to make whatever contribution that I can to support this community.

By the way, the missing subscriber demographic info seems to be related to ClaimMD’s 270/271 testing environment. The production environment returns the 271 response just fine. They’re still working on resolving the testing results issue.