Configuring a New Installation

37 views
Skip to first unread message

nick...@gmail.com

unread,
Oct 4, 2019, 10:58:24 AM10/4/19
to OHC-OPAL
Greetings,

I just discovered Opal today and was able to get it running fairly quickly.  Good job on that.  :-)

I'm researching options to set up a system for a rural medical clinic (not in the UK, FWIW).

There were a few things that confused me after I set it up, and I was hoping you could shed some light on the.

1. Should the default install work to add and edit patient records out of the box, or is there some set of plugins or other configuration that is necessary? (I see that there is a plugin system, but are any of them necessary for a sort of minimally functional installation?)  I saw the means for loading and editing lookup lists, which was nice. 
2. The idea of a Team seems to be at the forefront of the app, but when I choose the edit button for teams it does nothing.  (This seems related to: https://github.com/openhealthcare/opal/issues/1602)  Could you explain what Teams are and how they should be configured?
3. I assume that users should be added through the Admin -> Users page, but I saw that Users depend upon Roles.  When I went to look at Roles I saw that there were none, which seemed odd -- like maybe a default installation should have some kind of role defined (for the admin if nothing else).  This made me question whether or not I had installed the app properly.
4. How/where are episodes I read in the documentation that an episode could be a phone consultation or inpatient or outpatient visits, but all that I are options to add patients and work with the diagnosis, treatment etc. 
5. Is there an online demo that I could view?  Perhaps seeing a complete demo could help me see how my own server is mis-configured or incomplete.

Hope that my questions make sense.  It looks like a nice tool but I am not quite sure what it takes to get a small working installation.

Thanks,
Nick

David Miller

unread,
Oct 8, 2019, 9:40:52 AM10/8/19
to nick...@gmail.com, OHC-OPAL
Hi Nick, 

Thanks for your email!

At headline level, records system for a rural medical clinic is the kind of thing Opal could well be a very good fit for - will be interested to see how your evaluation goes.

Notes on your individual points inline:

1. Should the default install work to add and edit patient records out of the box, or is there some set of plugins or other configuration that is necessary?

The `startproject` `command should get you a minimally functional application - e.g. you can add patients, add treatments, diagnoses, allergies to their records, and a few other pieces.

I notice that the tutorial might need updating - for now, if you log in with the default credentials, you should see an 'add patient' button in the top menu, after adding a patient with that form, you land on their record, where you can add some entries. Default lookup lists should already be entered for e.g. conditions.
 
2. The idea of a Team seems to be at the forefront of the app, but when I choose the edit button for teams it does nothing.  (This seems related to: https://github.com/openhealthcare/opal/issues/1602)  Could you explain what Teams are and how they should be configured?

Over the last few years we've moved away from the implementation of teams being quite so central. It has worked quite well in secondary care settings at large institutions (e.g. Major metropolitan hospitals). More recently, we have started building applications that don't have any teams in them and relying on different core user journey metaphors. If you want to see it in action, I recommend replacing the "All patients" list in the scaffold app with the following (we assume any non-toy application will delete the all patients list relatively quickly - it's demonstrative rather than useful).

class FluJabList(TaggedPatientList):
   tag = "flu"
   display_name = "Flu Jab"

   schema = [
       models.Demographics,
       models.Diagnosis,
       models.Treatment
   ]


class EmergencyGpAppointments(TaggedPatientList):
   tag = "emergency_gp"
   display_name = "Emergency GP"

   schema = [
       models.Demographics,
       models.Diagnosis,
       models.Treatment
   ]

This will give you two teams - Emergency GP and Flu Jab. You can move between lists and on the patient detail page these options will appear in the teams box. The general idea is that teams functions as a tagging system, and while a patient is currently under the active care of a team of medics, they have this tag added. That means you can find such cohorts later, and generates you a patient list.
 
3. I assume that users should be added through the Admin -> Users page,
Exactly 
but I saw that Users depend upon Roles. 
Might be more accurate to say that Users can have Roles rather than _depend upon_...

I personally am skeptical that a useful usable generic case for roles in a medical records system exists - if it does, I certainly don't think we know what it is enough to enforce such a default ! 

While we use the 'roles' system extensively in production, we don't add any by default. A meaningful set of default roles would need to be also incorporated into user journey, coded into templates etc. Healthcare delivery is complex and subtle - we don't believe that we know the cultural and institutional context well enough to code defaults in the abstract and crystalize them in advance. So instead we the strategy is to make it as easy as we can to add such things and build up what you need once you've done the research to understand what _your_ users will need.
 
4. How/where are episodes I read in the documentation that an episode could be a phone consultation or inpatient or outpatient visits, but all that I are options to add patients and work with the diagnosis, treatment etc. 

Episodes are very thin models - their main purpose is to have something to hang more interesting models from. You can find them in the Django Admin, one should get created by the AddPatient pathway in the scaffold app. From a coding perspective, you need a patient to exists, and then you can call patient.create_episode()
 
5. Is there an online demo that I could view?  Perhaps seeing a complete demo could help me see how my own server is mis-configured or incomplete.

We don't currently have online demos of Opal functionality in general that you can see - I think strategically we'd look to improve the scaffold app & / or tutorial rather than attempt to maintain one online.

Do shout if you have further questions.

Best

David

--
David Miller
Open Health Care

Nick P

unread,
Oct 11, 2019, 10:38:53 AM10/11/19
to David Miller, OHC-OPAL
David,

Thanks for your reply.

Your Emergency GP and Flu Jab list examples were helpful.  I have a few more questions.

I see that by default the application is setup with an "Inpatient" episode type.  In the examples you gave me, of having a separate list for Emergency GP and Flu Jab, would those likely have different episode types?  Is there some UI element for choosing, "I have a new patient, and they are here for I am going to enter Flu Jab episode data -- or is that something I would need to add?  I'm assuming that multiple episode types would all still be part of the same Django project, I'm just not clear yet on how that would work. 

In my example, I am considering two use cases -- a rural health clinic, and a nutrition program.  The rural health clinic would be very similar to what I see in the scaffolding (perhaps without the need for location information).  The nutrition would I think be a different episode type, and would call for tracking height and weight -- I see that the Observations plugin may be useful here. 

I understand what you are saying about roles needing to remain open for implementation in different contexts.

If you could comment about having multiple episode types in the app, and if I am understanding it correctly.  Maybe another question is, are Rural Outpatient vs. Nutrition Program two *Teams* or two *Episodes* or both?

Thanks,
Nick

David Miller

unread,
Oct 11, 2019, 11:14:41 AM10/11/19
to Nick P, OHC-OPAL
Hi Nick, 

Definitely linked questions.

The main reason to have different episode categories is when you want really significantly different views for different types of episode.
This works well when you have teams functioning in very different ways - e.g. a dental service that does dentistry (checkups, fillings etc) _and_ orthodontics (braces etc) the things you record, the median duration of an 'episode' is 15mins vs 2 years etc...

Introducing this complexity can help with depth of bespoke customisation for different clinical services, but it can also be hard for users to understand everything.
We've used a range of strategies for selecting an episode category:
- two side by side buttons with appropriate labels
- role based - e.g. the "add patient" form you see is different depending on your role
- context based e.g. no add patient button on the top level chrome, but where you are in the app changes what you get
- calling it "refer this patient to $Team" and then creating a new episode of the appropriate category behind the scenes

It depends :) 

As a general rule I would see how far you can get with one episode category and only introduce it if you need it.
If the nutrition programme required lots of e.g. diet data capture I can Imagine it requiring a new category. If it's just height / weight I probably wouldn't bother.

Creating a RuralOutpatient category [1] and altering the templates [2] from what you get in the default inpatient template [3] should get you a fair way. 
You may well need some extras here like a custom appointment model.

If Nutrition vs. RuralOutpatient are teams, then both see the same patient detail page and all of the related entries.
If they're episode categories (because for instance it has really detailed diet planning information) then they become separate entries - this could make the general Outpatient screen more usable, it could just increase complexity.

HTH!

[2] ./patient_detail.html is designed for you to implement, by default it just extends ./patient_detail_base.html https://github.com/openhealthcare/opal/blob/v0.18.0/opal/templates/patient_detail_base.html
Reply all
Reply to author
Forward
0 new messages