Link between goals and other clinical concepts
bert.verhees at rosa.nl
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.
> 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 lists.openehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openEHR-clinical