Bert,
A starting point might be the distribution of your ten (or more) issues to Tom and myself.
Edgar
Interesting subject in this email. But it came through
Issue 1:
Bert Verhees wrote:
Interesting subject in this email. But it came through
Issue 1:
-----------------------
The use of in many programming languages reserved words in the HL7 datatypes.
I am talking about the datatypes: Set, Array.
-----------------------
Hi Bert,
almost all the issues you mention in this thread are actually due to the HL7 data types, which CEN unfortunately decided to adopt/adapt a long time ago. Tom Marley and others have struggled to find an version of them which a) remains faithful to the idea of HL7 bu b) fixes some problems, like strange inheritance. Personally, I am much more straighforward;-) I don't find the HL7 data types a good design at all, generally, and have made available the reasons in various standards discussions, along with many others who have pointed out the same problems (such as you are now doing). The result of this recently has been:
- an new ISO work item called "data types for clinical informatics" (or something very close to that), whcih will recognise 3 layers: inbuilt types (like in ISO 11404), general purpose clinical types (specified from requirements), and a 3rd layer for bindings to particular model systems, such as HL7. THis work would avoid name clashes and other problems prevalent in the HL7 data types. The part 3 should be part of the HL7 ISO standard, not the ISO data types standard (for reasons of sensible managing dependency, and just out of relevance), but HL7 of course wanted to put its specifications in the main new standard.
- CEN is now in a position of having to determine what the data types should look like for EN13606. In theory, they should be part 2 of the standard-to-be I mention above.
In practice, the data types required for EN13606 is not a hard problem. The total list for all structural attributes is as follows:
- string (= ISO11404 CharacterString)
- date_time (in ISO11404)
- object_identifier (in ISO11404)
- boolean (in ISO11404)
- a multimedia type (probably = an Array<Octet> in 11404)
- coded_text (not in 11404)
No substitutability is needed as far as I remember. So this list is very short, simple, and available in any object-oriented language. (Personally my recommendation to CEN is to define a set like this as the structural datatypes right now, taking them from layer 1 of the new ISO standard, which is more or less ISO11404. only the CodedText type needs to be added. This could be done easily, and while avoiding the problems of the HL7 CD etc types, such as qualifiers.)
The next set of data types that is required is those which inherit from DATA_VALUE, which is the type of ELEMENT.value. This list is a lot longer, and has substitutability rules:
- Date, Time, Duration, Date_time
- Partial dates and times
- Text (with language)
- Coded Text
- Quantity, Quantity Ratio, Quantity Range, Count
- Identifiers of real world entities
- Boolean/Bistate
- State
- Ordinal
- Time specification
- Uri
- Encapsulated Multimedia
- Parsable
This is the list of types I would see being developed as part 2 of the new work item in ISO. For the moment, openEHR has a pretty reasonable list of types which correspond to these, which could be used, although that would be up to CEN to decide.
It is in some popular languages not possible to use some words to define your own datatypes, or parts of the datatypes.
This makes it impossible to use the standard in that language as it is.A standard should be platform-independent (OS, programming-language), that is why I think it is an important issue
I worked around the issue by naming those types: HL7Set, HL7Array, and for consistency, I named the other Collection-types also HL7... (HL7Bag and HL7List).
That is about what you have to do for the moment, in in fact, in part 3 of the new ISO standard, where there will be an HL7 binding, such names will have to be used.
- thomas beale
Bert,
The HL7 II data type has the "assigningAuthorityName" so you can identify
the insurance company for example.
Thanks,
Amnon.
Bert Verhees
<bert.verhees@ros
a.nl> To
Sent by: Edgar Glück <edgar.gluck@kith.no>
owner-openehr-tec cc
hnical@openehr.or t.marley@salford.ac.uk,
g openehr-technical@openehr.org,
g.freriks@pg.tno.nl, "kay s"
<s.kay@salford.ac.uk>,
25/05/05 10:36 per-arne.lundgren@skane.se, "Gunnar
Klein" <gunnar.klein@sis.se>,
inger.wejerfelt@vgregion.se
Please respond to Subject
openehr-technical Issue 2
I also think that there is a need for a more concrete II class. Some countries have a “national id” for every inhabitant and I think that many local systems manage patients using this id. Also through insurance number or EHR number (inside a hospital). How to distinguish every kind of identifier for example at “id” attribute (SET type) in SubjectOfCarePersonIdentification?
Regards
Bert,
The HL7 II data type has the "assigningAuthorityName" so you can identify
the insurance company for example.
Thanks,
Amnon.
But what if you do not want to know the name of the company, but only wnat to
know the type of the identifier.
F.e. in the Netherlands it is sufficient to provide a bankaccount-number when
wanting to do a money transfer. You do not need to know the name of the bank.
And a bank can also be an insurance-comapny, so the assigningAuthority tells
me nothing about the type of the number.
Bert
Bert,
The HL7 II data type has the "assigningAuthorityName" so you can identify
the insurance company for example.
Thanks,
Amnon.
An application which has to find out which II in a list is the
insurancecompany needs then to know in what business a assiginingAuthority is
in, this puts a burden on the application(-developer), which should not be
there, which is inconvenient, and even can cause unresolvable problems
Bert
Thom,
and Tom,
It would be nice when CEN could agree with you about the data types needed for EN13606.
But twe can’t forget the GPICS and the refferal message standard.
Gerard
– –
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
+31 252 544896
+31 654 792800
Hi all,
the exercise of medicine is an art.
This is not an exact science as the physics.
With the biology, the anatomo-pathology, the x'ray explorations and R.M.Imaging,
the physician gets information that are validated.
They are validated because there was physical signal registration that was
digital, pictures in RMI. These pictures, as blades of microscope, can be
reread, in the time by other physicians.
They have a statute of data validated by the physician and therefore publishable
in the file of cares of the sick.
The diagnosis makes by the physician is the result of a reasoning, from one
wholes of information that it to on his patient. One teaches it to students
future physicians.
The diagnosis is sometimes fast, but often it asks for a delay of several days
weeks or years!! or never !!
Hypothéseses, elaborate by the physician, are only some likely, probable
information.
In France, there is an agreement to say that it is about " personal " Notes
that are not validated.and what are the property of the physician.
They are not therefore publishable and especially no opposable in judicial
procés case.
In short according to Shannon (theory of information), too much information, no
precise, mask the good information to take a decision.
Distressed for my English!!
Dr R LONJON
France
Hi Dr R LONJON,
This response pertains to:
"...
In short according to Shannon (theory of information), too much information, no precise, mask the good information to take a decision.
..."
REFERENCE (Shannon Information): http://www.iscid.org/encyclopedia/Shannon_Information
"...
concerned with quantifying information (usually in terms of number of bits) ...
as they are communicated sequentially from a source to a receiver ...
The amount of ...information contained in a string of characters is inversely related to the probability of the occurrence of the string
...
Shannon information is solely concerned with the improbability or complexity of a string of characters rather than its patterning or significance
..."
REFERENCE (Complexity): http://www.iscid.org/encyclopedia/Complexity
"...
often used to describe single systems made of multiple interacting parts. However,
... can be used for a large variety of applications
...* *Computational ... Time ... Space ... Kolmogorov (algorithmic) ... Connectivity ...
Descriptive/Interpretative ... Functional
..."
Decision Theory (e.g., http://www.answers.com/topic/decision-theory) would be more appropriate.
Once Healthcare-related information is available to a Practitioner one enters an environment in which
the types of decisions made and the content upon which they are based are outside of
Communications Theory (see Decision Theory Reference). Rarely is there 'too much' information.
A more important issue is Upon which portion of the available information, or all of it, should a
decision be based?
Regards!
-Thomas Clark
Dr LONJON Roger wrote:
However, in my opinion, one can have too much data. Information, by
definition, is more than data and conveys something understandable and
useful that was not known before. Information deals with raising entrophy.
Long story short, designers of systems need to undersatnd the difference in
data and information - ands, ideally, provide just what is needed when it
is needed to address the circumstances of the situation.
Ed Hammond
"lakewood@copper.net"
<lakewood To: openehr-technical@openehr.org
Sent by: cc:
owner-openehr-technical@ Subject: Re: Issue 1
openehr.org
05/28/2005 10:47 PM
Please respond to
openehr-technical
Hi Dr R LONJON,
This response pertains to:
"...
In short according to Shannon (theory of information), too much
information, no precise, mask the good information to take a decision.
..."
REFERENCE (Shannon Information):
http://www.iscid.org/encyclopedia/Shannon_Information
"...
concerned with quantifying information (usually in terms of number of bits)
...
as they are communicated sequentially from a source to a receiver ...
The amount of ...information contained in a string of characters is
inversely related to the probability of the occurrence of the string
...
Shannon information is solely concerned with the improbability or
complexity of a string of characters rather than its patterning or
significance
..."
REFERENCE (Complexity): http://www.iscid.org/encyclopedia/Complexity
"...
often used to describe single systems made of multiple interacting parts.
However,
... can be used for a large variety of applications
...* *Computational ... Time ... Space ... Kolmogorov (algorithmic) ...
Connectivity ...
Descriptive/Interpretative ... Functional
..."
Decision Theory (e.g., http://www.answers.com/topic/decision-theory)
would be more appropriate.
Once Healthcare-related information is available to a Practitioner one
enters an environment in which
the types of decisions made and the content upon which they are based
are outside of
Communications Theory (see Decision Theory Reference). Rarely is there
'too much' information.
A more important issue is Upon which portion of the available
information, or all of it, should a
decision be based?
Regards!
-Thomas Clark
Dr LONJON Roger wrote:
Hi all,
the exercise of medicine is an art.
This is not an exact science as the physics.
With the biology, the anatomo-pathology, the x'ray explorations and
R.M.Imaging,
the physician gets information that are validated.
They are validated because there was physical signal registration that was
digital, pictures in RMI. These pictures, as blades of microscope, can be
reread, in the time by other physicians.
They have a statute of data validated by the physician and therefore
publishable
in the file of cares of the sick.
The diagnosis makes by the physician is the result of a reasoning, from
one
wholes of information that it to on his patient. One teaches it to
students
future physicians.
The diagnosis is sometimes fast, but often it asks for a delay of several
days
weeks or years!! or never !!
Hypothéseses, elaborate by the physician, are only some likely, probable
information.
In France, there is an agreement to say that it is about " personal "
Notes
that are not validated.and what are the property of the physician.
They are not therefore publishable and especially no opposable in
judicial
procés case.
In short according to Shannon (theory of information), too much
information, no
What information consumes is rather obvious: it consumes the attention of its recipients. Hence, a wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.
-- Herbert Simon, economist --
Maybe the amount of Entropy (disorder) is reduced by information but
increases by too much data? I agree that one should be offered the
information that one needs at a given time but that implies that one can
define the scope in the information request,
Best wishes
Nick
Not necessarily - it is the 'stuff' that surrounds information that gives
meaning. Reduce too far and information loses its context and is at risk of
being meaningless information - a blood pressure of 120/80 is meaningless
unless context is supplied? Ape, human, earthworm about to explode!
To portray a human in digital form will require massively increased metadata
and context to relay what might have taken a 2 second glance from an
experienced clinician eg jaundice, death, fractured hip.
There are no simple routes but many doors we have yet to open and courage to
enter.
David Downunder
The message did not appear on the list at first send, so I try again
Bert
What information consumes is rather obvious: it consumes the attention of
its recipients. Hence, a wealth of information creates a poverty of
attention and a need to allocate that attention efficiently among the
overabundance of information sources that might consume it. -- Herbert
Simon, economist --
Two things
First: The subjectline of this thread does not anymore reflect its contents,
the contents-subject has changed, please change the subjectline too(, or
start a new thread).
Second: It is the responsibility of the applicationbuilder/designer to choose
which information should be presented in which way. The underlying objects
have nothing to do with the presentationlayer, except that they at minimum
should support the requirements. One can never predict for what
purpose/application/public the objects ever will be used.
kind regards
Bert Verhees
Hi Ed,
One needs to distinguish between System Designers and Application Designers and both can be
subdivided further, e.g., Fault-Tolerant. System Designers 'handle' the data and information;
Application Designers 'handle' the content.
Understanding the difference between data and information is required for both and each has to
be aware that some of the data and information may not be present for their consumption, perhaps
a majority may be destined for others. A simple analogy is a communications technology, e.g.,
Fibre Channel networking, in which the data in packets are subject to further structuring beyond
the current node. Some of the data can be 'local' and the remainder for remote users.
The System/Application Designer retrieves the data, and information, required to perform their
tasks and passes the remainder on. Good design includes data/information modification to
indicate later that the access has been made.
In some cases additional data, and information, is added to indicate that the data, and information,
has reached the current node or another event has occurred, e.g., errors reported. The original
data is left undisturbed. Such features are desirable, for example, in Fault-Tolerant Networking.
An EHR-based system serves many users with different requirements and often little contact
between groups of users, e.g., General Practice, Surgery, Mental Health, Public Health and Dental.
For whatever reason a record is created, by whom and within an environment it is a container
that users can add information but never delete information (persistent monotonically increasing).
If at some point a user is moved to consider the content useless they should be able to create
their own 'container' and link it to the original. 'Link' is very important since to do otherwise
would produce chaos quickly.
An EHR-based system compared with my paper-based Healthcare record (well over 100
pounds at present) shows the same separation of disciplines, e.g., GP enters their data, the
Surgeon theirs, the Therapist theirs and the Emergency Room theirs, each reminding me
it is my responsibility to inform the others of the results. All their 'data' end up in the same
bin, i.e., my paper file.
I often wondered why they would not or could not read each others reports until I tried to
read them myself. I then realized why Attorneys have to summarize medical records and
threaten to introduce the medical records into the court records.
One could say that it is 'too much information' and one would expect to be prevented in
Court from having a GP review and analyze the report from a Brain Surgeon, but in no
way would one be allowed to 'edit' even their own historical record.
My suggestion is to take what you need from the record, but be sure to take everything
you need, and move on. Practitioners can't end up as Data/Information Editors.
In creating records follow a set of rules that include 'error on the side of excessive
reporting' and ignore potential future comments. Going back to 'fix' the record is really
not a good idea.
Recall one difference between paper-based records and Electronic Records: the time
interval associated with data capture and recording is a lot shorter and hence reduces the
amount of time available to reflect on what you are doing.
Apart from the 'System/Application Designers' attempt to incorporate redundancy into
a records system to enhance recoverability in the presence of hardware failures and
software errors, extraneous record data in the opinion of a Practitioner rarely harms
them. If it becomes an issue them a discussion with others associated with the record
might relieve some tension.
A better approach might be to focus on the accuracy and precision of the data, and
information, that a Practitioner retrieves from the record.
Regards!
-Thomas Clark
William E Hammond wrote: