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

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:

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: )

1 Like

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.

1 Like

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

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 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.

1 Like

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

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