Link between goals and other clinical concepts

Clinical (archive)
41

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.

42

the problem with this dictum is that it doesn’t work as an Occam’s razor, which is what you need - i.e. objective criteria for making the decision. The criterion I developed in 2000 or so, to determine what should be in an RM underpinning archetypes was:

43

Sorry to respond so late, it was my birthday, yesterday. 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

44

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?

Hi Diego, I tend to agree on this. Because if you want a stable data-definition, you must be prepared for changes in thinking.
There will, however, always be some basic structures left.

A medical information model must be patient/EHR centric. All data must belong to a patient.
This is typical for an information system for storing medical data.

13606 was not such a system. 13606 is, in my opinion, in fact Composition-centric
(and a not archetypeable demographic section, I don't understand the purpose of that).

13606 was a message format, and demographic data (if medical relevant to a specific Composition) should be an entry of a Composition.
The patient, a number in the EHR-Extract was just a carrier of related medical circumstances.
An EHR-message was, per definition limited in scope.
The scope was a medical circumstance that was wished to communicate, together with the patientID in which this circumstance lived.

I believe, I have heard, this is going to change. 13606 will become an information system for storing medical data with a minimalistic structure.

Since quite some time, I implemented a multiple RM-kernel.
Now I see, it is also because it can be used to serve several different medical information structure philosophies, as long as they are Patient Centric.

13606 will have a more important role because of its minimalistic structure.
Organizations which want to implement information-standards now have tooling and a minimalistic Reference Model to do so.
For some ideas, 13606 will not fit, and a new Reference Model will need to be written.

I think that the Reference Model will loose some of its status.
Was it before the foundation of a software-structure, with a lot of classes to support, it now becomes more and more just an interchangeable information definition.

Now the LinkEHR editor change to RM-pluggable editor, and we have a complete new medical information use.
The customer, not depending on the vendor, can create or choose an information model.

We'll see if this is true, and if, where it ends.

Bert