2009-05-07 Developers Conference Call

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

<html><head><title></title></head><body>h1. Date

7 May 2009

In Attendance

  • Ben Wolfe

  • Burke Mamlin

  • Justin Miranda

  • Hamish Fraser

  • Mike Seaton

  • Darius Jazayeri

Agenda

  • Hamish wants to talk about meeting in Boston

  • Darius will bring up some thoughts on why encounter types should be concepts

  • Automatic liquibase updates need to go away. I have 5+ development environments and I always end up forgetting to switch the database in my runtime properties before deploying a version of trunk. This ends up killing my 1.4 database that took hours to import. I am proposing a flag set in runtime properties that disables the automatic update of the database. I will add a ticket and patch this week.

  • Sync updates

  • 1.5 alpha

Minutes

  • Meeting in Boston

    • There are many groups wanting to talk about their implementations or potential implementations in developing countries

    • 60+ people

    • Can break in 3-4 group easily and talk about technical issues, implementation issues, US issues, etc

    • How its been used dev countries + US, an overview of openmrs, highlight current implementations, where we are, how its designed/structured, a panel/broad discussion at end of morning for Q+A. an afternoon of breaking out. Have the people coming to this drive what they want to talk about.

    • TODO: Hamish to draft a schedule

  • Liquibase

    • Add liquibase to modules instead of sqldiff. <strike>TODO: Mike to create ticket</strike> - #1474

    • If liquibase updates haven't been applied at startup, a "maintenance page is shown". Have a user authenticate via jdbc as a System Developer and take them to a "perform these updates" page.

  • Darius's points on encounter types should be concepts

    • Malawi asked for concepts for all enc types because they wanted to store in the obs table an answer like: "type of scheduled return visit"

    • Either obs.value_coded should store things other than concepts or enc types become concepts

    • Burke: We should figure out what enc types are before we do anything.

    • Burke: In Kenya we use enc types as just "Adult Return", Adult Initial, Peds Return, etc

    • Darius: We use the same in Rwanda

    • Darius: We should talk about how encounter should be used.

      • How to model an entire visit?

        • See registration clerk

        • Vitals taken by a nurse

        • See doctor

        • See pharm to get meds

      • How to form a group of encounters?

    • Darius: We have concepts for each of our locations in lieu of value_location

    • Burke: We need value_coded to link to any kind of code set, not just concept.

    • Burke: Direct quote: You can turn anything into a thing.

    • Burke: Look to hl7. PV1.patient_class (recurring patient, n/a, unknown, emergency, in/out patient, preadmin) chap 3 table0004

      • Not helpful.

    • We need to model 1-n forms per encounter. But its a matza ball B

      • TODO: Burke create ticket for it. → #1476

  • Annotations for spring controllers are in trunk

    • Pro: You no longer have to have just one formbackingobject

    • Con: mappings are split up into different controllers instead of one xml file

    • Pro: Quick and easy to create new mappings/pages/controllers

  • Convenience methods on services

    • Darius wants PersonService.addPreferredName(Person person, String prefix, String given, String, middle, String family, String familyName2, String suffix)

    • Burke likes it

    • Ben does not

    • TODO ?

    • Investigate @Service Spring annotations

    • Investigate whether we can get rid of Service interfaces and just use classes

  • Crud for domain objects

    • We don't need Service.saveEncounterType/ServiceImpl.saveEncounterType/DAO.saveEncounterType/DAOImpl.saveEncounterType

    • We could reduce all of these down to Service.saveEncounterType/ServiceImpl.saveEncounterType/DAO.saveEncounterType/DAOImpl.saveEncounterType

  • Persistence of different objects

    • TODO: Ben look into possible solution

  • Transactions

    • Darius: transactions should be around the whole http request, not just each API save

    • TODO: Darius to look into possible solution

  • Sync updates

    • uuids has been merged to trunk

  • 1.5 alpha released

    • We need to do some testing

    • TODO: Darius to post the PIH's script for checking on things

  • Nightly trunk (bleeding edge) builds need to be put up somewhere: http://nightly.openmrs.org ?

</body></html>

</body></html>