Hi,
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.
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.
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.
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
regards
Minor addition to this topic:
This archetype is called âMedia fileâ in the international CKM: https://ckm.openehr.org/ckm/archetypes/1013.1.1800
