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. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Thu, 8 Aug 2013 16:05:22 -0400 Subject: Re: How to start From: lexisnexis5...@gmail.com To: openehr-technical at lists.openehr.org I am pretty good at Java development. But there are two many documents for a prototype. Can you send me a mapping text file and tell me all steps I should take to retrieve and save data into database? I have already downloaded openehr-aom, openehr-ap, openehr-dao, openehr-rm-core, openehr-rm-domain, adl-parser and adl-serializer packages. If you can give me a whole flow, that will be big helpful. Thanks, David On Thu, Aug 8, 2013 at 11:36 AM, Ing. Pablo Pazos <pazospablo at hotmail.com> wrote: Please specify what kind of examples do you need. For the software part I believe you can do it. The binding is just a mapping of the elements I mentioned on my previous messages, in a simple text file. Sent from my LG Mobile Lexis Nexis <lexisnexis5490 at gmail.com> wrote: >May I have some examples? I am starting to understand OpenEHR a little bit. > >Thanks, > >David > > >On Wed, Aug 7, 2013 at 10:41 PM, Ing. Pablo Pazos <pazospablo at >hotmail.com>wrote: > >> Create tables, saves and retrieves the.same way you do with any other >> system. This is not black magic, is just data :) >> >> But you need to create the bindings. >> >> In 2012 I created bindings and give them to developers of a mobile app for >> a company in Netherlands (Bert works in that project). The developers only >> had to understand the bindings, not the whole openEHR paradigm. >> >> Sent from my LG Mobile >> >> Lexis Nexis <lexisnexis5490 at gmail.com> wrote: >> >> >Should I create a new database table to store these fields: >> > >> >Last Name: >> >First Name: >> >Date of Birth Date: >> >Gender: >> >Phone: >> >Email: >> >Emergency Contact Person: >> > >> >I get confused about how to save and retrieve data and where data are >> saved? >> > >> >Thanks, >> > >> >David >> > >> > >> >On Tue, Aug 6, 2013 at 8:59 PM, pablo pazos <pazospablo at hotmail.com> >> wrote: >> > >> >> Hi Lexis, you can grab the demographic Person archetype here: >> >> http://www.openehr.org/ckm/ >> >> >> >> Then use the ADL Workbench to extract paths, and map those paths with >> your >> >> fields. We call that mapping a "binding" between archetype nodes and >> >> software elements/artifacts. >> >> >> >> -- >> >> Kind regards, >> >> Eng. Pablo Pazos Guti?rrez >> >> http://cabolabs.com <http://cabolabs.com/es/home>< >> http://twitter.com/ppazos> >> >> >> >> ------------------------------ >> >> Date: Tue, 6 Aug 2013 20:50:29 -0400 >> >> Subject: How to start >> >> From: lexisnexis5490 at gmail.com >> >> To: openehr-technical at lists.openehr.org >> >> >> >> >> >> I am a Java developer. I am assigned to develop EHR based on OpenEHR. I >> >> read some specifications and they seem very complex to me. For >> instance, I >> >> want to create a web page like: >> >> >> >> Last Name: >> >> First Name: >> >> Date of Birth Date: >> >> Gender: >> >> Phone: >> >> Email: >> >> Emergency Contact Person: >> >> >> >> How do I map this object to Archetype? >> >> >> >> >> >> David >> >> >> >> _______________________________________________ openEHR-technical >> mailing >> >> list openEHR-technical at lists.openehr.org >> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> >> _______________________________________________ >> >> openEHR-technical mailing list >> >> openEHR-technical at lists.openehr.org >> >> >> >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> >> > >> >_______________________________________________ >> >openEHR-technical mailing list >> >openEHR-technical at lists.openehr.org >> > >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> > >_______________________________________________ >openEHR-technical mailing list >openEHR-technical at lists.openehr.org >http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130810/c2eefd3f/attachment.html>
