Hi Pablo,
You need to understand that some of the RM classes are functional object rather than data objects and hence are not currently considered serializable, VERSION_OBJECT, EHR and perhaps CONTRIBUTION are examples of these. There is no specific statement about this in the specifications, and it can be reconsidered and clarified as we better understand this, but you can recognise classes in this category when they use object references rather than containment. VERSIONED_OBJECT has a counter-part of X_VERSIONED_OBJECT defined in the EHR EXTRACT specification which is serializable and has an existing schema located at http://www.openehr.org/releases/1.0.2/its/XML-schema/Extract.xsd (linked from http://www.openehr.org/releases/1.0.2/its/XML-schema/index.html). Looking specifically at Contribution, it only has a uid and a list of object references so it isn't very useful unless you have a use case that wants to list all the contributions for a particular EHR or similar. There may be the need for an X_CONTRIBUTION class in future. I _think_ I understand this part, but at the implementation level (and using REST services as plan to do) means some things should be serialized. [HKF: ] I agree there is a need to serialize the contribution, but we need to understand the true requirements. Do we need a new X_CONTRIBUTION class that contains VERSION objects or is the existing CONTRIBUTION class with object references sufficient for use in the context I suggested in the other email. Collaborative specification and implementation experience will help answer this. I know there are a lot of ways of serializing things like Versions contained in a Contribution, e.g. I can send different params in the HTTPRequest body, each one being one Version XML (this emulated the Ocean's CommitContribution service), [HKF: ] Not sure what you mean here or I can send only one XML on the body for the whole Contribution, this second way is what I try to do). [HKF: ] You indicated otherwise in your previous email The kind of thing you are trying to do is more related to the service model than the Reference Model and as you know there is only vendor specific specifications in this area. From Thomas' service overview you see there are two layers a EHR Service and a Virtual EHR Service. Not sure it is quite understand what distinguishes the two of these but there is some indication that the Virtual EHR provides aggregation of lower layer services including the EHR and Demographic services while also providing helper functionality such as contribution building and query result management. Another key differentiator is granularity of service calls, the Virtual EHR has fine grained, more frequent calls while the EHR service has course grained, less frequent calls. This little project is about a simple EHR Service to commit and retrieve Compositions in XML format (the granularity level here is the Composition). I understand a lot of this has to do with the service, but behind that interface I have to build a persistence layer, so understanding the model is also important (and I'm not an expert on the change_control package, so this is a great learning experience for me too). As I mentioned, I don't want (and I can't) build a complete version controlled EHR server, this is just a little system so my students can play around with my EHRGen tool (I use it to generate different EMR systems), committing/retrieveing compositions to/from a shared EHR server. [HKF: ] Which is why it makes sense to align with an existing implementation so that you could look at replacing it with a more enterprise scale implementation in the future. The problem that I have identified in my implementations over the years is that the use of the openEHR RM classes of AUDIT_DETAILS and VERSION are not very useful in the commit contribution operation, especially if there is some work being done on the service side, whether it is at the Virtual EHR service or EHR Service layer. Attributes such as system_id and time_committed are obvious candidates to be set by the service not by the client but the RM state that these are mandatory and my most recent work provides a service operation message that excludes these from the commit contribution message type but instead has the other RM attributes necessary (e.g. change_type and description) for the service itself to build the valid RM objects to be persisted. This CONTRIBUTION_VERSION class is a potential candidate to be added to the Extract or Service models to support contribution operations. I found the same problem: the change_control objects are distributed objects, so at one moment in time some parts of an object may be on the server, some other parts on the client and other parts not yet created. This is very unclear on the specs since it lacks time based diagrams to show what objects are created at what time and when. This could be a good improvement to the specs, what do you think? [HKF: ] I think we can look at this as we develop a service model specification and an online reference implementation will demonstrate this in practice. I feel it is truly a high priority for us to start aligning the various implementation APIs ASAP before we get too many more candidates, at least a minimum core set of operations. I think we have enough experience to get this started, I think the process is close to being finalised so now we just need contributors. Let me know if I can help and how. I'm always open to collaboration :D [HKF: ] As I said in the last response, I think you little project is a good opportunity to collaborate and test an openEHR service model candidate Heath -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121010/7fa7d021/attachment.html>
