Great! Re conferencing technology, does someone have an uberconference account that they can use to host this meeting?
I have a Webex account that will accommodate everyone, but I’d rather keep using the tool we use. But I logged into uberconference and it wouldn’t give me permissions to do anything significant.
UberConference also offers free accounts for individuals. The only main difference (as far as I know) is a free/personal account requires a PIN and doesn’t have international and/or toll-free phone numbers.
did we want to place this on the openMRS calendar? i wasn’t on the leadership call today but i thought that we had decided to make sure that these meetings are posted there also. If that is the case, perhaps someone can post?
We had a solid discussion of some of the major points today – see the notes page (link just above) for a summary, as well as the document (also linked above) in evolution. We will continue to update the document and merge the notes into the document where applicable.
We are going to set up one more live meeting. I have sent out a Doodle poll to those already on this list. Others can participate in the Doodle poll at http://doodle.com/poll/5dnqghhp2b4wa7kf
looks like the poll doesn’t use time zones, so I answered it as if it was East Coast time. I checked with @janflowers and I think she used Pacific, so one of us will adjust their answers when that is clarified.
Yeah, I remember clicking that link and setting the dropdown that ensued, but somehow it missed it. And you can’t change the setting once the poll is finalized. So rather than start a new one and generate more confusion, we’ll stick with this, and I will rely on the computer-savvy and global-savvy skills of our group.
Mike and I had a chat after the meeting that I wanted to share the main
points of (and maybe he can expound):
Building one application with all the following characteristics is is very
hard/expensive:
lots of features
solves the midsize clinic/hospital use case
solves the PEPFAR-funded ARV site use case
works well out of the box
backwards compatible
highly configurable
extensible by not-very-coordinated devs
consistent style and look and feel
dev process is very welcoming
good place for experimentation (gsoc, etc)
One approach is to commit ourselves to delivering all these
characteristics, but not necessarily all together in the same
application/distribution.
Specifically, the “Community Distribution” does not have to be the same
thing as the “recommended hospital distribution” or the “recommended HIV
clinic distribution”.
It sounds like some of these are issues for the document, and others are issues that could be left undecided within the document for further discussion.
Is the idea that these will be debated in Singapore, or mainly just presented?
I think that the question of whether “one community distro, +/- some
recommended distros (depending on purpose)” vs “one reference application
to rule them all” is a good one to debate in Singapore.
I think that before Singapore we should have an initial proposal of
OpenMRS’s goals and activities in 2016 for Objective #2 without strictly
specifying which of those model’s is right. We should be able to do this,
if we stay focused on that output.
Don’t forget to fill out the Doodle poll, @darius, @burke, @mseaton, @maurya, @akanter if you want to participate in the next live meeting. I’d like to finalize a time by tomorrow.
about what is in the distort. I do believe that there is a core functionality that is essential to the delivery of care-- and therefore essential to any distribution. that functionality would probably include the following from the list above
works well out of the box
backwards compatible
highly configurable
extensible by not-very-coordinated devs
consistent style and look and feel
dev process is very welcoming ( i am not sure that i know what this means)
good place for experimentation (gsoc, etc) ( at least at the edges)
BUT, i would include non technical specs for this - clinical functionality that we know that anyone who delivers care would want. That ‘functionality’ can be fairly limited to start, but the distro should ensure that other ‘core’ clinical functions are on the glide path. To ask everyone to design/program/replicate these core clinical features may result in time spent on ‘core’ that could be better spent on specific and unique functionality required by individual circumstances ( for instance, HIV or OB functionality)
if you’re following just this thread, but not Objective 2, please take a look at this post regarding assessment of distributions, whether there should be a single reference application, etc.