Generation of Example Instances of a Template

[linforest (Lin Zhang)]

A disirable feature would be generation of example Instances of a Template for demo.

Currently, when open a specified Template, the right panel will render it as a form that could be used for entering some example data. So, sometime, displaying and export/save the example Instance data would be a nice feature.

For example, the Web Template JSON to be displayed and exported/saved:

{
"vital_signs/body_temperature/any_event/temperature|magnitude": 38,
"vital_signs/body_temperature/any_event/temperature|unit": "°C"
...
}

Reference:
* 2.5. Step 4: Load Data — EHRbase documentation

For now, using the EHRbase Swagger UI, the operation GET {BASE-URL}/rest/openehr/v1/definition/template/{template_id}/example can be used to generate an example composition (populated with fake data; format = application/xml) for the specified template.

[borut.jures]

Generating example instances from a template is “easy” and can be fully automated (I know that @pablo, Archie and @borut.jures have done it – probably others too – please reply to add your solution).

Next level is generating fully randomized example instances where optional data is sometimes added and sometimes omitted and variable number of items is added for lists.

The interesting part is generating instances with clinically relevant data. I’m using YAML based formulas which clinicians can prepare:

formulas:
  # LOINC based formulas
  loinc:
    # Heart rate
    8867-4:
      set:
        - attribute: value
          element:
            value_range:
              low: 40
              high: 130

    # Body temperature
    8310-5:
      set:
        - attribute: value
          element:
            value_ranges:
              deg_C_snomed:
                low: 35.0
                high: 38.9
              deg_F_snomed:
                low: 90.0
                high: 102.0
            interpretation_ranges:
              deg_C_snomed:
                low: 36.1
                high: 38.0
              deg_F_snomed:
                low: 96.98
                high: 100.4

Notice that there are no references to archetype names or paths (even if they are supported for more complex cases). This means that clinically relevant data will be added to ANY template based on LOINC codes alone.

Manually creating example instances is time consuming and in the long run hard to maintain. Writing formulas (as shown above) would be time better spent.

It would be great if example instances with clinically relevant data were available for download in the CKM (try googling “fhir blood pressure example” and “openehr blood pressure example” – Google will autocomplete it for FHIR, but not for openEHR). From my experience developers can better understand JSON example than reading archetype description in CKM (even if CKM is more detailed). Maybe this is one of the reasons why FHIR is picked up so quickly by the developers.

[ian.mcnicoll]

Archetype Designer actually has this feature (I only recently discovered).

Via the Form tab, then enter some dummy data (or generate) then Export->JSON

[linforest (Lin Zhang)]

Synthea works for FHIR

Blockquote
Synthea is a Synthetic Patient Population Simulator that is used to generate the synthetic patients within SyntheticMass. Synthea outputs synthetic, realistic but not real patient data and associated health …

Such a “Synthea” for openEHR would be nice!

[borut.jures]

@ian.mcnicoll

Export->JSON

I was so hopeful, but it doesn’t export as canonical RM composition

It is probably web template as JSON.

[linforest (Lin Zhang)]

Wow, It’s worth trying…

[linforest (Lin Zhang)]

@borut.jures

From my experience developers can better understand JSON example than reading archetype description in CKM (even if CKM is more detailed). Maybe this is one of the reasons why FHIR is picked up so quickly by the developers.

Agree

[borut.jures]

@linforest

Such a “Synthea” for openEHR would be nice!

I’ll use Synthea FHIR data to map it to openEHR (Synthea doesn’t support openEHR format).

This is where posted formulas originate from – my MapEHR project for migrating legacy EHR data to openEHR
They were just re-purposed for my client’s example instance synthesizer.

[ian.mcnicoll]

It is a STRUCTURED JSON Compositon instance not a web template.

If I need a canonical json or xml, I just post the composition into a Better or EhrBase CDR and read it back again as Canonical .

[ian.mcnicoll]

Synthea openEHR data would be very interesting - I know @bna was working in this area a few years ago.

[borut.jures]

@ian.mcnicoll

If I need a canonical json or xml, I just post the composition into a Better or EhrBase CDR and read it back again as Canonical .

That is because you are not “lazy” like me

And it helps that you have a lot of experience with the tools. Consider a new developer trying to figure out “STRUCTURED JSON”, “Composition instance”, “web template”, “canonical json or xml”, “post to CDR”. They will be overwhelmed.

It would be great if Archetype Designer would export directly to canonical composition

[ian.mcnicoll]

Completely agree!! I think we could easily hide some of this in a wee developer playpark environment

[linforest (Lin Zhang)]

Is [FHIR-Bridge[(GitHub - NUM-Forschungsdatenplattform/num-fhir-bridge: FHIR Bridge acts as a broker between an HL7 FHIR client and an openEHR server.) relavant for this topic?

Imagined pipline: Synthea → FHIR-Bridge → [EHRBase, EHRServer…]

[ian.mcnicoll]

@borut.fabjan - we love the new Export Example JSON in AD via Form but can we expand that to support other formats like FLAT JSON, Canonical JSON?

[borut.jures]

@linforest

Is [FHIR-Bridge relavant for this topic?

It is, but it uses Java classes for mapping FHIR to openEHR. I tried a similar “code-based” approach but it was quickly rejected as “unfriendly” to clinicians – they prefer YAML over programming languages.

Similar to two-level approach of openEHR archetypes, mapping should also separate formal definitions of mapping clinical content from the technical implementation.

The idea is to have a generic tool to convert EHR data to openEHR where mapping rules are defined outside the tool (e.g. YAML/JSON). Ideally the mapping rules would be reusable by different tools/vendors.

[linforest (Lin Zhang)]

@borut.jures

reusable by different tools/vendors.

+1

I.e., technology and vendor neutral

[sebastian.garde]

This hasn’t been used much in CKM so far, but if you have a nice realistic example for a template (or archetype) in JSON, you can add these in CKM.

Agree it would be useful especially for developers to see this, ideally with realistic clinical data as @borut.jures says.

[ian.mcnicoll]

Yup @SevKohler is leading this work for HighMed to bring together the FHIR Bridge work and FHIR-Connect, so that it is based on sharable YAML-based artefacts.

[linforest (Lin Zhang)]

@sebastian.garde

you can add these in CKM

What role(s) is this CKM feature available for?

[sebastian.garde]

@linforest

What role(s) is this CKM feature available for?

Anybody can view this. Upload is for editors, CKAs.