Using EHRbase to store existing clinical data as pdf documents

Can EHRbase be used to manage the existing clinical data as documents(pdf, jpeg etc.)?

We have a lot of the existing clinical data stored as physical or electronic files. It is important that these are also included while implementing a CDR. Can EHRbase be used to manage these documents as well.

just FYI, here is the part of the spec that supports original content storage (or linking).

Thanks @thomas.beale

That is very useful. My question is more about the best practice of implementing EHRBase. Can I encode and store these documents inside EHRbase or is it better to store them in a separate document management system and keep a link in EHRbase?

My view is that in anything other than a trivial implementation, you should use a separate doc management system or simple store.

That’s certainly a common approach (especially as a doc store often already exists). In which case FEEDER_AUDIT.original_content will store a link that gets you from the EHR to the PDF, CDA or whatever it is.

In most cases this would not be ‘original content’ though.

We would normally use the 'Multimedia source cluster, which includes a DV_MULTIMEDIA ‘Content’ element to either handle to content in line or by reference.

Example of carrying a power of attorney PDF document

If they’re too many in numbers and/or too large in size (that’s subjective but I’d say if they take more space on disk then the json serialisation of the composition that represents them in openEHR, then they’re large), keep them somewhere else. Somewhere else can be whatever your engineering can deliver, so it’s up to your tech team to choose the tech. I’m making this point because they may decide to use the postgres db instance EhrBase itself is using, but it’d still be non-openEHR.

Keep an openEHR view of the documents so that they are known to your openEHR apps. This will make them searchable etc, and you can also implement access control based on the composition view of those pdfs. You can grow the openEHR scope of data in time by versioning the archetypes/templates used as the view to those documents. Check out multimedia type for keeping small thumbnails for images, so that users can have an idea of the real thing before they ask your implementation to fetch it.

1 Like

You probably want to do that anyway, since one day (in the distant future, by which time no new PDFs etc have been created for years) you might decide you just don’t need all those PDFs / images etc, and want to use just the native openEHR data. That means you can archive / decommission the doc-store, and it’s not going to hurt the EHR. The links might need to be processed so that they don’t end up being completely broken, but newer applications wouldn’t normally allow access to them anyway.

And using the RDBMS as Seref suggests is eminently sensible.

1 Like

Wouldn’t this be an IMPORTED_VERSION?

I don’t think EHRBASE supports this yet.

No, an Imported version is native openEHR content that has been imported from another openEHR system, e.g. imagine a hospital openEHR system importing patient 123’s data from a general practice openEHR system. Everything is native openEHR, but the hospital system needs to be given a copy of items it doesn’t yet have, e.g. updates to medications list, recent labs etc.

It’s the same idea as syncing Git repos.


to provide my 2 cents: you can store the PDF documents as base64 in EHRbase, but it depends on the amount and size. Within our broader platform (EHRBase + services), we use a S-3 storage like MinIO to store this data and store the URL in EHRbase. For import of HL7 MDM messages, this process is automated.

We considered automatically serializing multimedia content as part of EHRbase (e.g. to dedicated BLOB columns or even table), but it is not yet clear if and when we would implement this.

Thanks everyone for the responses

The bottomline is if the numbers are small we could use EHRbase. Otherwise an external store with a link in the main CDR


1 Like

Minor addition to this topic:

This archetype is called “Media file” in the international CKM: Clinical Knowledge Manager