Dear friends, ISO12967, in particular part 3, should be considered as a very good reference about how to define actual practical services. Of course the reference model in this standard is different from the openEHR RM, but some key ideas are very interesting and, in my opinion, provide a scalable solution to develop services. A great example is the way the standard manage basic common methods. In particular any class of the "RM" (information model if we are talking in ODP "language") must have some standard basic methods (literally) "For each class belonging to the seven cluster of objects defined in ISO 12967... the middleware shall be equippped with a computational object in turn equipped with a set of methods allowing to access and to manipulate every concept (i.e. objects and properties) of the class..." The basic methods for add, update, list, detail... are standardized for any class and thanks to this they are easier to use facilitating clients developement and services composition. Other basic ideas inside this standard could be successfully reused in openEHR services specification (saving efforts and easing reuse and composition of services), adapting the ideas to the openEHR's RM, of course.
Best Regards, Ph. D. Isabel Rom?n University of Seville El 10/02/2012 14:35, Bos(tjan Lah escribi?: > Hi, > > I have added service interface for our Java based Think!Ehr server at > http://www.openehr.org/wiki/display/spec/Marand+Think%21EHR+service+interface. > > Kind regards, > Bostjan > > On 07/02/12 15:15, Thomas Beale wrote: >> >> Over the last few years the number of openEHR implementations, both >> commercial and research, has grown. There should now be a significant >> amount of experience with service interfaces, and it seems time to >> get moving on defining some openEHR standards for them. >> >> In the interests of 'starting small', I would suggest that the EHR >> service is the best starting point. See here >> <http://www.openehr.org/wiki/display/spec/openEHR+Service+Model#openEHRServiceModel-EHRandRelatedServices> >> >> for one view of what this is, but even this description may change, >> as the world apparently progresses toward a more RESTful stateless >> architecture style. >> >> In summary, one view of an 'EHR service' is the interface to the EHR >> data store: a place to put and retrieve EHRs. Obviously lots of other >> services are needed to build a whole solution (as described in the >> page above), but this one has a small interface and is not >> complicated to understand. >> >> It seems reasonable to work towards a standard version by posting >> service definitions from existing systems / products, and following >> some discussion, to attempt to create a merged consensus version. >> Note: more than one service interface is ok! For example, a stateless >> REST style interface is just one approach; a stateful interface is >> just as valid for some purposes. Other flavours may also make sense. >> >> As an example of an EHR service interface, the Ocean Informatics one >> is posted here >> <http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Interface>, >> >> and is only about a dozen functions long. >> >> It would be great to see some other service interfaces posted - >> please do that here >> <http://www.openehr.org/wiki/display/spec/EHR+Service+Specification> >> - i.e. add an entry like the Ocean one, and then add a child page. >> >> Once we get a feel for the diversity (or unanimity), we might be able >> to make some quick progress toward a proper openEHR EHR service. >> >> - thomas beale >> >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at openehr.org <mailto:openEHR-technical at openehr.org> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120214/2805b466/attachment.html>
