That is my point exactly. If you use only the model (archetype && || template) and your data is not clinically valid, then should not this mean that the archetype needs work? What if someone in a clinical setting entered -1234567 in real life? You would not be able to catch that with archetype based validation. In this case, you should not be amending your code, you should be amending the archetype, or that is how I'd attempt to do it.
Kind regards Seref On Mon, May 7, 2012 at 3:59 PM, Diego Bosc? <yampeku at gmail.com> wrote: > I'm working on that, but the instances that are being generated for > the moment still need some further processing to be considered > clinically valid (e.g. if archetype says that a number <1000 is > expected, one valid value is -1234567, which makes no sense from a > clinical perspective). It needs works but looks promising so far > > 2012/5/7 pablo pazos <pazospablo at hotmail.com>: > > Hi Seref, I've a tool that generates composition instances from > archetypes > > and data, what I don't have is a way to generate a valid XML form from > those > > compositions. > > > > In order to do that, we should resolve current reported issues with the > XSDs > > (see my first email), and then generate XMLs, at first maybe by hand, > later > > integrated into tools. > > > > > > -- > > 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: Mon, 7 May 2012 15:26:28 +0100 > > > > Subject: Re: How about creating an openEHR test base? > > From: serefarikan at kurumsalteknoloji.com > > To: openehr-technical at lists.openehr.org > > > > > > I don't have the time to do what I'm going to suggest next, but if > someone > > has time in their hands, I'd suggest writing a tool that will > automatically > > generate valid XML RM documents, such as compositions etc. > > > > Archetypes and templates define boundaries of all valid instances of > > clinical models, and one can generate random instances that belong to > this > > set. Opereffa's current version supports this, but not with XML output. I > > used this approach to test performance of persistence options > > > > If our argument is that all the clinical information can be represented > via > > models, why should be create RM instances by hand? > > > > Regards > > Seref > > > > > > On Mon, May 7, 2012 at 3:05 PM, pablo pazos <pazospablo at hotmail.com> > wrote: > > > > 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.beale at 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 > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > _______________________________________________ > 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/20120507/fb2be7c6/attachment-0001.html>
