Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
Overview
Content Tools
Feedback on this page? Questions?
Copyright © 2004-2016 OpenMRS Inc. By using this site, you agree to the OpenMRS Privacy Policy.
Text is available under the Creative Commons 4.0 International Attribution License (CC BY 4.0).
Software is available under the Mozilla Public License 2.0 with Healthcare Disclaimer (MPL 2.0 HD).
"OpenMRS" is a registered trademark and the OpenMRS graphic logo is a trademark of OpenMRS Inc.
10 Comments
Michael Downey
If I am responsible for engineering quality assurance, I can't assure very much quality.
Andrew Kanter
I think most documentation would fall under Software Engineering. As for reporting, I think this falls under both Research and Content (since the report definitions themselves might be considered content but the purpose of the report is more related to use-case/outward facing relationship)
Chris Seebregts
As discussed on the call, I think it is important to have the office of the executive director represented as a box so that we can include the various functions that fall under that role and complete the picture in terms of a functioning organization. The typical role boxes could include resource mobilisation, strategy and operations, stakeholder relations and outreach, finance, admin, legal, public relations, ex officio on Board etc. (all the tasks Paul is mostly doing, already!)
Under software engineering, it may be an idea to have additional roles for linking to other software (not sure this is the correct name) e.g. DHIS, Mobile apps etc). This would entail working with other open source software organisations who want to link directly to OpenMRS to spec this out and move it through he development process. Perhaps having this role would have meant having the DHIS2 link sooner?
I am not sure documentation fits with the other two roles under content development, but also not sure where else to put it, unless a box of its own. It could be a big piece if done properly?
Jamie Thomas
At OpenMRS Camp14 we talked about the creation of a Software Testing Lea. Where will that role go?
Michael Downey
Hi Jamie Thomas ... That's probably the yellow box under engineering assigned to "Joseph Schnogenlocker".
Bill Lober
I see my name in a "Peer FOSS" section, under OpenELIS. I'd like to encourage some "growing together" of O/S in the lab space, and having OpenMRS reach out to the lab community, rather than to just one project, might be a nudge in that direction. 3 systems I can think of are: OpenELIS, BLIS, and Bika, and there may be others still on the "active list". Second thought, maybe Jan would be a better LIS representative than I would. Good thing to discuss next week?
Also, I might be a good liaison to either academia (though of course a number of us are academics), and/or to CDC/DGHA - I'm certainly not unique in having colleagues on the federal side, but I could ask Xen if he'd like me to make that role more explicitly part of my work with their group.
my other thought, Paul, interesting that (as is often the case) the technical roles are best defined, best filled out, best specified. I wonder if instead of the FOSS Peer liaisons, we should consider liaisons to groups working in strategically important areas with which OpenMRS data, OpenMRS software, and OpenMRS organization should interact. Instead of "DHIS/HISP", it would be "DHIS/HISP plus other M&E, Population Health interfaces". Instead of "OpenELIS" it would be "LIS: OpenELIS, BLIS, Bika, ..." Etc. Ditto Pharm. Ditto Logistics. My thought is that the mission would be a little more like keeping up with what's going on in an area and thinking about strategies and partners, rather than focusing only on one relationship. In some areas, DHIS, there probably is only one relationship, but there might be value in how it's labelled.
Burke Mamlin
Within Software Engineering, I could imagine things like:
Some of these could cut across other groups, but these groupings are meant to focus on the technical, developer-focused roles.
Bill Lober
To summarize my comments on the call - within partnerships, could think of relationships to Projects, Development Groups, or Sectors (eg., M&E/Population Health, Lab Info Systems, Pharm, Logistics).
While I don't like the term "Sectors", I do like that concept better than the other two, though Development Groups might need to be an exception in some cases - where a group works across several sectors/domains, for instance.
The partnership people would be the point of contact for those from different areas, if they had no place else to start with the community, but they would also have some responsibility for knowing who the participants were in a domain, and perhaps for reaching out to them periodically.
Burke Mamlin
Domains?
Bill Lober
I like "domains"
the software expression is "systems". The interoperability expression is "interfaces". The data expressions might be "domains". The organizational expression is "projects". I think domains is loose enough to account for all of them.
the liaison to the lab domain would be a point of contact for LIS developers, would know a little bit about the FOSS (and perhaps other) systems in use, would perhaps loosely track LIS projects and implementations and perhaps reach out to those projects when when appropriate, and would understand (and perhaps drive) OpenMRS' interface strategy to data in those domains.
Again, I see some domains of interest as
And, domain partnerships are not the only important partnerships.