# Want to test an openEHR repository? **Category:** [Implementers (archive)](https://discourse.openehr.org/c/implementers-archive/158) **Created:** 2013-08-20 17:46 UTC **Views:** 5 **Replies:** 15 **URL:** https://discourse.openehr.org/t/want-to-test-an-openehr-repository/15262 --- ## Post #1 by @pablo Hi everybody! I'm building a very simple Shared EHR Server with Composition commit and query services. The project is here: [https://github.com/ppazos/cabolabs-ehrserver](https://github.com/ppazos/cabolabs-ehrserver) The server is working but I'm finishing some improvements on the backend. I hope to deploy an instance online in a couple of weeks to play around, just for coordination purposes: **does anyone want to try the commit and query services?** I'll publish some basic documentation soon, so anyone who wants to try has all the needed info. Of course I'm available for any questions, comments and suggestions. There's no need to have XML Composition instances, I can provide 2 or 3 instances I use to test, so you can change the data on those XMLs. BTW, there's a client app that already talks to the server: [https://github.com/ppazos/cabolabs-emrapp](https://github.com/ppazos/cabolabs-emrapp) (this app generates 3 different XML Composition instances). --- ## Post #2 by @system Hi Pablo, I would be interested! Mate Dne 20. avg. 2013 19:48 je "pablo pazos" <[pazospablo@hotmail.com](mailto:pazospablo@hotmail.com)> napisal/-a: --- ## Post #3 by @pablo Hi Mate! Are you working with any specific compoitions? If you do, it would be a great exercise to try to persist and query your compositions, this will test the flexibility of the EHR Server. --- ## Post #4 by @ian.mcnicoll Hi Pablo, I would be interested in looking at this. I have a few XML instances that we can play with as well as your own examples. Ian --- ## Post #5 by @pablo Hi Ian, that's great. I need to solve this before putting this online: [https://github.com/openEHR/java-libs/issues/1](https://github.com/openEHR/java-libs/issues/1) Maybe this weekend this will be fixed and we can start testing. Just to have a reference, do you have a list of archetypes used on those instances? Right now the server works with flat archetypes in ADL 1.4 that mimic the 1.5 templates in ADL (this will be changed for ADL 1.5 templates when tools stabilize). --- ## Post #6 by @pablo BTW, here ([https://github.com/ppazos/cabolabs-ehrserver/tree/master/compositions](https://github.com/ppazos/cabolabs-ehrserver/tree/master/compositions)) there are some testing compositions committed to the server created and send from our testing app ([https://github.com/ppazos/cabolabs-emrapp](https://github.com/ppazos/cabolabs-emrapp)) --- ## Post #7 by @system It looks very nice --- ## Post #8 by @pablo Hi all, we're ready! I've created a small doc explaining how commit and querying works. It is all on GitHub: [https://github.com/ppazos/cabolabs-ehrserver/blob/master/EHRServer.pdf](https://github.com/ppazos/cabolabs-ehrserver/blob/master/EHRServer.pdf) Here you can find some testing compositions that can be committed to EHRServer: [https://github.com/ppazos/cabolabs-emrapp/tree/master/committed](https://github.com/ppazos/cabolabs-emrapp/tree/master/committed) Next monday I'll put the server online so anyone can test. If you can, before trying things out, drop me a line :) This will be on a machine at home, but if there are 2 o 3 people willing to use this, I'll consider to put it on some cloud service like Amazon. Any questions and suggestions are very welcome! --- ## Post #9 by @system This is a great development Pablo - and thanks so much for all the work. An agreement on the API for openEHR repositories is high on the Agenda for the Management Board of the Foundation. I will be releasing the minutes of the 2 day meeting of the openEHR Management Board and the Industry Partner Group next week. This piece of work was a priority and will form the basis for compliance testing. Chees, Sam --- ## Post #10 by @pablo Thanks Sam, we're getting there! It would be great to have some input on API. I'm willing to adapt/implement the current API to what the community mandates for a common API. I'll commenting on the minutes once released. About next steps for EHRServer, a lot of testing is needed to be sure it can support different kinds of clients. Implementing a SOAP interface is next on the pipeline. Right now we only have a REST interface. BTW, I'll be in OZ in October. --- ## Post #11 by @system Op 08\-09\-13 16:33, pablo pazos schreef: > Here you can find some testing compositions that can be committed to EHRServer: https://github.com/ppazos/cabolabs-emrapp/tree/master/committed > Let me first express that I think that this is a great initiative\. But I think I found some possible small mistakes or discussion\-points\. Please don't take it hard, it are small points, and some are a matter of opinion\. But before proceeding in this initiative, I think we need to have this clear, that is why I ask\. I took this as example: https://github.com/ppazos/cabolabs-emrapp/blob/master/committed/composition_1_0.xml It is suggested in the Github\-directory\-naming that the Composition is already committed\. This is someway confusing\. --- ## Post #12 by @pablo Hi Bert\! thanks for your comments\. I'll review all the attribute naming\. About the committed confusion, the xmls in emrapp are logged before committing them to the server\. So there is sime stuff like uid that is not present at the moment of logging\. If you see the compositions folder in ehrserver youll find the same compositions after commit, youll see uids\. Thanks again\! I'll come back after reviewing all your comments\. --- ## Post #13 by @pablo Hi Bert, For these points: "- In there is the element:I think this is a mistake. I think the attribute should be called different, f.e. archetype_id. ``` - But this element should also have an archetype_node_id to store the archetypeNodeId of the definition, mostly containing at0000. - Also, I miss an archetype_id/value element in the XML, which should also store the archetypeId if there is one, which is in the composition." ``` I reviewed the specs, this point is clear: see common.pdf, section 3.1.2 "Most classes in the openEHR reference model inherit from the LOCATABLE class, which defines the idea of ‘locatability in an archetyped structure’. LOCATABLE defines a runtime name and an archetype_node_id. The archetype_node_id is the standardised semantic code for a node and comes from the corresponding node in the archetype used to create the data. The only exception is at archetype root points in data, where archetype_node_id carries the archetype identifier in string form rather than an interior node id from an archetype." --- ## Post #14 by @system Is that so? This really surprises me. There are so many arguments against that. - It leaves no room for an archetypeNodeId for the root. - One would wonder why it is there anyway if it cannot be stored, and the explanation in the ontology-section of an archetype gets lost also. - The archetypeId is also used in another syntactical way in paths (f.e. AQL) then the archetypeNodeId is. - And also, there is another room to leave the archetypeId, in the archetype_details-property. To handle the both different attributes in the same way under the same attribute-name seems not necessary, not logical, and confusing. I don't know if I will rewrite my software to do this. I must really think this over. But thanks, Pablo, for being so precise on this. Bert --- ## Post #15 by @pablo Hi all, I'll leave my machine on with the server running for anyone wanting to try things out, and maybe break something so I can fix it later :) Now introducing... [http://ppazos.zapto.org:8090/ehr/](http://ppazos.zapto.org:8090/ehr/) tada! I have committed a couple of compositions to EHR 1 (uid=3c7025cf-cf6f-4c3f-b0cc-1176475f0781) like the ones here: [https://github.com/ppazos/cabolabs-emrapp/tree/master/committed](https://github.com/ppazos/cabolabs-emrapp/tree/master/committed) And created a couple of queries, one to chart data and the other to get compositions: you must select an EHR in order to get data [http://ppazos.zapto.org:8090/ehr/query/execute?uid=297c8014-7861-4a65-8652-ac1b4ec268cd](http://ppazos.zapto.org:8090/ehr/query/execute?uid=297c8014-7861-4a65-8652-ac1b4ec268cd) [http://ppazos.zapto.org:8090/ehr/query/execute?uid=be9466b1-fa90-400b-b454-67f94881a558](http://ppazos.zapto.org:8090/ehr/query/execute?uid=be9466b1-fa90-400b-b454-67f94881a558) Of course, you can use the services specified here: [https://github.com/ppazos/cabolabs-ehrserver](https://github.com/ppazos/cabolabs-ehrserver) Please send me al your comments about the system, the ui, the service API, errors you get, anything! The idea is to improve this and have an open source repo in the community to be used by all. Of course if you find bugs, please add an issue here: [https://github.com/ppazos/cabolabs-ehrserver/issues](https://github.com/ppazos/cabolabs-ehrserver/issues) --- ## Post #16 by @pablo Hi all, I've created another client for EHRServer, now in PHP: [https://github.com/ppazos/EHRClientPHP](https://github.com/ppazos/EHRClientPHP) This new client is only for querying the EHR. The previous client, also does commits and is developed in Grails/Groovy/Java: [https://github.com/ppazos/cabolabs-emrapp](https://github.com/ppazos/cabolabs-emrapp) Next thursday I'll be doing a small online demo in Hangout (it will be in spanish this time) --- **Canonical:** https://discourse.openehr.org/t/want-to-test-an-openehr-repository/15262 **Original content:** https://discourse.openehr.org/t/want-to-test-an-openehr-repository/15262