Today, We deployed the “David Blaine” version of the TB Module for our EMR solution here at IDI (http://idi.mak.ac.ug). This was mainly for bug fixes and usability improvements based on the feedback that we received from users in the past few weeks. Some of the improvements were related to performance. We had to fine-tune some of our Linq statements in some places to enable better queries to be generated by our ORM. We also added some lookup dialogs that present certain information that would be required to make instant decisions. e.g. showing weight trends to determine loss of weight.
We got some of the feedback in less than 30 minutes of usage. A reason to smile.
This TB module is represented by additional assemblies that are dynamically loaded by ICEA (EMR). If these assemblies exist in a certain folder dedicated for plugins and a manifest file indicates that it must be loaded, then the user will see a seamless integration of features related to it. User rights and security propagates into the loaded module, hence the user that is not explicitly given authorisation to the module will be denied access. We were worried early in the project about reflection and performance but later we found ways to cache some most frequently used views and lazy load images and other data. The system uses a model + view + presenter approach, and we had to made some modifications to the Krypton Toolkit to enable the views to come with their own Ribbon parts. i.e. each view comes with its own RibbonTabs, RibbonGroupButton, AppMenu items and anything you want fused with the main shell. This keeps the controls in context with the data at hand. We also added a mechanism within the framework which keeps the current patient context despite the view you are currently viewing. This enables us to change between views in different modules and still keep on the selected patient in context.
The TB Module is made up of a number of forms within the application.
- TBsuspect. This is used to enter details of the patient who would have presented symptoms which suggest that they may have TB. This would enable the TB doctor to perform a physical examination and order for investigations (in the lab – online) that need to be carried out. These may be sputum smear, culture and sensitivity, chest x-ray, abdominal ultrasound, lymph node aspirate, pleural fluid, lymph node biopsy or anything else.
- TBInvestigation. This will keep the results from the lab or radiology. It will enable the TB doctor to confirm the existence of TB, and if it exists then the Diagnosis form is filed in.
- TBDiagnosis. This is a very interesting form in that as the user fills it in, notifications and hints are displayed based on the rule based engine.
- TBFollowup. This is used for a person that is undergoing treatment and filled in on each follow-up visit and it will depend very much on the visit phase (2 weeks, End of Intensive, End of extended Intensive Phase, 5 months continuation phase, End of treatment, End of Extended Treatment). The rule based engine gives hints based on the examination and entries. e.g. When a patient has Skin Rash (side Effect), the doctor should verify whether its major using WHO (World Health Organisation) and NTLP (National TB and Leprosy Programme) standards and consult with TB Coordinator. If its mild then treat with anti-histamines e.t.c.
- TBOutcome. This was a challenge to develop because its linkages with all the other forms. The outcome is the termination of the episode which may have started from the patient being a TB suspect or transferred in at diagnosis phase. This is filled in when a patient completes, defaults, is transferred out, or is diseased.
We had a major challenge in that there had been an Access database which was used to enter information written on forms. The design was not what you’d want (not by us) and to make things worse, there were many fields which were not validated (esp dates) and it was hell to transfer the data into ICEA. The access system allowed duplicates and there was no relationship made between the forms I talked about. Forging relationships where there existed duplicates was a major challenge. I’m happy to say that we found a way to create relationships that did not exist through the TB module.
Technorati Tags: EMR