Link between goals and other clinical concepts

Bert Verhees bert.verhees at
Fri Jun 27 05:10:49 EDT 2014

On 26-06-14 09:57, Thomas Beale wrote:
> On 26/06/2014 08:33, Bert Verhees wrote:
>>> sure, but like I said, this is just the same problem moved up one 
>>> level. At some point, you still have to write classes with the 
>>> semantics of things like Observation or Composition or whatever.  
>>> Otherwise you can't get the data on the screen, or compute with it 
>>> in any meaningful way.
>> I think this can be solved with templates and information which can 
>> be in the archetype-meta-data. Don't you agree? What am I missing?

Sorry to respond so late, it was my birthday, yesterday.

> example: this structure 
> <> 
> is inside an openEHR OBSERVATION, and most implementations use full 
> Java/C#/other implementations of these classes. That enables you to do 
> things like handle openEHR OBSERVATION data representing time series 
> from a device natively, including varying periodicity, varying sample 
> widths, and varying math functions (max, min, ave etc). This makes it 
> very easy for an implementer to get time-based data from an EHR and 
> populate a screen graph widget.

I leave that to the client-developers. If they want classes to create 
graphs, that is fine for me. The kernel I focus on does not much more 
but validating, data-storage and data-retrieval, and it offers some 
templates for specific GUI-purposes.
And for that purpose I don't need classes which represent the RM.

And what they do on the client side, I doubt if they ever create 
RM-classes, they have RAD-like ways of software developing and often 
they mix GUI-interface-code with functional code.

We have agreed two different interface formats for posting and 
retrieving data, and that is how far my concern goes.

thanks, Bert

> Without any of this built in, e.g. as in 13606, CDA, or other models, 
> you have no guarantee that this kind of data (very common you will 
> appreciate) is even represented in a standard way, nor do you have any 
> classes to process it with. You have to assume that each CDA or 13606 
> data source has its own representation of such data, and build N 
> implementations to deal with it. For openEHR implementers, openEHR is 
> the target data, so we convert data into openEHR, which is a 
> higher-fidelity format, and the problems go away. You could 
> potentially convert them into a sort of standardised 13606, 
> representing the same thing but then you'd still have to build your 
> own classes to implement time-based data rather than re-use the 
> standard classes everyone else uses. I don't see the point. Especially 
> as openEHR has AQL.
> Now, there are things that are not actually in openEHR, that you might 
> want. So you can take the 'reference archetype' approach to that, and 
> build local classes. But you might as well still use openEHR as 13606 
> or CDA as the basis, since you will get more for free - if you make 
> your local native format something completely custom, then there is no 
> community or software you can use - you have to build everything yourself.
> - thomas
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the openEHR-clinical mailing list