View source for User Interface for RIMBAA Applications

[[category:Closed AID Issue]]
==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:
#'''Run time''': Dynamically (at run time) generate the UI based on a CIM/LIM-like definition
#'''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...
*#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: [http://www.openarchitectureware.org/ oAW], [http://www.eclipse.org/modeling/emf/ Eclipse EMF]
*#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, [http://www.eclipse.org/modeling/gmf/ GMF], [http://www.eclipse.org/gef/ GEF]
*#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
*#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 [http://www.eclipse.org/modeling/emf/?project=cdo 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, [http://www.eclipse.org/equinox/ Equinox]
*#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, [http://www.eclipse.org/modeling/emft/?project=teneo Teneo]

===Microsoft CUI project===
*See [http://blogs.msdn.com/wwhealthit/archive/2010/03/27/release-date-for-the-clinical-documentation-solution-accelerator.aspx], [http://www.isb.nhs.uk/docs/cui] and [http://www.mscui.net/Default.aspx], and video [http://www.youtube.com/watch?v=IXA_K2aNs2I].

#From the [[RIMBAA 201011 Minutes London]] minutes:
#*Michael van der Zel (University Hospital Groningen, NL), on their developments related to the use of Forms (Infopath) and User Interfaces (CUI Toolkit/ASP.NET & Silverlight) bound to HL7 v3. See [http://www.hl7.org/library/committees/java/20101104_RIMBAA_UI_UMCG.pdf 20101104_RIMBAA_UI_UMCG.pdf] for a copy of his slides.
#**Using a Patient Summary (EHR) application as an example, how can we create the link between database and UIs? 
#**Common UI elements like the "patient banner" (e.g. patient demographics and allergies), buttons of UI functions.
#**Wider long term aims (Michael acknowledges this will be very difficult) to go for full v3 semntics, End-to-End v3, SNOMED CT, RIMBAA from UI to DB. DCM to capture requirements. EHR-S FM as a reference.
#**Patient Banner (demographics + adverse reactions - brief list), Patient History, and Propensity to Adverse reactions (details of those reactions) candidates for UI, standardize data capture/access to increase patient safety.
#**Based on NHS CUI developments, includes tools that allow for translations of labels. Tools are set to be multilingual, those features are however not used by the NHS. Use/format of telephone numbers, ZIP codes, patient identifiers need modifications. They created a Dutch implementation guide for the CUIs, interpretation as well as translation of the CUI documentation.
#**Binding of v3 model (e.g. R_patient [universal]) to CUI control properties.
#**In terms of the technology matrix: UI-CO.
#**(Robert Worden enters the meeting)
#**InfoPath has limitations one will have to deal with. For one of the v3 models we could get it to display, but we couldn't get the data entry side to work. May need some flattening (e.g. using the method detailed by the "new ITS") of the v3 XML prior to binding it in InfoPath. 
#**Used a lot of CUI guidance. CUI doesn't have an information model.
#**CUI guidance should be made computable to serve as the basis for MDA forms
#**Hans: business rule validations is always tricky. the validation of the information .. either don't allow any invalid data upon entry, or allow data to be entered and validate at a later point in time. Michael: upon data entry. It was what the clinical users wanted. Hans: in an emergency situation one may have to deal with partial information. Michael: we have a workaround for that situation. Ann: involvement of user group is a key factor. 
#**Hugh: IM to UI mapping is a model-to-model mapping issue (view on the IM), and you can use the M-V-V-M pattern; models may be the same however. Hans: if you work from the DB upwards, then UI only presents that which is stored. Future UIs will show something else, much more image oriented. Putting words on the screen may be too simplistic a view. Therefore M2M is a requirement. Michael: there should be a well defined mapping, to document exactly how this should be done. Ann: we have to keep long term data in mind, information models may be old. we need a faithful rendering of the information, mapping may be fuzzy. David: messaging and persistence may not be that much of a different view on the data.