Hi All, especially Mike, Burke, and Saptarshi,
While working on the Pentaho sprint, we've realized that it one key way to
help people populate data warehouses from OpenMRS without writing lots of
brittle SQL is to write a PDI plugin for Kettle that accesses OpenMRS data
via web services. We've always intended to have the Reporting module expose
the ability to evaluate cohorts and datasets via web service. This will be
broadly useful, but this sprint gives us an excuse to do it.
So, we want to let Reporting expose the list of available
CohortDefinitions, and DataSetDefinitions, and allow you to evaluate those,
RESTfully. Ben and I discussed this today and came up with two approaches,
so we wanted to get opinions about which way to go. Ben plans to code one
up tomorrow morning...
*Option A (Exposes more of the way the Reporting module really works. I
prefer this, though it may be more confusing.)*
*Definition Resources*
GET /ws/reportingrest/cohortdefinition -> list of all cohort definitions
GET /ws/reportingrest/cohortdefinition/UUID -> one particular cohort
definition
GET /ws/reportingrest/datasetdefinition -> list of all DSDs
GET /ws/reportingrest/datasetdefinition/UUID -> one particular DSD
Also allow definitions to be created and edited via POSTs
cohortdefinition resource:
uuid
name
description (in default)
list of parameters (in default)
href to /ws/reportingrest/evaluatedcohort/UUID // tells you how to
evaluate this
datasetdefinition is similar
*Definitions are evaluated via different resources*
*
*
GET /ws/reportingrest/evaluatedcohort // ERROR
GET /ws/reportingrest/evaluatedcohort/UUID // evaluate the cohortdefinition
with that UUID
GET /ws/reportingrest/evaluateddataset // ERROR
GET /ws/reportingrest/evaluateddataset/UUID?date=2011-01-01 // evaluate a
DSD that has a "date" parameter against all patients
GET /ws/reportingrest/evaluateddataset/UUID?cohort=UUID&date=2011-01-01 //
evaluate a DSD with a parameter against a specified cohort
evaluateddataset resource:
uuid // of the underlying DSD
metadata // column definitions, etc
rows // either a list of lists (in the order of the columns in
metadata) or a list of column.name -> cell value maps
*Option B (Simpler, and doesn't expose the key definition/evaluated
distinction from Reporting. Ben prefers this.)*
*
*
*A single resource for each definition/evaluated pair*
*
*
GET /ws/reportingrest/cohort -> list all cohort definitions (as v=ref)
GET /ws/reportingrest/cohort/UUID -> specific definition (as v=default)
GET /ws/reportingrest/cohort/UUID?v=evaluated -> expensive operation;
evaluates the cohort and includes the result as a "members" property
GET /ws/reportingrest/cohort?v=evaluated -> ERROR
cohort resource
uuid // of the cohortDefinition
name
description (in v=default)
members (in v=evaluated)
evaluationContext (in v=evaluated)
GET /ws/reportingrest/dataset -> list all DSDs (as v=ref)
GET /ws/reportingrest/dataset/UUID -> specific DSD (as v=default)
GET /ws/reportingrest/dataset/UUID?v=evaluated -> evaluates the DSD
GET /ws/reportingrest/dataset/UUID?v=evaluated&date=2011-01-01 -> evalutes
DSD with a date parameter
GET /ws/reportingrest/dataset/UUID?v=evaluated&cohort=UUID -> evaluates DSD
against a specified cohort
This doesn't lend itself to letting you create cohort definitions or DSDs
by POSTing to WS, at least not via these resources.
-Darius
_________________________________________
To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to
[email protected] with "SIGNOFF openmrs-devel-l" in the body (not
the subject) of your e-mail.
[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
