An advocate needs a client’s medical records to prove the fact the legal matter turns on. Here is what a good system does, in order, with a question for you at each step.
Several stages here 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, so each part below says which kind of technology the work calls for.
Answer the questions on the parts you know from your own practice. The Commons team reads every answer, fixes what the list gets wrong, and takes the harder questions to the cohort working on this area.
The advocate works out which providers, clinics, hospitals, and agencies hold the client’s records. Everything after this is checked against that list, and a provider nobody names is a provider nobody requests from. An AI model or a guided interview can do this work.
What a good system does
Prompt the client and the advocate for providers they may have missed.
Keep the list open while the case runs, since new treatment happens during it.
Hold the list where the later stages can check against it.
What it must never do
Treat the list as complete when the client has not been asked.
Which providers do your clients forget about?
Answer this
Part 2
Requesting the records and tracking them
The advocate sends signed releases and requests, follows up, and keeps a log of what has arrived. Knowing which requests are still outstanding, and when to follow up, is the whole job here. Fixed rules can do this work.
What a good system does
Log the requests, send the reminders, and record what arrived.
Show which requests are still outstanding and when to follow up.
Keep the log matched to the requests actually sent and received.
What does your request log have to show you?
Answer this
Part 3
Collecting and preparing what arrives
Records come by mail, fax, portal, agency download, and from the client. The advocate turns them into searchable files with page numbers, because every citation later depends on those numbers. Fixed rules can do this work.
What a good system does
Convert paper and fax to searchable text and number the pages.
Get the text and the page numbers right on scanned and handwritten pages.
Say which pages it could not read.
What it must never do
Present text it could not read as text it read.
What arrives in a form your tools cannot read?
Answer this
Part 4
Organizing the records
The advocate removes duplicates and sorts the records by provider and date. The same pages arrive from a provider and from an agency file, and somebody has to sort out which pages are new. Fixed rules find the exact duplicates, and a model is only needed for the near ones.
What a good system does
Find exact and near duplicate pages, and sort the records by provider and date.
Keep the distinct pages, since two pages that look alike are not always the same page.
Show the advocate what it set aside as a duplicate.
What it must never do
Drop a page as a duplicate where the advocate cannot see that it did.
Where do the duplicate pages in your files come from?
Answer this
Part 5
Reading the records and pulling out what matters
The advocate reads the records, pulls out the findings, and builds an index or a chronology with page citations. A careful advocate builds that index while reading, logging page numbers by section and flagging findings, and then uses the index to navigate the record. This stage calls for an AI model.
What a good system does
Summarize the records and build a chronology with page citations.
Make every entry correct and cite the right page.
Log the page numbers by section and flag the findings, so the index can be used to navigate the record.
What it must never do
Invent content.
Leave out something important.
What do you pull out of a record first?
Answer this
Part 6
Checking what is missing
The advocate compares what arrived against what should exist, including treatment gaps inside the records. Knowing that information is absent from a record is as much a finding as anything in it. Fixed rules do the comparison, and a model is needed for the gaps inside the records.
What a good system does
Compare the records received against the provider list.
Flag the gaps in treatment inside the records.
Say when information is absent from a record.
What it must never do
Report a complete record while a provider on the list has sent nothing.
What is usually missing when the records arrive?
Answer this
Part 7
Applying the records to the legal question
The advocate connects the findings to the legal standard in the matter and may ask a treating provider for a statement. 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 the client’s housing conditions and their health. This stage calls for an AI model, with the advocate reviewing what it produces.
What a good system does
Map the findings to the legal standard in the matter.
Draft the brief, or the request for a provider’s statement, for the advocate to review.
Make every claim cite a page that supports it.
What it must never do
Produce a claim with no page behind it.
Which fact does your case turn on, and where in the record is it?
Answer this
Part 8
Using the records and protecting them
The advocate cites the records in filings, letters, or negotiations, and keeps them stored and shared only as the client’s consent and the law allow. Medical records are protected health information, and an advocate needs to know how a tool stores, uses, and shares the data before putting a client’s file into it.
What a good system does
Control access, log who opened the records, and honor a client’s choice to opt out of AI.
Say how the tool stores, uses, and shares the data, in terms a program can check before any client file goes in.
Keep a file whose client has opted out away from the AI tools.
What it must never do
Take a client’s protected health information into a tool whose handling of it nobody has checked.
What does your program require before a client’s record goes into a tool?
Answer this
Part 9
Putting it in front of staff and clients
A tool that works still has to reach a program. The cost includes the time spent on permissions, user accounts, and preparing records before the tool can use them, and the program has to be able to tell a client that AI is being used.
What a good system does
Give the program a practice for telling clients that AI is being used, and for handling a client who opts out.
Give the program the questions to ask a vendor about security, permissions, and system setup.
Say what the setup and the administration actually take, including permissions, user accounts, and preparing the records.
Give the program a way to introduce the tool without staff feeling that they are being replaced.
What it must never do
Leave a program with no answer about whether the vendor will still be operating next year.
What would your staff need to hear before this arrived in their week?
Answer this
Part 10
Knowing whether it works
Each stage has its own test, which is what keeping the fixed rules and the model apart buys. A test client’s history, with duplicates and missing providers planted in it, is enough to run most of them.
What a good system does
Check the provider list against the providers in a test client’s history.
Check the request log against the requests actually sent and received.
Check the text and the page numbers on scanned and handwritten pages.
Plant duplicates, and check that they are found and that the distinct pages are kept.
Check that every entry in the chronology is correct and cites the right page.
Plant missing providers and treatment gaps, and check that they are flagged.
Check that every claim cites a page that supports it.
Check that access is limited and logged, and that opted-out files stay out of the AI tools.
What would you need to see before you put a client’s record through this?
Answer this
What happens to what you write
Every note comes to the Commons team. We read it, correct what this list gets wrong, and publish a new version saying what changed. The questions that need practitioners to argue them out go to the cohort for this area, which writes the detailed specification from what comes back.
A note about one line is as useful as a note that adds a whole step. If what you know is how your program handles a client who opts out, write about that.
The two agendas for this workflow
You are reading this one
Step-by-step agenda
This is the first round, and it collects what the people who do this work say a tool has to do, in the order the work happens and in plain words. Read it to argue with it, to correct it, and to say what your jurisdiction needs.
Not written yet
Functional agenda
The cohort writes the detailed specification after this round, using the answers that come back from this page. It numbers every capability, states the standard each one has to meet, and sorts them by the scope of the system being built, so a builder can build against it and an evaluator can test against it.
