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