What will it take to interface with eFileIL?

Set up the necessary infrastructure which our CMS and EFSP will use to integrate with the EFM

Without wasting time on explaining a pile of acronyms, let's just say that our existing web services use REST technology rather than the SOAP technology used by eFileIL.  REST vs. SOAP is a common debate in the software biz (you can read more here, if you want), but the bottom line is that we have are implementing new tools to create the required interfaces.

eFileIL does offer guidance on SOAP use.  But they only do soy for some programming languages, and that doesn't include Java, which we (and the majority of web companies) use.  

Scope which affects the CMS (16 web services)

Since we already handled e-filing all the way from filer through Clerk, we will have to rip out of Judici and CMS the features which will now be handled by the EFM (e.g. filing fee collection, electronic service and filing review). 

Implement the web services associated with the actual electronic filing process

9 web services

This is the integration diagram which eFileIL uses  to show some of the actual e-filing web services which the CMS must support in order to work with the EFM.

Implement administration web services for access to EFM System Codes which the CMS/EFSP must support

7 web services

In order to work with the EFM, everyone needs to "speak its language", using various code lists:

  • Court Locations
  • Error Codes
  • Country Codes
  • State Codes
  • Filing Status Codes
  • Data Field Configuration Codes- over 20 different codes which control things like whether filings subsequent to case initiation can new parties to existing cases.
  • Service Type Codes

PC JIMS Inbox changes

For example:
  • Dealing with eFileIL "filing envelopes", which let teh filers submit more than one filing at a time on a single case
  • Will we allow for rejection of filings in the Inbox, given that the Clerk would call eFileIL to straighten them out (because the EFM will not allow any response message other than success)?
  • Handling pro se litigants- Judici may leave this to other EFSPs, but the Inbox will have to be changed. 

Scope which affects the EFSP (over 30 web services)

Implement administration web services for access to Court Specific Codes which the EFSP must use

1 web service call, but it provides 8 different "lookup tables" for the EFM codes applicable to our CMS

These make sure that all filings speak the same language as the AOIC or a given court chooses when customizing their implementation

  • Case Category Codes- NA
  • Case Type Codes (CH, L, etc))
  • Party Type Codes (plaintiff, defendant, etc)
  • Filing Codes- eFileIL says this will be a standard list statewide
  • Filing Component Codes (lead document, attachment)
  • Document Type Codes
  • File Type Codes (pdf, docx, etc)
  • Optional Services Codes- NA
  • Filer Type Codes
  • Procedure/Remedy Codes- NA
  • Damage Amount Codes
  • Name Suffix Codes- NA

Administrative processes to keep the EFM in sync with changes made by filers on the EFSP

30 web services total

The EFM is in charge of payments and service, but the EFSPs all accept direction from filers about what credit card to use or who to serve on a case.  So the EFM has to be kept updated.

  • Managing the Firm's Users- we have to support 10 different web services
  • Managing a Firm- 2 web services
  • Managing Attorneys- 5 web services
  • Managing Service Contacts- 5 web services
  • Using Service Contacts-- 2 web services
  • Managing Payment Accounts- 6 web services
  • Global Payment Accounts- not required, and we won't need these