How to Join
Click here to expand...
By Browser
By telephone
- US telephone number: +1 201.479.2627
Agenda
- Quickly review previous meeting minutes (5 min)
- Upgrading to Platform 2.0
- Review next meeting agenda
Minutes
Participants
- a few more from the Bahmni team
Agenda
- Migration to 2.0 Platform
Notes
- Bahmni team is working on upgrading to have the next Bahmni release based on platform 2.0 (and needs to decide if this can happen, or if it will need to delay until the next Bahmni release)
- A couple issues they've run into:
- 1. through the encounter transaction REST API in the EMR API module, they've been saving an entire visit at a time
- 2. they had previously been
- Philosophy of the platform:
- Should mainly work with patient's transactional data at the encounter level (or below).
- Don't assume that saving a visit will propogate to saving all its encounters and all its obs. (It probably does this now, but could change.)
- (In fact, we should fix this new, as a bugfix, to prevent saving a visit from cascading down to save encounters.)
- Bahmni is fine to do this (i.e. to separately call saveVisit() and then saveEncounter()
- The approach in the emrapi module's encounter transaction web service *is* the approach we want to follow (i.e. that you're sending some events, and those are recorded in one appropriate encounter)
- Behavior for editing an obs prior to platform 2.0: you have to call voidObs() and then create a new obs
- Starting in platform 2.0: you can edit the obs and call saveEncounter()
- Platform 2.0 now automatically picks up edits to obs and automatically does the void-and-create-new
Anghsu had said on Talk:
What I understand, this is the scenario:
1. Identify a visit if it is found or instantiate a new visit (not saved yet) <= We've agreed to stop cascading visit to encounter as bugfix in platform 2.0.1
2. Instantiate a new encounter and add to visit
3. Instantiate new obs and add to encounter
- theres another problem here with the session flush. Imagine, there is another piece of code which does the following
* check if a concept exists (conceptService.getConceptByUuid()
* this will flush because the session is dirty. This is irrespective of the Visit not cascading (in future fix)
This is really saying that do not associate the obs (or work over any persistent entity). [but this becomes very tedious]
4. Save visit (which in turn saves the encounter but not the obs)
5. Save the encounter (now it tries to save the obs)
About the voided flag...
one Acceptance Criteria for the work is that if you edit an obs.value, then call saveEncounter _twice_ it will only save one voided obs and one unvoided one.
Middle of next week Bahmni team needs to make the call about whether to upgrade to Platform 2.0 in the next Bahmni release, or delay to the one after that.
"Next release" would mean release 4-6 weeks from now
"the one after that" would mean 10-12 weeks from now
Preethi: we need Platform-2.0-compatible OMODs released (currently these are only in snapshot)
Daniel: can release these within the week
Next Steps:
- New ticket to remove the visit.encounters cascading in the hbm.xml [will repurpose the ticket created by Preethi for this]
- Dirty flag on obs needs to be cleared when the obs is saved [Wyclif will create a new ticket today]
- Bahmni team can work on this (and will, ASAP)
- OpenMRS can commit to releasing this as Platform 2.0.1 quickly
- Daniel will coordinate the release of refapp OMODs compatible with platform 2.0
TODOs
Transcripts
- Audio recording of the call: Listen online or download (available after the meeting)