Code Generation Strategies for ART DECOR

Last time I wrote about code generation using ART DECOR. This time we’ll look a some more code generation, and then consider various strategies for code generation.

In the previous post we saw how to generate HTML for a user interface for a transaction in ART DECOR. We can do the same for database code.




Like in the HTML generation, the XSLT used to generate the code operates on the output of RetrieveTransaction, and is rather small itself. And, like before, this is not a complete code generator yet: not all datatypes are included etc., so only use this as the start for your own code generators. This generated SQL (tested on PostgreSQL) implements the following database model:

 ada-codegen-dbEach concept group becomes a table, value sets (vs-measured-by) get their own table, which is populated by the rows in the value set.


If we hook up some middleware, which can be pretty generic, the middleware, the HTML UI and the database would be a complete application.

Some caveats for real-world usage:

  1. It’s probably better to derive the SQL datatypes from the HL7v3 datatypes in RetrieveTransaction (only possible when HL7v3 is the target, and specs are complete). For more information on generating SQL from HL7v3 datatypes, see RIMBAA_MGRID_HL7v3_Datatypes.pdf for a thorough approach.
  2. Value sets here get their own table. Another approach is to have one table for all value sets, with extra columns for value set name or id. Take care: the approach I’ve chosen uses artificial primary keys in de value set table (with values 1, 2, 3…). This works well for a single version, but what’s constant over several versions of a message is the combination of code and codeSystem. So if you follow my approach, make sure to keep the primary keys constant over time.
  3. I simply generated a separate table for each concept group. It’s easy to improve over that approach: groups which are 0..1 or 1..1 do not need their own table. Basically, the generated database is split in more tables than necessary.

The next question is what the best strategies for code generation along the lines I’ve sketched are. Of course it’s possible to generate an entire application, but that would be suboptimal. ART DECOR (usually, not necessarily) models interchange, so messaging between applications, and not static information models. The requirements for a database are as a rule not covered by interchange models. So while this approach is possible, it would probably need an augmented underlying model.

A better approach is to use code generation as a messaging layer between your own application and the outside world. Parse incoming messages and store them in temporary tables. RetrieveTransaction already contains XPath expressions which point to the right locations in the incoming XML (not 100% complete though, so use as a starting point). Then populate your own DB from the temporary tables, and empty the latter.


This is a very flexible model: when there is a new version of the messaging standard, simply re-generate the insulating layer with generated tables. This will enable you to read new messages without too much ado. The conversion to the proprietary DB will need some updating, of course: there is a new version of the message, so things will have changed. Still, the prorietary DB will be insulated from many changes to the messaging format itself, and the logic which needs updating will be minimized.

Another strategy is to use code generation to generate form parts which do not have corresponding fields in your own database. Such a strategy would involve:

  • generate an HTML form from RetrieveTransaction;
  • prepopulate the form with all the data which already is in your own database;
  • present the form to the user (embedded within your own application);
  • have the user complete the information which is not in your database;
  • generate a message, and send it.

This strategy corresponds well to cases where for instance generic patient data are already in your database, but additional information is needed for some report which needs to be sent. Again, if a new version of the report and message is coming along, this approach ensures only minimal changes to the underlying logic.

Code generation is already used in many projects in the Netherlands, both to generate UI and database logic, as well as for data extraction. All in all, ART DECOR provides all the tools needed to leverage your applications with code generation, and thus implement exchanges in a quick and robust fashion.

Mijn medisch dossier is van mij! Of toch niet?

Je hoort het met enige regelmaat. “Het is eigenlijk heel simpel: het dossier van een patiënt is eigendom van die patiënt! En niet van anderen, zoals de zorgverlener.” Maar zo eenvoudig is het niet.

Om te beginnen bestaat er in Nederland geen “eigendom” van intellectuele gegevens. Op het fysieke dossier kan wel eigendomsrecht rusten, maar in deze tijd van digitale dossiers is dat vrij betekenisloos geworden. Een digitaal dossier is dus niemands juridische eigendom. (Zie ook: ‘Van wie is het dossier’, Anton Ekker, Nictiz 2010.) Er is hoogstens sprake van auteursrecht, maar daarop wordt bij medische dossiers zelden of nooit een beroep gedaan. Prima, zal de tegenwerping zijn, misschien klopt dat in technische zin wel, maar dat is juridische haarkloverij. Moreel gezien is er maar één iemand eigenaar van het dossier, en dat is de patiënt! Maar nee, ook dat klopt niet.

Neem een simpel voorbeeld. Mijn arts schrijft mij een recept uit voor 30 keer 75 mg Nortrilen. Dat recept maakt deel uit van mijn medisch dossier. Maar mag ik nu naar eigen inzicht dat recept wijzigen, en die 30 veranderen in 300? De Wet op de Geneesmiddelenvoorziening stelt dat een recept door een arts ondertekend moet zijn. Wat ik dus ook zelf aanpas in een dossier, een recept is het daarna niet meer. Zo zal een arts ook niet willen dat ik in “mijn” dossier de diagnose obstipatie aanpas wanneer ik vermoed dat er toch wel wat ernstigers dan dat aan de hand zal zijn. (Wanneer een patiënt het niet eens is met een diagnose, heeft deze wel het recht een eigen verklaring aan het dossier toe te laten voegen.) En wanneer ik een bloedwaarde in een laboratoriumuitslag aanpas, is dat geen laboratoriumuitslag meer, maar gewoon een kladje waarin ik zelf wat gerommeld heb. Wat is dat nog voor “eigenaarschap”, wanneer ik de gegevens niet aan mag passen?

Zelfs het (laten) verwijderen van gegevens uit mijn dossier mag niet altijd. Meestal heb ik dat recht wel, maar niet als een aanmerkelijk belang van een derde zich daartegen verzet. Zo’n  belang kan bijvoorbeeld de arts zelf hebben. Wanneer ik een klacht over de arts indien bij een tuchtcollege, kan de arts zijn dossier nodig hebben om zich te verdedigen, en hoeft het zolang de zaak loopt, niet te vernietigen wanneer ik daarom vraag.

Kortom, ik heb het recht niet “mijn” dossier naar eigen inzicht te wijzigen, en onder omstandigheden kan ik het zelfs niet verwijderen. Wat voor een eigendom is dat? De feitelijke situatie is natuurlijk anders. Juridisch is er geen sprake van eigendomsrechten, en in lossere zin is het eigendom gedeeld:  de zorgverlener heeft het deels geschreven, en de medische inhoud is de verantwoordelijkheid van de zorgverlener.

Uiteraard kan ik prima spreken over “mijn medisch dossier”, maar dan in de zin van “over mij”, niet “van mij”. De essentie van “mijn dossier” is dan ook ten eerste dat ik mag bepalen wat ermee gebeurt: wie het in mag zien, wat er uit verwijderd wordt (met een klein voorbehoud om anderen te beschermen), en uiteraard: dat ik er zelf bij mag! Niet een beetje, niet een deel, maar helemaal. Dat is in Nederland in de praktijk nog niet altijd goed geregeld. Daarover een andere keer meer.

Using ART DECOR for Code Generation

ART DECOR is a framework for capturing medical information requirements, mostly for the exchange of data in healthcare. In a short series of articles we will explore the benefits ART DECOR offers for implementers. (See the ART DECOR Factsheet for a short general introduction, or for detailed documentation on ART DECOR.) ART DECOR captures the data needs of healthcare professionals and patients in datasets and scenarios. ART DECOR does not only help healthcare professionals and IT architects to model medical data, it also offers a wealth of goodies for implementers, some easier to find than others.

Take a look at one of our demos, Measurements by Patient. This page, the ProjectIndex gives access to most resources available for developers. Look for instance at the Vital Sign Result valueset from the Vital Signs Demo. It’s also available in XML and CSV, for easier importing into an application. But let’s look further, to the main transaction from the first demo, the Measurement Message. Most of the data needed for an application is in there: field names, data types, code lists, cardinality, help text (description). This data is also available as XML, and this is an ideal hook for code generation. This XML version of RetrieveTransaction contains even more in the <implementation> element, which contains an XML- or SQL-friendly name (shortName), as well as the HL7 datatype. RetrieveTransaction gathers all data from the dataset, transaction and valueSets, and combines those into a single view.


There’s also detailed documentation for RetrieveTransaction. RetrieveTransaction thus contains almost everything that’s needed for code generation. In the example below, I’ve made a basic HTML code generator. This is just an example, if you wish to use is for real code generation, you will need to adapt it – only some datatypes are supported, the submit action doesn’t actually do anything etc. Later we’ll look at a more full-fledged code generator.


What is done here is just a simple XSL conversion from the RetrieveTransaction output to a HTML page. The XML tab contains the RetrieveTransaction output, the XSL tab the stylesheet which is the actual code generator, and the HTML tab the generated code. The Result tab shows the rendered HTML (it is a .png, since the HTML doesn’t render well in WordPress – here is the HTML Result page as HTML).






As you can see, the actual XSLT to generate the HTML code is pretty small. A real HTML generator would need some more, but still needn’t be large. For a larger example, here is the generated HTML for the epSOS Patient Summary (due to IP issues, some Snomed codes are not included, so corresponding drop-downs will be empty).

In the second installment of this short series, we’ll take a further look at strategies for code generation with ART DECOR.