Other than users adding and removing items to allergy lists, problem lists, etc. directly, the active lists automatically maintain the lists by monitoring the entered observations. For example when the user enters an observation malaria problem added, the system captures the event and adds a new problem in the problems list. When the user enters an observation malaria problem removed, the system looks up the problem list, finds the malaria problem and ends that item.
Categories: OIP, OpenMRS
Categories: OIP, OpenMRS
A working active lists implementation is complete. Problem and allergy lists are implemented.
An allergy consists of allergen, reaction and severity properties. The problem consist of a basic concept. Both contain start and stop dates. They are used in case we need to define items with a date other than today when entering, and also to retrieve historical items with a past date range. Allergy, problem items are plain objects. Each type of object uses a helper class to interact with the system.
The user can create an allergy object with the three basic properties.
Allergy allergy = new Allergy(); allergy.setAllergen(allergen); allergy.setReaction(reaction); allergy.setSeverity(severity); Context.getPatientService().addAllergy(allergy, patient);
Removing an allergy is as follows.
Allergy allergy = new Allergy(); allergy.setAllergen(allergen); Context.getPatientService().removeAllergy(allergy, patient);
The active list entries are assumed to be coming from two paths. One is directly creating and removing objects as above. The other way is users creating the observations indirectly in the system which would modify the active list accordingly.
Categories: OIP, OpenMRS
I am working on the ticket #73, model must support constraining coded answers to one or more classes. I am implementing the first option, using two properties in the answer class to keep a concept set or a concept class. After implementing this ticket we can specify which concepts are possible for a given concept as an answer by the given concept classes and concept sets, in addition to the single concepts,
I am happy and proud to announce that I have been accepted for the OpenMRS Internship Program (OIP) also known as the Southern Summer of Code. OpenMRS is an open source medical record system framework for developing countries led by Regenstrief Institute and Partners In Health. OIP is supported by the International Development Research Centre (IDRC). OIP runs as same as the Google Summer of Code (GSoC) program. This is going to be fantastic.
A few days ago, I started making an initial patch to OpenMRS to update the database to the required version at the deployment time of the web application automatically using Liquibase, a unique tool to perform the database changes in a database implementation independent manner. This will eliminate the step where the user has to run the update-to-latest-db.mysqldiff.sql SQL script using the mysql client program in a shell. And it is database server type independent. Also this eliminates the dependence on mysql client program.
OpenMRS web application calls the Liquibase programatically at startup. It will read the database changes from an XML file and mark the performed database changes in a dedicated table. This works in a similar manner to how the database updates are done in the OpenMRS modules at present.
Update: See ticket #974
A few weeks ago, I created an external web application (WAR) separate from the OpenMRS WAR to update the OpenMRS to the latest release. It was a working but proof-of-concept work. It worked as follows.
The WAR file is deployed in the Tomcat application server where the OpenMRS is running. The update web application shows the running OpenMRS version and the available releases that are newer than the installed release. The existing release was scraped from the OpenMRS home page. The available releases are published in an index file located in a remote server. The index file location can be changed so that it can point to a file in the local file system or a file hosted in a server. It has entries as follows.
The pointed files are the same files available for downloading in the OpenMRS downloads page.
The user selects a release. The web application will download the files listed for that particular release. Web application will show the download in progress message. After files are downloaded, web application will run the SQL script using the mysql client program. Then it will undeploy the existing OpenMRS release and deploy the new release. Until this is finished the web application will show the install in progress message. After installation, web application returns to the available releases page with the installed release and list the available releases newer than the installed release.
Update: Source bundle can be downloaded here. This is not ready for production use.
Last week I created a patch for the OpenMRS module repository to allow a delete feature for added modules. Each version of the module can be deleted. And when all the versions are deleted, the module entry will be removed. Last night I did a bit of interface changes to make it look consistent with the existing code.
I updated the patch for the changes to the core OpenMRS, as Ben has instructed, to add an edit permission feature for the person attributes. I added the database modifications to the update-to-latest script, and added a list box of available privileges instead of a text box to the person attribute type edit page.