Hi Bert, -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com
Date: Fri, 29 Nov 2013 08:47:34 +0100 From: [email protected] To: openehr-technical at lists.openehr.org Subject: Re: Musings about a more web-friendly openehr On 11/28/2013 02:43 PM, pablo pazos wrote: One is, the most important, but not in our hands, make the AOM important, create RM's above the AOM, use it for other purposes than OpenEHR only. The more the AOM is used, the less developers will complain about complexity. IMO end system developers should not even know about AOM. We can create stuff that hides that from them and they can just consume APIs the way they are familiar with, e.g. like they consume Twitter or Google Maps APIs. I think you misunderstood. What I wanted to say, if the AOM is used in a wider/broader field then OpenEHR, it is something developers get used to, and because of the broad use they are motivated to get on the learning curve. I understood. My opinion is they don't even need to have that learning curve (in most cases there is not enough time and they have to show working results in a month or so). In my opinion there are several levels of API-possible. One level is semantic rich, like createObservation, then there can be, a bit more generic: createEntry, but it can also be completely generic, like createObject. In that approach the API is forcing developers to know what is an ENTRY or an EHR OBJECT. If we use just an XML, we need to tell them how to create it, and that's specified on XSDs. Creating an XML is simple and they just need to know where to put their data, e.g. in an ELEMENT.value tag.Then if we have only one commit service on our API, they just need to send the XML without knowing much about the meaning of each RM class, or AOM paths and node_id. We just need to tell them to copy the right values in the right places of the XML. Of course this is not the best approach conceptually speaking, but is a pragmatic one, just to get things done. But is just my opinion. Time will tell if I'm right or terribly wrong :) Depending on the reference model the object can be a Locatable, if it is an OpenEHR or 13606 Reference Model, but as far the AOM concerns, Locatables do not exists. The AOM only knows archetypes, an AOM-instance-structure is created by the ADL-parser, and as the parser eats it, you have a valid AOM-structure. This is a powerful concept, which can be served by a generic API, but what that will look like, I don't know. To overcome acting in the wild, and creating data without predefined structure, archetypes need to conform to a Reference Model. So there is a two way validation needed: One, is the archetype conform the Reference Model? This only is needed at creating time of the archetype. The other is are the data conform the archetype? Many other fine features are also available on base of AOM, like AQL and templates. Anyway, that was what I am thinking about when developers know the AOM. When you have these things organized, you have a generic database-engine on base of the AOM. I think, very powerful concept. I understand, but this process you mention seems to be closer to an ontological approach than to implementation. IMO formal ontologies for validating models and then validate data are good for research, but this approach is very far from real world implementation. Yes I know there are exceptions, but those exceptions came from research. What I mean is when you need to develop a software that should be used by doctors and you have 4 months to do it. I'm focusing on this kind of projects when I mention to simplify things for app developers so they can use openEHR without even knowing it. What do you think? Cheers! But there are some black holes, and one of them is the communication between client and server. As you know, I do it on base of path/value combinations, but many others do it on base of a kind of object-instance-natation, DADL or XML or JSON, or whatever. Bert _______________________________________________ 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/20131129/df2e67a0/attachment.html>
