User Interface for RIMBAA Applications

Summary

How can we put a User Interface on a RIMBAA application?

• Can we reach the goal of sem-automatically generating a UI based on a CIM, with controls that are suitable for the (flavoured) data types being used, and bindings with value sets - validating the data that is entered according to the appopriate templates and OCL statements?

Analysis

UI's will be based on the RO/CO or AO cells as defined in the Technology Matrix.

There are two (extreme) options:

1. Run time: Dynamically (at run time) generate the UI based on a CIM/LIM-like definition
2. Development time: Define the UI first (based on a set of very small CIM/LIMs??), bind elements in the UI to RO/CO/AO classes/attributes.

Discussion

There are some known methods:

• One hospital uses an XSLT to transform HL7 v3 XML to a HTML interface (transform RS/CS to RO/CO to UI)
• Most will code a User Interface by hand and will use XPath to bind the data to the UI Components (create UI; map/bind elements from RO/CO/AO to UI elements)
• Some will use a tool like InfoPath
• Generate the User Interface at design-time (PHI) or at run-time (a RIMBAA run-time Engine?)
  • Rene: you'll always need to do some pre-formatting, otherwise the generated layout may be quite nonsensical/counter intuitive for the human user.
  • See also MIF>XForms https://xmlprocess.projects.openhealthtools.org/

XForms

• Kevin Coonan (20090205): I am looking to build an application which can take an instance of a MIF and use it to generate a web-based "fill in the blank" application. I hope this will let us design forms, surveys, questionnaires, case report forms, etc. as RMIMs and use the resulting MIF to drive the application.
• Lloyd: I know the UK has done a lot of playing with x-forms, but I don't think they've done anything directly driven off of the MIF. One thing to consider would be generating off a "collapsed" view of the MIF - one that strips out all the fixed values and removes extra "layers" that are present in the RIM but don't add any extra business value. Though I suppose the x-form itself would do that. Also, consider using business names where they exist instead of formal RIM names as that might make things a bit more intuitive to users.
• Ian Townend: I've thought about generating Xforms from Schema on and off for a while but not had a chance to elaborate on it. I think it would be a useful for real systems as well as building examples. We use Xforms for a few things and I'm sure at least one of my colleagues will come back with a list of things we've done.
  • I think that it would be good for us to think about what we need to do and where on this. For example, we might need to add some information to state which parts we want to be displayed to a user and whether or not they can edit those parts e.g. we wouldn't want codeSystem displayed at all though we want it to be populated and we might have code displayed but greyed out and populated when someone selected a displayName from a drop down box for example. Or we might want some fixed values to still be displayed on a form but it being clear they're fixed and not editable.
• Ravi N: Please visit https://xmlprocess.projects.openhealthtools.org/ as I think this NHS CfH project should be able to be adapted to the requirements. There are existing functionality to annotate MIF models , maintain OID catalog etc.
• Ioana: I agree... there are established open-source tools for generating XForms from XSDs and we should try leverage them.