Pablo, This is a good list, I have already commented on 1-3 and I am also interested 4-6.
I think a JSON format project would be good to make sure we get consistency earlier than later, it is not like XML where you can publish a schema and I suspect various toolkits will have their variations. Producing test data is a time consuming effort, producing valid instance is easy enough but at present clinical archetypes are still moving so these get out of date quickly. The real work is developing know bad instances, because there are so many ways something can be bad. So we need to define the scope of this effort and perhaps using the test archetypes on openEHR is not a bad approach as these may be more stable than the clinical archetypes at this point. Having said that, perhaps as part of the CKM review process we can produce test instances that can be made available to CKM users and developers alike, this could be done at any stage of the review process, not just at completion. Interoperability testing is extremely important, the IHE process demonstrates the benefits of this. I have done this with Rong several years ago and we found a few slight variations and assumptions that we needed to correlate, again I think we should do this sooner than later before we have too many systems installed with their own set of assumptions. This really needs resourcing but I think it should be the vendors that do this since ultimately they will be beneficiary of having an openEHR compatible system, but we do need some governance and tooling to support this process so we need some additional contributions to kick start the process. I think your initiative is a really good start, it is certainly not a new idea but you're making it happen, keep it up. Regards Heath From: openehr-technical-boun...@lists.openehr.org [mailto:openehr-technical-bounces at lists.openehr.org] On Behalf Of pablo pazos Sent: Monday, 7 May 2012 11:36 PM To: openeh technical Subject: RE: How about creating an openEHR test base? Hi Thomas, just to be sure we are on the same page: >From previous emails: What we need is to test our implementations (EHRs, services, repositories, etc), we don't want to test the tools or the specs (i.e. we will not use an archetype for a "guitar" concept). We want to concentrate on flat archetypes and operative templates, things that will be used by systems, not on source ADL archetypes with slots, abstract types and other things that makes implementation a pain in the 4$$... you know what I mean. JSON and other serialization formats should be considered only for transport purposes, not for modelling, BTW I mentioned only RM instances in JSON, not archetype instances (but it's possible to transport archetype and templates using JSON). What I want (and maybe others) is: 1. to be sure that RM XSDs are correct compared to the specs, 2. have some RM XML instances are correct validated against XSDs, 3. to have RM XML instances generated for some OTPs, with the referenced source archetypes and term sets accessible too, 4. create some JSON form of those RM XML instances to play around with REST services and web browser/javascript apps, 5. create some test cases in our own projects to be sure we are ok, maybe share those tests and results, 6. maybe do some interoperability tests, e.g. generate some of this artifacts in one system, transport them to another and see if test cases pass or not. What do you think guys? Kind regards, Pablo. _____ Date: Mon, 7 May 2012 10:30:34 +0100 From: thomas.be...@oceaninformatics.com To: openehr-technical at lists.openehr.org Subject: Re: How about creating an openEHR test base? On 06/05/2012 13:28, pablo pazos wrote: Hi Peter, thanks for the pointer. I think this is only ADL related and only 1.5. My idea is to include ADL1.4 and RM instances in XML and JSON, RM & AOM XSD, also term sets. Maybe we can took some samples from there, but I believe this new repo has a wider scope. What do you think? My view is that this existing repository should be expanded to include all test case archetypes in ADL and any of the other serialised formalisms. Today it does mainly concentrate on ADL/AOM 1.5 test cases. Let's think about what other test case material could be added, and how it should be organised. Rong Chen (Sweden) and Koray Atalag (NZ) have thought quite a lot about this in the past and I am sure would have ideas to contribute - Erik Sundvall has been thinking about some of the other serialisations. I have to admit to only having seriously thought about test cases for bidirectional tool processing, which is currently ADL, dADL, and will extend to XML-AOM (I just haven't gotten around to this yet). I have not thought too much about test cases for JSON or YAML, but I have done the output serialisations for them. Having done the first implementation of JSON, I think it is too weak a formalism to be seriously useful, because it lacks too many basic semantics - particularly dynamic type markers. Its cousin YAML is over-complicated (and in its whitespace form, nearly impossible to get right!), but does have proper OO semantics and I think can be used as a lossless serialisation. Others may have more evolved ideas on how these particular formalisms should be used in openEHR, so I am very happy to be educated by the experts. My main aim is to make sure that the transformations of ADL => JSON and ADL => YAML are correct. You can experiment with JSON, YAML and XML outputs of any ADL 1.4 or 1.5 archetypes right now, using the ADL workbench, which has a bulk export mode into these formalisms. We have already discussed last week with Rong & Sebastian about moving the openEHR terminology there, and how to manage it more effectively, so the scope of this knowledge repository is going to continue to grow anyway. So any community input on how to expand this repository and manage it is welcome from my point of view (I realise the above might only be a subset of your original scope Pablo, so there are probably some things that still need to be done elsewhere.) - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120508/27bce04a/attachment-0001.html>
