Hi Heath, thanks for your comments, you mentioned really important issues.
From: heath.fran...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: RE: Understanding how to commit contributions to an EHR Server with XML Date: Tue, 9 Oct 2012 10:41:12 +1030 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. 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), or I can send only one XML on the body for the whole Contribution, this second way is what I try to do). 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. 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 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? 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 Kind regards,Pablo. Heath From: openEHR-technical [mailto:openehr-technical-bounces at 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+Interface -- 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.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121009/f92974e3/attachment-0001.html>
