Kindred PHR - it's more than a name change...

Although myoscar.org still exists and the original myoscar.org code will remain in the Open Source world, a completely rewritten user interface (UI) will soon be released and will be branded as kindredphr.com.

And yes you can sign up for an account for free. Just click "Sign Up".

Having a working email address is very important as you will need it to recover your password or if you want to get notification when you receive something in your PHR account.

For those who already have a myoscar account, don't worry. The new UI is just what it is - a new UI. It can still access the old myoscar database. But under the hood, the entire access control and database layers have been updated with more features and yes the code is way more robust.

The new UI is based on the Twitter Bootstrap framework which is very mobile device friendly. The key new feature is the way one can build connections (more on that in my next blog). The focus is also on usability, consistency and consumer friendly.

Give it a try!

Further thoughts on "How does MyOSCAR file its records"

I had written the principles behind the filing system for MyOSCAR previously. The current MyOSCAR database server is based on an Open Source product MySQL version 5.1.30. MyOSCAR v1 began its life as an unintentional "fork" of the Indivohealth project. The original Indivohealth project has now been replaced by the totally different Indivo X (or the Smart Indivo) which fully supports the SmartPlatform project. The original Indivo PHR was based on the Berkeley DB which is now owned by Oracle. Over time pressures from a number of research projects necessitated a switch to a relational database. We have been using MySQL for our other projects (OSCAR EMR) so MySQL was a natural choice. However, health documents are still stored as individual documents. MySQL provides some relational structure to facilitate database searches and improve overall database performance.

Now looking into the future, how can we provide storage for potentially very large number of documents, some of which can be very large documents (e.g. the file size of a 30X human genome sequencing file is estimated to be about 500GB). And how can we enable the possibility of an individual storing his health records across multiple databases, which may be physically separate? What do organizations like Google, Facebook, or Twitter teach us about this?

I have started looking at a couple of potential solutions:

NoSQL


SQLite

Will continue...

Installing MyOSCAR Server (v2) from scratch

[Dr. Peter Hutton-Czapski maintained a much more hands-on detail installation instructions in the OSCAR Manual site.]

Server requirement: The following aren't truly requirements but are what was used during the initial development of this version.
running :
- oracle jdk1.7.0_17
- tomcat 7.0.14
- mysql 5.1.30
build :
- maven 3.0.5

Technical details
The MyOscar Server projects code is a maven2 project. To build the code you run "mvn package" and you should find a war file in the target directory.
The MyOscar Server projects 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 server is mostly just a set of network accessible SOAP services with a database back end, there is currently no UI built into the server although in the future a thin set of administrative pages maybe build.

Installation details
1) build the code or get a copy of the war file
2) copy/deploy the war file to tomcat as you would with any war file.
3) When starting tomcat, you can pass a system parameter of "-Dmyoscar_server_config=override.xml" where override.xml is an xml config file which overlays the default one., you will most likely want to at least set the database configuration parameters in here if not smtp parameters as well.
4) start the tomcat server
5) go to the url https://localhost:8091/myoscar_server/, follow the options to go to the install page. This page will setup the database and tables for you. The page will disable itself once the database schema exists to prevent anyone else from running it or accidents from happening. After initial install this is also the admin / monitoring url. There is an option for enabling recaptch on the admin login to mitigate automated hacks, see the recaptcha.txt file.
You will need a client program to access anything, examples include the Oscar EMR, or the MyOscar Client, you will need to remember the administrative user/password you just used in step #5.

Upgrading Installations
Always backup your database before performing an upgrade.
To upgrade the system, just deploy the new war file into tomcat, then start the server.
Upon startup if any database updates are required they are run automatically. There maybe some lines printed denoting the running of these updates they will look similar to : "start update : UpdateTo2"

Testing URL
to be redetermined, old urls no longer supported by cxf, no more browser pings

Installing MyOSCAR Client (v2) from scratch

[Dr. Peter Hutton-Czapski maintained a much more hands-on detail installation instructions in the OSCAR Manual site.]

Server Requirement: The following aren't truly requirements but are what was used during development.
running:
- oracle jdk1.7.0_17
- tomcat 7.0.14 (version 6 is not sufficient)
build:
- maven 3.0.5


Overview
This is one of the client side applications for the MyOscar Server (v2) program. The MyOscar Client program is primarily intended to be used by patients to view and control the data in their medical records. Generally speaking doctors/providers should be using an EMR for their access like the Oscar EMR.

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 projects 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 with the MyOscar Server's web services. The client side has no data store and does not maintain or store any data (other than tomcat access logs).

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 "-Dmyoscar_client_config=override.xml" where override.xml is an xml file which overlays the default one. The only really important setting right now is "myoscar_server_base_url" = "https://localhost:8091/myoscar_server/ws" That needs to point to the SOAP url that's running your MyOscar Server. If you go to it with a web browser it would be the page that is says "Available SOAP Services:" as the first line.
4) go to the client url, i.e. https://127.0.0.1:8096/myoscar_client/, you should be at the login screen. You should be able to login with the default user/password you specified in the MyOscar Server installation.

How does MyOSCAR file its records

I have described earlier that individual patient personal health record document is stored in MyOSCAR as individual file with a unique file identifier. The internal format of this file follows some variation of the CDA standard. The file is individually encrypted based on a unique key belonging to the patient. The idea is that even if an unauthorized individual is able to access these files, that person cannot have access to the information contained in these files.

In this discussion I shall elaborate on what is now, and what will be in the future, the way MyOSCAR organizes and stores these files in its Data Store server. The Access Control layer of MyOSCAR must understand the filing structure in order to retrieve individual patient's entire health history.

At the present moment, the organization of these files are stored in a relational database, i.e. when I want to look up which file contains a list of my blood pressure record, I should be able to find it quickly from the database which file contains the history (and maybe the content) of all my blood pressure record. In practice this is probably much more complicated than that. Let me elaborate.

MyOSCAR is designed based on the idea that each patient owns his own electronic medical record (EMR). In a classical EMR design, there are these fundamental principles and practices:

• Authentication and authorization - the system must contain information pertaining to the identity (username and password) of everyone given access to the EMR. The owner (or the administrator) of the EMR is the patient himself. Who else and what can be accessed are controlled by the patient and changes to the access profile and audit of all accesses are maintained by the EMR.
• All read and write accesses are timestamped and signed by the authorized user. Records are never deleted. They can be hidden from the viewer (or archived) but can be retrieved from the audit trail and used as medical evidence in court. The owner of the EMR has the option of being notified whenever a record is read or modified.
• There are records that are essentially free text and there are records that contain codified information (or meta-data). Both types of record are equally important and useful in different situations. Codified information must contain both the code and the coding system used (including the version information). Both types of information must contain as many process information as possible. These may include, the observer or the author, the observation date and time, the recording data and time, and other information that help readers understand the information, e.g. language.
• External information must be distinguishable from original internal information. This is because internal information is considered more reliable having authenticated the author and digitally signed at the time the information was stored. In contrast, external information is based on some level of trust between the sending agent and the receiving agent and can not be validated.
• If interpretation of previous stored data is required (e.g. via data mapping tool) the interpretation must be marked as interpreted data and the mapping information must be included in the documentation.

The typical data types in a primary care system may contain (but not limited to) these sections:

• Personal identification section - often known as the Demographic section, contains all the personal identification data such as name, date of birth, gender, contact information, insurance, next-of-kin etc. Any change to any of this data will be logged. Typically, this section should allow expanded fields as different jurisdiction may have specific requirements for identifying individual patient belonging to that jurisdiction.
• Patient summary section - this is sometimes called the Cumulative Patient Profile (CPP) or the more structured and HL7 compliant Continuity of Care Record (CCR). This section typically contains the most important and the latest summary of a patient's medical condition including medical alerts and drug allergies, major medical conditions, drug profile, immunization, and important psycho-social information that may play an important role in the health status of the patient. The storage area for this section includes fields that contain the actual data, as well as pointers to the other section of the EMR, e.g. drug profile.
• Disease Registry - if the patient has been identified by a health care professional, or a health care organization, as having the disease(s). Each disease typically includes the actual diagnostic code(s), e.g. ICD9. The identified disease(s) are assumed to meet all the inclusion and exclusion criteria for diagnosing the disease(s).
• Prevention, including immunization and other preventative procedures.
• Laboratory section - this can include records containing the original data format, e.g. HL7, and classification system, e.g. LOINC. It can also include files in PDF format as well as scanned images.
• Diagnostic Imaging section - this may include the actual images or the reports as read by the radiologists.
• Correspondences - may include electronic messages and faxes. These are typically internal, a copy of the prescription or an xray requisition; or from an external source such as the hospitals, consultants, and other caregivers. The format may be structured, e.g. HL7, or unstructured, e.g. scanned images.
• Measurements - typically discrete data elements, e.g. BP, weight. Each measurement must contain observer/author, timestamp for observation and timestamp of recording. If information is from an external source, or has been interpreted (see above) the information must be included.
• Medication - history of all prescribed drugs, almost always from an external source (e.g. family doctor or specialists). It can be from the patient's self-report, e.g. over-the-counter drugs, vitamins, herbs etc. It should also include a section of drug allergies or drug intolerance. It may also contain a medication administration record (MAR).

The entire patient record may reside in on MyOSCAR database server but in future it maybe scattered in different physical servers or even different MyOSCAR servers anywhere else on the Internet. If a patient wants to own a copy of the entire record, it should be possible to retrieve absolutely everything to be stored locally, in encrypted format. Alternatively, some form of patient summary can be downloaded or printed for portability.

How to create surveys in MyOSCAR

[This blog is an adaptation of the original document written by Pavel Antiperovitch in September 2009. The more technical document is now contained in the official OSCAR User's Manual site.]

The MyOSCAR Survey Module was built to read a survey script file written according to the following instructions (which was derived from the programming standards of a MUMPS configuration file). The script file defines the survey questions and flow. The purpose of this document is to describe the format of the script file.

(I) The Header
The header of the script file contains several global parameters.  For example:

.title=Diabetes Risk Survey
.instances=1
.hidden=false

The following Table contains a list of global parameters.

Property	Values	Default	Explanation
.title	text		Title of the survey as it will show up in the drop-down list menu.
.instances	number (integer)	65000	A number of surveys each user can fill out.  If one-time survey, enter "1".  Once the survey # has been reached by the user, it will no longer appear in the drop-down menu.
.menuhidden	true/false	false	Indicates whether the survey will appear in the menu.  If "false" is selected, it will not appear in the menu and the users must have the link to the survey to fill it out.  This is useful if a research investigator wishes to e-mail out links to surveys at specific time points in the study.
.progressbar	true/false	true	Indicates whether the question progress bar is displayed in the survey.
.geomapping	true/false	false	Turns the geomapping module for the survey on/off (to map responses geographically).  This was used in the pandemic surveillance survey.
.booleanResultStatement	statement that evaluates to true or false		This allows the result for each survey to be rendered as true or false.  For example:  (A1.size()>=3) means that question A1 must have at least 3 items checked off.  This was used in the pandemic surveillance survey to indicate that the user must check off at least 3 symptoms to be classified as "true" for having the infectious disease.

(II) The Body
The body of the script file consists of a series of questions, where the beginning of each question is marked by a line starting with '.qu='. The following is an example of the question block:

.qu=E3a,type=select
Do you have any difficulty walking up 10 steps?
 
.an=1
1 = No
2 = Yes
3 = No longer do this due to the difficulty of doing it
4 = No longer do this, but reasons are not related to my health
5 = Never did it
6 = Don't know / refused
.lo=1
.hi=6
.if (E3a = 1) E3c
.if (E3a = 2) E3b
.if (E3a = 3) E3e
.if (E3a = 5) E4a
.if (E3a = 6) E3c

.next=E3b

The following are explanations of each of the above script line:
.qu=E3a,type=select 
*Required*
".qu=" indicates the start of the question; "E3a" is the question identifier (only alphanumeric characters are allowed - keep this short and simple, no spaces!)
"," separates the properties
"type=select" defines the answer to this question type as "select" (see below for possible question types).

Do you have any difficulty walking up 10 steps?
*Required* 
This block defines the actual question text.  You can use HTML to add various font properties or images.  The question block is always terminated by the ".an" line.  When the text is displayed the rendering survey engine puts <br> (enterspaces) in the html, so if you put multi-line html and javascript, you must escape it with <%--   your stuff here      --%> otherwise your code/html will be interspersed with <br> tags.

.an=1

*Required*

".an" stands for "answer", and indicates the start of the answer block. If the question shows the participant a list of choices, they would be listed underneath

1 = No
2 = Yes
3 = No longer do this due to the difficulty of doing it
4 = No longer do this, but reasons are not related to my health
5 = Never did it
6 = Don't know / refused

This block defines the answer choices, and is only applicable for question types "check" and "select". This is ignored for all other question types. Each choice consists of two parts: the identifier and text, separated by ' = '. The identifier is an integer that will be used to reference the answer choice in 'if' statements (see below), and the text is the part seen by the survey participant. Note that the identifier is optional, and defaults to incrementing numbers starting with 1. However, including the identifier is considered good form.

.lo=1
.hi=6

This defines integer answer validation, where .lo and .hi indicate the lowest and highest allowed integers respectively. To avoid problems, it is advisable that this is included ONLY for questions of type "number" (otherwise using these properties makes no sense).

.if (E3a = 1) E3c
.if (E3a = 2) E3b
.if (E3a = 3) E3e
.if (E3a = 5) E4a
.if (E3a = 6) E3c

This is the 'if' statement block that defines the survey question flow. In this example, E3a is a question identifier. The answer to each of these questions is mathematically compared to the value using operators such as =, >=, <=, <, >, @. 
If the condition is true, the survey jumps to the next question specified at the end of the line. For instance:
- The first statement is interpreted as "if answer to question E3a is '1', go to question E3c".
These 'if' statements are executed in order as defined. If one evaluates to "true", all the other ones are ignored.
- If the question is of type "check", it holds multiple answers. In this case the operator '@' must be used to symbolize "contains". For example, 

.if ((E3a @ 3) and (E3a @ 4)) E4a
.if ((E3a = 1 or E3a = 6) and (E3a = 1 or E3a = 3 or E3a = 4)) E4a

if the 1st statement reads "if the answer to question E3a contains 3 and 4, then go to question E4a"

.next=E3b

*Required* This defines the next question if the 'if' statements are missing, or all evaluate to 'false'. In this case, ".next" indicates that the next question in the configuration file is displayed. Optionally, the question identifier can be specified to direct the survey to go to a different question (i.e. ".next=E3c")

CAUTION: Make sure that the questions in the condition of the 'if' statement have been asked before. If the question appears in an 'if' condition that has not yet been asked, the survey module shows an error at runtime.

The following question types are curently supported:

• void - the question does not require a response. This is useful for displaing information such as introduction and conclusion instructions

• number - the user enters an integer answer.

• string - the user is given a textbox to type words or sentences.

• select - the user is given a series of options to select from (can select only ONE answer)

• check - the user is given a series of checkbox options to select from (multiple selection allowed)

• decimal - the user is given a small text box and value is stored as a decimal

DO's and DON'T's: If you must ask the user the same question more than once, copy + paste it under a different ID (don't make this more confusing that it has to)

Examples:

.title=Risk Profile Recording Form
instances=1

.qu=intro,type=void
This form will ask you a series of questions about your cardiovascular
health.  For each question, please select or type the appropriate response
and press "next".  You may exit the survey by clicking "Save and Close", and
return to it later by signing into myOSCAR and clicking the 'Surveys' link on
the left hand-menu.  The survey will save by default every 3 questions.
.an
.next

.qu=E1,type=select
Is this a repeat visit?
.an
1 = Yes
2 = No
.if (E1 = 1) finish
.next

.qu=E2,type=select
In general, would you say your health is:
.an
1 = Poor
2 = Fair
3 = Good
4 = Very Good
5 = Excellent
.next

.qu=E3,type=number
What is your height in cm?
.an
.lo=0
.hi=500
.next

.qu=E4,type=number
What is your weight in kg?
.an
.lo=0
.hi=1000
.next

.qu=E5,type=select
Have you ever had a transient ischemic attack (TIA or mini-stroke)?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E6,type=select
Have you ever had a stroke?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E7,type=select
Have you ever had a heart attack?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E8,type=select
Has your doctor told you that your cholesterol is high?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E9,type=select
Has your doctor told you that you have diabetes?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E10,type=select
Have you ever been diagnosed with high blood pressure by a doctor?
.an
1 = Yes
2 = No
3 = Not Sure
.next

.qu=E11,type=select
Are you currently taking prescription pills for high blood pressure?
.an
1 = Yes
2 = No
3 = Not Sure
.if (E11 = 1) E12
.next=E13

.qu=E12,type=select
Do you take pills for high blood pressure each day?
.an
1 = Yes
2 = No
.next

.qu=E13,type=select
Do you currently smoke?
.an
1 = Yes
2 = No
.next

.qu=E14,type=select
In a typical week, how many times do you eat high fat or fast foods?
.an
0 = Zero
1 = 1-2
3 = 3 or more
.next

.qu=E15,type=select
Typically, do you drink 2 or more alcoholic drinks a day?
.an
1 = Yes
2 = No
.next

.qu=E16,type=select
Do you eat 5 servings or more of fruits and vegetables a day?
.an
1 = Yes
2 = No
.next

.qu=E17,type=select
How frequently do you add salt to foods during cooking or at the table?
.an
1 = Rarely
2 = Sometimes
3 = Often
.next

.qu=E18,type=select
In a typical week, how frequently do you feel overwhelmed or stressed?
.an
1 = Rarely
2 = Sometimes
3 = Often
.next

.qu=E19,type=select
Are you moderately physically active for 30 to 60 minutes, most days of
the week? (e.g. brisk walking, active gardening, swimming, dancing or biking)
.an
1 = Yes
2 = No
.next

.qu=E20,type=select
Do you live alone?
.an
1 = Yes
2 = No
.next

.qu=finish,type=void
Thank you for completing this questionnaire.
Click "Next" to save your answers and exit.
.an
.next

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.