Separating Models from Implementation

[erik.sundvall]

@NeoEHR

I’ve reread the entire thread and looked for requirements for simplifications.

• The clearest request I could find came from Erik and Ian for GraphQL.

At Karolinska the most burning need* right now is actually generation of template-specific schema (that fit into mapping tools like Mirth and Altova MapForce) and corresponding bi-directional format-converters (converting data instances bidirectionally between simplified and canonical openEHR formats). This is available for XML in from of TDS+TDD+bidirectional XSLT from some openEHR system providers, but sadly not yet officially specified by openEHR.

That said, the GraphQL approach is highly interesting for other needs we also have, so I posted some initial questions in the corresponding thread.

*) We are currently working with populating our CDR with e.g. lab data coming from sources using EDI, HL7 v2 etc. Mapping tools handle the source formats well and can usually target XML schema or JSON schema and generate instances following those. With mapping tools informaticians and lab IT staff can create and maintain conversions without beeing programmers, then we’ll just need to call in the programmers for tricky parts that the tools don’t solve - this approach scales better than programming every conversion.

[NeoEHR (Borut Jures)]

@erik.sundvall

With mapping tools informaticians and lab IT staff can create and maintain conversions without beeing programmers, then we’ll just need to call in the programmers for tricky parts that the tools don’t solve - this approach scales better than programming every conversion.

Nothing scales as good as computers generating the converters/code/applications

[NeoEHR (Borut Jures)]

Here is a sample of simplified code working with blood pressure template:

More in this answer.

More about the generator’s code in this answer. It takes only a few lines and the generator can output code in TypeScript, C#, Kotlin,…

[bna (Bjørn Næss)]

@erik.sundvall

At Karolinska the most burning need* right now is actually generation of template-specific schema (that fit into mapping tools like Mirth and Altova MapForce) and corresponding bi-directional format-converters (converting data instances bidirectionally between simplified and canonical openEHR formats).

I made a simple XSLT to transform an #openehr composition into a simpler form more easy to work with in tools like Altova. The idea was to help the national cancer registry in Norway.

Source here : kremt-examples/xslt at main · bjornna/kremt-examples · GitHub

They are not using this. They map the canonical xml using Altova.

[birger.haarbrandt]

@bna

They are not using this. They map the canonical xml using Altova.

Sounds painful

[bna (Bjørn Næss)]

@birger.haarbrandt

Sounds painful

Indeed. Very patient and nice guy working on this.

The most important thing : They accept canonical openehr as input to the registry. No additional, unnecessary and resource driven mapping to a wire format like fhir.

[thomas.beale]

Just out of curiosity: I guess the notation ..data = ... is a kind of builder pattern in Dart? Why the double dots?

[NeoEHR (Borut Jures)]

Yes. It is called “Cascade notation”. Since I had to look-up the name, here is the link with explanation and examples: cascade notation

The main difference in my example is for “data” and “protocol”. With double dots I didn’t have to repeat “bloodPressure” twice:

var bloodPressure = BloodPressure();       <= there is an implicit "new"
bloodPressure.data = BloodPressureData();
bloodPressure.data.history = BloorPressureDataHistory();
bloodPressure.data.history.events = [BloorPressureDataHistoryEvent()];
...
bloodPressure.protocol = BloodPressureProtocol();