Hi Erik, Just one correction, CONTRIBUTION points to a ser of VERSION, not VERSIONED_OBJECT.
>From your & Thomas comments, I've designed this little protocol: createContribution: client sends a XML contribution (based on EEE-v1.xsd) to the server with references to Versions that will be added later (Versions are in the client)addVersion: adds a Version to a contribution (the XML version is based on openEHR Version.xsd), the reference to the correspondent contribution is in Version.contribution. A contribution is committeable when all referenced versions are added to the server.commitContribution: the client tries to finalize the transaction & the contribution / versions / compositions are added to a EHR on the server (shared record). What do you think of this approach? I think I found an issue (or just a confusion of names) on the specs about object_ids: common_im p. 56 describes VERSION<T>.uid as owner_id, creating_system_id, version_tree_id, there is also an operation VERSION<T>.owner_id().common_im p. 40 says VERSION<T>.owner_id() extracts the uid of the owning VERSIONED_OBJECT.common_im p. 46 says the VERSION<T>.uid is object_id, creating_system_id, version_tree_id.common_im p. 46 says the object_id part of the VERSION<T>.uid is a copy of the uid of the container VERSIONED_OBJECT.common_im p. 53 the owner_id attribute is mentioned on VERSIONED_OBJECT<T> to be the EHR id. If I understand the idea: VERSION points to VERSIONED_OBJECT and VERSIONED_OBJECT points to EHR, is that right? What do you think about leaving the name owner_id for the pointer to the EHR and object_id for the pointer to the VERSIONED_OBJECT? -- 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 Date: Sun, 7 Oct 2012 21:27:35 +0200 Subject: Re: Understanding how to commit contributions to an EHR Server with XML From: [email protected] To: openehr-technical at lists.openehr.org Hi! A CONTRIBUTION points to the IDs of it's contained VERSIONED_OBJECTs and the VERSIONED_OBJECTs at the same time points to their related CONTRIBUTION, thus it is probably easiest to finalize them in the same transaction in most systems if they are stored/retrieved as separate objects. (You have probably already figured that out, I am just trying to avoid misunderstandings by newcomers that might be reading.) In the LiU EEE REST based approach we have added a temporary writing space called "Contribution Builder" where you can add/modify a collection of VERSIONED_OBJECTs until you are satisfied and then make a call to get them committed into the EHR in a combined CONTRIBUTION. Another option is of course to send a collection of VERSIONED_OBJECTs (from a client) with e.g. a bit of XML-wrapping (also including metadata for the CONTRIBUTION). We have not finished specifying and testing an XML serialization for that yet, but that could of course be done (now we use a Java-based object as collection to pass data from the Contribution Builder). I have now uploaded an old XSD (from some experiments 2010) containing definition of CONTRIBUTIONs (and some other stuff) as an attachment to http://www.openehr.org/wiki/display/dev/Persistence - It should be considered as an experimental non-official pre-alpha version... (The LiU EEE REST design paper has been submitted for review, see http://www.openehr.org/wiki/display/projects/Projects+Home Contact me if you need a personal login to our tiny demo-server.) Best regards, Erik Sundvall erik.sundvall at liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733 On Sat, Oct 6, 2012 at 5:13 PM, pablo pazos <pazospablo at hotmail.com> wrote: Hi all, I found there is no CONTRIBUTION XSD defined on the openEHR XDS, and if it exists, I can't commit CONTRIBUTIONs using only one XML message, because CONTRIBUTION references (using OBJECT_REF) the VERSIONs I need to commit, but each VERSION also references (by OBJECT_REF) the container CONTRIBUTION. The main problem here is: the instances of those classes (CONTRIBUTION and VERSION<COMPOSITION>) are distributed objects. So if I send 2 messages to the EHR Server, one to create the CONTRIBUTION and other to create VERSIONs, the fisrt CONTRIBUTION.versions will be empty on the server, so invalid for a while (until it's VERSIONS are committed). So, I'm beginning to suspect that I need a little protocol to be defined here. The other option is to define my own XSD for an envelope that could include both, CONTRIBUTION and it's VERSIONs. I prefer to define a protocol than new custom XSDs. Does anyone that implemented a service like this came to the same conclusion? All your comments will be of great help, thank you. -- 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 From: [email protected] To: openehr-technical at lists.openehr.org Subject: Understanding how to commit contributions to an EHR Server with XML Date: Fri, 5 Oct 2012 15:14:15 -0300 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+Interface -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121009/3894a026/attachment.html>
