Child pages
  • 2010-05-20 Developers Conference Call
Skip to end of metadata
Go to start of metadata

Date

20 May 2010

In Attendance

Agenda

  • Quickly review previous meeting minutes (5 min)
  • Concept does not implement OpenmrsMetadata. Shouldn't it? (30 mins) (Darius)
  • Should obs.obsDatetime and obs.location be required? See this (30 mins)
  • After-action review & next week's agenda (5 min)

Minutes

Last Week's Minutes

  • No response from Shaun on GSoC; Paul went to visit him at his desk during the meeting
  • Assistant Release Manager for 1.8 will by Ryan Crichton (not Daniel)

Concept Implementing OpenmrsMetadata

  • Concepts have properties that could / should be treated as metadata via implementing OpenmrsMetadata
  • Minor releases such as 1.7 are supposed to be "backwards compatible" within the major version; breaking the API is bad, but adding features is good
  • Changing the results of Concept.getName() from ConceptName to String will potentially break the API
  • Darius will investigate how much work this will require
    • simple changes = do it now
    • complex = let's talk about it some more

Requiring Obs.obsDatetime and Obs.location

  • An obs typically inherits the datetime and location from the encounter
  • Two questions came up about this:
    • Should we cascade changes from encounters to obs for these data?
    • How do you record data that is really just administrative and does not incorporate an encounter or location?
  • Datetimes should never be null, but locations on obs should not be required
  • Also locations are sometimes unknown for Encounters and there is no core data for an unknown Location
  • Cascading changes from Encounter.location to Obs.location
    • No need to handle the case where you have the same location specified for encounter or obs but meant to be different
    • Roger's example: entered an encounter at the wrong location but as you were doing that you intentionally specified the lab results location as the right location; editing the encounter and changing the location gets cascaded to the proper observation incorrectly
    • Is this a realistic problem? Yes.
      • Paul's example: _to be edited by Paul_ if someone switches the encounter location from "at the clinic" to "in the lab at the clinic" (coarse -> fine granularity) may affect the data integrity, since another obs may actually have been performed "in the treatment center at the clinic"
    • Same problem as the datetime, because an observation with an unknown datetime will get the default datetime ... but nobody thinks it matters
      • Dave's example: Encounter.EncounterDatetime = collection date, Obs.obsDatetime = results date
  • SOLUTION:
    • Make it an OpenMRS Someday ticket: #2347
    • Relax constraints (not-null) on Obs.location and Encounter.location
    • Add convenience method Obs.getObsLocation() to look at associated Encounter if null on obs
    • _still under consideration_ If obs location h1. encounter location, cascade encounter location change to obs location

Misc.

  • Decided to postpone next week's GSoC presentations in lieu of providing an OpenMRS overview demo for beginning developers Transcripts ==
  • Backchannel IRC transcript
  • Audio recording of the call: Listen online or download