2009-10-08 Developers Conference Call

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment

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(question)
      • Unknown Location
      • Default Superuser(question) - 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.
  • Concept Name Tags
    • 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
  • XForms Module
    • 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
  • Road Map
    • 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.