Eligibility Provider Interface

OpenEMR Development
, ,
1

I am trying to flesh out how to move the system from the concrete implementation of src\src\EDI270.php.

I was reviewing creating an interface EDI270Interface that holds the contract on the methods that I needed to change in the EDI270 to make it work with WayStar. The EDI270 class should be changed to EDI270Availity. Then those classes can be put in src\Billing\Clearinghouse. @mdsupport @robert.down

In the src\Services\Billing directory, I created the EDI270EligibilityService class. This class can have a listener in it for modules that can switch out which clearinghouse should be used. This is my pseudo code.

@stephenwaite are you working on this already? Or do you know of someone that is working on this?

2

hi @juggernautsei , sounds great. I’m not and don’t know of anyone who is but would be glad to assist, thanks for reaching out.

1 Like
3

@juggernautsei, we don’t use this. From design perspective where intent is to provide eligibility check service, one can think of the following:

  1. abstract class eligCheck to provide default properties and methods for OpenEMR.
  2. inherited classes eligCheckX12 using generic X12 structures with eligCheckAvaility, eligCheckWayStar etc. to provide vendor specific property and/or method overrides (e.g. other HETS Vendors)
  3. interface eligCheckX12, eligCheckFHIR

That could put in place a structure that permits plugging in additional sources in future.

1 Like
4

@stephenwaite for the next move in the eligibility restructuring. I want to move the EDI270.php file into

|—>src
|---->Billing
|_______>EligibilityProcessor

I am testing all of what I do on our production system. The Eligibility provider for us is WayStar.
The reason that I am using Interfaces is to stay away from inheritance at the moment. It should be easy enough to relocate the EDI270.

Then the challenge will be to replace the static class call in the edi_270.php file with a concrete class that uses an interface.

Which clearinghouse is the EDI270 coded for? My idea is to change the name of the file to reflect which clearinghouse the class is for. The EDI270 will be the concrete implementation of the interface. So, in essence, I am trying to introduce polymorphism in this area.

These are my thoughts. Feel free to redirect me.

5

I did some research with Chatgpt and came up with the code below. This seems the cleanest way to call the class necessary to process the eligibility requests. I think this is what Jerry was hinting to do.

class SingletonRegistry
{
    private array $instances = [];

    public function getInstance($className)
    {
        if (!isset($this->instances[$className])) {
            $this->instances[$className] = new $className();
        }
        return $this->instances[$className];
    }
}

// Example classes
class A
{
    public static function toString($res, $X12info, $segTer, $compEleSep, $eFlag): string
    {
        return $res . $X12info . $segTer . $compEleSep . $eFlag;
    }
}

class B
{
    public static function toString($res, $X12info, $segTer, $compEleSep, $eFlag): string
    {
        return $res . $X12info . $segTer . $compEleSep . $eFlag;
    }
}

// Usage
$registry = new SingletonRegistry();
$instanceA = $registry->getInstance(A::class);
$instanceB = $registry->getInstance(B::class);

echo $instanceB->toString($res = 'a - ', $X12info = 'b - ', $segTer = 'c - ', $compEleSep = 'd - ', $eFlag = 'f');

I had to remove the

 private function __construct()
  {
  }

But if I change it to

 final public function __construct()
  {
  }

No fatal error.

PHP did not like this for some reason. Once removed the code returned nicely. I will be trying this out in our production system tomorrow.