# A possible approach to model concepts with encapsulated data

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2007-03-22 13:30 UTC
**Views:** 2
**Replies:** 1
**URL:** https://discourse.openehr.org/t/a-possible-approach-to-model-concepts-with-encapsulated-data/15239

---

## Post #1 by @Koray_Atalag

Dear all,

All that it takes is a "killer" function ;\)

The problem became obvious when discussing about ECG and Archetypes
recently\. When you want to assemble an archetype either for ECG or for a
composite concept with ECG data \(possibly not conforming to usual ECG
form\), electronic version of ECG  contains both biosignal data and
annotations which contain valuable contextual data and clinical
information\. This also true for other modalities like EEG, EMG to name a
few\.

Currently we can represent any complex e\-Modality data by the
DV\_ENCAPSULATED or DV\_MULTIMEDIA data type in an archetype\. But in this
way all the structured into becomes inaccessible \- at least feasibly\.

So specific question is: How to design archetypes to model such
situations effectively? \(without loosing data and without altering the
openEHR approach too much \(i\.e\. not creating a DV\_DICOM, DV\_SCP\-ECG and
so on\)?

So my proposal would be \(if technically possible\):

a\) Design an Observation archetype with the usual data structures and
elements

b\) Place the biosignal data part including annotation complying with
DICOM into DV\_MULTIMEDIA as \.dicom

c\) Create in Multimedia or Encapsulated class a function accepting
parameter \(item ID\) mapping to the item of interest within the DICOM
file \(i\.e\. frequency, latency, duration etc\.\)\. This function will
"get/fetch" the corresponding item according to openEHR data types\.

d\) Some of the elements in the archetype may set the "value" by calling
this function with an appropriate ID as parameter

Actually I see similarities with the internal references of archetype
slots\. The notion of referencing values or structures was already there\.
The only big difference is "when" this happens: The current referencing
is at  "Concept/Class" level meaning happens before instantiation,
however in this approach a value will never be available before
archetype instantiates\. But the structure and type info will be there\.

At runtime when archetype instances are forming, each one loaded with a
different biosignal data, referencing elements' values can be populated
directly from the multimedia data it contains\. A huge benefit I can
foresee is that a query running against the persisted info can
efficiently search for structured information rapidly\.  Otherwise either
the multimedia file has to be indexed or parsed at runtime \(not
efficient, redundancy\) or these data are entered by the feeder system
\(unlikely\)\.

Since this approach is very generic and simple \- only a single function,
it can be applied to other future standards without altering/breaking
the overall structure and semantics of openEHR approach\. Possible
candidates are SCP\-ECG standard getting stronger against FDA\-HL7 XML
standard and I guess there are many more to come from biomedical
industry and genomic world\.

As the last word I can say that it also enables an openEHR based
application to retrieve Resolution and Size\(pixel\) of a certain image
file too\. Also a radiologist might want to instantly know the slice
thinkness and kV/mA of a CAT scan picture\. None of these attributes are
present now and they shouldn't ever be\.\.\.

Sounds reasonable?

Koray Atalag, MD

---

## Post #2 by @Sam

Hi Koray

I think this is a good approach and is the same as I have proposed. It is important to see that an ECG report would comprise a number of archetypes - perhaps a diagnosis as well as the observation. The hard part is the observation. Using the history model in the openEHR observation class does enable serial data - but the history also contains a summary attribute for data sampled over a period of time. This could be used for the digital data as a MIME type.

One danger is that it might be seen to be making a new standard.....but I think the EHR does demand some access to key clinical information within these fractured approaches out there.

I think that the standardisation of structured health record information is a good reason to go for your approach.

Cheers, Sam

Koray Atalag wrote:

---


**Canonical:** https://discourse.openehr.org/t/a-possible-approach-to-model-concepts-with-encapsulated-data/15239
**Original content:** https://discourse.openehr.org/t/a-possible-approach-to-model-concepts-with-encapsulated-data/15239