(Some scattered thoughts in case this is helpful.)
Back in ~2005 PIH did something like this in Rwanda, and we were calling it Bulk Entry. IIRC the idea is that you’d pick an HIV Treatment Group (this was a program state), and print out a one-page data collection sheet for them (with columns for weight, CD4, etc) and then at the end of the day you’d transcribe that one page of data into the bulk entry tool. So basically it looks like a spreadsheet.
It’s no longer used and I have on idea where to perform code archeology to find it. (But you wouldn’t want that code anyway.)
I agree that it’s a sometimes-useful feature.
If I were doing this today, I would consider doing this via spreadsheet upload. E.g. actually do the data entry into a spreadsheet, where the first column must be a patient identifier, and that treats its column headings as concept short names (or better, concept mappings).
Alternately, I would try to simplify the use case as much as possible (e.g. don’t support obs groups, and don’t support multiple copies of the same obs).
These days I can imagine a nifty modern UI where the data is actually submitted/saved row-by-row, but it feels super-fast to add a new row by just hitting tab at the end of the previous row, and then typing a patient identifier (or searching by name.) Though, in your case I guess you have a pre-configured set of patients, so you either want to populate this with a cohort, or a comma-separated list of patient ids.
The other thing you need to do is define which columns (i.e. concepts) to capture data for. The quickest way may be to leverage HTML Form Entry, and use the fact that it can read the schema of a form’s XML, and give you something nicely structured. That may be a bit of a hack though (and you’d have to ignore a bunch of tags). Or else you can define a whole new form entry technology with some simple way of defining its bulk entry forms. (Of course you know the downsides to that.)