Hi Pablo, I think we have an excellent opportunity here to take this offline with Erik to work up a combined logical service specification and RESTful technical service specification as a candidate for the openEHR service model.
It looks like you?re looking for a Virtual EHR Service. The other one you may want to look at if you haven?t already is the Marand Think!EHR at http://openehr.org/wiki/display/spec/Marand+Think%21EHR+service+interface (although it is under the EHR Service area I consider this more like a Virtual EHR Service due to its operation granularity). In the interest of consolidation you should consider using something like this but since Erik has already implemented a RESTful service you should be looking at something closer to his API. See comments below. Heath >From your & Thomas comments, I've designed this little protocol: 1. createContribution: client sends a XML contribution (based on <http://www.openehr.org/wiki/download/attachments/786486/EEE-v1.xsd?version= 1&modificationDate=1349637658000> EEE-v1.xsd) to the server with references to Versions that will be added later (Versions are in the client) [HKF: ] Agree, but you may want to not provide any data in this operation like in the Think!EHR specification, since you probably don?t know what the contribution looks like yet, even the commit audit. You can think of this as creating a placeholder to which you versions. Rather than not return a response message you may want to return the empty Contribution object with service side attributes populated such as system_id, contribution uid and a temporary commit_time, this allows you to reference the contribution in subsequent calls. 2. 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. [HKF: ] The Think!EHR has operations such as CreateComposition and ModifyComposition, perhaps these don?t quite align with a RESTful approach but logically what you are trying to achieve here is some context to apply preconditions ensuring a composition does or does not already exist. It also allows you to just provide the composition object and have the version maintenance done for the caller. Having said that I find that not exposing the version can be a bit limiting at times in more complicated situations. The Think!EHR maintains a session context so there is no need to provide a reference to the contribution but in a more stateless paradigm you would need to provide a reference to the contribution, the most obvious place to do this is using the Version object. My more recent thinking regarding the response to these operations is to return the updated contribution object since it only has references the versions it contains this is not too verbose. 3. commitContribution: the client tries to finalize the transaction & the contribution / versions / compositions are added to a EHR on the server (shared record). [HKF: ] This is where the contribution audit details are more likely to be known, by using the contribution object most recently returned in a previous operation you can submit the entire contribution object to commit its contents. Again the finalized contribution would be returned. 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: 1. 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(). 2. common_im p. 40 says VERSION<T>.owner_id() extracts the uid of the owning VERSIONED_OBJECT. 3. common_im p. 46 says the VERSION<T>.uid is object_id, creating_system_id, version_tree_id. 4. 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. 5. 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? [HKF: ] 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? [HKF: ] I think the class specification is not really able to be modified but the descriptive text could be made more clear. I agree that object_id is a better term and a term I use a lot. In the case of the VERSIONED_OBJECT owner_id it needs to be generic because It is used for demographic records (repositories) as well as health records. -- 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: erik.sundv...@liu.se 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: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121010/59ebac5d/attachment-0001.html>
