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.