Date

20 May 2010

In Attendance

• Michael Downey
• Pascal Brandt
• Cristian Chircu
• Malte Friese
• Umashanthi Pavalanathan
• Shazin Sadakath
• Lu Zhuang Wei
• Firzhan Naqash
• Ruwan B. Egodawatte
• Darius Jazayeri
• Jeremy Keiper
• Justin Miranda
• Burke Mamlin
• Paul Biondich
• Glen McCallum
• Win Ribeka
• Sy Haas
• Wyclif Luyima
• Ben Wolfe
• Dawn Smith
• Hamish Fraser
• Diederik van Liere
• Rafal Korytkowski
• Andrey Stelmashenko
• Nareesa Mohammed-Rajput
  <!--
• Lorinne Banister
• Ryan Crichton
• Dave Eaves
• Daniel Futerman
• Mark Goodrich
• Katherine Kuan
• Kenny MacDonald
• Pratik Mandrekar
• Wayne Naidoo
• Zeshan Rajput
• Tammy Dugan
• Carl Fourie
• Isaac Holeman
• Andy Kanter
• Michael Kopinsky
• Dieterich Lawson
• Heather LaGarde
• Simon Peter Muwanga
• Mike Seaton
• Yati Tandon
• Aliya Walji
• Judy Wawira
  -->

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