2009-08-27 Developers Conference Call

2009-08-27 Developers Conference Call

Date

27 August 2009

In Attendance

<!--

  • You
    -->

  • Mike Seaton

  • Ben Wolfe

  • Burke Mamlin

  • Paul Biondich

  • Saptarshi Purkayastha

  • Win Ribeka

  • Brian McKown

  • Darius Jazayeri

  • Justin Miranda

  • Hamish Fraser

  • Jeff Rafter

    • Jeff's son.

Agenda

Minutes

  • Modules to implement in India

    • Should try to migrate from various implementation specific Registration modules to a base OpenMRS Registration Module

    • Saptarshi has added image capture and other features to his GSoC Registration Module.

    • TODO: Saptarshi to upload Registration Module to a lab.

    • Billing Module: Other groups are interested as well.

      • TODO: Saptarshi ask other implementers on implementers mailing list regarding financial module.

    • OPD: Out-Patient Department

      • HtmlFormentry would be good... possibly enhance HtmlFormentry to work for OPD module.

      • Prompt or label on html form that includes tokens to work with logic service.

      • TODO: Saptarshi describe OPD requirements to dev mailing list so we could maybe build these features into HtmlFormentry.

    • Lab Tests and Results

      • Darius said: Reporting work will have a lot to show a week before Implementers meeting.

      • Darius said: DHIS export list of indicators as IXF and load into OpenMRS, linking indicators to calculation in OpenMRS and in OpenMRS prepare export to push to DHIS.

    • Jeff Rafter said: Baobab is working on an In-Patient Module.

      • TODO: Jeff will upload screenshots of In-Patient module.

      • TODO: Jeff will write to labs.openmrs.org and request what he needs for a lab.

    • Darius might lead a discussion on proposed changes to user, person, and patient

    • Discuss localization of internal data options (http://dev.openmrs.org/ticket/372) -Ben

  • Sync Hackathon:

    • Sync is running in module now.

    • Will fix a few bugs and move other things to module.

    • Jeff is willing to help on sync.

  • AmrsRegistration Module

    • Brian gave overview of Lab8 AmrsRegistrationModule

    • TODO: Brian mail dev list on Monday when version 1.0 is ready

    • TODO: Brian will prepare wiki page with screenshots of workflow of AmrsRegistrationModule

    • Darius mentioned that neither Java or Hibernate support multiple inheritence... hence you cannot have a user and a patient being the same person and be true to the programming language.

    • Roles would be collections of the underlying person.

    • Patient and User are roles of a person. We shouldn't need Hibernate magic to make that happen.

    • Add person_id attribute to both User and Patient could solve the problem.

      • Hence a proper foreign-key relationship as opposed to assuming person_id=patient_id=user_id.

    • Compromise:

      • Add person_id on User and Patient.

      • To start, we could have Patient extend Person in java, but User does not. User has a Person object as an attribute and all calls to User.getName() do getPerson.getName() under the hood in the User object

      • Have an Organizational Role that goes onto person (instead of only onto user which gets reused for privileges...which Burke hates)

    • Plan to describe work and agree upon it so the community can help

    • Sunny wants a job description or other org role on person as well. Right now they're using person_attributes for that

    • We want to stay out of too many Human Resource peices. Maybe that is where we could integrate with HRIS.

    • We need to localize columns like encounter_type.name.

    • Darius proposes a new table keyed on table name, primary key, and column name

    • Mike proposes that we put it all in the name column like: "en=Initial Visit;es=Initio Visita"

      • We would add a hibernate object that parses that and lets the pojo take care of localization

      • Burke says we could provide a database method for people doing raw sql queries against the effected table so that they don't have to see the localized string

      • EncounterType.getName() could call private EncounterType.getLocalizedName(Context.getLocale()) to keep things how they are now.

      • EncounterType.getNameByLocale(Locale) would call EncounterType.getLocalizedName(Locale)

      • TODO: Darius and Mike to write the decision in the ticket