26 February 2009
- Justin Miranda
- Ben Wolfe
- Hamish Fraser
- Paul Biondich
- Darius Jazayeri
- Mike Seaton
- Brian McKown
- Burke Mamlin
- Sam Mbugua
- Dave Thomas
- Saptarshi Purkayastha
- Program Location - We've received multiple requests for adding location to programs. I (Justin) probably won't be able to attend the call because of limitations (mic and internet not working well) so Darius will probably present our case.
- Terminology mapping: http://forum.openmrs.org/viewtopic.php?f=2&t=326
- Process for gathering requirements for large scale implementations efforts ala Rwanda
- Adding location_id to the program_workflow table.
- Overall reason: Mike: need to answer these questions: "Who was enrolled in a program in a given month in a given location"
- Justin: need to keep track of which clinic/health center a patient did the program in. So that the history of where things occurred is kept. This is an alternative to just using the health_center person attribute
- Darius: This will allow a patient to be in the same program in two different programs
- Mike: similar to "longitudinal data" discussion.
- Paul: need a better way to track longitudinal data. currently program is the only way, but we need a better way
- Ben: can't be a required column because some people might want to store programs across all locations
- Mike: Attaching location_id to program_workflow_state ? seems a little hackier
- Paul/Mike: basic underpinnings of programs needs to be looked at again
- *TODO: (Ben) add to roadmap of re-doing programs and workflows to store data better.
- *TODO: Darius+Mike to investigate whether we just 1) add program_workflow.location_id or need to 2) add a new program_workflow_state_location_map table. Results of investigation will be posted to the dev list for more discussion. Background should be given in the email for those not on this call.
- Terminology mapping:
- Andy Kanter proposed a new spec for changes he would like to see here: http://forum.openmrs.org/viewtopic.php?f=2&t=326
- Paul: We need to address how we can help non "core" developers suggesting data model changes. We left the suggestion out there unattended for too long.
- Paul: This needs to be data modeled correctly in the core for the long term
- Hamish: agreed and we need to work it out for Rwanda soon. Exporting/importing codes is needed as well
- Paul: We don't want to hack it in, we need community help (Andy's domain knowledge)
- *TODO: (Ben) need to add concept_map changes to the roadmap
- *TODO: Hamish to find out what exactly is needed. Simple? complex? What have they done so far? 4pm call with Kanter today.
- Process for gathering requirements
- Some requirements are core functionality and some are customizations for the implementation.
- *TODO: Hamish to send requirements around
- Brian: need some sort interoperability discussions with external systems (relating to Brian's recent work on Pharmacy system querying/posting data to openmrs)
- Paul: Rwanda will need this and need some EMR interoperability
- Brian's update about LIMS integration
- AMPATH is installing a LIMS system to get results from lab machines directly into openmrs
- Has written a processor to read hl7 messages from a folder and import into hl7 in queue
- March 1st deadline for getting everything running is going to happen
- PCS is using LOINC codes ?
- Brian brings up an idea of storing quantity for drugs ordered
- We current don't store this information in obs
- Brian: Perhaps just store an obs_group with one obs for DRUG, one obs for DRUG_QUANTITY
- Brian: Do we need to keep track of who dispensed?
- Paul: Not in a clinical repository
- Darius: It is relevant to the pharmacy system, may or may not be reported via openmrs
- Brian brings up the REST module
- Do we need to create a PCS LAB SYSTEM user ?
- Ben: Tie user's in pcs to user's in openmrs and the user authenticates to that?
- Brian: Yes
- Darius: Lead Lab Tech needs to be able to set/change the username/password for the PCS LAB SYSTEM user