I guess should switch from digest mode, responding to the archives is a pain 
That would depend on which data element, grouping or optionality you
were talking about - I can better respond to something concrete versus
abstract
With flexible software there are always options. You can for instance
build a form type which acts like an order for all intents and
purposes - with states, transitions, signatures, work flow, scheduling
and business rules. That form can be made wholly of only openEHR
archetype based data elements using the semantics they were originally
intended for. In that case you bypass the order model all together.
Similarly while you can have a registration form that directly maps to
the patient, address, phone, contact, business tables you can
alternatively have a form type that updates the patient model but has
its own set of data elements for nationality, marital status, reason
for visit, and whatever else. It all depends on the goals you are
trying to achieve and I think from a technical and software
architecture perspective it can accomodate both a regular US hospital
looking to implement an EMR for patient safety and a research
organization looking to implement a very pure OpenEHR compliant data
warehouse.
Now there is always lots of work to be done but it is coming along at
a good pace and I will have an open ehr demo nbr 2 out next week. I
don't think a test case has ever been established for what to show -
so I will show a couple of workflows and then AQL querying for the
data entered.