A Plan for the Federal Courts CM/ECF

 

Alpine Texas Federal Courthouse

The US Government General Services Administration’s 18F Team performed an “11-week Path Analysis on the federal judiciary’s Case Management and Electronic Case Files (CM/ECF) system. Our research focused on user needs, business agility, organization and processes, and the Administrative Office of the U.S. Courts’ (AO) culture and legal mandates.”

We discuss below.

 

---

First, thank you Jason Tashea via his Justice Tech Download system once again for the notice.  The full PDF reports from the GSA can be viewed/downloaded here.

In summary GSA’s 18F unit (I can’t get my head around this name, sorry) wrote:

“Our synthesis of the information we gathered from 100+ participants across 77+ sessions shows the pain points (i.e., specific problems users are experiencing) of the current state of CM/ECF:

• Unsatisfactory user experiences for both internal CM/ECF and external Public Access to Court Electronic Records (PACER) users.
• Court business needs are not being met, resulting in 200+ software versions with many local modification.
• Although nearly all courts have upgraded to the Next Generation of CM/ECF (NextGen) or signed up to do so, more than 50 courts have not yet gone live on NextGen.
• The foundational technology is outdated, and some components are becoming obsolete; it is not sustainable.
• Decentralization and complexity are causing system instability, high maintenance costs and security risks.
• Current contracts make it difficult to hold contractors accountable to quality standards.

From my friends in and working with the US Federal Courts these criticisms seem to be generally “on point”.

18F then wrote that they recommended “the following path forward for the judiciary" that listed the following summary: 

• Build a new, open-source system with modern technology and architecture.
• Some components of the new system could be built in-house, but for others, it may be more cost-effective and efficient to use contractors who have relevant domain expertise.
• Consider cloud computing as an option.
• Simplify AO operations and encourage courts to innovate through Application Program Interfaces (APIs).
• Design strong data standards and investigate a data catalog and governance framework.
• Align database schemas across all court types and adopt a new database type that can handle multimedia and other large files. PACER should share the same database.
• Adopt a DevSecOps culture to support the integration of security and operations concerns at every phase of the software development lifecycle; from the architectural design phase through, testing, deployment, delivery, and production.
• Stand up a new cross-departmental and cross-functional team to develop and maintain the new national system for courts. This team will need some domain-knowledge support but should be empowered to build the new system independently.
• Incorporate a Quality Assurance and Surveillance Plan (QASP) in contracts to hold contractors accountable for quality deliverables and continue using the time and materials (T&M) contract type.
• Meet with CM/ECF stakeholders to leverage their domain expertise during planning and building phases.

Some comments.

First, there have been several excellent studies and the resulting report of the CM/ECF stakeholders.  I think that any meetings with them can use perhaps a compilation and modernization of those reports. And if you are going to talk to the stakeholders, perhaps one can study successes that have been accomplished by the state and other international courts.  There are some very good ones out there.  In other words, do not just look inward.

Second, contractor accountability.  The courts don’t change their business processes and work very much from year to year.  The CMS framework simply needs to allow for customization of organizational structure, work roles, events and tasks, and documents by each court.  Scheduling frameworks can similarly be customized.  So, for the contractors, the court can define and award fixed-price contracts with confidence in my opinion.

Third, cloud development is a no-brainer.  Any new system should be built with that technology as a foundation as can support improved “DevSecOps”.

Fourth, strong data standards.  I’m not sure what that really means as the data field definitions can be standardized.  But the workflow and the local customizations will govern the data entered in the fields.  I don’t think that standardizing a lot of field data really achieves the underlying goal of better data analytics.  It is the documents that can do that (as I wrote about before here and am planning to do again next week). 

Fifth, in that same vein, updating the core database technology is very much needed and could benefit PACER.  As new databases have vastly improved capabilities to deal with document size data fields I agree.

Sixth, I would suggest that pure Agile development is not needed.  Instead, well-understood components can be used to guide the development.  See the CITOC bulletin on this concept at: https://www.ncsc.org/__data/assets/pdf_file/0034/18979/nextgen-court-component-model-2017-12-08-final.pdf

Last, I like the framework/development approach suggest (with caveats).

It is a worthwhile report to read.