Hi Erik, I notice that you have provided a schema for VERSIONED_OBJECT which doesn?t align with the RM class and overlaps with the X_VERSIONED_OBJECT already defined in the extract.xsd. I think we should leave VERSIONED_OBJECT as not serializable and use the X_VERSIONED_OBJECT class as the serializable class as what I believe is intended by the specifications.
I agree we should add the EHR_STATUS and EHR_ACCESS types, there is an existing issue at SPECPR-26 for this. I like the idea of the extended VERSION_OBJECT classes but this only has value if this can be done in a way that makes the data element strongly typed. Regards Heath From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Erik Sundvall Sent: Monday, 8 October 2012 5:58 AM To: For openEHR technical discussions Subject: Re: Understanding how to commit contributions to an EHR Server with XML 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: pazospa...@hotmail.com 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+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 _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.or g -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121009/408506c3/attachment-0001.html>