This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "User Interface for RIMBAA Applications"

From HL7Wiki
Jump to navigation Jump to search
Line 19: Line 19:
 
**Rene: you'll always need to do some pre-formatting, otherwise the generated layout may be quite nonsensical/counter intuitive for the human user.
 
**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/
 
*See also MIF>XForms https://xmlprocess.projects.openhealthtools.org/
 +
 +
*Andy Harris: integration with templates/LIMs, commonality is one of the key reasons for using RIM. Start with the generic controls, make them work, bolt them together, less generic as you go up the data stack.
 +
  
 
===XForms===
 
===XForms===

Revision as of 08:40, 1 January 2010

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/
  • Andy Harris: integration with templates/LIMs, commonality is one of the key reasons for using RIM. Start with the generic controls, make them work, bolt them together, less generic as you go up the data stack.


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.
  • Adam Flinton: We have a JSF-XForms framework (Tomcat/Myfaces/Chiba). Right now I am doing our Domain file which is based on the dynamic mif (interactions, trigger events etc) but then adapted to our needs.
  • Brandon Ulrich: Your question made me think about some ways of accomplishing similar objectives using the HL7 domain context model built in the CfH static model designer. In addition to the RMIM info from the MIF, you'd also have access to the RIM, vocab, and datatypes. I'll give a few examples and cite some related technologies; I'd be happy to go into detail on any of these if there's interest...
    1. Generate a simple cross-platform application. The easiest way to build a generic RMIM editor would be to generate one. This would require writing a model to model (M2M) transformation of the HL7 domain context, which would serve as an input to the existing Eclipse toolset. From this you can generate a simple editor that supports editing and persisting (XMI included, RDBMS fairly easily) instances. It's nothing fancy but works well enough; we use these generated editors to edit the rim, vocabulary, and datatypes. Required knowledge: oAW, Eclipse EMF
    2. Create a customized editor. If you're willing to get your hands dirty, you can generate a more complex editor, then customize this generated editor as you see fit. You would also be able to use the validation framework to validate the your instances. In addition to the above transform, this would require setting lots of knobs and dials to properly configure the generator and writing a good amount of Java code. Required knowledge: oAW, Eclipse EMF, GMF, GEF
    3. Just create an XForm, please. If you only want an XForm, you could write a M2M transformation to accomplish the task that would be similar to step 1. In this case, you're probably best off working with the technologies that you're already familiar with. Required knowledge: oAW, Eclipse EMF
    4. Allow remote instance manipulation via a web service. This is essentially the web services equivalent of option 1 above and would provide the same set of basic services. If HL7 provided a shared artifact repository (e.g. using a technology like CDO), the models could be incorporated from the repository. You could then write your web application using your technology of choice. Required knowledge: oAW, Eclipse EMF, Equinox
    5. Generate a simple web application. If the end result is a simple web application and you're not concerned about reuse, it's probably easiest to generate the entire application. First, you'd have to write a generic version of the web application using whatever language/framework you prefer. This application would serve as a template used by a model to text (M2T) transformation. You can also take advantage of validation, hooks to vocab, etc. Required knowledge: oAW, Eclipse EMF, Teneo