Cohort forming
Medical Records Review
Help an advocate gather, organize, and read a client’s medical records to prove the fact the legal matter turns on, with the client’s health information protected throughout.
Help an advocate gather, organize, and read a client’s medical records to prove the fact the legal matter turns on, with the client’s health information protected throughout.
This page is the shared target for this situation. Any court, legal aid office, or builder working on it in their own region can take the vision, the blueprints, and the standards here instead of starting over, and set the parts that are local to them. The point is that the same work is not designed from scratch in every county.
Does this match how it goes where you are? Leave a note on this workflow.
Legal aid advocates use a client’s medical records to prove a fact the legal matter turns on. In a disability benefits case, the fact is that the client cannot work. In a disability rights matter, it may be the client’s need for an accommodation. In a medical legal partnership, it may be the link between a client’s housing conditions and their health.
Advocates gather, organize, and read these records by hand, and the work is slow and repetitive. Technology could take on parts of it, as long as the results are accurate and the client’s health information stays protected.
The work follows the same stages in each setting. The advocate finds the sources, requests the records and tracks them, collects and prepares what arrives, organizes it, reads it and pulls out the findings, checks what is missing, applies the findings to the legal question, and then uses and protects the records.
Several of those stages can be handled by ordinary software that follows fixed rules, and only some call for an AI model. Keeping the two apart makes each one easier to test and easier to replace later.
Medical records are protected health information. An advocate needs to know how a tool stores, uses, and shares the data before putting a client’s file into it, and a program needs a practice for telling clients that AI is being used and for handling a client who opts out.
Most advocates do the review by hand. They read page by page, highlight, and type notes into a spreadsheet, a Word document, or a paper file. Some use keyword search in a PDF reader to move faster. A careful advocate builds an index while reading, logging page numbers by section and flagging findings, and then uses the index to navigate the record. Practice varies from advocate to advocate.
The requests are logged and the outstanding ones are visible. What arrives is turned into searchable text with page numbers, the duplicates are found, and the records are sorted by provider and date. The advocate gets a chronology where every entry cites the right page, the missing providers and the treatment gaps are flagged, and the findings are mapped to the legal standard with a page behind every claim. Access is limited and logged throughout, and a client who opts out of AI is kept out of it.
This is one vision, taken from a write-up of how this work goes today and which stages technology could take on. Technology could play out in other ways here, and the cohort weighs them against this one.
Who this serves: Legal aid advocates in disability benefits cases, disability rights matters, and medical legal partnerships, the paralegals and students who prepare the records, the clients whose health information it is, and the programs deciding whether to buy a tool for this.
Where this came from: A write-up of this workflow covering how the work goes today, what advocates say they need, and which stages technology could take on. This page is built from those materials. The cohort for this area picks it up from here.
The step-by-step agenda is open for review now. The cohort writes the functional agenda and the standards from the answers that come back, and this page carries them when they exist.
What a system here has to do, written as the work in order and in plain words, with the question the Commons team wants answered about each part. Start here if you review these records and want to say what a tool needs.
Read the step-by-step agenda →What the system must do, stage by stage, saying for each one whether the work calls for ordinary software following fixed rules or for an AI model. The specification has to carry the tests as well: a test client’s history to check the provider list against, planted duplicates and planted missing providers, and a check that every entry in a chronology cites the right page.
How anyone judges whether a builder did this well: whether every entry in the chronology is correct and cites the right page, whether planted duplicates are found and distinct pages are kept, whether planted missing providers and treatment gaps are flagged, whether every claim cites a page that supports it, and whether access is limited and logged.
The rest of the package follows once those two exist. It covers the baseline numbers, the procurement and contract terms, including the questions to ask a vendor about security, permissions, and system setup, the reference architecture, which says what any program can take as it is and what each one has to set for itself, the stories and materials from teams who have already built something here, and the tests.
The public benefits cohort is forming now, and this is the first workflow in front of it. Members bring what they have seen in their own practice, argue about what a tool here has to do, and read the drafts.