Hi,
The term lifecycle may not be appropriate for archetypes, and suggestions for a better term are more than welcommed.
Assuming that we constrain our interest only to a set of information encapsulated in a single archetype, would you provide the technical lifecycle you can imagine, for an archetype? The scenario is very simple: an archetype is loaded from disk, displayed on screen, and after data is provided by user, data is saved on disk, later loaded and edited, and saved again. That’s it!
To better explain the context of the question, please think about the java reference implementation. I’ll skip some minor steps and give my own points, and I’d like to hear yours.
Archetype is created via a tool like Ocean’s designer.
It is loaded by the parser in the java ref. impl.
It’s in memory representation is parsed, and know we the constraints on rim data types expressed in java language terms and instances of these terms in memory.
Assuming we are creating a gui only for an archetype, we can create a form using the constraints on data types, and Ocean’s tool has an interface tab that does it.
A user provides information using the generated form.
We can check the validity of the data entered using the in memory representation of archetype, like dates, amounts being in allowed interval, and simply warning user if any data is not valid.
Things become interesting after this point. In the context of the java reference impl. and immutable rm classes, we can now create rm instances since we now have data, and we can persist them. If we were think of the simplest use case of just storing information and loading it back, would we need RM instances here? How about saving a custom represention of user input like an xml file to disk, and reading back for updates? As long as the link to original archetype is preserved, updates can be checked for validity.
In short, I’d be very happy to hear your description of the flow for a very basic scenario “in the context of java ref. impl”. Especially how you’d use the RM classes (in immutable/mutable form) and when.
Those of you who are active in development of archetype based systems can provide very useful feedback for others to follow
Kind regards
Seref
Ps( the use of templates is deliberately excluded here, to keep things within a smaller scope)
Things become interesting after this point. In the context of the java
reference impl. and immutable rm classes, we can now create rm
instances since we now have data, and we can persist them. If we were
think of the simplest use case of just storing information and loading
it back, would we need RM instances here? How about saving a custom
represention of user input like an xml file to disk, and reading back
for updates? As long as the link to original archetype is preserved,
updates can be checked for validity.
In the database you save the "composition", which is a representation of
the data provided by the user using your form generated by the
archetypes and templates. How you save the composition on the database
depends on your implementation. In our case, we save the compositions in
XML in the database, indexed by patient id. This is efficient and useful
when you want to retrieve compositions of a particular patient, but it
is inefficient for population queries ("get all the patients with high
blood pressure in the last 3 months", for example). To allow this kind
of queries, we have mechanisms that allow to flag data of interest and
save them in indexed tables to fast queries. But again, how you save and
load the information depends on your implementation and usage. You could
just save the composition as XML files and create a stylesheet to show
the XML file on the screen without parsing them into java objects.
I think 'lifecycle' is not the term you want, since most people use that
to mean 'authoring lifecycle' i.e. the authoring, review, approval
history of an archetype. Here we are talking about the runtime usage of
an archetype. If I understand correctly the question it is: can the
runtime instantiation of the Java RM objects be avoided in some simple
circumstances? It seems unlikely to me, because most of the RM classes
have some routines that would be commonly used during data capture, e.g.
have a look at the History package in the data structures part of the
model - http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html
Hi Tom,
Thanks for the correction of the term. Yes I’m referring to runtime usage of archetypes.
After taking a look at the RM class code in ref. impl. I guess it is safe to say that some RM classes seems to check for proper values, and that’s a reason to create instances of them. I guess this is where syntactic checks about captured data are done.
Also almost any business logic written against the reference object model would require interfaces of these classes, so their instances would be needed in any case you have data to process, so even if I could avoid them for a very simple case, I’d need them again for making any use of data in software. It takes some coding to see their use
I would have thought that if you wanted to persist data and retrieve it so that it conformed consistently with the archetype, then you would have to invent some model of persistence which would have at least some if not all of the characteristics of the RM - so why not use the RM! You even said that you are parsing the archetype and building instances of the RM datatypes in memory…
Not sure how you would do it otherwise as the archetype is just a model of constraint on the RM ie when we are building forms for instance, the widgets conform to not just the archetype, but also the underlying RM and are really archetype constrained versions of RM instances but in a GUI model. ie. A quantity for systolic blood pressure on the form is a quantity widget that conforms at some level to the RM but is constrained by the archetype to mean systolic with units mmHg and range 0 to 1000 etc.
Hi Hugh,
I am not in my brightest state of my mind at the moment, so I may deny that the following belongs to me when I wake up in the morning…
I think I can build a GUI automatically without instantiating a single RM class at all. The reason is; the archetype gives you all the information about the types you’d expect from input. The mappings from constraints to GUI elements is mostly a one time job: coded text to combo boxes, free text to text boxes, duration to some more specialized widget, amount to a textbox with a combobox for unit etc… (this is pretty much what Ocean’s archetype editor seems to do, but of course the classes in that source code are not as well seperated as the java ref impl)
Whatever the value is given, the input from GUI can be validated via AOM instances, right? I know the constrained RM type in AOM, I know the constraints is must satisfy. So the moment I’d create the instances would be after gui generation, data input, and validation via AOM instances. At that time I have constraint fullfilling data which can nicely be placed in a RIM instance.
For persistence, the archetype is still the deriving force, since to create a structured set of RM instances, you need the AOM tree anyway, because that’s where the structure is, and since every node in AOM has its path, a tree with (node, value.toString()) tuples is all I need for simple persistence
So, with some extra coding, It seems possible to parse an archetype, generate a gui, validate input and save data without using RIM classes. I’m not saying that this is the right way to do it, it is just that the role of the RM classes seem to begin “mostly” when you start coding business logic. Again this is about the java ref. impl. Other implementations may assign more behaviour to RM classes. The feeling I get is, the whole thing is really archetype driven (and is it not the point anyway?)
Many thanks for the feedback, and I hope I did not confuse anyone…
Just one small problem - the built RM instance structure usually
deviates in some way from the archetype structure, e.g. the archetype
might have a single EVENT node that stands for any number of EVENTs; the
data may have EVENTs at 0, 5min, 10min, ..... The same goes for most of
the repeated structures in the reference model - the archetype may only
have one or a few 'models' of what the data should look like, while the
actual data may have many.
