Mohammad Al-Ubaydli’s blog

Using Ajax for Cleaner Software

Posted in Articles, Medicine, My publications, Technology by Dr Mohammad Al-Ubaydli on November 22, 2008

Published in UK Health Informatics Today Autumn 2008 edition.
Mohammad Al-Ubaydli, MB BChir Cantab
Founder, Patients Know Best – www.patientsknowbest.com

Ajax is a new web programming technology that solves an old conflict between CIOs and clinicians and eases the use of innovative devices in large organizations.

For IT staff, managing a single server with web browser-based clients is much easier than installing client software on every single computer that clinicians use. But for clinicians, web browser client software is too slow and simple: only clients installed locally on a Windows machine provide the responsive and rich user interface needed for consultations with patients.

Traditionally, this conflict was settled in favour of the clinician. Staff from the IT department had the Sisyphean task of installing software onto every computer, and no sooner had they completed one round before the next one began with a newer version of the software. Furthermore, local software stored data locally, requiring strong security protocols on each computer.

Ajax can end this cycle. It allows web browser-based clients that are fast and powerful in their response to server software, which the IT department may now focus on managing. Ajax is an acronym for Asynchronous JavaScript and XML. XML is the data that is exchanged between client and server, and JavaScript is the browser-based programming language that is powerful enough to support complex user interfaces.

Asynchronous is the clever and recent innovation; it allows the browser to only update the part of the screen that is relevant to the user’s most recent interaction. In other words, rather than redrawing the entire page in response to a user’s click, the web browser can redraw only the relevant part in an Ajax-driven page. The rest of the page can continue to function asynchronously as the XML arrives for the part that the JavaScript is changing.

The release of Google Maps in 2005 was a watershed event in showing the world what Ajax could do. The technology had been in place since 1999 when Microsoft introduced the XMLHttpRequest programming object for asynchronous communication in Internet Explorer, and soon afterwards Mozilla and Opera followed suit with support in their own web browsers. However, few sites made use of the technology and few users understood its significance. But with Ajax, maps on Google’s website loaded quickly and scrolled even more quickly. By contrast, existing map sites had to reload the entire page with each click by the user.

Slowly, mainstream healthcare software developers are integrating this approach into their products. Naturally, it is startups that are first to do so, companies like Tolven Health and Net.Orange. From my conversations with the executives of larger, more entrenched companies, they too are making the switch.

Just as significantly, it is easier to deploy innovative devices because most of them support Ajax in their web browser. Apple’s iPhone, for example, was notorious among developers because the first version only accepted Ajax software. The web browsers of most new smartphones also support Ajax.

This means that clinicians can use operating systems other than Microsoft Windows, something that has so far held back deployments in the NHS.

The switch to Ajax does have security implications. On the one hand, Ajax-powered thin client software is more secure than locally installed thick-client software because the data is only stored on one central server for which security can be maximized. But the ubiquity of the web means developers must abandon previously tolerated but inherently insecure practices.

Most significantly, state data must only be stored on the server, not the clients. Examples of state data include the fact that the end user is a doctor or the identification number of the patient they are looking; these must be maintained centrally even if they are temporarily displayed on a local web browser. Programs that do not have this architecture leave themselves open to manipulation at the local computer level. For example, a malicious end user may easily identify and manipulate their state data by editing the local cache file to identify him- or herself as a doctor.

Such vulnerabilities were always possible with old, thick-client computing models. Security through obscurity made this tolerable because each program had its own security model and fragmented market share. By contrast, the web is much more transparent and information about vulnerabilities is shared
quickly and comprehensively.

If you are working with an experienced programmer who is new to Ajax, the risk is that such a programmer would assume that programming in the web environment is the same as working with Windows. A simple explanation of this vulnerability is typically enough to enable a change in programming habits.

Such changes in habits are well worth the effort. The end results are software that is cleaner to deploy and manage as well as increases in the productivity of IT staff –things from which we can all benefit.

Tagged with:

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: