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.

What are MyOSCAR Apps

As defined by the National Alliance for Health Information Technology in a report to the National Coordinator for Health Information Technology (NCHIT), “a PHR is an individual’s electronic record of health-related information that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared and controlled by the individual.” 

The core principles in the design of a sustainable, widely adopted PHR should therefore include the following:

• There should be strong adherence to nationally recognised interoperable standards in order to promote health information sharing.
• PHR users should be able to interpret their health information in order to manage their health and illnesses.
• The system should make it a priority to address privacy and security issues.
• Cost should be sustainable, both to individuals and the public.

What is MyOSCAR

It is designed from the ground up as a Personal Controlled Health Record (PCHR). We apply everything we know in the design of a multi-national, multi-language, ISO-certified, Electronic Medical Record (i.e. OSCAR) to create an electronic health record, managed and controlled by the individual owner. It is created as a life long medical legal health and wellness record. It takes a pragmatic approach to conform to interoperable standards. As such, it uses what is currently acceptable standards with the flexibility of migrating to future standards. It uses the eXtensible Markup Language (XML) for data modelling and Clinical Document Architecture (CDA) to store it's documents. The document database is encrypted for security and is designed to be extremely difficult, if not impossible for data mining. Moreover, as part of the future work plan, an individual can have multiple PHR accounts distributed across multiple servers, very much like an individual owning multiple email accounts. These accounts can be merged or consolidated even at a local storage device level, using technology such as the smart phones or thumb drives, for ultimate portability.

What are MyOSCAR Apps

Broadly speaking, these are web applications that interact with the individual's MyOSCAR data to produce clinical or administrative benefits. Apps can be native or remote. The following is a summary of the differences between the two types of Apps:

1. Native Apps are fully integrated with the distributed software and are managed by the MyOSCAR server owner. Remote Apps operate on their own web servers typically residing elsewhere on the Internet. These remote Apps interact with MyOSCAR using published terminology and messaging standards.
2. Native Apps use the same User Interface (UI) as the native MyOSCAR Client whereas remote Apps may operate within the MyOSCAR Client UI, typically as a "frame" or may use a completely different and independent UI, typically in a pop-up window or a new tab on the Internet browser.
3. Native Apps, once added by the individual user, have full read and write access to all the MyOSCAR data whereas remote Apps are restricted (by the MyOSCAR access control layer) to read only, or read and write the data elements that have been specifically permitted by the user at the time when the App is added.
4. Native Apps keep their aggregate data within the same MyOSCAR server. This data is accessible by users who are known to the MyOSCAR server. Remote Apps keep their aggregate data outside of the MyOSCAR server. The use of this data is dictated by its own privacy policy as published and known by the MyOSCAR user.
5. Development of native Apps follow the same ISO process in the production of the MyOSCAR software. Remote Apps are developed and maintained by the App code owner.  However, remote App developer may choose to follow the same Open Source Software license as the MyOSCAR project and place the code in the same code repository. However, the App code may follow its own release cycle and may or may not need to be part of the ISO quality management process.
6. Endorsement of native Apps are typically done by the MyOSCAR community through its volunteer supported management structure. Remote Apps are rated by MyOSCAR users and can improve ratings by endorsement from reputable organizations.
7. Native Apps usually do not receive industry funding.

The following discussion applies only to remote Apps. In general, a remote App must publish its compliance in three important areas:

1. Type of data to be pooled
• (1A) No data of any kind will be stored. Individual health information is used only once and promptly removed from the App after each use.
• (1B) Anonymous or de-identified data - data that have been stripped of all subject identifiers and that have no indirect links to subject identifiers.  There should be no limited identifiers in anonymous or de-identified data set.
• (1C) Coded data - data that have been stripped of all direct subject identifiers, but in this case each record has its own study ID or code, which is linked to identifiable information such as name or medical record number.  The linking file must be separate from the coded data set. 
• (1D) Fully identifiable data -  it is assumed that this App must comply with the legislative requirements of a Health Information Custodian (HIC).       
2.  Use of pooled data must be stated clearly in the privacy policy
   
   • (2A) Data captured in the App server is never shared. It is possible that the App server may use the data to generate internal use statistics or other administrative reports.
   • (2B) Data can be used to generate population based report. The App must seek consent at the time the App is added by the user.
   • (2C) Aggregate Data may be shared with other outside applications. The App must seek consent at the time the App is added by the user.
   • (2D) Individual/identifiable data may be shared with other outside applications. The App must seek consent every time an individual data is shared with an outside application. Individual may set "break glass" policy at the time the App is added.
   
   
3. Endorsement and funding must be explicit
   
   • (3A) App does not receive any external funding
   • (3B) App receives funding from not-for-profit or government organizations
   • (3C) App receives industry funding which has not direct control over the App or its data
   • (3D) App receives industry funding which may have control over the App and or its data 

At this point of the MyOSCAR development, it is a balancing act to promote Freedom or to impose Constraint. The "policing" of individual App regarding its adherence to its declared compliance to the above will be difficult. Until we have a critical mass of MyOSCAR users as well as App developers, we should take a more flexible approach and focus on educating developers the importance of these principles.

In the following blogs, I will give examples of Apps that have been developed or at various stages of development and examine how they fit with the above principles.

What are the potential clinical and business benefits for using MyOSCAR?

I have been a MyOSCAR user since 2005. I had no idea where it was going at the time. We started with the free software from MIT/Harvard. We made some changes to OSCAR to make it easier to communicate with patients right from OSCAR. I had some research money to hire a few students in the summer to stuff envelops and to create accounts for my patients. We invited some 500 patients to participate. So what have I learned so far. Am I closer to convincing my colleagues (and patients for that matter) to use MyOSCAR?


Before addressing the clinical and business benefits, I have learned over the years that there are still a lot of misunderstanding and myths about the the whole idea of Personal Health Record. Here is a list of common objections and my arguments for using MyOSCAR:

(1) I don't want my patients to see all my record
You don't have to if you don't want to. MyOSCAR is a different record outside of your OSCAR record. Patients don't have access to their records in OSCAR. You provide a copy of anything you think would benefit your patient, or if a patient requests for it.

(1b) I don't want to see all the stuff my patients record, or records from other providers (like naturopaths!)
This is similar to (1). You don't have to read anything if you don't want to. It's there if it is helpful - like patient's home BP monitoring. MyOSCAR is the patient's record, owned and controlled by the patient. You don't have any legal responsibility in making sure all the stuff there are accurate or useful. It's no different from patients coming in with a spreadsheet of their BP readings.

(2) I don't have time to check all the emails from my patients
Patients cannot contact you if you don't give them permission. You get to choose who can contact you and if you think the patient has abused that privilege you can remove that privilege anytime you want (I have only done that once over the years). The patient will get a message "You don't have permission to contact this provider" when he/she tries to contact you. You choose to give permission to someone whom you think would benefit from having this method of access. I have found that I have fewer phone calls if patients can write me via MyOSCAR. I decide when and where to return their message. I get on average 1 to 5 messages a week.

(3) What about legal liability if you write something down and patients act on your advice? Or if you send patients their reports and patients misunderstand the results?
This is no different from offering your advice face to face or by phone. Apparently about 40% of phone conversations are never documented in the chart. It's your word against your patients. If the conversation is clearly documented, it tends to be better thought out, with references from reliable sources, and patients have more time to digest the advice. You also provide opportunity for patients to clarify your advice further if necessary.

(4) I don't want "frequent flyer "patients to fill up all my appointments
Again, it's a privilege you give to your patients for online booking. Our clinic has chosen not to post any restriction but your clinic can decide who, when, what kind of appointments, which (participating) provider, how many appointments etc.

(5) Many of my patients don't have a computer or Internet access
Most of them do and they are quite computer/Internet literate. In many situations it is the caregiver, or the Power of Attorney who will gladly manage the MyOSCAR account on behalf of the patient.

(6) It is too expensive and who is paying for it
MyOSCAR is free(!). Well, the cost of using MyOSCAR is fairly low even if you are not the techie, do it yourself kind. Patients are quite happy to pay for it according to the many surveys we have done.


Well, once you have "disarmed" your colleague with great arguments above, you can then present these benefits, starting with business, then clinical. Many of these have fairly good supporting evidence.

(1) Online Self Booking will save you money
At least one university health service is banking on reducing one receptionist position because of this feature. My patients will be very happy not to have to be put on hold (sometimes at the back of a queue of 25 callers at 8:30 in the morning!). I don't have experience with this but our surveys suggested that patients are willing to pay for this service!

(2) Secure messaging can be a revenue stream
This is a difficult one especially if you are on a Fee-for-service style practice. For a capitation type practice, studies have shown that secure messaging can reduce the number of office visits, or enhance the quality of a visit if prior communication via secure messaging has taken place. More about this under clinical benefit below. Again, surveys have shown that patients are willing to pay for this service. In the United States where supply exceeds demand for family practice, patients are willing to switch family doctor if one will provide secure messaging service!! One of the commonest type of messages I get is medication renewal. Although I don't charge patients (I have a capitation type practice), I have seen other clinics charging a fee for every medication renewal by phone. Likewise, you should be able to charge a "processing fee" for making copies of patient's record or forwarding test results with an annotated advice message. I have considered the MyOSCAR service as a "block fee" for individual, or a family.

(3) Installation and maintenance of MyOSCAR can be as easy as you like
If you can't provide technical support you can always out-source it; or if you don't want to install your own MyOSCAR server, you can send your patients to another MyOSCAR host out there. Once again, I think patients are very reasonable, they will be happy to pay for the service with support included. This is not for everyone in your practice. It's about a choice offered to your patients. I can now enroll a patient at the end of a visit with just a few clicks in OSCAR. I print the registration letter which includes the patient's username and temporary password and instruction of how to login. I can decide whether the patient can or cannot communicate with me right from the registration screen. There are more and more self-support Youtube videos to help patients using this service.

(4) There will be Apps (potential revenue sources as well as evidence based clinical management for patients)
MyOSCAR is a perfect platform to launch Apps. The Online Booking is really part of the Clinic App. The Clinic App can stream (RSS feed) from your clinic site important information and announcements right to the patient's MyOSCAR account. Patients can pick Clinic specific functions, such as Booking Appointments. The idea of a Clinic App is that patients can interact with the clinic at the clinic level. 

There have been many Apps going through their study phases:

• MyBP - hypertensive patients managing their cardiovascular risk factors with the help of a small group of professionals (pharmacist, dietitian, and a nurse practitioner).
• MyMEDS - medication monitoring of effectiveness and adverse reaction
• eDiabetes - screening of patients at risk of developing diabetes
• eAAPS - electronic Asthma Action Plan System
• BORN - antenatal care
• ORN - Ontario Renal Network managing Chronic Kidney Disease
• Chronic Pain - managing chronic pain
• HealthLink - managing complex patients who are using huge amount of health resources
• TAPESTRY - keeping patients healthy at home
• I-am--able, I-am-pregnant; these are some of the previous studies that used MyOSCAR as a platform for communication, patient entering their clinical status; and patient executing self-management care plans.

(5) Asynchronous secure communication can improve efficiency and outcomes
It will not be immediately obvious in the beginning but I have found a few particular situations where clinical benefits are quite immediate:

• Home bound patients: it will save a few home visits and even home visits will be briefer
• The sandwich generation will be the most grateful. I have looked after many complex geriatric patients with the children communicating with me via MyOSCAR. They are usually middle age professionals who would appreciate keeping in touch without taking time off. These busy professionals also happen to be parents with children in need of quick advice
• Some mental health patients require frequent follow-ups. MyOSCAR will reduce the need for 30 minute counselling. Patients will learn self monitoring of symptoms and side effects of medications and feedback can be done "virtually".
• Patients going through tough time can benefit from improved access and communication. These are patients going through cancer treatment, or after hospitalization.
• This is a particularly great forum to include allied health professionals in coordinating care with very complex patients (e.g. chronic pain or patients with multiple co-morbidities).

How I use MyOSCAR from day to day

It's been a while since anyone has posted here so I think it's time for an update.

I opened my email this morning and lo I received a notifier from a patient. The message simply said:

You have received a new message from JANE DOE. Login to MyOSCAR to view the message.

You can't click a link to open MyOSCAR. It's a safety feature to avoid phishing. But I have a bookmark for MyOSCAR so it's easy enough to open up another window (or a tab in the same browser). But I actually don't even have to do that because my EMR (OSCAR of course!) is fully integrated with MyOSCAR. So I simply go to my EMR and click the MyOSCAR tab (see the big red arrow):

I can see the new message(s) as well as the older messages I have left in my Inbox:

A glance at my Inbox revealed that I have received 12 messages this month so far. Not bad for a practice in which about 600 patients have been offered the MyOSCAR service.

Using my EMR to work with my patient's PHR makes it a lot easier to keep track of things. For example, the patient's message as well as my reply are automatically inserted into the patient's chart:

So when I see Jane next week I can review all that have happened leading up to that point.

I will describe more MyOSCAR features on my next post. But suffice to say that the secure messaging feature of MyOSCAR has become an indispensable tool for my patient care. I can deal with a lot of my patient's problems a lot sooner and at a much more convenient pace for both me and my patients. I am certain that my patients (the ones who use it anyways) really appreciate the improved access to getting help.

I have heard many objections from health care providers about letting patients send them electronic messages. Generally these are the common ones:

(1) I will be flooded with messages and where do I find the time
My answer to that is that my experience has been the opposite. Let's say this month I received 12 messages out of 600 patients. That's about 2 messages per 100 patients per month, or about 20 per 1000 patients which is the average size practice. I am sure I have saved at least a few physical visits (or phone messages) and when I actually see these patients in my office, the visit will be shorter and of better quality since so much of the needed information have already been communicated. And I can do my work without the constraint of my office schedule! And no more phone tags!

(2) I am afraid of the legal consequences since conversation will be on black and white!
My argument is that it is actually better to have everything documented. My correspondence tend to be more thoughtful and better prepared (like having looked up more information before I make a statement). I remember once being asked by a patient what she needed to do when she had to fly on a plane given that she was on a blood thinner. I actually looked things up and gave her an answer that I was more confident with. If she had come to my office and asked me the same question point blank, I would not be able to look things up, and would probably have given her an answer I was less confident with.

I am convinced that the future health care system will demand more online communication between patients and providers. It will provide better care, and hopefully improve health!