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.
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.
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).
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.
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.
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.
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.
"- 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.”
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
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.
