On 25/06/2014 20:56, Bert Verhees wrote: > >> >> The Composition class is defined in 13606 and openEHR to do one job - >> act as a container for data captured during the same health event. It >> doesn't do all jobs. There is no reason we would not add other >> classes in the future to openEHR to handle other general categories >> of data, either at a similar level as Composition, or finer levels - >> just like we would add a new data type if we need it. > > This is exactly the problem why I mention it. Because OpenEHR is in > the RM, and not in archetypes, people using it, must wait for you or > others to add a new class. It makes them dependent. At that moment, > they experience an information-lock-in.
anyone can make a local change, test it, and propose the change to the RM. And anyone can make 'reference archetypes' as you proposed earlier. It's encouraged. > > There is another problem also, because OpenEHR as RM guarantees to > remain backwards compatible, it cannot remove classes from the RM. > This means there must be some provision to handle redundancy in > data-definition which can occur when new classes are added. Redundancy > means, more paths to store data of the same semantic meaning. The > start of big trouble. I think it all depends on what the new classes are. We aren't likely to add many, and they are all generic, i.e. semantically invariant classes. There are no domain specifics in the RM, only general concepts like the classes you see today. New classes would need to be at the same level of generality. > > I learned a lesson, a long time ago, and I see that this is still a > valuable lesson.The lesson was: Never put semantics in the database > design, put it in the data. > (it is an often made mistake to ignore this lesson) that's the foundational basis of openEHR ;-) > > I think more or less it can be applied to this discussion. > You can in analogy regard the Reference Model as database-design and > the archetypes as semantics to explain the data. > The big trouble which can occur in redundancy in data-definition is > because of having semantics in database-definition level. > > I am still not aware of a good reason to create a semantic rich RM, > while there are enough possibilities to link the data to the semantics > via archetypes. there isn't a semantic-rich RM, there is an RM that has only semantics that are general across health, and I would argue much of observational science. As you know, there are no lab results, prescriptions, ECGs or any of the 1000s of other clinical things in the RM - those things are all archetypes. What is there are semantics that appear to be invariant across the domain - 'Observation' and so on. Time seems to have proved this a reasonable choice. > >> >>> You could also model the OpenEHR information model, which now >>> resides in the reference model, in such constructed >>> archetype/template-based information model, using only >>> structure-based archetypes. >> >> well, you could get some way. Developers like the structures in >> Observation and Action and Instruction, because they can be >> programmed once in Java, Ruby, Python, C#, ... etc and they just >> work. No archetypes to worry about there, and yet they take care of a >> lot of quite complex data like differential time-series, multi-drug >> orders and so on. > > Information must be the purpose of an EHR-definiton, not solving > developer-issues. well - that depends on what the developer issues are. If a badly designed or too-simple RM causes developers to write software that generates non-interoperable data, then it's a serious data problem. > > In my case, f.e., I don't even have classes representing a Reference > Model. I don't need them. Archetypes are the thing I worry about. Data > must conform the constraints in the RM and in the archetypes. > For my kernel it is the same if a dataset represents an ItemTable, an > Observation or a Person. > They are treated the same way, > - they are validated on XMLSchema ((RM-validation) f.e. an Observation > cannot live on its own) > - and on Schematron (archetype-validation) > - and stored as XML, > - and can be queried by AQL or XPath/XQuery. > > Maybe this was a problem in the year 2004, in that time we saw all > developers mimicking the Reference Model in class-schema's of their > favorite language. Me too, but not anymore. > So you solved a problem that I do not have. well I guess that means you are using a different category of architecture. But if you are using any archetype specialisations, then you are actually using more or less the same architecture, just one level up. How do you want to solve the problem of having a standard representation of orders, or time-series data, across all countries, so that re-usable software can be written? You can only do that with wide agreement on those semantics, wherever they are specified - in an RM, or in some layer of archetypes. > > Do other people have this problem? Are they relying on RM-classes to > process datasets? > >> >> If you try to replicate all those details as reference archetypes, >> you'll get some of it done, but since you can't create generic >> (templated) types or use multiple inheritance (at this stage, at >> least) in ADL/AOM, there are going to be limitations. Solving that >> means upgrading ADL to have the power of a language like C++. I'm not >> sure if that's what we should be doing. > > I am not sure about this, I don't see the multiple inheritance. > > As I see it on a quick glance (just an idea), there must be > base-archetypes, a base archetype would represent the base class > structures, as you can find them now in the RM. > I think a new attribute would be needed to the CComplexObject-items. > It would be the attribute rmtype. > Like this > ITEM_LIST[archetype_node_id=at0001, rmtype="COMPOSITION"] matches ....... > etc etc > > This is no problem in using attributes because they are easy to query. > The kernel now also relies on the attribute archetype_node_id=at0001, > without any problem. this is certainly possible, but just making easy things needlessly hard in my view. You can do all this, or you can just use the reference model and get it all for free. > > >> >> Right now, displaying a time-series of heart rate v treadmill speed >> over 15 mins is dead simple in openEHR - the data structures are all >> there. Doing that in even 13606 requires: >> >> * defining reference archetypes for time-series data, where the >> events can have secondary state i.e. each event has a primary >> datum like heart rate, and 'state' data like exertion (treadmill >> speed) >> * writing software that knows how to transpose the Cluster/Element >> structures into a logical time-series, and figure out what is the >> main datum, what is the state, what are the widths of every event >> and so on >> o remember, there won't be any Java / Ruby / Python /.. classes >> to do this - you have to do it all manually. >> > > I don't understand why you bring up this subject. > > I stated a few times that OpenEHR is a fine information model, and > maybe there are some difficulties in EN13606, that may be true. > I also wrote that designing medical information models is not my > specialty. > So I will not easy say about an medical information model if it is > good or bad. I can only judge it on basic-design-rules. > > The point is that you don't have to choose if you use generic kernel. that's also easy to do with reference models. There are many reference models right here <https://github.com/openEHR/reference-models/tree/master/models>, to plug into a kernel. > 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. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140626/9ee5c074/attachment-0001.html>
