2009-10-08 Developers Conference Call
Date
8 October 2009
In Attendance
<!--
You
-->Mike Seaton
Justin Miranda
Burke Mamlin
Paul Biondich
Win Ribeka
Brian McKown
Ben Wolfe
Darius Jazayeri
Agenda
Core metadata (e.g. concept datatypes, concept classes) need to have the same UUIDs across different servers. We need a changeset for this.
"Random" ticket to discuss http://dev.openmrs.org/ticket/1044
Concept Name Tags
Look at Road Map
Talk about XForms module projects - Paul
Minutes
Core Metadata need to have same UUIDs across different servers.
Critical - needs to be in 1.5.1
Core Metadata:
All common Concept Datatypes
All common Concept Classes
Unknown User
Unknown Location
Default Superuser - Darius' 60% No vs. Burke's 73% Yes
Adult Initial Encounter Type
ID and Name are the same across implementations. (not necessarily date created)
Definitely NOT core metadata:
Possibly some day have the API use UUID to look up a core metadata.
Ticket #1842.
Logic Module
Need patch to remove logic items from core.. awaiting review.
Minimal documentation exists on how to use it.
Need to have a ConceptName-A-Thon - should have Andy Kanter in this.
TODO: Draft e-mail to OpenMRS DEV List about how to use Concept Names
Darius, if were to redo it, would rather add Prompt as a Form Field and not as a Concept Name (Prompt = The text the user sees on the Encounter Form)
Must address differences between what are Concept Names as opposed to Form Field Names
Could discuss this at AMIA - Andy Kanter will be there also.
Darius: like the model in SmartCare (by ?). Concept name is useless because it's not being used in any forms.
Darius: Obs need to point to form field where the obs came from.
Burke: Need to enhance form field and field data model to handle prompt so we don't need to use concept name in the form
Burke: ConceptNameTag doesn't have canonical name. When you use a Concept in a form the default prompt will come from ConceptName but you can modify the prompt to make the prompt more intuitive for the user. That means you're editing the form not the Concept itself.
TODO: Burke send email out to the dev list:
How to use concept name tag properly
Not all field are concept based
Meeting on AMIA to discuss this
Paul: The prompt should not bound to the concept because not all prompt will be concept based
Paul: XForm is a way to go for form entry system
Paul: Create OIP slot for Daniel to mentor more people to improve the XForm module. We need to define what we want to see out of the module, we need to shape the XForm module to a module that will be really useful to the community.
Darius:
Create a relative positioning for the form elements.
Wants to see the XForm renderer ( the magic behind the form )
Side Projects at AMPATH that can benefit - one approach is to make one of them operational.
Ben showed demo on XForms Module in Eldoret
Basic things work
Lot of global properties (could be a configuration page or a global properties portlet)
Things that we do not know if works or not:
Problem Added/Resolved
Cannot paint a form in a nice way: Such as add header, etc.
XForms standard specification does not handle style sheets, etc.
Just did a Google Search and found that Daniel has worked on this: See Purcforms.
TODO: Create XForms module component in Trac
TODO: Create project to harden Xforms to work seemlessly with OpenMRS 1.5 (Paul, Darius, Daniel, Ben to discuss this within the next week) Paul will send an e-mail to initiate.
TODO: Ben, Darius to add Xforms tickets. Ellen will build an XForm for PIH Lab 7
Who is Release Manager for 1.6 (... and silence...)
Want 1.6 to be beta before end of 2009
Logic should be stable release in 2010.
Darius is nominated to be Release Manager for 1.6
Synchronization supported as a module?
That is actually a 1.5.1 feature? Ben: This is a 1.6 feature that will be backported to 1.5.1.
Allow person to be both patient and user. See Ticket #1506
Logic implemented in a module. See Ticket #1626
Ability to store and use structured numeric concepts
Is in a branch. - Burke: Should aim at 1.7
"Random" ticket to discuss http://dev.openmrs.org/ticket/1044
Brian opposed to making this an abrupt change.
This could be in 2.0 - Brian thinks implementations should be given some path to prepare for such a huge data model change.
Darius concerned that we have given developer time to this and we should either implement it or reconsider how to classify tickets as being 'vetted' or 'approved'. Or 'raw' vs. 'well-formed' ideas.
That is to say, anyone in the community can tackle a ticket... but we need to make sure that we have a pathway to implement tickets or at least let people know whether this ticket has been 'vetted'.
Ben says could be a community managed process, but as soon as we have a 'ticket manager' we could manange the process better.