Hi David, I already said this but I want to be clear: there are not fixed “steps” for implementing openEHR, it depends on requirements, technology and the methodology you use.
You should advice your boss, this is not something you can learn and implement in a month.
I think I also mentioned this before: for your first prototype you only need an archetype parser, i.e. adl_parser and ADL Workbench to extract paths.
Please read this email carefully, is long but it has info you can use to start doing something right away. I can clarify this if you have questions, but I’ll not repeat this in future emails or tell you to read previous messages. Don’t take me wrong, but at an early stage you have to go through these ideas a couple of times before asking further questions. I know you have pressure on your side, but this is not an API you can read the reference, ask a couple of questions, and start coding right away…
About mappings, those are system dependent and I can’t give you those. You just need to create something like this:
Mapping between a field on screen and a node on an archetype:
screen_a.field_a maps_to archetype_id.node_path
Mapping between a column on a database and a node on an archetype:
table_a.column_a maps_to archetype_id.node_path
Then, when you receive a data from screen_a on field_a, you know which archetype to load, and which node to get. You can use that node to validate data using constraints on the archetype. This is straight forward. I’ve been doing automatic data validation using archetypes for the last 4 years on EHRGen.
Then you can use the database binding to know where to put the data, so data store can be also automated using bindings. This means you don’t have to write routines for every piece of data that you want to store: you just write one generic routine to do that, and use the bindings. This is how EHRServer works.
This is key: the app logic might not know how data is persisted and where, is a generic algorithm that does all the magic, giving you more time to do interesting stuff instead of inserting data into a database. Also, if you have a client app, the client doesn’t know where and how the data is persisted, you just send the data and when you want to query, the data is magically there without making your client apps save ids or references to the data persisted in another component. These are good practices applied: SoC, low coupling and high cohesion, etc.
Another use of the UI-archetype binding is that you can generate the UI using archetypes 
In the openEHR course in spanish, I teach two methodologies of creating openEHR systems, one is using bindings, and the other is using metadata to autogenerate software elements (screens, database artifacts, maybe code generation for logic (data validation, data transformation, persistence, …), etc). For the last, archetypes are the kernel metadata, but you also need UI definitions, terminologies, process definitions, etc.
About saving and querying, I already mentioned that on previous messages: “Create tables, saves and retrieves the.same way you do with any other system. This is not black magic, is just data :)”.
There are strong opinions about this and some people doesn’t understand this yet, but this comment is key: is not mandatory to implement the complete information model at the persistence layer, at least not a 1-to-1 mapping. Your persistent model can be different to the information model, but there will be semantic links between them that makes both models compatible / semantically equivalent. That’s why you need some kind of mapping/binding if those models are not mapped 1-to-1 (persistence & openEHR IM).
What is mandatory is that your system (not your persistence layer alone) can receive and retrieve openEHR data using services.
If one developer chooses to implement the openEHR IM at the persistence layer, is just a design decision. I’ve made this decision in the past, and have a working implementation doing that (EHRGen https://code.google.com/p/open-ehr-gen-framework). Experience told me is a mess to implement the complete information model at the persistence layer using a relational model, but it has big advantages for data processing, e.g. executing path based queries is easy because queries are executed against the openEHR IM (and this can be done regardless of the DBMS you use, relational, document, key-value, object oriented, etc.).
But that model is also too complex to be handled in a relational DBMS (I’m talking about performance here), that’s why my new persistence implementations use a mix of XML and relational (EHRServer https://github.com/ppazos/cabolabs-ehrserver). This also use openEHR XML for commits and yes, it can handle path based queries over the relational DB.
BTW, both projects I mentioned are open source. If you want to learn how they work, just download, test and read the code If you have any questions, I’m here to help.
