Re: [Gnumed-devel] roadmap

[Christian Heller]

Karsten,

> I have eventually dropped the idea of fully defining forms in
> the database but rather only storing metadata *about* the paper
> forms in the database. The forms template should perhaps be
> XML with 3 main sections: how-to-display, how-to-"print",
> placeholders for data. The database then stores this XML at
> whatever stage it happens to be at in nascent_forms.template.
> Completed and "used" forms are stored in
> "completed_forms.content" - again, the full XML source. A
> display parser generates a simple (!) input UI (works well for
> me daily in our practice). A "print" (or fax/...) parser
> generates the appropriate target format from the XML source
> once submitted. Thus arbitrary intermediate form filling
> interruption is possible. I have many thoughts here but we
> need to start small.
>
> Better suggestions ?

I recommend to use extra XML files for:
- domain (knowledge) data (EHR)
- screen display
- print layout
- etc.

The reason is more independency between the single models. Translators
may be used to read data from one and write them to another model.
Here an (oversimplified/ uncorrect) example ("null" checks etc. omitted):

display.panel.table.label = ehr.problem.episode.objective.blood_pressure;

If you like, you can put yet more elements into extra XML files, e.g.
a Panel or other GUI components so that they may be reused to compose
different GUIs.

Eventually, you would see that more and more code (whole classes) can
be defined in XML and Python is only needed for the parser. That is
what I am currently working on, in Java. As everything goes more and
more XML, I get independent from Java or whatever parser/language is
below. My aim is pure C, one day. Finally, GNUmed, OIO, OpenEHR,
Res Medicinae, ... could synchronize their XML models (in some years).

Rgds,
Christian