Resources

Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Resources

Page tree
Skip to end of metadata
  • Created by user-5cf01, last modified on 2010-08-18
Go to start of metadata

<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>

Feedback on this page? Questions?

Visit OpenMRS Talk, our community discussion hub.

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.