Link between goals and other clinical concepts

Diego Boscá yampeku at gmail.com
Thu Jun 26 04:16:04 EDT 2014


Well, I would say that deciding what's in and what's out of the
reference model can be tricky sometimes. If we assume that clinical
knowledge evolves (one of the basis of dual model approach) isn't safe
to say that the less clinical knowledge we put in the reference model
the better?

You can always define reusable patterns to be applied over the
archetypes, but these patterns itself can be evolved (just in case you
feel that some day event series could be represented in any other way,
for example). At the end, an Observation is an specialization of Entry
class with some structures already available for you to use.


2014-06-26 9:57 GMT+02:00 Thomas Beale <thomas.beale at oceaninformatics.com>:
> On 26/06/2014 08:33, Bert Verhees wrote:
>
>
>
>
> You can use multiple in archetypes-based reference models to validate and
> store and query data. You can allow certain parts of an healthcare
> organization, without any technical provision, to implement new ideas about
> medical data structures, maybe necessary for specific treatment.
>
>
> 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?
>
>
> 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.
>
> 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
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org




More information about the openEHR-clinical mailing list