Eligibility Provider Interface

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?

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

@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