We are going to build a RESTful server to share some data related with OpenMRS ID.
Here’s the our plan, besides the basic profile (well not much…), and some verified client could put their own data into our database, and share that with others(maybe).
Somehow as the developer, I’m rather confused about it… See, there is not much data on the Dashboard I can provide access to public… And since it’s developed for our Community, I’m wondering what kind of needs you want.
Just throw me anything you want, don’t be shy!!!
Update
You may see the details in the end of my Mid-term presentation.
Here
Wiehwa and I spent some time writing a draft specification for the OpenMRS ID API.
While it’s being edited, I’ve published it as a Google Doc: http://om.rs/idspec. We will eventually move it to the wiki when it’s stable.
Please comment on the spec with ideas about representing OpenMRS IDs in a RESTful way
To summarize that spec, here are the API endpoints we have:
/users - list of users. logical base for other endpoints
/users/:username - basic profile data
/users/:username/emails - email addresses
/users/:username/groups - user group membership (admin only)
/users/:username/mailinglists - mailing list subscriptions
/groups - list of all user groups (admin only)
/mailinglists - list of all mailing lists
All endpoints support CRUD operations (though many are limited by what we can and can’t technically do—for example the /users/:username endpoint only supports RU operations).
I’d be curious to hear if @burke has any feedback, or @paul and/or @ryan with regard to possible downstream use in the OpenHIE project. And of course, feedback from everyone else.
One thing that @paul and @ryan will be interested in (I’m guessing) is the ability to store 3rd-party application data (“extra” data according to the OpenMRS ID data model). That’s somewhere this spec still needs to be extended to.
