The typical flow of HTML Form Entry is to enter data for a single patient in a single form. However we are running into a situation where data is entered for multiple patients who are in a pre-defined group, on a single form, which has to be captured as is, but individual encounters recorded for each patient (I think).
Has any-one run into this situation, and if so how did you approach it?
I wonder what kind of use case this is! 
With some of the tools that we are working with you enter the same data for a group of patients, and have to create individual encounters for each patient.
(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.)
This sounds like it could tie in nicely with the outcomes of the RESTful Submission of Forms in HTML Form Entry GSoC project. Once you’re able to submit HTML forms through a REST API, this should open up possibilities for bulk form entry through an OWA with spreadsheet upload or a modern UI as Darius has suggested, by mapping rows to html forms, and POSTing each row/form through the API successively.
This can be a big plus, though I’m not sure about including this as a primary goal of GSoC project. Extra credit. Maybe?
Agreed, likely too much work to include in the scope of the GSoC project (but I like your idea of adding this under extra credit). I guess my comment was directed more at @ssmusoke, to say that if he’s willing to wait a while, this work could provide a starting point to build out a bulk form entry OWA.