# Model CEN/TC251 13606

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2002-12-02 20:02 UTC
**Views:** 3
**Replies:** 9
**URL:** https://discourse.openehr.org/t/model-cen-tc251-13606/14445

---

## Post #1 by @system

Dear colleagues,

The last week I had a discussion with some colleagues of me at TNO\.
They studied the OpenEhr proposal for a model for the EHR\.

It is their opinion, and I agree with it, that the Kernel is not generic
enough because it contains things like the structure of the document
\(folder, transaction, etc\)
Even things like an organiser archetype must become a real archetype and be
not a part of the kernel\.

With regards,

Gerard

\-\-  <private> \-\-
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

\+31 252 544896
\+31 654 792800

---

## Post #2 by @David_Lloyd

Gerard

Several points:
1\.Specifically, openEHR proposes a number of Reference Models, supplemented by Archetype Models\.

2\. You seem to use the word 'Kernel' as a synonym for Reference Model\. If this is not so, please will you explain your use of the word Kernel?

3\. The Reference Models proposed by openEHR are just sufficient to meet the set of published requirements \(e\.g\. ISO 18308\) for an EHR and apply to \_any\_ EHR\. It is necessary to delineate various levels in the Architecture in order to be able to place Classes, Attributes, and Functions appropriately to meet the requirements\.

4\. The Reference Models are indeed generic, in the usual sense that they are not prescriptive about what \_information\_ must be in an EHR, but make possible the representation of all those kinds of information known to exist in \(or be necessary for future\) EHRs\.

5\. For each Reference Model there will be a corresponding Archetype Model \(only the Data Types Archetype model has so far been released\)\. Authors of actual Archetypes, conforming to the Archetype models, will be able to impose the required constraints of their domains to guide the construction of instances of EHRs\.

6\. To my way of thinking, everything about the Reference Models is \_generic\_\. Archetypes provide the means of using the models to construct EHRs for particular, i\.e\. non\-generic, domains\.

I hope this helps to resolve what appears to be a fundamental difference between us\!

With best wishes

David

---

## Post #3 by @Bruno_Frandji

Dear All,

I have had at last some time to look at your different messages and
contributions\.

I would like to say immediately that I deeply appreciate the open spirit and
the quality of the work done\. In fact it is impressive and therefore I felt
that before contributing myself I should have time to deeply analyse all
contributions and at the end I realised that I could not do it as
comprehensively that I would have wished\. So I will
take the risk of submitting a contribution knowing that maybe the questions
I
raise might already be covered in some message or document\. Nevertheless
that is the only way I could do it and I felt it would be a pity if I did
not try to bring to the group, experiences from 13606 implementation from a
RICHE/NUCLEUS/HISA culture in order to add to contributions coming from the
GEHR culture\.

My analysis of the proposal is that it adds to the current standard several
features including :
\- Archetypes modelling and communication, which is highly desirable for all\.
Recordcomponents, recordcomponents tree\-structure should be typable in a way
that can be modelled by users and transmitted from a system to another\.
\- Structural constraints to the EHR such as contributions, transactions,
mandatory folders wich is certainly highly desirable in a GEHR culture but
might not be in others, or so is the way I feel\.

In order to develop this topic I will enlight two chapters from the proposal
version 0\.2\.

In the proposal an overall principle is presented in chapter 2\.2\.2 :
? \(left hand side\) care events are conceptualised as "clinical sessions" in
which any number of "clinical statements" can be made\.
? Clinical statements can have their own internal structure \(temporal and
spatial\) and eventually data values \(shown in blue & black on the left hand
side\)\.
? Clinical sessions cause changes to be made to the EHR \(lower arrow\)
? \(right hand side\) each change is conceptualised as a "contribution", i\.e\.
a set of changes to existing content taking the repository \(the EHR\) to a
new, consistent state\.
? The EHR has an internal structure informed by:
1\. the structure of what is being recorded \(leading to "Entries"\)
2\. the need to organise this  \(leading to "Sections" and "Folders"\)

Also there is a chapter 2\.3\.6\.2 Recorder that I also copy here :
The notion of "recorder" has been a difficult one historically\. In the
current standard, it exists on the class Architectural\_component, implying
that any node in a tree of data could have a distinct recorder\. "Recorder"
is understood to mean the person or agent inputting the data to the EHR
system, leading up to the point of hitting a "Commit" button \(or calling the
equivalent API function\)\. The problem with the idea of distinct recorders,
or even a recorder distinct from the committer, is that there is no way for
the application via which data is being entered to know about different
people using a keyboard, mouse etc, or different agents acting through an
API, unless each one of these is separately authenticated in its own
explicit "micro\-session"\. This would require clinicians to type in PINs or
authenticate with a swipe card for each grain of information they create by
direct typing etc\. This seems highly unlikely, and as far as is known, no
EHR systems work like this\. The scenario in which multiple recorders seems
possible \- in an ICU situation \- also seems to be the least likely situation
in which carers would want to be wasting time re\-authenticating before
typing something on a keyboard, assuming they are interested in updating the
EHR at all, which seems quite unlikely\.
Note: the notion of "recorder" discussed here is distinct from that of
"information provider" which is understood as the actor \(person, device or
software\) who originates information\. In the candidate models, information
provider is  an attribute in the Entry class, allowing distinct "information
providers" at a fine\-grained level\.
Consequently, there appears to be no justification for a "recorder"
attribute anywhere\. However, it has been left in the Candidate A model for
the moment, pending further discussion in WG1 which may throw up a real
scenario in which it can be shown to be needed\.

Those two chapters may enlight the main problems I have with the proposal\.

The underlying paradigms included in these chapters appear to be very
primary care oriented\. In a primary care environment it makes sense to
record as the context of information the notion of "transaction" or
"contribution"\. It appears natural since the information is recorded through
a physician having in most cases the patient in front of him\. It is an easy
way to record and retrieve information in this case\. In a secondary care
environment, although this principle may certainly be possible to implement
since GEHR people have done it, it is much less "natural" since patient
information
is recorded from various terminals by different users in a large period of
time\. At least there is no reason to say things should be done only that
way\.
In a secondary care environment, notions like "sessions" hardly present an
interest since the system session linked to an EHCR system user may be
opened in the morning and terminated in the evening, even if systems offer
time\-out features\. Using session to represent temporal context appears
therefore to be poor\. Also contrary to what is stated, the notion that a
recorder of an information is difficult to identify in a secondary care
environment is not correct\. In a secondary care hospital you have to require
that any user is properly identified\. It is also necessary for
accountability purpose which is a strong requirement in several european
countries\. I did not find any major difficulty in implementing this\.

There are other ways to provide temporal and spatial contexts\. In a
RICHE/NUCLEUS/HISA culture the context of the entry is at least partially
provided by the notion of acts \(healthcare services or activities\)\. Every
provision of information is always done within the context of an act during
its life cycle where it may take different statuses \(established, demanded,
accepted, scheduled, in progress, completed for example\)\.

Using this paradigm there is no need to record things like sessions,
contributions, transactions\.\.\. Even folders should remain optional\. Using
this paradigm things like SCC that have little value in a GEHR\-based system
become useful\.

I have always thought that not all system providers need to deal with acts
although HISA implies it and it seems that people from HL7 feel otherwise\.
Indeed, including acts as well identified concepts in the standard would
bring a lot of value to systems and users\. It would allow to represent in
standard ways all the knowledge around act types\. But whether or not CEN
TC251
decides to do it, act\-based systems as well as GEHR\-based systems should be
supported by the new standard\.

I hope you find this contribution useful\.

Best Regards
Bruno Frandji

---

## Post #4 by @thomas.beale

Bruno Frandji wrote:

> Dear All,
> \.\.
> raise might already be covered in some message or document\. Nevertheless
> that is the only way I could do it and I felt it would be a pity if I did
> not try to bring to the group, experiences from 13606 implementation from a
> RICHE/NUCLEUS/HISA culture in order to add to contributions coming from the
> GEHR culture\.
>

I am delighted that you can make some time to contribute, because your experience and long\-term involvement will no doubt have something to teach us\.\.\.

> My analysis of the proposal is that it adds to the current standard several
> features including :
> \- Archetypes modelling and communication, which is highly desirable for all\.
> Recordcomponents, recordcomponents tree\-structure should be typable in a way
> that can be modelled by users and transmitted from a system to another\.
> \- Structural constraints to the EHR such as contributions, transactions,
> mandatory folders wich is certainly highly desirable in a GEHR culture but
> might not be in others, or so is the way I feel\.
>

so in the CEN proposal, we did not include the abstractions of EHR or CONTRIBUTION\. TRANSACTION is just the GEHR/openEHR name for COMPOSITION \(I hope that one day we will all use one name for this\)\. In openEHR, FOLDERs are optional in the EHR, although at least one "X\_FOLDER" \(extract folder\) is required in an EHR\_EXTRACT \(this could be made optional as well \- I never really thought about it\)\. In the CEN proposal, I thought our modelling of FOLDERs was conformant with the original CEN models\. However, Dipak and David have worked more with them than I have, so if there are errors, it may be my fault\.

> In order to develop this topic I will enlight two chapters from the proposal
> version 0\.2\.
>
> \.\.\.
>
> Those two chapters may enlight the main problems I have with the proposal\.
>
> The underlying paradigms included in these chapters appear to be very
> primary care oriented\. In a primary care environment it makes sense to
> record as the context of information the notion of "transaction" or
> "contribution"\. It appears natural since the information is recorded through
> a physician having in most cases the patient in front of him\. It is an easy
> way to record and retrieve information in this case\. In a secondary care
> environment, although this principle may certainly be possible to implement
> since GEHR people have done it, it is much less "natural" since patient
> information
> is recorded from various terminals by different users in a large period of
> time\. At least there is no reason to say things should be done only that
> way\.
> In a secondary care environment, notions like "sessions" hardly present an
>

we have to be careful here\. We used \(and this is my fault\!\) the term "clinical session", which I adapted from Alan Rector's paper on PEN&PAD\. Here is an extract:

"All chains begin with a time, place, agent \.  We call an agent at a place at a time a session and a patient as seen at a session is known as a contact\.   Our fundamental principle is that all statements in the medical record record are observations by agents at a particular place and time\.  Therefore, all descriptions in the medical record are required to begin with a session\.  "

\[from \- A Framework for Modelling the Electronic Medical Record AL Rector WA Nowlan S Kay CA Goble TJ Howkins
Medical Informatics Group, Department of Computer Science, University of Manchester,Manchester M13 9PL, England\]

I used the term "clinical session" rather than jsut session because the word 'session' also means a user logged in & authenticated on a computer\. So in openEHR we distinguish between "clinical session" as "a business activity by the health system, with, on or for, the patient"\. A "business activity" would normally be a billable unit of time, and may be an encounter \(patient present\), an intervention \(patient may be unconscious\), a pathology test \(patient not there at all\)\. There is no assumption about computers being present at all for a "clinical session"\. Whereas "session" means a user logged in on the computer system\.

There may be a better term than clinical session, but I haven't found it\.

> interest since the system session linked to an EHCR system user may be
> opened in the morning and terminated in the evening, even if systems offer
>

agree completely \- so I think the first thing to resolve is whether you understand "clinical session" in our principles as the same as "session" on a computer \- which it is not at all\.

> time\-out features\. Using session to represent temporal context appears
> therefore to be poor\. Also contrary to what is stated, the notion that a
> recorder of an information is difficult to identify in a secondary care
> environment is not correct\.
>

we aren't saying that it is difficult to identify people, jsut that it would be difficult to identify them within a single "session", i\.e\. the context of interaction with the computer which produces a Composition\. I\.e\. it would be difficult to separately identify distinct users modifying the one composition\.

> In a secondary care hospital you have to require
> that any user is properly identified\. It is also necessary for
> accountability purpose which is a strong requirement in several european
> countries\. I did not find any major difficulty in implementing this\.
>

but each user must have authenticated themselves before typing something? Are you saying that multiple people authenticated themselves and updated a single Composition before someone committed it?

> There are other ways to provide temporal and spatial contexts\. In a
> RICHE/NUCLEUS/HISA culture the context of the entry is at least partially
> provided by the notion of acts \(healthcare services or activities\)\. Every
> provision of information is always done within the context of an act during
> its life cycle where it may take different statuses \(established, demanded,
> accepted, scheduled, in progress, completed for example\)\.
>

This I have no problem with \- ENTRYs in openEHR and the CEN proposal are there to record one of the following:

\- retrospective, historical information \(usually called observations\)
\- thoughts on other observations, which in openEHR are called "evaluations" \(Rector and others call them "meta\-observations"\)
\- prospective information, which we call "instructions", and which contain "action specifications"

The last of these can have all the lifecycle states you mention\. We are still developing the semantics of this type, particularly on how it interacts with guidelines and decision support\.

> Using this paradigm there is no need to record things like sessions,
> contributions, transactions\.\.\. Even folders should remain optional\. Using
> this paradigm things like SCC that have little value in a GEHR\-based system
> become useful\.
>

Ah \- well, the concepts of contribution, transaction and folder are all information management concepts, they are not concepts from "reality", i\.e\. what is being recorded\. The idea is that, no matter what you record, it will live inside a standard framework of Transactions and Folders in a repository, and the repository will be changed in increments of Contributions\. If you think about it, these concepts are no different from a\) transactions in computer science \- many many systems use the concept of Transaction as the unit of modification, b\) folders in directory systems in computer operating systems for organisiing information, and c\) the idea of change requests or change sets in configuration management\. The concept of Contribution is the same as "change set" in configuration management, which is used in all version control systems and products\. None of these concepts is particular to health, but we have modelled them specifically so that their sematnics are clear\.

> I have always thought that not all system providers need to deal with acts
> although HISA implies it and it seems that people from HL7 feel otherwise\.
>

well, they think everything is an act, even a "document", while we think that everything is information, and we model explicitly the structure and context of recording it\.

> Indeed, including acts as well identified concepts in the standard would
> bring a lot of value to systems and users\.
>

we are considering adding an Act type to openEHR, as a subtype of Observation \- the meaning would be "act in the past"\. We already have "act specificaiton" i\.e\. "act in the future"\.

> It would allow to represent in
> standard ways all the knowledge around act types\. But whether or not CEN
> TC251 decides to do it, act\-based systems as well as GEHR\-based systems should be
> supported by the new standard\.
>

agree\.

> I hope you find this contribution useful\.
>

definitely \- and I am quite happy to continue to debate any of the above\. We think we have developed a model which describes things well, but there is no guarantee that our model is right, and it takes a dialectic process of argumentation to better the model\. But first of all, we need to understand our terms the same way\!

\- thomas beale

---

## Post #5 by @Mike_Mair

Dear Gerard, David

One definition of the GEHR 'kernel' is that of 'record engine'\. I wondered
what your view of the CDA was now in this role, after the Berlin CDA
conference? The succession of CDAs can be turned out by any suitably
equipped record system, and the CDAs used as a common currency for them\.
Sometimes these CDAs might not actually exist unless created for their
communicative role between systems, in which case they are virtual CDAs, and
the record engine entirely 'virtual'\. This substitutes a 'virtual kernel'
for the GEHR product, and does the same job of providing a communality of
process between participant record systems without the specifics of the GEHR
kernel, but it still would permit use of GEHR type components such as
archetypes\.

Regards

Mike Mair

---

## Post #6 by @Walter_Dierckx

Hello to you all,

I'm rather new in this discussion, but perhaps it is indicated to take a
look at the Belgian developments at
http://www.chu-charleroi.be/kmehr/htm/kmehr.htm.

This message format is accepted by the Belgian government as a standard for
clinical data exchange between healthcare actors\.

Kind regards,

Walter JC Dierckx, director
Logis Medical Systems
Antwerp \- Belgium\.

\-\-\-\-\-Oorspronkelijk bericht\-\-\-\-\-

---

## Post #7 by @system

Dear Mike,

What sets aside a document from a message?
What is recorded in q EHR system?

A document is the information a healthcare provider attests by signing it\.
It contains a set of information in a clear context\.

What is submitted in a EHR system has to be a set of documents, in my view\.

Next to the set of documents other information is part of the record: lab
tests, etc\.

In my view documents are persistent and reflect those parts of the recorded
and exchanged information that the healthcare provider attested\.
Documents are not virtual at all and always exist\.

Gerard

> Dear Gerard, David
>
> One definition of the GEHR 'kernel' is that of 'record engine'\. I wondered
> what your view of the CDA was now in this role, after the Berlin CDA
> conference? The succession of CDAs can be turned out by any suitably
> equipped record system, and the CDAs used as a common currency for them\.
> Sometimes these CDAs might not actually exist unless created for their
> communicative role between systems, in which case they are virtual CDAs, and
> the record engine entirely 'virtual'\. This substitutes a 'virtual kernel'
> for the GEHR product, and does the same job of providing a communality of
> process between participant record systems without the specifics of the GEHR
> kernel, but it still would permit use of GEHR type components such as
> archetypes\.
>
> Regards
>
> Mike Mair
>
> From: "David Lloyd" <d\.lloyd@chime\.ucl\.ac\.uk>
> To: <openehr\-technical@openehr\.org>
> Sent: Tuesday, December 03, 2002 8:40 PM
> Subject: Re: Model CEN/TC251 13606
>
>> Gerard
>>
>> Several points:
>> 1\.Specifically, openEHR proposes a number of Reference Models,
>
> supplemented
>> by Archetype Models\.
>>
>> 2\. You seem to use the word 'Kernel' as a synonym for Reference Model\. If
>> this is not so, please will you explain your use of the word Kernel?
>>
>> 3\. The Reference Models proposed by openEHR are just sufficient to meet
>
> the
>> set of published requirements \(e\.g\. ISO 18308\) for an EHR and apply to
>> \_any\_ EHR\. It is necessary to delineate various levels in the Architecture
>> in order to be able to place Classes, Attributes, and Functions
>> appropriately to meet the requirements\.
>>
>> 4\. The Reference Models are indeed generic, in the usual sense that they
>> are not prescriptive about what \_information\_ must be in an EHR, but make
>> possible the representation of all those kinds of information known to
>> exist in \(or be necessary for future\) EHRs\.
>>
>> 5\. For each Reference Model there will be a corresponding Archetype Model
>> \(only the Data Types Archetype model has so far been released\)\. Authors of
>> actual Archetypes, conforming to the Archetype models, will be able to
>> impose the required constraints of their domains to guide the construction
>> of instances of EHRs\.
>>
>> 6\. To my way of thinking, everything about the Reference Models is
>> \_generic\_\. Archetypes provide the means of using the models to construct
>> EHRs for particular, i\.e\. non\-generic, domains\.
>>
>> I hope this helps to resolve what appears to be a fundamental difference
>> between us\!
>>
>> With best wishes
>>
>> David
>>
>>> Dear colleagues,
>>>
>>> The last week I had a discussion with some colleagues of me at TNO\.
>>> They studied the OpenEhr proposal for a model for the EHR\.
>>>
>>> It is their opinion, and I agree with it, that the Kernel is not generic
>>> enough because it contains things like the structure of the document
>>> \(folder, transaction, etc\)
>>> Even things like an organiser archetype must become a real archetype and
>
> be
>>> not a part of the kernel\.
>>>
>>> With regards,
>>>
>>> Gerard
>>>
>>> \-\-  <private> \-\-
>>> Gerard Freriks, arts
>>> Huigsloterdijk 378
>>> 2158 LR Buitenkaag
>>> The Netherlands
>>>
>>> \+31 252 544896
>>> \+31 654 792800
>>>
>>> \-
>>> If you have any questions about using this list,
>>> please send a message to d\.lloyd@openehr\.org
>>
>> \*     David S\.L\. Lloyd, Technical Consultant
>> \*     CHIME \- Centre for Health Informatics and Multiprofessional
>> Education, at UCL
>> \*     E\-Mail:   d\.lloyd@chime\.ucl\.ac\.uk   Tel:      \+44 \(0\)20 7288 3364
>> \*     Web:  www\.chime\.ucl\.ac\.uk/\~rmhidsl\#contact
>>
>> \-
>> If you have any questions about using this list,
>> please send a message to d\.lloyd@openehr\.org
>>
\-\-  <private> \-\-
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

\+31 252 544896
\+31 654 792800

---

## Post #8 by @Mike_Mair

Dear Gerard

Something that persists and is attested may be called a document\. However
as we ascend the CDA level hierarchy \(levels 1 through 3\) and the CDAs
become 'template enhanced' \(to borrow Tom Beale's phrase\), they might be
thought of as a  more versatile than documents\. They will contain machine
processable data entities, such as archetypes\. Once the R MIM, HMD etc\.
processes are sorted out, they would serve as messages as well\.

The virtual CDA idea was introduced in a paper on
'Seamless Care and the CDA' at the Berlin CDA conference by  Timo Itälä and
Aino Virtanen \(see  http://www.hl7.de/cda2002/progoverz.html \) They say that
they
are implementing it for 40% of the population of Finland\. The CDAs are
evoked
on request, but need not otherwise exist\.

The hallmarks of the CDA are 'persistence, wholeness, stewardship, and
potential for authentication', and when taken together are the same as
'attestation'\. The commitment to turn out CDAs on demand implies a process
of attestation and persistence in the participant systems, but a CDA based
standard need not tell them how to do that\.

We might get further with a virtual kernel turning out CDAs, than with a
kernel that does have a
standard specification, but which is not widely adopted\. Its a less
ambitious
vision than the total EHR concept, and might itself only be stage on the
way, but it would be a start\.

Regards,

Mike Mair

> Dear Mike,
>
> What sets aside a document from a message?
> What is recorded in a EHR system?
>
> A document is the information a healthcare provider attests by signing it\.
> It contains a set of information in a clear context\.
>
> What is submitted in a EHR system has to be a set of documents, in my

view\.
>
> Next to the set of documents other information is part of the record: lab
> tests, etc\.
>
> In my view documents are persistent and reflect those parts of the

recorded
> and exchanged information that the healthcare provider attested\.
> Documents are not virtual at all and always exist\.
>
> Gerard
>
> > Dear Gerard, David
> >
> > One definition of the GEHR 'kernel' is that of 'record engine'\. I

wondered
> > what your view of the CDA was now in this role, after the Berlin CDA
> > conference? The succession of CDAs can be turned out by any suitably
> > equipped record system, and the CDAs used as a common currency for them\.
> > Sometimes these CDAs might not actually exist unless created for their
> > communicative role between systems, in which case they are virtual CDAs,

and
> > the record engine entirely 'virtual'\. This substitutes a 'virtual

kernel'
> > for the GEHR product, and does the same job of providing a communality

of
> > process between participant record systems without the specifics of the

GEHR
> > kernel, but it still would permit use of GEHR type components such as
> > archetypes\.
> >
> > Regards
> >
> > Mike Mair
> >
> > From: "David Lloyd" <d\.lloyd@chime\.ucl\.ac\.uk>
> > To: <openehr\-technical@openehr\.org>
> > Sent: Tuesday, December 03, 2002 8:40 PM
> > Subject: Re: Model CEN/TC251 13606
> >
> >
> >> Gerard
> >>
> >> Several points:
> >> 1\.Specifically, openEHR proposes a number of Reference Models,
> > supplemented
> >> by Archetype Models\.
> >>
> >> 2\. You seem to use the word 'Kernel' as a synonym for Reference Model\.

If
> >> this is not so, please will you explain your use of the word Kernel?
> >>
> >> 3\. The Reference Models proposed by openEHR are just sufficient to meet
> > the
> >> set of published requirements \(e\.g\. ISO 18308\) for an EHR and apply to
> >> \_any\_ EHR\. It is necessary to delineate various levels in the

Architecture
> >> in order to be able to place Classes, Attributes, and Functions
> >> appropriately to meet the requirements\.
> >>
> >> 4\. The Reference Models are indeed generic, in the usual sense that

they
> >> are not prescriptive about what \_information\_ must be in an EHR, but

make
> >> possible the representation of all those kinds of information known to
> >> exist in \(or be necessary for future\) EHRs\.
> >>
> >> 5\. For each Reference Model there will be a corresponding Archetype

Model
> >> \(only the Data Types Archetype model has so far been released\)\. Authors

of
> >> actual Archetypes, conforming to the Archetype models, will be able to
> >> impose the required constraints of their domains to guide the

construction
> >> of instances of EHRs\.
> >>
> >> 6\. To my way of thinking, everything about the Reference Models is
> >> \_generic\_\. Archetypes provide the means of using the models to

construct
> >> EHRs for particular, i\.e\. non\-generic, domains\.
> >>
> >> I hope this helps to resolve what appears to be a fundamental

difference
> >> between us\!
> >>
> >> With best wishes
> >>
> >> David
> >>
> >>
> >>> Dear colleagues,
> >>>
> >>> The last week I had a discussion with some colleagues of me at TNO\.
> >>> They studied the OpenEhr proposal for a model for the EHR\.
> >>>
> >>> It is their opinion, and I agree with it, that the Kernel is not

generic
> >>> enough because it contains things like the structure of the document
> >>> \(folder, transaction, etc\)
> >>> Even things like an organiser archetype must become a real archetype

and

---

## Post #9 by @thomas.beale

> Dear Mike,
>
> What sets aside a document from a message?
> What is recorded in q EHR system?
>
> A document is the information a healthcare provider attests by signing it\.
> It contains a set of information in a clear context\.
>
> What is submitted in a EHR system has to be a set of documents, in my view\.
>
> Next to the set of documents other information is part of the record: lab
> tests, etc\.
>
> In my view documents are persistent and reflect those parts of the recorded
> and exchanged information that the healthcare provider attested\.
> Documents are not virtual at all and always exist\.
>
> Gerard
>
I agree, but I also saw the presentation that Mike is talking about, and they do in
fact create virtual CDA instances whcih are made available via the web to give
users a virtual view of the EHR\. This is using CDA documents not even so much
as messages \(there is no new content\) but as web forms \- in other words, a
standardised view template for source data from difference systems\.

\- thomas beale

---

## Post #10 by @system

When information has to be exchanged between legal entities
\(organisations or persons\)
Then only attested and selected information can be exchanged using a
transaction type of exchange\.

Of course system integration, where one healthcare provider collects the
data stored by \(on on behalf of\) him from systems that he controls and is
responsible for, is allowed\. This type of 'virtual' use is NOT exchange of
information between legal entities\.

The Essential Requirements for the EHR that we are writing in my institute
make this strict distinction\. It is based on unpublished discussions between
healthcare providers and legal experts in Holland\.

Gerard

>> Dear Mike,
>>
>> What sets aside a document from a message?
>> What is recorded in q EHR system?
>>
>> A document is the information a healthcare provider attests by signing it\.
>> It contains a set of information in a clear context\.
>>
>> What is submitted in a EHR system has to be a set of documents, in my view\.
>>
>> Next to the set of documents other information is part of the record: lab
>> tests, etc\.
>>
>> In my view documents are persistent and reflect those parts of the recorded
>> and exchanged information that the healthcare provider attested\.
>> Documents are not virtual at all and always exist\.
>>
>> Gerard
>>
> I agree, but I also saw the presentation that Mike is talking about, and they
> do in
> fact create virtual CDA instances whcih are made available via the web to give
> users a virtual view of the EHR\. This is using CDA documents not even so much
> as messages \(there is no new content\) but as web forms \- in other words, a
> standardised view template for source data from difference systems\.
>
> \- thomas beale
>
\-\-  <private> \-\-
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

\+31 252 544896
\+31 654 792800

---


**Canonical:** https://discourse.openehr.org/t/model-cen-tc251-13606/14445
**Original content:** https://discourse.openehr.org/t/model-cen-tc251-13606/14445