Generating GraphQL from OPTs

[borut.jures]

@erik.sundvall

To make examples more realistic and complete (and possible to submit to an openEHR CDR) you could wrap the Blood pressure OBSERVATION in a COMPOSITION an add time an other mandatory fields (and skip pulse pressure + mean arterial pressure).
Showing example code instantiating a BP measurement would also help people understand usage

I’ve posted COMPOSITION for the Vital signs in another thread. It looks like this:

I’ve also posted an example code for instantiating BP:

@erik.sundvall

Then code would be even more readable and less prone to error by programmers, perhaps part of your code above could then be something like:
..property= TERM.property.Pressure

I have all the terminologies generated as models too:

In the above example CODE_PHRASE is used since that is what is expected by the RM. To help programmers understand the codes I added the terminology text in comments:

..property = CodePhrase(TerminologyId('openehr'), '125') /* Pressure */

I’ll see if the generated terminology classes can be used. They will probably be used in validation.

@erik.sundvall

So does the superclass Element(or some other ancestor) contain a validator algorithm that makes use of the Constraints?

I’ll answer this in another post since parts of the validation rules are not in computable form yet:

RM invariants in a computable form

In another post Erik noticed a “validate()” method in an OPT model class. The idea is to generate validation rules for OPT elements. There are 3 levels: Using generated constraints to validate that the OPT fields are in accordance with the constraints. Each OPT model class will implement a validate() method to validate its data. It will also call a validate() method of its ancestor (in case of RM classes - see #3 below): [Screenshot 2022-01-08 at 08.48.19] Using the “rules” section in t…