after having the set of archetypes that specifies your clinical record (structure, constraints, terminology), I would recommend to create your Operational Templates (OPT) using the Ocean Template Designer. That is a big XML with all the referenced archetype semantics in one file (easy to handle).
After that, you have to make some design choices:
- Database technology
You can choose a relational, object based or document based technology. My preference is a mix of relational + some XML support. Most relational DBMS today support xml as a native datatype.
- Data model
There are two extreme models a) map the RM 1-1 to a DB model, b) use a key/value approach. For requirements that needs to query the hierarchy a) is better, but you'll have a lot of joins in relational DBMSs. For queries based on plain data b) is better but you'll need to have some logic if you want to build the hierarchy back from the k/v sets.
Why I mentioned the hierarchy? As you might notice, the openEHR Information Model has a tree structure, so is hierarchic by default, and that's because clinical information is hierarchical in nature.
What I did in my EHRServer was creating structured indexes in a relational DBMS. This approach sits in the middle of a) and b). I also use ORM tools (http://grails.org/doc/latest/guide/GORM.html) to automatically map object instances into tables.
One key aspect of the data model is to save the reference to the archetype that defines every data point, that can be done in the DB itself or using metadata to map archetype paths to a table/column.
- UI definition
You can create your UI by hand, or generate it from archetypes + templates. Either way you'll need some metadata to bind the fields on the UI to fields on archetypes. For this I use the field id and the archetypeId + path.
This helps me to bind input data from doctors into the openEHR Information Model, and with the right metadata this can be done in a generic way.
If you don't know about archetype Ids and paths, please read: http://openehr.org/releases/1.0.2/architecture/am/archetype_principles.pdf
I would recommend also the Architecture Overview: http://openehr.org/releases/1.0.2/architecture/overview.pdf
- Business logic
Binding data to your data model is part of the business logic, also validating that data. For validation I use the constraints that appear in the archetypes and operational templates. IF you have the archetype Id + path, you can get the constraint from the archetype and then you can evaluate that constraint against input data.
- Integration of previous components
Glue all the stuff together and you'll have: UI <-> logic <-> DB
Hope that helps.