Technology and architecture challenges in UI implementation.

The problem

In UI implementation, clinical applications demand quite capable UI controls. Just take a look at Microsoft CUI project components, and you can see how specialized widgets clinicians need in order to use clinical software efficiently.

Since these are not the usual buttons and checkboxes of a business application developer, even if the design is approved by the clinicians, their implementation demand a capable UI technology. Just investing into strong UI technologies does not solve the problem, because openEHR implementations heavily rely on models, in other words composition of RM classes described by ADL.  Joining the UI to these models is an architectural challenge, and unfortunately all UI technologies do not fit with all architectural  options. There are pros and cons of UI choices, and I'll try to list and discuss them below.

The reality about distributed systems

In today's world, developing a clinical application which does not have a distributed nature is not likely. After all, most of the effort in openEHR, Snomed CT, HL7, and other initiatives is about sharing data. There is a very strong assumption of sharing data among clinicians, so the system becomes distributed at some point anyway. Web applications are distributed by nature, due to browser server communication, and desktop applications (other than a single doctor in a single practice scenario) are also distributed in nature, mostly due to database and business logic being at seperate layers, and mostly on different machines than the client's machine. There are many doctors out there with a simple software that runs on a windows 98 environment (yes, windows 98) using a piece of code written in Delphi, but these are the people we want to connect to others anyway. So I'll assume that any implementation will end up in a distrubuted nature somehow.

Binding to model

In any distributed software, the user is given a front end, a UI, which has to be connected to some back end functionality, and how that connectivity is achieved is the problem of the implementor, not the user. This is a very well known requirement which has been implemented in various forms through many different technologies.  This binding to back end is a key factor in decrasing costs for the implementor. The easier and more efficient it becomes to connect UI to back end, the better an implementors position in competition with the others. If you can change the location of a UI widget without compiling code, that is and advantage, if you can simply annotate a UI widget with a special expression that will automatically connect its value to some back end object, that is an advantage. Unfortunately, you just can't say, okey than let's pick up the most efficient one, and use that, because other requirements like capable UI widgets conflict with this one. Let's see why

How UI binding to back end works in modern technologies

I'll take  JAVA and .NET as two major technology platforms, with the most advanced architectural practices and available frameworks. If you are using Python, Ruby, Orbeon, Eiffel, C++, your method for binding UI to back end may or may not be different, but your input to this dicussion would be appreciated.

Today, some form of data binding is available for almost all serious technology frameworks. The name for binding to back end may be data binding, or method binding or bean/object binding, I'm referring to practice of declerative bindings from UI to some back end functionality.

Naturally, UI frameworks have to define a well documented, well defined way for bindings. You can not expect developers to use a different binding for each UI widget (at least not in all domains), so at least for form based business applications, there are generic binding mechanisms like binding the value of an textbox to a backend object. There is usually a set of basic widgets, like text box, combo box, check box, and table etc. There is usually a set of development tools which let you use this framework, both visual studio for .NET and Eclipse Web Tools Project are examples of capable tools which let you modify GUI layout, develop and deploy code etc. If this setup of components, tools and frameworks is enough for you to fulfill the requirements of users, then things are fine.

As you need to change things, especially in the UI, this scenario begins to become more complicated. An example from Opereffa is the JSF bindings. Java Server faces has nice things like templating, which lets you reuse UI artifacts, it has a good data binding mechanism for binding UI widgets to back end Java beans (objects), it has a lifecycle mechanims to which you can tap into, it has validation methods for data sent to server etc. JSF is the latest web development stack which is a specification, so it is the usual industry accepted Java technology like many others we've been using for the last decade or so. In terms of UI, this specification's implementations offer a set of options, which are more or less like the others. Some implementations have some javascript support for more convenient components like date pickers etc. This mature and tested framework, which should cover a lot of use cases, begins to be insufficient when it comes to building a web based clinical application with openEHR. Here is a list of things I had to to, along with their explanations.

1 to 1 or n to 1?

A design question that came up early in the proof of concept work was this: do we generate a seperate back end object for all UI forms, or do we bind all forms to a generic mechanism that can process all UI forms?

The advantage of having a seperate object for each form is, it is possible to stay closer to the normal way the framework is supposed to be used. You can generate source code for each model, with field and method names corresponding to archetype nodes. However, this scheme of things requires a recompilation and redeployment each time you change something in an existing GUI-object binding, and whenever you introduce a new set of artifacts, ie new models to the system.

Using a single binding mechanism to back end on the other hand, lets you create artifacts in the form of JSF XHTML files, and you can update them on the fly, as the system is working. Personally my golden rule is to invest in cheaper maintenance in software whenever you can, so this is how Opereffa works, but is this type of binding possible at all in JSF, with its default setup? The answer is no, and here is why.

Archetypes describe models, to which we need a way to refer to from UI. The binding example given here shows the situation at the moment, but normal binding syntax of JSF does not let you express the semantics you need for archetype binding. So Opereffa extends JSF's Unified Expression Language resolver with a custom resolver to connect UI artifacts to a single resolver. 

This solution, which requires a little bit modification to JSF, is still  a JSF solution, since it uses valid options in the framework. We can use open source or commercial tools to modify JSF XHTML files, and we have both automatic connectivity and tool based productivity, It looks good! Things get tough when we reach the UI level at the browser.

Which technology for the browser?

The browser is the platform now. There is an incredible amount of functionality you can perform within a browser, ( just take a look at quake live ) and this is good news, because the UI layer for a web application is the browser, and it is good to have a lot of power at this level, so that we can give clinicians an efficient UI.

The problem is, the more specialized the UI layer, the more disconnected it becomes from server side web stacks. Asp,NET, JSP, JSF, Ruby on Rails, PHP are all server side web stacks, and things like bindings to business objects are features of these stacks. They expect the browser to render html or HTML + some javascript and they expect a good old http post or get to initiate the bindings to objects.

When you choose more specialized technologies for browser, like Google Web Toolkit, Flex, Flash, Silverlight etc.., the classical web stack technologies become irrelevant. These powerful UI frameworks of the browser either use their own protocols or well known methods like JSON or Web services (or REST for a simpler version of it). So if you invest in them, you need a different set of tools to increase your productivity. In case of Opereffa, selecting one of these means two things:

1) Binding mechanism is no longer useful, since it expects a http post

2) Tooling around JSF is no longer useful, since JSF artifacts are not used, you now need a designer for Google Web Toolkit related tool, or a Silverlight designer.

From a project management point of view, younger technologies are risky. You have to find develoepers who have experince in your chosen technology, and no matter how much hype is behind them, technologies just don't cause developers to grow in trees. You can find someone with 5 years of JSF experience, who has an idea about how to handle almost any requirement with JSF. Try the same for GWT or Silverlight, and lets see what happens.

The technologies themselves also have to prove that they they can survive real life, and with ASP.NET and JSF you can find many working examples of important projects, but if you switch to some young technology, you are either the next success story or the sacked project manager who is just in between jobs at the moment...

Back to doctors waiting for their capable GUI. We chose DOJO in Opereffa, so that we can have something better than plain HTML, and we can still use JSF bindings. At the moment, it is working, but is it absolutely future proof? I don't think so. It can survive up to a point where users of Opereffa say: "this form takes forever to fill", or "why can't we have those useful widgets in Opereffa?". The thing to remember at that point is the cost and benefit of choosing a different combination of technologies and architecture.

One can bypass HTML and invest in a RIA (Rich Internet Application) technology. For UI this may feel like a fresh breath of air, but don't be surprised if some of the project managers and developers spontaneously combust. You may have to buy new licences for a set of tools, you may have to deal with setup of a new middleware, which ends up consuming twice the hardware your old one used to consume. The point is, every change has an effect.

Non technical issues

In Opereffa, we have multiple non-technical, non-functional requirements. It needs to focus on open source, it needs to support tooling, it has to be industry friendly. But we can never win all of those battles. For example if pressure for very specific components in UI becomes too high, JSF can be replaced with a web services type of layer, which is direcly connected to UI via some sort of remoting technology. We may win clinicians, but lose technical people with this decision. The choice is not our all the time either. We may have to abandon JSF + DOJO combination simply because it can't do some of the things we need to do, or can't do them properly. This is why we have CRB, to push us if we need pushing.

Technologies

There are a couple of technologies mentioned above, in the context of this discussion. They are all capable UI layer options, with their pros and cons. Here is a brief summary of them:

DOJO Toolkit: It is an open source AJAX framework with its own widgets. It allows design of custom widgets, and it can parse and turn normal HTML output in the browser into its own widgets. This is the way it is used in Opereffa, since it is possible to decleratively mark JSF components in XHTML files, so that their output can be parsed by DOJO. It is also a pure client side javascript kit, in the sense that making use of it does not require you to tweak anyting in the server side, When used in declerative way, normal HTML editing tools can be used to edit source code, ui layout etc.DOJO is quite good at isolating the developer from quirks of multiple browsers, and javascript probably has the largest market penetration among all other browser technologies, including flash. It is cross platform, so all major platforms should be able to consume it.

Flex: It is a technology that uses flash runtime in browsers, it is open source and free, but its development envrionment is not (EDIT: The Eclipse based Flex Builder product from Adobe is free for educational use and for unemployed developers, see https://freeriatools.adobe.com/ ). Cross platform technology.

Flash: Still an option to build very capable UIs, very mature, but just like Flex, it uses Actionscript, which is not a very common language among enterprise developers. Cross platform technology. (a little weak in mobile domain though)

Silverlight: With its version 3, it has become a powerful development option, Microsoft does a great job of connecting its technologies to each other, but due to its nature Silverlight can be pretty much a standalone technology that can consume web services, so it should at least theoretically be usable with a web services based middleware. Its advantage at this point is that MS CUI work is being implemented in Silverlight, so there is an easier way for its users to make use of CUI, compared to other technologies.

Mostly server side technology with AJAX support:  Many MVC oriented frameworks like JSF, ASP.NET (and ASP.NET MVC), Ruby on Rails etc, can be included in this category. This hybrid combination can be more flexible, but especially for complex GUI operations, it can quicky become hard to maintain.

<Insert your favorite technology here>: please comment so that this discussion can go forward.

Conclusion

There is no killer combination of technologies for building capable UIs in clinical application domain. You may win at the front layer, but lose in other dimensions. Your identity matters, if you are a company with customers waiting for solutions, you have more freedom in certain ways, compared to a community project which needs to position itself between multiple vendors, clinical communities and technical communities.

The reason Opereffa is created is to test these assumptions, to see if gains from a decision can outweight losses from it. Hopefully, we'll move towards a better total output with feedback from both technical clinical communities.