The only lists of data available are metadata lists, for configuration, however I would like to suggest that we add views of the following:

Encounters - with filters for patients, encounter types, encounter start and end dates and the ability to export the data into Excel and CSV (Data tables already has this capability and is used in Data Integrity module)

Observations - with filter for patients, encounter types, encounter start and end dates, observation types (these are the concepts for only the data that has been collected)

Encounter Observations - a de-normalized list of the observations in an encounter (which is an extension of 1 and 2 above). I am fine with having this as a separate page which is only accessed for a single encounter or a single patient for performance reasons

I have received requests for exporting all the encounters for a patient and rather than write a report I believe this will provide the necessary solution.

Is there any design reason why data is not displayed in this form within OpenMRS?

For the reason as to why this is not in place, it is a result of not being able to know needs for each and every implementation. That is why a generic reporting module was created such that you can use it to come up with a solution to the above.But when various implementations start asking for similar kinds of reports out of the box, then there comes what is being worked on as built in reports.

For the reason as to why this is not in place, it is a result of not being able to know needs for each and every implementation. That is why a generic reporting module was created such that you can use it to come up with a solution to the above.
But when various implementations start asking for similar kinds of reports out of the box, then there comes what is being worked on as built in reports.

I think the default would be provide a de-normalized view of the data by encounter type (which seems to have the same concepts) to be meaningful.

@ssmusoke I would say that if you can provide a very concrete description of the first most valuable thing, then others can comment on whether they agree with this, and we can evolve to a consensus on what/how to build.

@ssmusoke: you created this thread talking about tabular views of OpenMRS data, and clearly you have some specific ideas in mind around it. But I’m not sure that others are getting those same ideas.
So, put together a quick mockup (even in text), or just describe how the screen might look.

And then this will export a row-per-encounter spreadsheet, with a few patient details, and also with all the obs values flattened out.

Just to point out that including the obs values is technically difficult because of repeating obs and obs groups. How would you want those to work?

(Though actually I see that there’s an EncounterAndObsDataSetEvaluator already in the reporting module, so maybe the best thing to do is to just build a thin UI wrapper around calling this, and see if that’s sufficient.)

I don’t know if last year’s GSoC built-in reports module complete enough to be a good starting point for this. If not, just writing an OWA with a few UI widgets, that then calls Reporting REST should be pretty easy for someone to build.