What is the Clinic App

The Clinic App (CA) is a "Remote" App developed to enhance communication between OSCAR and MyOSCAR. The privacy compliance levels as described in my previous blog are:

• (1A) No data of any kind will be stored. CA passes patient sensitive data between OSCAR and MyOSCAR. Individual health information is used only once and promptly removed from CA after each successful transmission.

• (2A) Data captured in CA is never shared except between the MyOSCAR server and the OSCAR instance. CA may gather basic traffic data to generate internal use statistics or other administrative reports. Moreover, only patients who are already patients of the OSCAR clinic may add this app to the user's MyOSCAR account. By adding this app the user is giving explicit consent to sharing his/her MyOSCAR data with the OSCAR clinic.

• (3B) This App received funding from a federal government agency.

CA Features

CA is a web service tethered with a specific OSCAR installation. The idea is that each OSCAR server will host an instance of CA which will establish and maintain communication with a MyOSCAR server. At this point, one CA can communicate with only one MyOSCAR server whereas one MyOSCAR server can communicate with multiple CA's (and therefore multiple OSCAR clinics).

At this point CA has two important functions: Appointment Booking, and Clinic Information sharing.

CA is designed such that different clinics may put their own logo and public information like hours of operation or a list of providers and or services offered at this clinic etc. This can be done as built in html codes or RSS feed from sources that dynamically update clinic information (such as Facebook). The problem of static built in html codes is that it requires modifying the generic CA code every time the CA software is updated. (Tech talk: the general idea is that all application related jsp's will be in /application and all custom html pages will be in /customizations. When a new version comes out, all you have to do is copy /customizations over into the new version and everything should continue working, in theory.)

Before reading the following highly technical details, it may be helpful to watch this Youtube demonstration of what CA looks like:
https://www.youtube.com/watch?v=4BvEnxaodYo

Enhancement Planned

• Each CA should be able to handle more than one clinic so that clinics don't have to have their own instances of CA and would be spared from having to maintain the web service.
• Improved handling of patient appointment types based on demographics. For example, a male patient should not be offered an appointment for PAP.
• Patients should also be able to "friend" a particular provider whose available appointments will appear when booking an appointment.

To give you an idea of what is happening to the ongoing enhancement of CA, here is the most recent "Change Log" (quite technical):
02-12-2013

-Added logic to learn which days not to search for.  Replaces a hack before that would set the cached dayWorkScheduleTranfer holiday flag to true.

02-07-2013

-Add ability to look for an override file in a directory based on the context name of the webapp

02-01-2013

-Add Caching to RSSFeed 

-changed rssfeed header from title to date. (the title was generally to long for a header) 

01-31-2013

-handle if patient isn't a patient of the clinic

-handle if oscar goes down while patient is in booking app.

-handle if patient's provider is not accepting online appointments.

01-27-2013

-Added Caching to dayWorkScheduleTransfer object.  

-Added configuration file to turn off trying to register with myoscar server 

01-22-2013

-Initial Commit

Technical details

This is a maven2 project. To build the code you run "mvn package" and you should find a war file in the target directory.

The project war file should be a standard war file and should in theory deploy like any other war in any normal servlet container (although tomcat is the only one tested).

From a runtime point of view, the client is just a set of web pages which communicate against the oscar web services as well as against the myoscar web services. No information is stored locally.

Requirements

The following aren't truly requirements but are what was used during development of this.

running : 

- jdk1.6.0_24

- tomcat 7.0.14 (version 6 is not sufficient)

build :

- maven2 2.2.1

Appointment Filters

Filters can be applied to available appointment slots.

The initial use case is : "Open Access" appointments must only be allowed to be bookable 24 hours in advance.

So, the regular appointment sorting out goes through it's logic and returns a list of available timeslots, then it continues to run through the OpenAccess24hTimeSlotFilter.java class and removes any open access timeslots not within 24 hours.

To get the above working we have AvailableTimeSlotFilter.java which is a call back interface.

configure/add your filter in config.xml as <available_time_slot_filter_class list_entry="true"> (see the reconfigured OpenAccess example in there).

The appointments your filter return should be a list of "allowed" appointment times. This means to can add / remove appointments as you want.

Installation details

1. Build the code or download the war archive.
2. Deploy/copy the war file into a servlet container like any standard war.
3. When starting tomcat, you can pass a system parameter of "-Doscar_patient_portal_config=override.xml" where override.xml is an xml file which overlays the default one.
4. In the config.xml (and it's override) file the 2 most important settings would be the oscar web services settings and the myoscar server web services settings, they need to be correct for this to connect to them.
   There are also 3 parameters that need to be setup, the list of oscar provider numbers, appointmentTypes, and time codes. These parameters control which providers show up on the booking list, what appointment types they can pick from, and what time slots in the providers schedule is eligible for online booking. You will need to have setup oscar with the schedule templates for the providers working schedule. This means you must also have created appointment types and time codes for the schedule, also make sure you setup the holiday days properly in oscar.
5. Go to the client url, i.e. http://127.0.0.1:8285/oscar_patient_portal/test_login.jsp that should bring up a test login page to check if everything is working properly, you can bypass the myoscar client by using this page but you must fill in the userId (not username).
6. From the myoscar_client side, assuming your configuration is correct, it should register itself with the myoscar system with in a minute if you starting the server. Once that happens you should see it as an option under the persons preferences.