Personal tools
You are here: Home / OSCAR EMR 12.x / 4.0 Developers / 4.8 Specialist / 4.8.1 Overview

4.8.1 Overview

While OSCAR can be used "as is" for many specialist practices, customized work-flow is supported through customization of the view presented to the user. This includes the eye-form which is the most developed interface for Ophthalmology/Optometry, and a javascript based way to interact with the encounter page.

Introduction

As the OSCAR community grows, the software must be able to support customizations for the wide spectrum of users. Specifically, as specialists and medical professionals outside the primary physician setting join the community, OSCAR must be able to present many different views of the clinical information contained within.

Up until when this functionality was added, if an OSCAR user wanted data presented slightly different in the eChart, they would have to hire a programmer to modify the source code, and usually that programmer would have to put the new code in a conditional statement which could be enabled or disabled from a new properties. This proliferation of conditional code, and the rapid influx of properties has added complexity for both the OSCAR developer as well as the OSP (Oscar Service Provider).

The specialist interface tries to address these issues by customizing views in OSCAR mainly through the use of JavaScript. OSCAR exposes a simple way to customize (to a certain extent) how data is presented on virtually any page in the system. These changes do not require core code changes, and thus can be maintained and revised without upgrade of the core OSCAR components.

The initial release is currently available in OSCAR 11/12 .

As the needs of data representation in different spaces becomes more apparent, the library will grow, and authors of alternate views will have more options available to them for representing data and workflows which meet their client needs.

The framework has mainly applied to the eChart view, as well as the main schedule view, and consultation requests in a more minor fashion.

The idea is to develop views which are built upon components which can then be assembled in differing configurations. The initial requirements, and implementation evolved from the development of the Opthalmology module (also known as the EyeForm) by the OSCAR McMaster development team.

Currently, which a custom script is enabled, it's enabled for all providers of the instance. The roadmap for this component calls for enabling custom scripts based on multiple variables, such as the curently logged in provider, the type of appointment, the program in which the provider is seeing the patient, etc.

 

for further detail see

Document Actions