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