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. 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. The Contribution Builder functionality that Erik references fits into the Virtual EHR layer while the CommitContribution operation on the Ocean EHR Service you reference below is at the EHR Service layer. The later expects something like the former to build the contribution to be submitted as a complete contribution. The implementation of the Ocean EHR Service operation below leaves the contribution to be constructed by the EHR Service, however the contribution UID can be specified in the version(s) being committed along with the audit details provided in the operation parameters. So as Erik indicates, the contribution object is finalized in the same transaction as the VERSION objects but the work to build the contribution object is done by the EHR Service. Ocean also has a Virtual EHR service which provides contribution builder functionality, it uses the EHR Service CommitContribution operation to finalize the contribution to storage. So from this perspective, the additional piece of XSD required is actually specified in the service specification as an operation message rather than a RM schema. This can be aligned with the definition of the EHR EXTRACT schema since they are really extract operation messages and we do need to consider how this works in a RESTful paradigm so that we can align the message types used in a SOAP service with a REST service. 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 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. Heath From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of pablo pazos Sent: Saturday, 6 October 2012 3:44 AM To: openeh technical Subject: Understanding how to commit contributions to an EHR Server with XML Hi all, I'm studying the change_control package to create a simple example of data commit to an EHR Server (to be used in a future course). I'm also reading the service examples published on the wiki (Ocean & Marand EHR Services). As I understand it, when an EMR app (local) wants to commit data to an EHR Server (global/shared), all committed data (e.g. a list of Version<Compositon>) should be referenced by a Contribution. Also, each Version<Composition> references the container Contribution. All references are managed using OBJECT_REF instances. My idea is to make the commits using XML messages (following openEHR XSDs) with only one message per commit. I don't know if I can represent both references using openEHR XML (Contribution->Version & Version->Contribution). I suppose this operation [1] on the Ocean's EHR Services is resolving both references internally: void CommitContribution(HierObjectId ehrId, AuditDetails commitAudit, OriginalVersion[] versions) Another assumption on that service, is the AuditDetails has the Attestation to sign all the committed Versions (the signature for all the Versions is calculated using the same AuditDetails object). I've seen Version XML examples where the Version has a reference to a Contribution, but the referenced Contribution is a mistery for me :) (it could be really helpful if someone can share an XML example of a Contribution). Any ideas, pointers & corrections are very welcome! (BTW: I don't want to implement a full version-controlled environment, just want to make a simple commit process the right way). [1] http://www.openehr.org/wiki/display/spec/Ocean+Informatics+EHR+Service+Inter face -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121009/8ca09ac7/attachment.html>
