@akshika47@harsha89 I’m working on a request parameter issue at the moment and I’m unable to find the exact way that the request parameter is added to the URL.
The said URL is given here:
Frankly, I’m kind of perplexed as to how this file gets involved within the module. I know that it does, since I corrected an issue in its label. The problem is that the {{patientId}} part doesn’t add the patient’s ID. I don’t know the way the files interact to figure out how to solve this.
This generates a link to open a patient’s surgeries in the General Actions section of the Patient view page.
Wow that was awesome @dkayiwa! it worked on the first try with {{patient.patientId}} Thank you!
Could you kindly point me to any resources about using these app.json files? I would like to learn more on how they’re used.
If they’re not used anymore, could you give me an example module that works in a similar manner, but with a newer structure? I checked the Appointment Scheduling module so far.
Thanks again @dkayiwa. The App Framework is new to me.
@akshika47@harsha89 I’m rewriting the scheduler with latest version of Optaplanner. I should ideally be done with it by now but I got a little preoccupied with the first week of my internship. We are in the last, and the most crucial, step of completing the module migration.
There are two paths that I can take.
Apply changes to Optaplanner through versions 6.0.0 to 7.0.0 step by step. There are a number of backwards-incompatible changes to the API in-between these versions.
Create a new scheduler in the latest OP version straight-away, taking the current implementation as a guide.
I’ve decided to go ahead with the first option. Currently working on applying some changes.
As for the next round of development, I’d like to consult experienced OpenMRS users who know what’s required during pre-theater data collection activities. I’m sure the community has many doctors and other involved people who can provide valuable input on this, like @ball.
Pre-theater workflow enhancements
I considered the following in my proposal for pre-theater concerns. Please add what I have missed, make suggestions on implementation and raise any concerns you may have
Evaluating patient medical history
Past surgeries
Diseases that may affect the surgery
Current medications - may cause complications
Allergies - for chemicals, drugs or anything else used in surgery
Fitness for surgery
Checking the body condition of the patient for signs that the surgery may not be viable
Prescriptions to be taken before the surgery
Dyes
Anesthetics, antibiotics, antifungals, analgesics, IV fluids, Electrolytes, anticoagulants, diuretics, barbiturates
Fasting periods
NBM periods for the surgery
Legal requirements (where applicable)
Documents requiring legal consent of the patient for the surgery
Some of these can be taken from other modules. For example, allergies could be queried with the Allergies API. I plan to finalize the data model of pre-theater workflow enhancements by the end of this week.
Attaching the Post-op form (in 4 parts). Since we don’t capture pre-surgery information, there is information collected that might be useful for your pre-theatre workflow (ie. pre-surgery diagnoses, urgency, ambulatory status, etc).
The beginning section handles the team (eg. surgeon, assistants, nurses, anesthesiologist). If you want to capture similar information, you should configure these provider types via metadata along with privileges. You might also want surgery scheduler as a role. We currently create new team members (OpenMRS users) with “System Administration” → “Manage accounts”. This works.
Going along the lines of the form Ellen showed, here are some preliminary sketches of the pre-op data collection form. I’m kind of concerned with the way we can gather the data of the patient history section. Having someone type in text areas doesn’t seem very practical.
All of these sections come within a single page. Do you think it’d be better to break them down into separate, smaller pages?
Currently we can’t view the details of a surgery after we create it. There’s no singular view for one. Was that available in the module before? @harsha89@akshika47
I wouldn’t recommend free-text for so many things – especially if you want to do anything useful with the data (reports, summary, etc.) I would only recommend for 2 things – 1) if the system is all point-of-care, the clinicians can read each other’s free text; 2) If you never need the data to begin with since it’s not easily usable.
For allergies, you should use the allergy module. For past surgeries, you should record with an obsgroup (past surgery or procedure) and 3 concepts (date, procedure, diagnosis). Physical condition should be coded. I understand this is tougher to build and likely longer to enter by the clinician, but the data will be useful.
Understood, indeed it’d be much easier to perform analytics with proper granularity.
In fact, the original module was supposed to use concepts to store procedures but that didn’t happen due to time constraints. I read the original discussion about it here and I think I have an idea about how this needs to be done. Besides, you’ve mentioned exactly how the past surgery data should be stored. Thanks for that
I discussed with @akshika47 and our main concern is the time it’d take to fully implement this. I don’t want this module to go to waste so I’d really like to implement the functionality. But it’ll take me a bit of time. We may need to scale down on some of the latter objectives for this summer. Winter is coming, anyway,
A binary code seems the simplest for the physical condition. If we include it as a concept with coded values and take into account the intermediate states, what options between unfit, risky and fit would be adequate?
@merovingienne - If there’s a section of the form that you want to discuss, let’s attack that together. We can discuss using this talk thread or find time via skype. I can assist with selecting the right concepts and the htmlform syntax.
I created the concepts for them via the web interface.
PAST PROCEDURE (Grouping concept)
PAST PROCEDURE DATE
PROCEDURE
PROCEDURE DIAGNOSIS
Is there a way to add them to a startup script of the module, so that the concepts get automatically created in a new instance of OpenMRS?
Once the observation concepts are created, we can record the past surgery obs in the Obs table for each procedure the patient mentions. A point worth noting is that we need to add the current surgery as a past surgery obs once it is completed.
This part doesn’t require any encounter or other association. No need to anchor it with a particular surgery. But we need to associate in-theater workflow data collection with the surgery somehow. Let’s talk about that on another post later.
Allergies are fetched and shown in the surgery page now. Used the Allergy API for it.
For pre-theater prescriptions, do you have any comments on the structure I proposed before? It’s in the screenshots I posted above. Here’s a direct link.
I feel like this could also be recorded with concepts.
Physical condition - Concept with Coded concept answers
UNFIT
RISKY
FIT.
Between these, what else can we add?
@ball And another thing is that right now the module uses GSPs to show forms and collect data. Should we use HTML forms with the HTML Form Entry module?
Recommend new concept to @akanter (ie. Adding diagnosis to CIEL:160714. For non-coded, add CIEL:161602)
Concepts should not be UPPERCASE (ie. ‘Unfit’ not ‘UNFIT’).
Sometimes, you can re-use similar meaning concepts. Can you use ‘Generally unwell’ instead of ‘Unfit’?
If you create an obsgroup/convenience set, you can (re-)use existing concepts. Use ‘Past procedure set’, but with set members of ‘Procedure’, ‘Diagnosis’, ‘Procedure date’. Then you can re-use building blocks. (However I would recommend that you do use CIEL concepts when possible. This point is meant to explain building a convset.)
Thanks, Ellen. If you want the module to work with more implementations than I believe there needs to be standardized concepts (such as from CIEL) and the concepts should be referenced via standard reference mapping such as we do for the TB module. It is important to work backwards, from what you are going to use the data for, to the forms you are going to collect it, to the concepts that need to be on the forms, and then to where you are going to get the concepts. A spreadsheet can help you pull it all together and map to the existing CIEL concepts (also can use www.openconceptlab.org) and run them by @ball or me.
Thank you!
