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