Using the openEHR Template Designer to create Clinical Document Definitions

Quick overview of what you need to know about the Template Designer to create Clinical Document Definitions (Operational Templates) that can be used in software.

I have created this video some time ago, might be helpful for people starting with templates and operational templates Using the openEHR Template Designer to create Clinical Document Definitions - YouTube

1 Like

Undoubtedly, openEHR can be used to store the information in various Clinical Documents, if I’m right.

But I’ve been wondering if openEHR could meet all the requirements that HL7 CDA meets. In other words, I’d like to see if openEHR have all the features [1] provided by HL7 CDA.

[1] The HL7 Version 3 Clinical Document Architecture (CDA®) is a document markup standard that specifies the structure and semantics of “clinical documents” for the purpose of exchange between healthcare providers and patients. It defines a clinical document as having the following six characteristics: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness and 6) Human readability. URL: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

There are many differences between CDA and openEHR, the first difference is CDA is a definition of an XML format, while openEHR is a specification for a full EHR architecture. The second difference is CDA is only a document definition, while openEHR has other extra features like having EHR management and FOLDER management (CDA doesn’t have EHRs or FOLDERs).

At the document level, anything that could be done in CDA could be done in openEHR, but the other way around is a little tricky.

And lastly, the CDA model wasn’t designed to be archetypable, in openEHR you have clinical documents archetypable by design. CDA works with implementation guides, that are plain text documents, and openEHR relies on archetypes and templates, that are computer-processable definitions.

(disclaimer: I do workshops related to openEHR and to CDA :slight_smile: )

3 Likes

Wow, an awesome explanation. So many thanks, Pablo! :+1:

Then openEHR could be used to implement a Document Registry/Repository if my understanding is right.

Correct, in the context of IHE XSD an openEHR repository could play the Document Repository role. but I would implement Document Registry as a different component though. But it depends on design.

I did some work around EHRServer to use it as a IHE XDS.b Document Repository.

2 Likes

NO WAY!!! You are so amazing!
And this reply fully clarified my question above.
Thanks a lot, Pablo! :grinning:

2 Likes

I’d just back up @pablo 's comments to say that I am very confident that a document repository based on openEHR would meet all of the CDR criteria, including potential IHE-XDS compatibility

Borut Fabjan of Better did a PhD on this subject see https://vimeo.com/97714771 and we are using a variant of his XDS Metadata archetype routinely in UK templates
openEHR Compositions have the added bonus of being completely cross-queryable, unlike CDA documents.

3 Likes

Thanks Ian for the valuable evidences and links. :blush:

I think one of the differences is that CDA is self-contained, whereas in openEHR you need the combination of Template and composition to interpret the data. Also, openEHR does not have a mandatory human-readable representation and might be rendered differently. Regarding electronic signatures, I think there is no difference (though I’m not sure if the canonical representation inside openEHR is elaborated enough to guarantee identical checksums).

However, there are plenty of characteristics in openEHR that make it a good alternative to CDA as mentioned by Ian and Pablo. We actually combine openEHR with IHE XDS in HiGHmed to make our data available through the registry. However, there is sometimes not a clear cut-off point between documents that should belong into the registry and more granular, transactional data. This can be addressed by on-demand documents, but there are no clear rules. Also management of metadata between the standards is a bit messy. One of my students did a master thesis to integrate openEHR as an embedded repository actor in IHE.

Hope this helps

2 Likes

It’s does help!
Indeed, those’re what I missed.
Thanks Birger!

In CDA you also have an implementation guide, which is a plain text document that helps producing and interpreting CDAs. Without that, it’s difficult to process a CDA correctly. The “implementation guide” in CDA plays the role of the Operational Template in openEHR. The difference is an OPT is processable by software, while the impl. guide should be interpreted by a human.

You can generate the same kind of implementation guides automatically from archetypes. We even manage to generate them multilingual thanks to archetypes having that quality

1 Like

I think this will be a growth area in openEHR tooling. We are not making the best of what we have right now, to enable auto-generated documentation. One issue is how much to shoehorn into the current template format, or whether we need an other layer on top of that (akin to various form-builder languages but not identical).

1 Like

I think another layer on top is required. I was exploring this in my head the other day and came up with a rough idea for tooling on top of templates: I was thinking maybe a VSCode extension that loads up a webtemplate and displays a tree on the side. Clicking on the element will insert a snippet in various formats into the current document (after doing some conversion), along with the necessary import statements. Some formats that I thought of were:

  • Markdown for documentation
  • Mdx for documentation with interactive components with documentation.
  • React/Angular/Vue/Web component for interface generation.
  • Flutter Widgets for native mobile interfaces

There needs to be a component library for each of the frameworks, but that’s doable once a framework is in place.

However, what I’m having second thoughts about is how to create a reproducible 2nd layer on top of the templates, while still allowing the underlying templates to be developed iteratively. Compiling the templates into another format (md, mdx, HTML, React, etc) and making edits in place is not a good idea since the changes will be lost when the templates change. The vscode extension can help, but again the snippets have to be to manually modified every time the template changes. Having a proper second layer with a configuration option for each node in the template is possible, but it almost as much work as creating the template itself in the first place.

Is there any good way to establish a second layer, while still:

  1. Making it reuse as much work done in the first layer
  2. Maintaining some decoupling from the template so as to allow rapid iteration.

The FHIR Shorthand is becoming a popular way to write profiles and Implementation Guides. Maybe, something to learn from that? Just throwing ideas out here.

1 Like

It is a challenge, as particularly in early stages there will be all sorts of path-changes - how does the FHIR IG process manage that?

I’d happily steal any good ideas from others!!

Yes, but that is tooling support, is not normal process for HL7 CDA design. What people implementing HL7 CDA generally does is writing the Implementation Guides as documents. That is a pretty standardized process in the “HL7 world” (is that a thing?). What I mentioned in the previous comment is how the processes are generally done and what are the main differences between HL7 clinical documents and the openEHR approach.

It can be done based on ADL2 (so archetype/template friendly). ADL1.4 is no problem, and shouldn’t neither be OPT, as contains all needed information

As a little comment to this, I did an experiment the other day and managed to get a first version of FHIR Shorthand generation from archetypes in half an hour. So it’s definitely possible ;D
First we should let FHIR people decide how a FHIR Shorthand definition would look like for “foreign” reference models, as I believe that is in their TODO list

Hi every body,
I need your help please to convert general Json file to openEHR template. it is possible?
I want to store the PGHD data from Fitrockr application.

I have a sample from its Data
Many thanks for your guidance

openEHR templates are not a data format, are a data definition format. You might want to transform a data file to a composition in JSON I guess.