15 min | standards for Forms | Erik Sundvall | Diego Bosca : https://lhcforms.nlm.nih.gov/lhcforms Erik Sundvall : Current need in multi-openEHR-vendor projects (in Sweden) where we would like at least some GUI/form logic to be authored once and then reused in several different vendor solutions (Cambio, Tieto/Better, SECTRA structured forms, perhaps NeoEHR?) Previous mail list discussions (2008) regarding GUI-hints in openEHR templates. Some highlights: Suggestion
Discussions (all): considers rules from ADL - (Definitely useful within an archetype - with ADL2 possibly also in templates across data from different archetypes?) Nedap is using these rules, need to ask Pieter Bos for feedback. Edit: In Slack Pieter later wrote: Regarding the rules: the implementation is open source in Archie. It outputs things such as 'set the value at this path to this', and 'this part of the data must exist (is mandatory)'.If anyone would like to try, there's an imementation running at archetype-editor.nedap.healthcare. sign up and login, create a repository. Using the basic editor you can only define sums and averages. If you click 'advanced editor' at the bottom, you can see and edit the rules to achieve quite a lot more, and there's a form implementation that executes them as well. Note that this form only does compositions, observations and evaluations. (edited) Oh it also outputs a copy of the object provided as input, modified by the rule evaluation, plus whatever assertions failed and succeeded, of course For editing the rules by hand, I would recommend the visual studio code extension, but it cannot execute them on data
need to ask Matija Polajnar about Better’s form-builder45 Min | Presenting NeoEHR | Borut Jures | I'll list what I have done so far in case it helps to prepare questions: I started with a BMM parser and converter to in-memory representation of the BMM files. I used the BMM files to generate classes for AM and RM types. I generated UML diagrams for the AM and RM types (https://neoehr.com/openehr/uml ). I wrote a OPT2 to JSON converter since Pieter was busy and didn't want to add the required small fixes to his to-do list. The generated AM types have a fromJson() method that can read the OPT2 JSON. At the same time it validates that it conforms to the correct format (see file AM206.zip). When the OPT2 is loaded into memory as AM classes I build in-memory model of the OPT. From the in-memory OPT model I generate OO representation of the OPT (see file VitalSignsSDK.zip). The generated OPT models should be structurally similar to the UI representation of the OPT (I'm guessing). I'll work on trying to generate a forms app next. In-memory model of the OPT has a "walker" that calls a "writer" methods. The walker part is always the same (SDK or forms). For the forms I have to "only" write a different writer. This "only" is probably a bigger task that all of the above.
You have done the same with your code bases. I haven't done anything new. Maybe the only difference is that all the code can be run on a client side (web, iOS, Android) or server side.
This allows for scenarios such as: Reading OPT2 (in ADL) on a client. Validating OPT2 on a client before generating JSON for the CDR. Validating received JSON on the server (I have to add invariants to the generated code). Automated conformance checking?
|