Archetype ontology

[Gerard Freriks]

Sam,

There is a difference between looking at various screens during a
consultation and the signing of part of the information that needs to be
signed. E.g. Orders, communications with others.

It is clearly not necessary to make movies of what was presented on the
screen during the consultation.

Gerard







On 16-09-2002 01:45, "Sam Heard"  wrote:

> Karsten
> 
> I do not go with the screen shot idea - the issue here is the accountability
> and if the information is stored in an explicit manner and the rendition can
> be stored (XSLT or application) then it will be clear what the person saw -
> the problem with screenshots is the plethora of views that might be used in
> a single consultation. And can we be sure that the screen was paged down?
> And what was the resolution of the screen - and the visual acuity of the
> practitioner - and what parts of the screen did their eyes stray to...
> 
> Our research in GEHR had a clear outcome - clinicians did not want this sort
> of EHR and it served no useful purpose.
> 
> Cheers, Sam
> 
> Dr Sam Heard
> The Good Electronic Health Record
> Ocean Informatics, openEHR
> 105 Rapid Creek Rd
> Rapid Creek NT 0810
> Ph: +61 417 838 808
> sam.heard at bigpond.com
> www.gehr.org
> www.openEHR.org
> __
> 
> 
> 
>> -Original Message-
>> From: Karsten Hilbert [mailto:Karsten.Hilbert at gmx.net]
>> Sent: Saturday, 14 September 2002 5:49 PM
>> To: Gerard Freriks
>> Cc: Melvin Reynolds; Thomas Beale; William Hammond; Sam Heard;
>> Openehr-Technical
>> Subject: Re: Archetype ontology
>> 
>> 
>>> So an EHR is a series of signed, authored messages that can be used in
>>> court. Without the fulfillment of the requirements, the EHR is
>> nothing but
>>> information written in the sand before a wave of the sea washes it away.
>> This is, however, the way medicine worked for thousands of
>> years, and reasonably well, obviously. It is trust that
>> defines the doctor-patient relationship, not proof.
>> 
>>> What an application does with the information on a screen and in its
>>> database is much less relevant from a legal perspective.
>>> What is signed is relevant.
>> Are you suggesting applications should store digitally signed
>> screenshots ?
>> 
>> Regards,
>> 
>> Karsten Hilbert, MD
>> GnuMed i18n coordinator
>> --
>> GPG key ID E4071346 @ wwwkeys.pgp.net
>> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
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 at openehr.org

openEHR "Silver" Model

[Gerard Freriks]

Hi,



My personal thoughts are:


This discussion is trivial.

CEN decided to:
- renew the ENV 13606
- use the two model approach
- produce a standard that can be used to produce: messages, documents and
implementable objects

My preference is the platinum model :-)
But I go for the gold one.

And as long as we can show that one is able to map to the silver one or the
bronze one, I see no problem. Mapping means that we are able to produce an
Archetype that fulfils  the requirements of all those models.

A consequence of the decision taken by CEN is that the Kernel (including the
data types) plus the Archetype model must be stable and as complete as
possible. The various degrees of granularity (that equals the number of
concepts and equals the number of archetypes and complexity of it) will be
outside of the control of the standardisation organisation. It will be in
the hands of the domain experts/user communities.
Each user community that wants to exchange information will use the Kernel
and Archetype Model plus the set of agreed archetypes it needs to use.

So we must provide all proponents of the bronze and silver options
archetypes that fulfil their requirements.

My option is the Patinum one ;-)


Gerard

Ps:
A likewise argument can be made for the data type problem.
We have the PT41 proposal, the HL7 one and the OpenEHR one.

Possibly we have to show that all three are mappable and therefore equally
correct and interchangeable.

On 17-09-2002 05:48, "Andrew Goodchild"  wrote:

> 
> Hi All,
> 
> I know this is probably a very politically sensitive topic, but I am
> wondering what the path forward for harmonization of openEHR with CEN
> 13606.  I was talking to Peter Schloeffel yesterday and Peter mentioned
> that there are three options:
> - the "bronze" option, which involved fixing a couple of things in the
> existing CEN model and adding archetypes to it.
> - the "silver" option, which simplifies and modifies openEHR and uses that
> as a basis for the new CEN model
> - the "gold" option, which uses the full openEHR model as the basis for
> the new CEN model
> 
> Peter also mentioned to me that it was highly likely that the "silver"
> option would be the most successful.
> 
> My question to the list is, what would you simplify or modify in the
> openEHR model?
> 
> My gut feeling is to remove everything not required by ISO 18308, but I am
> not sure what that would entail or the side effect of that.
> 
> Any thoughts?
> 
> cheers, Andrew
> 
> _-_|\Andrew Goodchild
> / *   DSTC Pty Ltd
> \_.-._/   Brisbane, Australia
> vhttp://staff.dstc.edu.au/andrewg/
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Gerard Freriks]

come fascinated with the discussion over how best to
>> balance the needs of the various parties involved in the provision and
>> payment of healthcare services so as to improve the quality and
>> decrease the cost of health care here in the U.S..  Talk about a
>> non-trivial problem!  Interestingly, it looks to me like all
>> the nonsense can be traced back to the health record and some
>> fundamental questions about who owns it, who controls access to it,
>> etc.  Thanks again for sharing.  Hope to hear from you soon.
>>  
>> Best regards,
>> Bill
>>  
>> 
>> - Original Message -
>> From: Sam Heard <mailto:sam.heard at bigpond.com>
>> To: Bill Walton <mailto:bill.walton at jstats.com> ;
>> openehr-technical at openehr.org <mailto:openehr-technical at 
>> openehr.org>
>> Sent: Wednesday, April 23, 2003 6:10 PM
>> Subject: RE: openEHR security
>> 
>> Bill
>>  
>> Security and the EHR - ah theres a question! At least having a
>> reference model of the EHR makes this something that might be
>> tackled effectively. The current openEHR model has and access
>> control feature on ARCHETYPED in the Common Reference Model. The
>> idea being that anything that can be archetyped - that is, it is a
>> coherent clinical composition or concept - can have its access
>> controlled.
>>  
>> It is envisaged that the EHR will have an access control list
>> which can be transfered to other centres as part of an extract if
>> required. This requires standardisation of access control groups.
>> We have done some work in Australia to get a set of access groups
>> that could be standardised across health care and I enclose a copy
>> of this document for your consideration.
>>  
>>     Hope this is a start - very interested to work with you on this!
>>  
>> Cheers, Sam
>> 
>> -Original Message-
>> From: owner-openehr-technical at openehr.org
>> [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill
>> Walton
>> Sent: Thursday, 24 April 2003 7:36 AM
>> To: openehr-technical at openehr.org
>> Subject: openEHR security
>> 
>> I apologize for not having had the time to dig in and find
>> this out for myself yet, but I'd really appreciate it if
>> someone could tell me if security has been addressed in the
>> openEHR architecture and, if so, point me to the
>> documentation.  I'm trying to understand the system's
>> capabilities to limit access not only to authorized
>> individuals, but also to limit the access of authorized
>> individuals to specific subsets of an individual's record.
>> Thanks in advance for showing me where to dig.
>>  
>> Best regards
>> Bill
>> 

--   --
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 at openehr.org

GEHR philosophical background info

[Gerard Freriks]

On 2003-04-29 3:44, "Thomas Clark"  wrote:

> Hi Paul,
> 
>
>
>
> You are very right concerning the involvement of judges and attorneys. The
> legal issues must be handled up front.
> 
> -Thomas Clark
>>>>>

Yes.
The problem is that in Europe, the USA, Canada, Australia, etc,  there are
many legal systems.
One generic solution that will fit all will be difficult.

The problem is intractable because it is a problem with at 5 degrees of
freedom, if not more.

In order to solve this we need discussions on:
Descriptions of contexts,
Type of infrastructure (pull/push, federation/messaging, MAC/DAC, the level
of social (persons) control versus the dependency on technology for control,
etc,
What is stored in the audit-log,
Scenario's / use cases.

And then we can have nice discussions as I read now on this list.

One solution is to assume for the discussion the existence of a Service next
to the EHR service that will control access. And that the EHR service is
completely ignorant and passive for this Access Service to operate. Then
each country (legal jurisdiction) is able to handle its own context.
And we all can use the same standard for the EHR.
The Access Service will act as 'firewall' and has all the responsibilities
for granting access.

Personally I favour this simplistic approach.
But I know there are two major contexts:
- within a legal entity
- between legal entities.
In an institution there can be a mix of these two.

Within a legal entity I will depend on social measures and therefore audit
trails for security. For this solution we need a set of agreed rules plus a
discussion on the content of the audit-trail.
Between legal entities information can only be exchanged when a person
consciously accepts responsibilities for a set of information to be shared
for a specific purpose with a specific set of other persons. The provisions
for exceptions need to be spelled out completely. Here again the audit-tral
and a set of rules are needed. But foremost it must be one person that takes
full responsibility.
As you can see I try to solve the problem by not depending to much on
informational facilities in any EHR. But I will depend on the audit-trail
where will be recorded what was published and what was accessed by whom, for
what purpose, etc. This is not part of the EHR.

The reason why I'm suggesting this way of solving the problem is:
- the problem of access control is about handling responsibility and proof.
Only persons can be held responsible
- Access control easily assumes that the evaluation of Identity, Role,
Participation, the trustworthiness of information (or sets if information)
are constants of time. All are not constant at all over time. Therefore we
can not rely on machines to operate on values judgements (rules) from the
past. But we need judgements made by responsible persons as a reaction to a
request by an other responsible person as much as possible.




Gerard




--   --
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 at openehr.org

Encoding concept-relationships in openehr archetypes.

[Gerard Freriks]

Hi,

Is it?
Is it about how to represent the domain "normal values"?

Or is it more general: Are concepts related?
Then the problem is: what relations are there between concepts (archetypes)?
What semantics of these relationships between archetypes (concepts) do we
need to describe reallity (including decision support)?

Gerard



On 2003-08-04 5:38, "Thomas Beale"  wrote:

>> Admittedly, I'm slipping into the realm of decision support, but I think it
>> really is simply the structure of the domain of normal values in this
>> specific
>> application.  I'd like to use archetypes to represent this, just as a I might
>> use them to represent the min and max of a given quantity.  Is the capability
>> all there already?  If not, what's missing?
>> 

--   --
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 at openehr.org

certification and verification of OpenEHR

[Gerard Freriks]

Dear Chris,

CEN/TC251 is co-operating with OPENEHR.

We are in the process to define a next version of our EHR standard.
It is basicly a standard that defines a Document and facilities for handling
it properly. Plus it will enable to locate doucment items in space and time.
On top of this the standard (EN136060) will include Archetypes.
With these archetypes all kinds of clinical concept models can de defined by
national, loca', regional organisations.

Where appropiate the Archetypes will be able to use items like SNOMED-CT.
And record coded information. The Archetype (=clinical concept model)
The Archetypes need a stable set of archetype-fragments that define for
instance the demographics of persons and organisations, but also the generic
structure of a referral letter,the generic investogation, etc.

We at CEN think it is a tractable problem.
And the people from OPENEHR have demontrated that it is in several beta
implementations.

I can refer you to the OPENEHR website and the CEN one (www.CENTC251.org)
for kore information.


Gerard

On 2003-08-04 16:51, "Christopher Feahr"  wrote:

> In my view, the EHR effort... partly by virtue of the inclusion of the
> "record" concept... is starting at too complex a level... at a point
> where we are almost designing a particular business management system in
> the standard.  A rule-free standard model for the INFORMATION should
> exist first.  From what I understand, SNOMED CT is a very good start on
> that.  Also as a standard, we should make an effort within each care
> domain to model the actors, places, and things in healthcare, the
> relationships between them that are always true, and the relationships
> among the information elements that are always true.  This can serve as
> a useful framework or high-level model for the much more granular and
> often unique process and information models of each local
> user-enterprise.

-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

HISTORY DATA SET IN EPR

[Gerard Freriks]

Hi,

As a GP with 20 years of experience in the Netherlands I learned that free
text plus a not to complicated set of codes (ICPC) is sufficient for daily
practice. We could generate automatic advice for medication based on
complaints or diagnosis.

ICPC contains roughly 2000 complaints, diagnoses and procedures.
It will cover 80% of every thing a GP will encounter during the day.

The provision of medicine is an art.
The registration of all medical (and other) relevant facts and findings is
retelling the story of the pati?nt. It is a narritive process.
Have we ever seen a piece of literature completely written in complex codes?

The study of Archetypes (see the OpenEHR website) will reveal that
Archetypes plus free text plus codes will enable future physicians a lot of
flexibility and expressive power.
Much of the flexibility will depend on the ontology (medical knowledge and
knwoledge of the world) behind the scenes.

And bye the way.
In the R&D facility where I work we have a very powerfull tool for analysis
of free text. Recently a lot of progress has been been at this.
If the free text is 'enriched' with Archetypes this process of meaningfull
data extraction will become much more easy.

Gerard Freriks

-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800




--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: "Christopher Feahr" 
> Organization: Optiserv Consulting
> Reply-To: "Christopher Feahr" 
> Date: Mon, 11 Aug 2003 07:32:52 -0700
> To: "Thomas Clark" 
> Cc: "Karsten Hilbert" ,
> 
> Subject: Re: HISTORY DATA SET IN EPR
> 
> Presently, each doctor and EMR software vendor is cooking up his own
> shorthand-language, and I'm suggesting that information should be
> reduced as much as possible to a standard set of codes.

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Free text analysis

[Gerard Freriks]

Dear colleagues,

This 'free text analysis tool' is a commercial product that will analys
"free text".
Ontologies, archetypes are of importance to increase further its analysis
capabilities.

So I must disappoint you the tool is not free.
But the use of archetypes as being specified in OpenEHR are important.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: Conrado Vi?a 
> Date: Wed, 20 Aug 2003 00:50:47 -0300
> To: "Gerard Freriks" 
> Cc: 
> Subject: Free text analysis
> 
> Hi All,
> I would like to ask Gerard Freriks to post some more information on the tool
> for free text analysis he mentioned.
> 
> I think there is an influence on any EHR schema (even when built with
> archetypes) by the way chosen to retrieve the particular fragment of
> information. I also think archetypes could play an important role on future
> health-related free text analysis. That's why I thought my request was valid
> for a post.
> 
> Since this is my first message to the list I think it appropriate to
> introduce myself (just a warning so I don't bore busy people with the rest
> of the e-mail)
> 
> I'm a Systems Analyst working on an academic project for our country's main
> public hospital ("Hospital de Cl?nicas", Uruguay).
> Our work deals with the retrieval, analysis and integration of Epileptic
> patients clinical data. We evaluated the use of openEHR some months ago, but
> found too little empirical proof of its adequacy... :(
> We don't have our web page finished yet, and the first version is going to
> be in Spanish only, but I could send or post information on it when it's
> done, if I receive any request.
> 
> Best Regards,
> 
> Conrado Vi?a
> 
> 
> -Mensaje original-
> De: owner-openehr-technical at openehr.org
> [mailto:owner-openehr-technical at openehr.org] En nombre de Gerard Freriks
> Enviado el: lunes, 11 de agosto de 2003 19:36
> Para: Christopher Feahr; Thomas Clark
> CC: Karsten Hilbert; openehr-technical at openehr.org
> Asunto: Re: HISTORY DATA SET IN EPR
> 
> 
> Hi,
> 
> As a GP with 20 years of experience in the Netherlands I learned that
> free text plus a not to complicated set of codes (ICPC) is sufficient
> for daily practice. We could generate automatic advice for medication
> based on complaints or diagnosis.
> 
> ICPC contains roughly 2000 complaints, diagnoses and procedures. It will
> cover 80% of every thing a GP will encounter during the day.
> 
> The provision of medicine is an art.
> The registration of all medical (and other) relevant facts and findings
> is retelling the story of the pati?nt. It is a narritive process. Have
> we ever seen a piece of literature completely written in complex codes?
> 
> The study of Archetypes (see the OpenEHR website) will reveal that
> Archetypes plus free text plus codes will enable future physicians a lot
> of flexibility and expressive power. Much of the flexibility will depend
> on the ontology (medical knowledge and knwoledge of the world) behind
> the scenes.
> 
> And bye the way.
> In the R&D facility where I work we have a very powerfull tool for
> analysis of free text. Recently a lot of progress has been been at this.
> If the free text is 'enriched' with Archetypes this process of
> meaningfull data extraction will become much more easy.
> 
> Gerard Freriks
> 
> --
> Gerard Freriks, MD
> Convenor CEN/TC251 WG1
> 
> TNO-PG
> Zernikedreef 9
> Leiden
> The Netherlands
> 
> +31 71 5181388
> +31 654 792800
> 
> 
> 
> 
> --   --
> Gerard Freriks, arts
> Huigsloterdijk 378
> 2158 LR Buitenkaag
> The Netherlands
> 
> +31 252 544896
> +31 654 792800
> 
> 
>> From: "Christopher Feahr" 
>> Organization: Optiserv Consulting
>> Reply-To: "Christopher Feahr" 
>> Date: Mon, 11 Aug 2003 07:32:52 -0700
>> To: "Thomas Clark" 
>> Cc: "Karsten Hilbert" ,
>> 
>> Subject: Re: HISTORY DATA SET IN EPR
>> 
>> Presently, each doctor and EMR software vendor is cooking up his own
>> shorthand-language, and I'm suggesting that information should be
>> reduced as much as possible to a standard set of codes.
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
> 
> 
> 
> 

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Uniform Model Code for Electronic Healthcare Records

[Gerard Freriks]

Hi,

Many of the 'codes' have been translated into less than two hundred
"essential requirements" that we at TNO apply to IT systems in healthcare.

The link provided will point at those requirements.
www.health.tno.nl/trust/documents/referenties_er.pdf

These requirements will be extended by a second set of requirements.

The first set deals with the interactions between a system (and its
organisation) and a user.
The second set will deal with the interactions between systems and their
organisations.

Information publishers and IT software industry are being certified by TNO.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: "lakewood at copper.net" 
> Reply-To: "lakewood at copper.net" 
> Date: Tue, 26 Aug 2003 09:17:26 -0700
> To: angelo rossi mori 
> Cc: openehr-technical at openehr.org
> Subject: Re: Uniform Model Code for Electronic Healthcare Records
> 
> Hi Angelo,
> 
> Each jurisdiction will have laws governing eCommerce, the Internet and
> electronic records in general. There are very good reasons to do so,
> e.g., privacy, security, fraud prevention. Try this link:
> 
> http://library.lp.findlaw.com/articles/file/00323/000777/title/Subject/topic/C
> onsumer%20Law_Consumer%20Protection/filename/consumerlaw_1_392
> 
> It applies to US law (codes that are adjudicated in court). If the link
> doesn't work try:
> 
> http://www.findlaw.com
> 
> This allows one to perform a search of the FindLaw database.
> 
> Try:
> electronic+record+healthcare
> 
> This search should produce the following link:
> 
> http://corporate.findlaw.com/local.html
> 
> which requires a selection of 'state' or 'international'
> 
> The result is a 'marketing'  oriented display but it does contain
> information on who is involved.
> 
> Try:
> 
> http://www4.law.cornell.edu/uscode/
> 
> for the U. S. Code (federal law). Note that there is a 'title' on
> 'Foreign Relations and Intercourse' but no 'title' on Healthcare. or
> Health. Use the search engine to search all of the US code (upper
> right-hand side of the web page).
> 
> Try searching for 'health'. Scan each page for 'record'
> Reason: The search engine was used by the founding fathers and should
> have been replaced years ago.
> 
> You will probably not find an entry related to 'health' 'record'.
> 
> Hence, a Judge attempting to adjudicate a case involving electronic
> healthcare records would have no U. S. code to guide them.
> 
> Next is legislation (enactments of Congress)
> 
> Try:
> 
> http://www.wedi.org/public/articles/details~13.htm
> 
> HIPAA  Legislation Information
> 
> HIPAA isn't going to resolve issues related to global electronic
> healthcare records. It is targeted toward the domestic US healthcare
> insurance industry with some provisions for Patients and Providers.
> 
> Deploying OpenEHR in the US will encounter HIPAA at the federal level
> and the separate legislative enactments of the 50 states and other
> special jurisdictions, e.g., the VA operates in its own world.
> 
> This can be characterized as a legal structure having incompatibilities
> with a global legal structure that would support global electronic
> healthcare records. Hence the suggestion that a uniform model code is
> needed suggesting what should or should not be included within the code
> and enactments of a particular jurisdiction.
> 
> The same would apply to other countries, e.g., asian and middle east.
> 
> Basically, the uniform model code would list what needs to be integrated
> into the code and legislative enactments. Start soon since these things
> do take a lot of time.
> 
> Hope this helps! Always consult a qualified attorney within the subject
> jurisdiction and have them explain it.
> 
> -Thomas Clark
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> angelo rossi mori wrote:
> 
>> Thomas,
>> what do you mean for "legal codes on EHR" ?
>> 
>> And are you really sure that EU has agreed about any set of codes ?
>> 
>> I would like to know more ...
>> 
>> -Angelo
>> 
>> At 23.43 25/08/2003 -0700, lakewood at copper.net wrote:
>> 
>>> HiAll,
>>> 
>>> Would appreciate responses regarding legislation regardin non-EU
>>> legal codes on electronic healthcare records. The EU already has a
>>> well-developed set of codes.
>>> 
>>> The US seems to be a problem since there are 50 states, a federal
>>> government and special jurisd

Common RM

[Gerard Freriks]

On 2003-03-26 2:12, "Thomas Beale"  wrote:

> 
> 
> Grahame Grieve wrote:
> 
>> 
>> I thought all the content of a single transaction was confined to a
>> single language?
> 
> there is one point of view that all of a single _version_ must be a
> single language, and another that says even this won't be realistic due
> to patient respones in other languages.
> 
>>>>>

The context of any entry in the EHR is that it is the view, the perception,
of the person that authors it that is recorded in the entry.

It will be confusing to write part of the entry in English and another part
in sanscrit. As it is confusing to use the HL7 2.x syntaxe in one part and
that of Edifact in an other.

What patients tell in what language is most of the times via the perception
of the healthcare provider that is documenting the healthcare process.

GF



--   --
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 at openehr.org

openEHR security; Directed to Thomas Beale

[Gerard Freriks]

he patient
>>>> is fully able to decide what she *wants* the doctor to know).
>>>> Etc.
>>>> 
>>>> Medicine is neither the military nor a secret service, literally
>>>> (it's not mass media either, on the other end of the spectrum).
>>>> 
>>>> Just a clinician's muttering ...
>>>> 
>>>> Karsten
>>>> --
>>> 
>>> Karsten,
>>> 
>>> I agree and have concerns about being expected to take responsibility
>>> without access to all the facts.
>>> 
>>> I suppose this may not be an issue as I suspect that most people won't
>>> restrict the information in their file.
>>> 
>>> However, to fragment a medical file into bits I can and can't see is
>> similar
>>> to taking the view that mind and body are separate entities.
>>> 
>>> If something is restricted, will I know there is something there that I
>>> can't see? Or will I be blisfully ignorant? How can I know if a piece of
>>> information is irrelevant unless I can see it to assess it?
>>> 
>>> More mutterings!
>>> 
>>> Matt
>>> 
>>> 
>>> -
>>> If you have any questions about using this list,
>>> please send a message to d.lloyd at openehr.org
>> 
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>> 
> 
> _-_|\Andrew Goodchild
> / *   DSTC Pty Ltd
> \_.-._/   Brisbane, Australia
> vhttp://staff.dstc.edu.au/andrewg/
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

--   --
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 at openehr.org

openEHR security; Directed to Thomas Beale

[Gerard Freriks]

On 2003-05-02 19:25, "Bill Walton"  wrote:

> Hi Gerard,
> 
> Gerard Freriks wrote:
> 
> /snip/
> 
>> In other words: the OpenEHR can assume that the Access Control function
>> operates as if it is a fire wall that executes a set of rules
>> and that the
>> Audit trail is the log with violations (Exceptions) the fire wall had to
>> grant.
>> 
>> The operation of the 'firewal' and audit trail are outside the scope of
> Open
>> EHR.
> 
> While I support the concept of seperating the access control functionality
> from the storage / retrieval functionality, I'm afraid I have to disagree,
> with all due respect, to the segregation of the audit trail and to what I
> understand your definition of what needs to be contained in the audit trail.
> The notion that the audit trail only log exceptions will be a non-starter
> here in the U.S., I think.
>>>>>

I understand your remarks.
But.

The following information must be added to get a fuller picture of how I
envisage things:

-0- The context for my remarks is the discourse, using human and computer
processable documents, between health professionals over time and space. My
context is not updating databases using messages.
-1- Electronic systems must provide at least the same quality in all aspects
when compared with paper based systems. The quality can be better but never
less.
-2- Of course persons entering the system are logged
-3- And only information is readily available to which one has rightful
access because one is working in the same department the patient is in.
All access to the information will not be logged in the audit trail.
(paper based systems don't record where the eyes hit the paper and ink)
I assume a high degree of social control in a department.
-4- Audit trails in the sense that is recorded why, what, when, from where,
by whom has used the exception path to reach information are needed when the
requestor is overruling the access controls.
-5- the preferred way of obtaining information must stay (as it always was)
direct contact between health professionals either orally or by writing.

My fear is that because anything can be recorded and tracked or traced we
feel obliged to do so in the electronic domain.
Example: The Data Registrars Office in the Netherlands is of the opinion
that access to electronic medical records can be granted only by using two
ways authentication (password AND biometrics) The only justification is that
it is possible. But it is unaffordable and to complex to organise in the
healthcare domain)



--   --
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 at openehr.org

Record Level Data Security; storage plus fixed and mobile transmission

[Gerard Freriks]

On 2003-05-02 22:43, "lakewood at copper.net"  wrote:

> Security begins at the data storage level. Unless it can be protected at
> this level more sophisticated techniques applied to transmission and content
> will not be as effective as desired.
> 
> Three common approaches are:
> 1)Data security
> 2)Data management and
> 3)Access to storage media-resident data, e.g., somebody's disk drive
> 
>>>

You leave out completely the legal, social control and organisational
aspects.
Technology isn't a silver bullet.

Gerard

--   --
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 at openehr.org

Record Level Data Security; storage plus fixed and mobiletransmission

[Gerard Freriks]

Dear Thomas,

At OpenEHR there is an emphasis on the exchange of documents but also on
storage of objects in systems.

What you are referring to is the first topic (messages).

Gerard



On 2003-05-03 19:52, "lakewood at copper.net"  wrote:

> Hi Gerard,
> 
> Record Level Data Security  has little to do with legal, social control and
> organizational aspects.
> 
> I agree that these are important, and in many cases more important, than
> record level data security. They are more complex issues that are dependent
> upon factors varying from culture to informal/private business arrangements.
> To be complete others would have to be added.
> 
> The approach taken was to start at a level where secure global electronic
> data interchange of healthcare records is possible, a possible model being
> the "Association For Payment Clearing Services".
> 
> http://www.apacs.org.uk/downloads/List%20of%20Standards5.pdf
> 
> The perceived need is secure, standard record formats so that information
> can be accessed even though it was created under a system using a different
> record format. 
> 
> -Thomas Clark
> 
> - Original Message -
> From: "Gerard Freriks" 
> To: ; 
> Sent: Saturday, May 03, 2003 2:40 AM
> Subject: Re: Record Level Data Security; storage plus fixed and
> mobiletransmission
> 
> 
>> On 2003-05-02 22:43, "lakewood at copper.net"  wrote:
>> 
>>> Security begins at the data storage level. Unless it can be protected at
>>> this level more sophisticated techniques applied to transmission and
> content
>>> will not be as effective as desired.
>>> 
>>> Three common approaches are:
>>> 1)Data security
>>> 2)Data management and
>>> 3)Access to storage media-resident data, e.g., somebody's disk drive
>>> 
>>>>> 
>> 
>> You leave out completely the legal, social control and organisational
>> aspects.
>> Technology isn't a silver bullet.
>> 
>> Gerard
>> 
>> --   --
>> Gerard Freriks, arts
>> Huigsloterdijk 378
>> 2158 LR Buitenkaag
>> The Netherlands
>> 
>> +31 252 544896
>> +31 654 792800
>> 
>> 
> 

--   --
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 at openehr.org

OpenEHR: congratulations!

[Gerard Freriks]

Dear Thom, Sam, Dipak and Peter,


I congratulate you with the fact that OpenEHR is part of the HealthConnect
context in Australia

OpenEHR is mentioned in the recent "Interim Research Report" on page 21 and
several other places.
(http://www.healthconnect.gov.au/consult.html)

For the CEN/TC251 EHRCOM Task Force this will provide a strong support and
motivation to make much progress the next couple of months on the exciting
and important new European, Australian and HL7 standard for the Electronic
Health Record.

Gerard Freriks

-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


--   --
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 at openehr.org

Pathology requirements TIMED MEASUREMENTS

[Gerard Freriks]

HI,


On one hand there is the notion as used in HL7 where series of messages
update databases producing a list of updated measurements.

On the other hand there is the notion as used in CEN/TC251 and OpenEHR
where documents are used to enhance the raw data by providing a human
interpretation and advice by an expert using the updated measurements in the
database.

Gerard


-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: Sam Heard 
> Reply-To: Sam Heard 
> Date: Mon, 27 Oct 2003 11:41:47 +0930
> To: Bhupinder Singh , Thomas Beale
> , Openehr-Technical  openehr.org>
> Subject: RE: Pathology requirements TIMED MEASUREMENTS
> 
> Bhupinder
> 
> The only values we are not wanting to show are those that are wrong - and
> have been changed in a later version. The idea behind this is to store the
> information in an openEHR system inside the Pathology service and then send
> an extract - rather than develop a lot of messages.
> 
> Cheers, Sam

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Pathology requirements CONTRIBUTION - 2 versions at once

[Gerard Freriks]

Hi,

Only an attribute will not be enough.
It has to be accompanied by rules.

Information will be stored in various contexts and not always in the same
system. The same information will be stored in separate contexts.
A change in the status of the 'Lifecycle marker' in one machine will not
result in changes in other machines, unless there is a replication service.
It is unlikely that all systems will be able to deal with such a service.
In order to handle this we need rules.
My suggestion for a rule would be: the 'Lifecycle marker' is valid
(maintained) in one system only.
Moving from one jurisdiction to an other means that the person that takes
responsibility for the admission of this information into a new
jurisdiction/system sets the marker to: received and admitted.

Part of the rules is a state machine that provides all the states of the
'Lifecycle marker'.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: "Thomas Beale" 
> Reply-To: "Thomas Beale" 
> Date: Mon, 27 Oct 2003 08:16:55 +1000
> To: Openehr-Technical 
> Subject: Re: Pathology requirements CONTRIBUTION - 2 versions at once
> 
> That is why I am suggesting that all such Entries havea lifecycle
> marker. This is somehting which I think our colleagues at UCL have long had in
> their system, and I have never seen a scenario which I thought justified it
> until 
> now...

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Model Code for EHRs

[Gerard Freriks]

Hi,


Have a look at:
http://www.health.tno.nl/trust/new/englishinfo.html

Don't be fooled by the word 'website'.
At present we are making an extention to QMIC to encompass the EHR.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: "lakewood at copper.net" 
> Reply-To: "lakewood at copper.net" 
> Date: Sun, 31 Aug 2003 22:51:28 -0700
> To: openehr-technical at openehr.org
> Subject: Model Code for EHRs
> 
> Hi All,
> 
> Reviewing model codes for eCommerce and EHRs. The most advanced appear
> to be those in the following entities:
> 
> -EU community
> -Australia
> -New Zealand
> -Canada
> 
> Note that eCommerce has been included because the goals, objectives,
> security and privacy concerns closely parallel those for EHRs.
> 
> I plan on extracting portions from the best sources and putting them in
> a new document. Modifications will be made.
> 
> The objective is to see if the product is worth anything.
> 
> Would appreciate any comments, suggestions, pointers.
> 
> Regards!
> 
> -Thomas Clark
> 
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

connection between Reference Model and Archetype Model

[Gerard Freriks]

Hi,

Have a look atL
http://www.centc251.org/
And find the new draft open for comments on the front page.

Gerard

> 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


> From: "Sebastijan Mrkus" 
> Organization: Ericsson Nikola Tesla d.d.
> Reply-To: "Sebastijan Mrkus" 
> Date: Fri, 19 Sep 2003 16:26:00 +0200
> To: 
> Subject: connection between Reference Model and Archetype Model
> 

> Can anyone post link or a reference to a document that describes connection
> between Reference Model and Archetype Model.
>  
> We are currently working on a project that uses CEN ENV 13606 as Reference
> Model and we are trying to implement archetypes.
>  
> Any suggestions would be greatly appritiated,
>  
> Sebastijan
>  
>  
>  
> 


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030923/52879af9/attachment.html>

Open Source EHR at the Americal Academy of Family Physicians ...

[Gerard Freriks]

> 
> Dear colleagues,
> 
> It is laudable that HHS obtained the rights for the use of SNOMED-CT in the
> USA.
> It is understandable that pressure will be used to deploy SNOMED as the
> preferred terminology.
> It is perfectly understandable that this pressure will result in the
> incorporation of SNOMED into HL7 v3.
> 
> But...
> 
> In Europe CEN/TC251 has declared to base its activities on HL7 v3 RIM. And for
> several years we at CEN are co-operating in a very fruitful way with HL7 on
> the basis of a renewed Memorandum of Understanding.
> In Europe we have to take into account the requirements of several European
> countries.
> Not all countries have easy access tot SNOMED or have plans to obtain the
> rights to use SNOMED.
> 
> Meaning, that HL7 must carefully investigate how and to what extend SNOMED-CT
> will become incorporated in HL7 v3.
> 
> (?There is a need to bring into sync UMLS and HL7 at some level. To my mind
> Semantic Network and HL7 V3 RIM have to be reconciled. This will facilitate
> reuse in an object oriented way while retaining semantic validity.  We can
> then have a true unified health information infrastructure.?)
> 
> This topic will be a good one to place on the next agenda when the board of
> HL7 and CEN/TC251 chairman and convenors will meet.
> 
> With regards,
> 
> Gerard Freriks
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
Leiden
The Netherlands

+31 71 5181388
+31 654 792800


> From: "Shah, Hemant" 
> Reply-To: "Shah, Hemant" 
> Date: Wed, 27 Aug 2003 09:53:45 -0700
> To: openehr-technical at openehr.org
> Subject: RE: Open Source EHR at the Americal Academy of Family Physicians ...
> 
> The recent agreement between the Health and Human Services and the College of
> American Pathologists about integrating SNOMED into UMLS, and making it
> available for free to everyone in USA, was a landmark.
> 
> Is there a thought process within HL7 that is exploring such opportunities? If
> HHS agrees to support HL7 to allow it to make its standards available for
> free, it will hasten its adoption and development while it serves the goals of
> the federal government too.
> 
> There is a need to bring into sync UMLS and HL7 at some level. To my mind
> Semantic Network and HL7 V3 RIM have to be reconciled. This will facilitate
> reuse in an object oriented way while retaining semantic validity.  We can
> then have a true unified health information infrastructure.
> 
> Regards, 


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030925/f0cfe886/attachment.html>

Open Source EHR at the Americal Academy of Family Physicians ...

[Gerard Freriks]

Ed,

I agree with you.
Today I had an discussion with Diane Ashman on this topic.
She is very willing to think along those lines.
But we all must move with caution, think of the many consequences and find
the proper balance.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


> From: William E Hammond 
> Date: Thu, 25 Sep 2003 09:03:42 -0400
> To: Gerard Freriks 
> Cc: Mark Shafarman , Gunnar Klein
> , Nan Besseler , Magnus Fogelberg
> , P Zanstra ,
> , "Shah, Hemant" , Eline 
> Loomans
> 
> Subject: Re: Open Source EHR at the Americal Academy of Family Physicians ...
> 
> 
> I agree with Gerard that we need to be careful.  However, that does not
> mean that we go to the lowest denominator.  IF we think SNOMED is the best
> solution, then we need to spend our time and energy on finding how to make
> SNOMED available to the rest of the world.  We have a debate in our school
> system in Durham.  The poorer kids do not have access to the Internet and
> to laptops.  The debate is whether to prohibit the use of computers and
> Internet for school work or to try to find methods that will provider
> laptops and Internet access to the poorer kids.  I think the answer is
> simple.
> 
> However, I do think it is important to make sure that SNOMED is the answer
> and will be acceptable before we move aggressively.
> 
> Ed Hammond

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Archetype constraints and interfacing instruments/DSS to an OpenEHR system.

[Gerard Freriks]

Hi,

One thing I know that in this time frame CEN/TC251, HL7 and ISO/TC215 
co-operate harmonized standards are/will be produced.

It is without any doubt that nothing is forever.
We expect that our co-operation will produce a series of standards in 
Medical Informatics that will last longer than ever and will be able to 
evolve and improve.

How many alternate and competing HTML (or XTML) or TCP/IP standards do 
you want?


Gerard Freriks


-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 01 Dec 2004, at 20:41, lakewood at copper.net wrote:

> Hi All,
>
> Change is an ever-present factor, requirement and necessity. This is 
> true in Healthcare as it
> is in many other human endeavors. Standards that prohibit or avoid 
> change at some point become
> obsolete.
>
> Regards!
>
> -Thomas Clark
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 949 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041201/c6aac404/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

Dear all,

Am I correct to conclude and propose that:

- episode: situation considered to occupy a time interval

- there are at least 4 context's in which the term 'Episode' is defined:
disease related (point of view of the patient),
treatment related (point of view healthcare provider),
adminstrative contact related (point of view of healthcare 
institution),
insurance related (point of view payer)
- sometimes the period is real and enumerated (dd-mm-yy, ISO 8601 : 
1988Data elements and interchange formats - Information interchange - 
Representation of dates and times),
sometimes indefinite (one week ago, some weeks ago, ongoing, during, 
before, etc,  as defined in CEN/TC251 EN1238 Time standard for health 
care specific problems)

Gerard


-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 04 Dec 2004, at 01:00, Elkin, Peter L., M.D. wrote:

> Dear Thomas,
>
> ?
>
> I favor the episode being a single point of audit (regardless of the 
> timeframes at which an episode starts and stops). ?So all encounters 
> and non-encounter events would indeed be part of an episode of care. 
> ?This brings continuity to the notion of an episode of care.? Episodes 
> allow the summarization of the care which has occurred during the 
> episode and there should be a provision in the OpenEHR architecture to 
> affix this information to the Episode for further reference.
>
> ?
>
> Warm regards,
>
> ?
>
> Peter
>
> ?
>
> Peter L. Elkin, MD
>
> Professor of Medicine
>
>  Director, Laboratory of Biomedical Informatics
>
> Department of Internal Medicine
>
> Mayo?Clinic, College?of Medicine
>
> Mayo Clinic, Rochester
>
> (507) 284-1551
>
> Fax: (507) 284-5370
>
> ?
>
> ?
>
>
> From: owner-openehr-technical at openehr.org 
> [mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale
> Sent: Thursday, December 02, 2004 5:36 AM
> To: Openehr-Technical
> Subject: Modelling Episodes in openEHR
>
> ?
>
>
>  Dear all,
>
>  the definitional debate about what an "episode" will of course 
> continue long into the future, and we will not solve it here - indeed 
> there will never be a single definition. But we can in the abstract 
> identify a couple of solid concepts:
>  - episode of care by a care delivery enterprise / health care 
> provider - provider-centric
>  - episode of course of illness / situation - patient-centric; 
> finishes at death, return to health, or stabilisation (chronic 
> problems)
>
>  A long-term effort into these types of concepts is the CEN TC/251 
> Continuty of Care work (prEN13940), led by Fran?ois Mennerat, who is 
> on this list. The current draft of this standard is hosted on the 
> openEHR website at 
> http://www.openEHR.org/downloads/prEN13940_2004E_041107.zip (600k zip 
> file of 2Mb Word document), and is worth a read. Notable definitions 
> from this work include:
>
>  - period of care (was "period of service"): situation during which 
> one or more contacts occur between a subject of care and one or 
> several health care professionals, in the framework of a care mandate 
> held by a health care provider
> - episode of care: situation during which health care activities are 
> performed by one health care provider to address one health issue
> - cumulative episode of care: situation encompassing the occurrence of 
> all health care activities related to only one health issue thread
>
> In the above, "period of care" appears to be the same as what I have 
> informally called "episode of care" above; while "cumulative episode 
> of care" appears to correspond to the second informal definition. 
> People may like to use the prEN13940 definitions.
>
>  In any case, the practical problem we have is to provide a way to 
> model episodes (however defined) for users of openEHR, while retaining 
> data and service interface interoperability. To model patient-centric 
> clinical episodes (of illness, pregnancy etc) we believe that the 
> current approach of using LINK objects to connect Entries, 
> Compositions to be the best one. An animated slide presentation done 
> by Dipak Kalra, using EN13940 terminology shows how this works in a 
> particular example - see 
> http://www.openEHR.org/downloads/CONTSYS-EHRcom.ppt (143k powerpoint).
>
>  The other kind of eposide - "period of care/service" - we believe can 
> be done using Folders. After some discussions recently with Dipak 
> Kalra, we would suggest the following two ways of doing it in openEHR.
>   1.  One "episode" = an openEHR Folder

Modelling Episodes in openEHR

[Gerard Freriks]

Thom,

It seems we are in agreement.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 04 Dec 2004, at 12:54, Thomas Beale wrote:

> Gerard Freriks wrote:
>
>> Dear all,
>>
>> Am I correct to conclude and propose that:
>>
>> - *episode:* situation considered to occupy a time interval
>>
>> - there are at least 4 context's in which the term 'Episode' is 
>> defined:
>> disease related (point of view of the patient),
>
> this kind of episode often has vague boundaries, and I think we have 
> to rely on following LINKs in the EHR to find all its pieces. If I get 
> bronchitis that seems to get better before it gets worse every two 
> weeks, is this a single episode or many? I don't think it matters - 
> what matters is being able to find all the information items relating 
> to a given problem.
>

And relating data in a specific context for a specific purpose that 
some times is defined in a group and sometimes defined by one actor for 
his own purpose.
Episodes likes these are more general and NOT depended on business 
rules.



>> treatment related (point of view healthcare provider),
>> adminstrative contact related (point of view of healthcare 
>> institution),
>
> these two are I think possible to identify as being delimited by known 
> points in time, as long as the provider has a clear rule for when they 
> are providing health care, versus when they are not. They might be 
> providing care in parallel with other providers of course - e.g. Dipak 
> had a good example of patients on weekend leave from a mental health 
> institution, who become the responsibility of the local GP for the 
> weekend, but don't really stop being the responsibility of the 
> institution.

episodes like these are depended on (local) business rules that vary 
from place to place.

>
>> insurance related (point of view payer)
>
> How re-imbursing institutions want to define episodes is something I 
> don't know much about, but Tim Churches or someone may have something 
> to add here. How does that work in NL, Gerard? I know there is a 
> mixture of government and private payors.

I don't know them either.
But think of mergers between firms and new insurance products and 
updates within one firm.


>
>> - sometimes the period is real and enumerated (/dd-mm-yy, ISO 8601 : 
>> 1988Data elements and interchange formats - Information interchange - 
>> Representation of dates and times/),
>> sometimes indefinite (/one week ago, some weeks ago, ongoing, during, 
>> before, etc, as defined in CEN/TC251 EN1238 Time standard for health 
>> care specific problems/)
>
> I think such vague times can only be for clinical use (patient had an 
> "episode" of bronchitis about 2 weeks go, lasting about a week). For 
> billing or other computable purposes such as statistical studies, you 
> have to be able to know which things are in and which are out.
>

I agree.




> - thomas
>
>
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3103 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/72403de6/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

The disease  episode is about the patient and can and will be exchanged.

Other episodes defined on the basis of local business rules will not be 
exchanged.

GF
-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 04 Dec 2004, at 16:44, Bill Walton wrote:

>>
>> I think any institution has to have a firm model
>> for what it thinks an episode is
>
> Assuming that different institutions will adopt models that differ, 
> what are
> the implications for the exchange of data and the creation of a 
> lifelong
> EHR?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 687 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041204/688bece1/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

Sam,

Is it correct to say that:
- Each type of Episode will be an specific  Archetype that maps 
starting at  the folder.
- What must be communicable  generically is the disease type Episode 
since this can be true in many places.
- The Non-disease Archetypes are based on local business rules and 
don't have to be communicated to others outside the own organization. 
So each organization will have its own Archetype that fits their 
business rules.
- It will be wise to use in the Archetypes terms that conform to the 
CEN/TC 251 Continuity of Care standard.
- Three proto-Archetypes defining the various episodes must be 
standardized in order to create interoperability.
- Two non disease type proto-archetypes will be highly  specialize-able.
- The disease related proto-archetype will be of the kind that can not 
easily be specialized.

New term (=concept): proto-archetype - A standardized Archetype.
This proto-archetype must be the starting point for specialization in 
order to produce an Archetype to be defined and used in a local 
community.

Bye the way.
What types of standardized proto-Archetypes will we need?
What are the rules for specialization?
Which proto-archetypes can and can not be specialized?
Or are we more subtle; to what degree? Etc, etc.
Do we need accepted rules that govern the production and usage of 
Archetypes?

Gerard



-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 06 Dec 2004, at 03:08, Sam Heard wrote:

> Bill and all
>
> This is a very important consideration and one that we need to get 
> right for lots of reasons.
>
> Tom has been proposing an aggregation  approach - allowing us to find 
> all data that relates to something - a disease, care at an institution 
> etc.
>
> It is clear that there are aspects of the episode that are specific to 
> the care setting and administrative and billing requirements. We could 
> have a composition that held information about the administrative 
> aspects of the episodefor billing purposes or secondary data 
> collection. It would be possible to archetype an 'episode' folder to 
> contain one of these - and possible to define what is held within it 
> should that be appropriate.
>
> It is clear that a simple aggregation model is not enough, but we also 
> do not want to have lots of folders to describe one episode from 
> different perspectives.
>
> The Mayo can only have one episode per patient at any timethis 
> ensures that the person who opens an episode is responsible for 
> closing it - and summarising it, tying up lose ends etc. This is a 
> very important quality issue in distributed care environments. But in 
> the Australian setting where we have primary and secondary care 
> separated - the notion of secondary care episode is largely a billing 
> or funding issue - although we have discharge referrals back to 
> primary care.
>
> In primary care, the idea of an episode - a single one at a time - is 
> appealing to me - meaning it is non-routine care for the problems the 
> person has. It stops what Michael Balint called the "collusion of 
> anonymity" - a destructive outcome of 'shared' or 'parallel' care.
>
> Cheers, Sam
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3288 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041206/d0152127/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

Hi,

On 06 Dec 2004, at 09:10, lakewood at copper.net wrote:

>
> An episode at age 10 is not likely to be important at age 30, 40 or 
> beyond.
>

?!

An episode of appendicitis at 10,
an episode where the spleen is removed,
an episode of leukemia at 10,
all are more or less very important,
when talking about the disease related episode.
In contrast the administrative related episodes are NOT important under 
must (non-legal) circumstances.
Although it might be important to know for a relatively short period 
that because of hart failure the patient is admitted to a hospital 
every other week.

The list of recorded episodes is very valuable to discern important 
medical facts from common colds, and bruises.
It is the patients medical history where important medical facts are 
grouped.

Do we have a list of use cases for each type of Episode?

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1063 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041206/8cedb77e/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

wow, wow!

GF
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 07 Dec 2004, at 06:46, Sam Heard wrote:

>> Bye the way.
>> What types of standardized proto-Archetypes will we need?
>
> There are some interesting ones potentially.
>
> visualisation is one that I am interested in. To cover external 
> observation and all forms of Xrays, Ultrasound etc. The advantage is 
> that if you are interested in the Liver - it would be easy to find all 
> visualisations - at laparotomy, by ultrasound, CT.
>
> The price for such an approach may be too high - but I kind of like 
> the idea of it. Visualisation.ultrasound or visualisation.xray.ctscan
>

What else?
Lets have a look at the CEN/TC251 General Purpose Information 
Components (GPICS) or HL7 v3 CMET's) as starting points.

Visualisation on one hand might means the procedure and result as in a 
Dicom report.
Or on the other hand a specialisation of the Observation GPICS where 
the focus is on the expert opinion about the result of the former 
'visualisation-type'.

We need at least two classes of archetypes dealing with obeservations 
(and possibly other topics): the procedure plus result and the expert 
opinion about it.


>> What are the rules for specialization?
>
> There are the technical ones that ensure that a specialised archetype 
> does not break the rules of the parent - some of these are working in 
> the editor. Generally, specialisation is appropriate if a query on one 
> archetype should return information even if it is in another.
>

We need those things ecxplicitly in writing.
They have to end up in CEN/TC251 EN13606 part 3.


>
>> Which proto-archetypes can and can not be specialized?
>
> No rules as yet.

We need rules for this and several other things.


>
>> Or are we more subtle; to what degree? Etc, etc.
>
> Yes...we are learning a lot about this as we go.
>
>> Do we need accepted rules that govern the production and usage of 
>> Archetypes?
>>
>
> We do, and we need to put these together as we go...

Who?
How?

Where is the list?




-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2302 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041207/31eee120/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

Hi,

That seems a good suggestion.

Gerard


-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 11 Dec 2004, at 17:20, Thomas Beale wrote:

> And our current suggestion (from Dipak Kalra and myself at least) is 
> that a special Composition be used in an episode-Folder to hold 
> administrative data - i.e. in addition to all the clinical 
> Compositions in the Folder.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 526 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041212/478b3f45/attachment.bin>

Modelling Episodes in openEHR

[Gerard Freriks]

Hi

reed in the text below.

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 11 Dec 2004, at 17:13, Thomas Beale wrote:

As
  Software Configuration Management (SCM) is very important in my view.

Use case (one of many):
The plan is to have several test be performed: several chains of events 
are opened.
Each track provides preliminary partial reports. Each of these partial 
findings will give rise potentially to recordings in the record and 
extra actions.
Some of the tracks might include referrals to other physicians that do 
their thing and document the work in their version of the patient 
record.
After some time all tracks are resolved and must be consolidated.

This whole process needs a form of SCM for the generated information in 
federated EHR situation.

A way I view this process is: that there is one main track where the 
plan was set up and executed.
Each track generates intermediary reports that have a short shelf-life.
At the end of each track all information is summarized and an expert 
provides his personal opinion answering the question that started off 
that track.
The owner of the main track holds responsibility for the final 
consolidation.


>
>>
>> An episode at age 10 is not likely to be important at age 30, 40 or 
>> beyond.
>
> soI suspect some doctors will have something to say about this 
> statement!

Thomas, you provided an example.
On other one.
Car accident and spleenectomy 20 years ago, still influence decisions 
today.

And then. One fact unimportant at a certain time can become very 
important later.

> in summary - I agree with all your points above, except that I don't 
> think that "episodes of activity" can be conveniently archived and 
> forgotten about. But it is an interesting analogy that I for one had 
> not thought of, and may well bear further analysis.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2029 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041212/bf39269c/attachment.bin>

Episodes in openEHR

[Gerard Freriks]

Colleagues,

Consider the following as requirements from the Netherlands.

The Dutch GP organization NHG has defined Episode as:
An Episode is a chronological collection of medical data (episode 
items) of one patient and describes the state changes over time 
concerning one health problem.

The name of the episode describes the health problem  (health issue) 
and can be changed over time.

The episode unordered list contains all episodes, open or closed.
Episodes can have an attribute indicating "attention"
Episodes can be closed and opened.
Episodes can be joined and split

One episode consists of episode items.
Episode items are: report as the result of a contact, 
Prescription/Order, Diagnostic Archive, Correspondence.

Most of Marten Spook's attributes stem from these Dutch GP requirements.
I consider Episodes as an alternative view on the information collected.
It is a list consisting of links pointing to registered information 
that is available in the system.
The preferred place to store this list is the Folder.

And then there are our DBC's (DRG's) One DBC is almost the same as an 
Episode.

Gerard

--  --
Gerard Freriks
TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 20 Nov 2004, at 02:42, Thomas Beale wrote:

>
>  This is part of a discussion that started off the list. The need is 
> to be able to model Episodes in openEHR, while remaining compatible 
> with available structures.
>
>  Currently, there is no "Episode" class (although this doesn't 
> necessarily have to remain this way). Up to now, we have never been 
> able to nail down sufficiently 'standard' requirements to satisfy 
> everyone's idea of an "episode".? Instead we have suggested that 
> Folders be used as reference containers to Compositions considered to 
> have occurred in an episode. The current EHR reference model shows 
> this.
>
>  More recent thinking on this issue:
>  - on my recent visit to Mayo Clinic at Rochester Minnesota, I 
> discovered that their idea of an Episode in the MICS system is "a 
> period of care overseen by a particular clinician". E.g. if someone 
> comes in with an injury, the doctor referred to (by a GP or by A&E) 
> 'runs' the episode. Even if the patient sutains an MI while in 
> hospital, and that becomes her main problem, and a cardiologist gets 
> involved, the original clinician in almost all cases is in charge of 
> the episode, and will make the discharge summary. An episode can be 
> 'closed' on the MICS system, but can be reopened by some special 
> operation, e.g. if erroneous information is spotted later on. I seem 
> to remember that someone else can take over an episode - presumably if 
> the original clinician becomes unable to continue giving care for some 
> reason. (Someone from Mayo on this list might want to correct me if I 
> have any of this wrong).
>
>  - Maarten Spook of 2Cure, Amsterdam has some very typical 
> requirements of an "Episode", as follows:
>  We think of attributes like:
>
>   1.  startDateTime: the date-time the episode is started (medically)
>   2.  stopDateTime: the date-time the episode has ended (medically). 
> When present this folder is closed?
>   3.  createdDateTime: the date-time the episode was created 
> (administrative)
>   4.  contributers: care providers and their role (participations?) 
> It 
> would be clear to see who had added info and who is responsible for 
> this episode etc
>   5.  structured annotation: a short description of the content / 
> context of the episode
>  My comment on this is: of the above attributes, it is the first 3, 
> and maybe #5 which need to be associated with an episode as such. 
> Contributors can be determined from the contributors to versioned 
> Compositions in openEHR (remember "Contributor" is actually a class 
> itself in the openEHR Common model). Let us consider if we could 
> achieve this just using Folders, as a "straw man" proposal.
>
>   1.  clinical start date time can be determined from the start_time 
> of the first Composition in the Folder
>   2.  clinical stop date time can be determined from the endt_time of 
> the last Composition in the Folder
>   3.  created date time of the "episode" - administrative. Depends on 
> what this really means. The creation date time of the Folder 
> representing the episode is easy - it is the time_committed in the 
> audit attribute of the type VERSION resulting from the 
> class VERSIONED_COMPOSITION being a binding of VERSION_REPOSITORY to 
> COMPOSITION.
>   4.  contributors - as mentioned above, these can be derived from 
> 

Episodes in openEHR

[Gerard Freriks]

Colleagues,

Looking at the discussion it is very obvious that there are several 
points of view and all are reasonable and correct.

One: the patient viewpoint. The Episode (as I described): one patient, 
one health issue, and many healthcare parties, contacts, etc
Two: the Healthcare party viewpoint. The administrative view. One 
admission upto discharge for whatever reason.
Three: What is the viewpoint as seen from the third type of healthcare 
party? The payor.
Four: What is the viewpoint as seen from Government reporting, 
reserach, etc?

Each viewpoint needs its own definitions of attributes and code systems
And all must be harmonized.
I expect that work in CEN/TC251 (System of Concepts for Continuity of 
Care) might enlighten us.


Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 20 Nov 2004, at 20:19, Elkin, Peter L., M.D. wrote:

> Gerard and Colleagues,
>
> At Mayo Episodes of care start with any billable encounter with the 
> health system (e.g. clinician visit, lab test, etc.) and ends when the 
> clinician of primary record says that the episode is complete.  For 
> curable illness this often occurs after the cure.  For chronic 
> illnesses it usually ends when the patient reaches a steady state or a 
> goal (e.g. Diabetes Mellitus with a HgA1C < 7.0 mg/dl).  For surgeries 
> it may be after the first post hospital visit.  For medical 
> hospitalizations it is often at the time of discharge.  This has two 
> important implications.  One there is one clinician who is identified 
> as the team leader of record who is charged to coordinate all of the 
> care from any provider in the health system.  Two, at the end of an 
> episode the clinician is mandated to sum up the episode and state for 
> the record what are the final diagnoses for this episode of care.
>
> I hope that this helps.
>
> Warm regards,
>
> Peter
>
> Peter L. Elkin, MD
> Professor of Medicine
> Mayo Clinic, College of Medicine
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2052 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041121/9a8f546a/attachment.bin>

A patent application covering EHRs

[Gerard Freriks]

Hi,

Lets be sensible.
A template is nothing but a screen thta can be filled.

As far as I know that has been described many times before 2001.
Isn't it?

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 23 Nov 2004, at 22:02, Tim Churches wrote:

>
> OK, many thanks. Your paper covers many of their claims, although it 
> does not mention controlling selective uploading and access to 
> particular data items via a template, which is also part of their 
> claims - but I have found another paper which desribes that. But your 
> paper covers their other claims nicely - the more the merrier!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 744 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041123/e38d0a0b/attachment.bin>

Archetype vs. ontology

[Gerard Freriks]

Hi,

An other property of the Archetype is that it is derived from a a model 
that models the structure via which information is stored/represented/ 
retrieved in a system.

GF


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 23 Nov 2004, at 17:26, Carl Mattocks wrote:

> Philippe, Sam et Al :
>
> Seeking clarification ..
>
> Is it true to say :
> the real distinction between an Archetype and an Ontology is that -
> the role of an Archetype (item) is to provide contextual constraints
> the role of an Ontology (item) is to provide conceptual constraints
>
> an Ontology (item) concept can be applied as an Archetype (item) 
> constraint
>
> an Ontology item must have object oriented properties e.g. it is 
> composed
> an Archetype item must have data (info) properties e.g. it has a type
>
> a Set of Archetype items (whether or not linked to a template) may have
> info properties that are the equivalent of a particular Ontology (but 
> not
> explicitly asserted)
>
>
> carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1107 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041123/24b94efb/attachment.bin>

A patent application covering EHRs

[Gerard Freriks]

Hi,

How serious is it really?

Is there anybody with a legal opinion?
I only have a laymans opinion about this ridiculous patent.

Gerard

ps:

A few snippets from en CEN/TC251 standard published in 1999.
CEN/TC251 ENV 13606:
1. Scope This European Prestandard specifies messages that enable  
exchange of electronic healthcare record informationbetween healthcare  
parties responsible for the provision of clinical care to an individual  
patient. These messages allow information from an electronic healthcare  
record held by one health professional to be sent to another  
healthprofessional. The messages specified by this European Prestandard  
can be used to convey:? a complete copy of a patient's record as stored  
in one information system; ? parts of a patient's record that form a  
logically sound extract or summary of that record;? parts of a  
patient's record used for updating a parallel record on another system.  
The primary purpose of these messages is to support the provision of  
care to individual patients. The availability ofconsistent, continuing  
clinical care, when and where it is needed, requires appropriate and  
unambiguous communication between clinical professionals. The messages  
specified by this European Prestandard are designed to meet  
thisrequirement by enabling users of different clinical information  
systems to exchange electronic healthcare record information.  
Implementation of these messages will therefore assist the maintenance  
of timely and appropriate patientrecords.

With a definition of Health care party:
--  3.39. healthcare party. Organisation or person involved in the  
direct or indirect provision of healthcare services to an individual or  
to a population. --
Met andere woorden. Hetgeen functioneel beschrven staat is omvat in de  
CEN voornorm voor het EPD.

The concept "Template" is mentioned.
Any input screen is a template. And before 1999 this concept was  
defined  and in use.

As far as Access Control is concerned
Part 3 of the CEN/TC251 ENV 13606 is about the expression of elements  
needed for access control.

1 Scope This European prestandard specifies data objects for describing  
rules for distribution or sharing of electronic healthcare records in  
whole or in part. This European prestandard establishes general  
principles for the interaction of these data objects with other  
components and mechanisms within an electronic healthcare record  
application, thereby controlling the distribution of electronic  
healthcare records in whole or in part. This European prestandard  
establishes ways of creating information with associated security  
attributes. This European prestandard defines a methodology for  
constructing rules built from defined data objects, capable of being  
implemented using a range of techniques, to effect the control of  
sharing of electronic healthcare record data. This European prestandard  
establishes principles that allow security policies to be implemented  
and incorporated in order to ensure the safe use of the data. This  
European prestandard specifies a method for constructing an Access Log,  
that can be rendered human viewable, that records distribution of the  
data to which a Distribution Rule is attached. This European  
prestandard does not specify the mechanisms and functions that take  
part within the negotiation procedure and therefore fully automate the  
data distribution process. This European prestandard does not specify  
the mechanisms and functions that will allow some systems to  
continuously reauthenticate the data communication session and monitor  
its integrity. This European prestandard allows the sharing of records  
distributed in space, time or responsibility. This European prestandard  
does not specify  the data objects and packages represented in an  
Information System.

At this moment I have no time to browse further.
But on the website of NIST more is to be found about Role based Access  
published before 1999.
And persons like Bernd Blobel and Ross Anderson wrote about security in  
health care


gf

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 23 Nov 2004, at 03:29, Tim Churches wrote:

> There is some concern here in Australia over a patent application  
> lodged by the Pharmacy Guild of Australia over some rather generic  
> features of EHRs. These concerns are reported here:
>
> http://australianit.news.com.au/common/print/ 
> 0,7208,11467621%5E15319%5E%5Enb%20v%5E15306,00.html
>
> or here:
>
> http://snipurl.com/atst
>
> The application has been lodged under the international PCT (patent  
> co-operation treaty), and it appears that country level applications  
> have been lodged in at least the UK, Canada and the US, as well as  
> Australia.
>
> At a glance, there would not appear to be much in the way of novelty  
> in t

Archetype vs. ontology

[Gerard Freriks]

Hi,

I can buy this.
But have you ever seen the UML model behind ICD, ICPC, or even SNOMED?

I know I;ve seen the one behind the CEN/TC251 EN 13606 where a kernel 
model (UML) representing a generic document will be populated by 
Archetypes that are derived from a Archetype model (UML).

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 24 Nov 2004, at 17:29, Carl Mattocks wrote:

> HI GF :
>
> Do you agree that this can also be true for an Ontology .
>
> carl
>
> 
>> Hi,
>>
>> An other property of the Archetype is that it is derived from a a 
>> model
>> that models the structure via which information is stored/represented/
>> retrieved in a system.
>>
>> GF
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 863 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041124/385a9fad/attachment.bin>

Archetype constraints and interfacing instruments/DSS to an OpenEHR system.

[Gerard Freriks]

Hi,
We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old rusty' 
standards.

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 29 Nov 2004, at 20:56, Damon Berry wrote:

> Sam,
>
> Thanks for the helpful comments
>
> Sam Heard wrote:
>> I believe that DSS
>> groups will be a major player in determining the final archetypes 
>> that are
>> agreed at a high level.
>>
>
> It seems to me that in the same way, archetypes will have great impact 
> on
> the development of future EHR-compatible instrument interface 
> standards. If
> instruments and instrument interfaces are required to provide 
> information
> that is complete enough to be integrated into the EHR, then additional
> context information will need to be appended as the measurement values 
> are
> recorded.
>
> Lets assume that a typical existing instrument interface was not 
> designed to
> produce shareable EHR extracts - a safe bet in my view. Result: missing
> context info. So to ensure compatibility either,
>
>  - the instrument interface is revised by the instrument vendor to 
> satisfy
> the associated archetypes
> OR
>  -  an adapter on the EHR side of the interface adds the required 
> context
> information prior to submitting it to the EHR-S proper. (not very nice)
> OR
>  - some compromise is reached on the completeness of the archetype.
> (dangerous)
>
> OK - maybe I am exaggerating - but it would be interesting to pick a
> "legacy" instrument standard (say crusty old ASTM 1394-91) and see how 
> it
> holds up.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1658 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041129/e6c62e81/attachment.bin>

Archetype constraints and interfacing instruments/DSS to an OpenEHR system.

[Gerard Freriks]

Karsten,

The advantage is that there will be no 3 or 4 competing standards, but 
just one.
It seems enough.

Gerard


-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO-PG
Zernikedreef 9
2333CK Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 29 Nov 2004, at 23:44, Karsten Hilbert wrote:

>> We, at CEN are devoted to CEN/IEEE/ISO developments and not 'old 
>> rusty' standards.
> The advantage of which is what, exactly ?
>
> Karsten
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 537 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20041130/1329336d/attachment.bin>

Flavour of null

[Gerard Freriks]

 data types are rectangular and multi relational.
atrey.karlin.mff.cuni.cz/~doug/magdon/terms.html

?   Any one of several different types of data, such as integer, 
real,  
double precision, complex, logical, and Hollerith. Each has a different  
mathematical or logical significance and may have different internal  
representation.
www.control.co.kr/dic/dic-d.htm

?   The kind of data being stored or manipulated. In programming, 
the  
data type specifies the range of values that a variable or constant can  
hold, and how that information is stored in the computer memory. There  
are four basic types: Floating-point, Integer, Double and the  
String/character data type.
www.angelfire.com/ny3/diGi8tech/DGlossary.html

?   The kind of data stored in a field. NUMERIC, COMPUTED, and  
WORD-PROCESSING are examples of VA FileMan DATA TYPEs.
www.hardhats.org/fileman/u1/glossary.htm

?   A set of values. Optionally may include the set of operators 
used  
for manipulating those values. declaration statement - A statement that  
is used to specify the attributes (ie, properties) of an identifier.
cisnet.baruch.cuny.edu/friedman/cplusplus/glossary.htm

?   Total value of landings
www.fao.org/DOCREP/003/X2465E/x2465e0g.htm

?   The type of value represented by a constant, variable, or some  
other program object. Java data types include the integer types byte,  
short, int, and long; the floating-point types float and double; the  
character type char; and the Boolean type boolean.
docs.rinet.ru/KofeynyyPrimer/ch38.htm

?   A description on a field that determines what kind of 
information  
you can enter in the field. Field data types include Text, Memo, and  
Number.
www.cs.rtu.lv/PharePub/Microsoft%20Access%2097%20Quick%20Reference/htm/ 
ch09.htm

?   On computer science, a datatype (often simply type) is a name 
or  
label for a set of values and some operations which can be performed on  
that set of values. Programming languages implicitly or explicitly  
support one or more datatypes; these types may act as a statically or  
dynamically checked constraint on the programs that can be written in a  
given language.
en.wikipedia.org/wiki/Data_type
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 08 Apr 2005, at 23:27, Sam Heard wrote:

> Dear All
>
> A reminder on why flavour of null is at the ELEMENT level: it allows a  
> composition with mandatory data to be saved even if the data is not  
> available, or allows a reason to be stated for data that is missing.  
> It also allows us to deal with the HL7 flavour of null on the data  
> types.
>
> I am concerned that the flavour of null is set to DV_CODED_TEXT and  
> not DV_TEXT (ie. it has to be coded from a terminology). I agree that  
> some systems will want things coded for safety in some situations, but  
> I believe that this should be handled through archetypes and  
> templates.
>
> Laboratories will want to use this for all sorts of reasons, one clear  
> example is when an electrolyte sample has haemolysed - and they cannot  
> give a potassium reading (they do not want to omit it!)
>
> So I want to propose that the flavour of null is set to DV_TEXT.
>
> Cheers
> Sam Heard
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 12411 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050409/60497c10/attachment.bin>

Confidence indicator [was Flavour of null]

[Gerard Freriks]

I can have 100% confidence that the patient remained silent when asked: 
"Do you have HIV?" by refusing to answer the question.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 11 Apr 2005, at 12:03, Philippe AMELINE wrote:

> So, as a summary, I would say that :
> 1) confidence applys only when there is a value, it can be a numerical 
> rating (0 to 100% in Odyssee)
> 2) Null value can have an explanation for null
> 3) The process itself should have a quality descriptor, and it would 
> be nice to have a relationship between this global information and 
> "local" data confidence.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 737 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050411/52e334be/attachment.bin>

Dr R LONJON Confidence indicator !

[Gerard Freriks]

Peter,

I like to accept ypur suggestion.

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 13 Apr 2005, at 19:55, Elkin, Peter L., M.D. wrote:

> Dear Roger and Thomas,
>
> We have looked extensively at Multivalued logic for quantitating 
> uncertainty.  It turns out that most folks in that world have taking 0 
> false and one true with a number of discrete, usually equally spaced 
> values in between for uncertainty.
>
> After a longwinded go around with a Prof of Philosophical Logic at 
> Princeton (Dr. Graham) We determined that there at least three 
> reproducible types of uncertainty (with good inter-rater reliability) 
> and ~ seven semantic categories.
>
> The types are Probable (our guess is around 85% true +/- 5%) and 
> Unlikely (our guess is around 15% true +/- 5%) or Just as likely as 
> not (again our guess is around 50% +/- 15%).  These number come from 
> the average PPV of the evidence when a physician "Makes a diagnosis" 
> and NPV when a physician rules one out.
>
> Other distinctions are less reproducible.  When taken together most 
> clinicians would say that Probable is stronger than Likely, however 
> the assignment to actual cases is not in our experience reproducible 
> between knowledgeable reviewers.
>
> I suggest that you first code (as we do) True, False or Uncertain.  
> Then qualify Uncertain with a semantic type indicating strength.  This 
> allows a model that can grow with our ability to represent more 
> closely evidence based medicine.
>
> Warm regards,
>
> Peter
>
> Peter L. Elkin, MD
> Professor of Medicine
> Director, Laboratory of Biomedical Informatics
> Department of Internal Medicine
> Mayo Clinic, College of Medicine
> Mayo Clinic, Rochester
> (507) 284-1551
> Fax: (507) 284-5370
>
>
>
> -Original Message-
> From: owner-openehr-technical at openehr.org 
> [mailto:owner-openehr-technical at openehr.org] On Behalf Of Thomas Beale
> Sent: Monday, April 11, 2005 11:42 PM
> To: openehr-technical at openehr.org
> Subject: Re: Dr R LONJON Confidence indicator !
>
> Dr LONJON Roger wrote:
>
>> hello philippe and thomas,
>> excuse me to intervene, in English of bad quality.
>> in medicine for me, a result must be validated and must be signed by 
>> the
>> producer. This result is therefore automatically a total confidence 
>> level. It
>> is a very important notion on the legal plan when these results are 
>> put to
>> disposition on a shared medical file (server web)
>>
>> Inversely if this result is approximate, with a coefficient of mistake
>> importing, it is not about a validated data and therefore 
>> publishable, because
>> consequences in r?ponsabilit? for their author are unforeseeable if 
>> the patient
>> carries complaint.
>>
>> I am unaware of this aspect of the problem so enters in your 
>> reflection.
>>
>>
> It is actually quite common: consider that in a differential diagnosis,
> confidences are always expressed in each of the possible diagnosesa,
> e.g. 90%, 9%, 1% for possible reasons for a child's fever. I don't see
> it as being about mistakes, it's about the estimation by a clinical
> professional of the probability of correctness of an opinion. In
> openEHR, confidences always appear in data of the EVALUATION type. 
> There
> is no question of clinician confidence in OBSERVATIONs - they are for
> all intents objective. Of course, machines may have limited accuracy
> (inbuilt error) and numeric results may be reported with limited
> precision; these situations can be archetyped.
>
> - thomas
>
>> Cordially
>>
>> Dr R LONJON
>> france
>>
>>
>
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3806 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050414/7f331f05/attachment.bin>

Dr R LONJON Confidence indicator !

[Gerard Freriks]

-1- Almost never a diagnosis is 100% certain.
-2- Almost always a test result has uncertainty attached to it
-3- Many times a conclusion is reached based on many uncertain and 
conflicting facts
-4- Quite often a condition, a diagnosis, is assumed that gives rise to 
a treatment. Not indicating that the patient is suffering from this 
condition but using treatment as a test procedure. Doing nothing is 
such a test procedure.

Eric Wulff (from Danmark) published philisophical texts about health 
care and these topics.

gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 20 Apr 2005, at 13:58, Thomas Beale wrote:

> I'm wondering if there is a meta-algorithm of some sort lurking behind 
> the scenes, which takes account of uncertainty in a note, and also 
> severity of non-discounted possibilities, as a way of deciding what to 
> do next. There is undoubtedly published work on this...
>
> thoughts?
>
> - thomas beale
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1072 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050422/bbb58527/attachment.bin>

EntityNameParts

[Gerard Freriks]

We must get used to the notion that patients not always have to provide 
their real names.
And that in order to provide healthcare we need to know the real 
(administrative) identity.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 17 Mar 2005, at 13:50, Grahame Grieve wrote:

> At 11:29 PM 17/03/2005, you wrote:
>> > Richard is often abbreviated to Dick in English usage.
>> > No idea what the origin is - lost in the mists of time.
>> >
>> > So, if you get
>> >   initial = D
>> >   given = Richard
>> >
>> > you don't know that the D is an abbreviation for Richard.
>> > And if you do know that it is, there's no way to say so
>>
>> Well, is there a *need* to say so ? What's fundamentally
>> wrong with just storing the D as a second first name along
>> with Richard ? I probably am too much of a pragmatist.
>
>
> hi Karsten
>
> depends which hat I'm wearing. If I'm programming, then
> I probably won't care - delegate the problem to the user.
>
> If I'm wearing my standards hat, or writing a reference
> demographics server, then I would care
>
> Grahame
>
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1211 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/b5c55b72/attachment.bin>

OIDs / II

[Gerard Freriks]

Dear all,

My ideas:
- unique identifiers are numbers that are unique.
- each collection of information that has an attribute with this unique 
number can be collected and presented as belonging together,
- with one unique identifier per (pseudo)identity all information 
belonging to this unique identifier can be collected and presented as 
belonging together
- this type of use is identifying documents (or parts of it) as 
containing information about the same person with a specific identity.

- it is NO PROOF of the real identity of the person. That is a 
different matter.

- When we have to uniquely identify persons we need other things than 
numbers.
- Unique numbers must not be trusted.
- Unique numbers that identify persons generate problems: identity 
theft.
- Only knowledge that is known by the person, or features his body 
posesses, will help to identify persons.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 20 Apr 2005, at 12:43, Bert Verhees wrote:

> Dear Grahame,
>
> For example the CEN GPIC subjectofcare which has a property id
> The type is a Set of II
> The use is excplained as:
> "An identifier or identifiers that may be used to uniquely identify the
> subject of care.
> Examples: social security number, health service number, hospital
> number, case notes number"
>
> Please indicate where there is a mismatch between the intention and the
> use of II.
>
> CENTC251 could learn from that. It would be a great benefit to the
> standard if this would be sorted out.
> And if it will, then the need for an extra qualifier to tell which the
> type of identifier is presented, may disappear, depending on your 
> solution
>
> Kind regards
> Bert Verhees
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1829 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050426/14704952/attachment.bin>

EntityNameParts

[Gerard Freriks]

Disasters or not.
This is not what I ment.

In real life we buy a loaf of bread without a full identication.
In real life I get healthcare without the need for the care providers 
to know my name.
And when I pay in cash they don't need my bank account number.

The only need a unique identifier (set of) to find records filed 
previously.
Any unique thing will work as well.
A real name, address, data of birth, or
my bankaccount,
the date of my mothers birthday,
a token,
a phoney name,
or an other unique thing like a series of scars on my skin, a 
photograph, my fingerprint, etc, etc

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 26 Apr 2005, at 09:56, Bert Verhees wrote:

> Op dinsdag 26 april 2005 07:37, schreef Gerard Freriks:
>> We must get used to the notion that patients not always have to 
>> provide
>> their real names.
>> And that in order to provide healthcare we need to know the real
>> (administrative) identity.
>
> When you build a system that is only usable when you have a working
> Internet-connection, in my humble opinion, this is a bad system.
>
> There are many situations where you don't have good networks, think of 
> war,
> tsunamies, big disasters, maybe you want to register people for the
> healthcare they get, but if a stupid application refuses to accept a 
> patient,
> because the OID cannot be resolved (when you say mandatory to a 
> programmer,
> he will make it mandatory), tha application will be useless.
>
> But this example is beyond the scope of my problems (for now).
>
> Bert
>
>>
>> Gerard
>>
>> --   --
>> Gerard Freriks, arts
>> Huigsloterdijk 378
>> 2158 LR Buitenkaag
>> The Netherlands
>>
>> +31 252 544896
>> +31 654 792800
>>
>> On 17 Mar 2005, at 13:50, Grahame Grieve wrote:
>>> At 11:29 PM 17/03/2005, you wrote:
>>>>> Richard is often abbreviated to Dick in English usage.
>>>>> No idea what the origin is - lost in the mists of time.
>>>>>
>>>>> So, if you get
>>>>>   initial = D
>>>>>   given = Richard
>>>>>
>>>>> you don't know that the D is an abbreviation for Richard.
>>>>> And if you do know that it is, there's no way to say so
>>>>
>>>> Well, is there a *need* to say so ? What's fundamentally
>>>> wrong with just storing the D as a second first name along
>>>> with Richard ? I probably am too much of a pragmatist.
>>>
>>> hi Karsten
>>>
>>> depends which hat I'm wearing. If I'm programming, then
>>> I probably won't care - delegate the problem to the user.
>>>
>>> If I'm wearing my standards hat, or writing a reference
>>> demographics server, then I would care
>>>
>>> Grahame
>
> -- 
> Met vriendelijke groet
> Bert Verhees
> ROSA Software
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2855 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/e904c0ac/attachment.bin>

EntityNameParts

[Gerard Freriks]

In order to get proper treatment the identity can stay obscure.
Identification is not a necessary condition for any treatment.

Information is sometimes.


Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 27 Apr 2005, at 06:19, Grahame Grieve wrote:

> It's not the same. For various reasons care providers (may) need
> to properly identify their patients/customers. Healthcare may be
> provided on an anonymous basis under some circumstances, but the
> nature of these circumstances and the care provided will depend
> on jurisdiction
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 692 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050427/8f48b6a2/attachment.bin>

OIDs / II

[Gerard Freriks]

Thomas,

Will you bring this topic up in Berlin?

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 27 Apr 2005, at 13:48, Bert Verhees wrote:

> Op woensdag 27 april 2005 11:21, schreef Thomas Beale:
>> Bert Verhees wrote:
>>>> presented as belonging together,
>>>
>>> it is not that simple, a collection of information can have more 
>>> then one
>>> number, and the CEN-standard does not provide meta-information in 
>>> some
>>> cases, f.e. PatientExtendedInformation carries a Set, which is a 
>>> set
>>> of numbers (identifiers), those numbers in a list do not have
>>> meta-information, except for the OID, but that meta-information can 
>>> only
>>> be resolved over a network-service (which does not yet exist).
>>
>> as I have indicated before, I think that CEN needs the data type we
>> added to openEHR - DV_INDENTIFIER, whose definition is below. I also
>
> It would help me a lot if CEN would take this instead of the original 
> ID, this
> one has all what is suitable for my purpose
>
> Bert
>
>> don't agree that it is realistic to identify everything with OIDs. 
>> There
>> are three reasons, the major one Bert has already given.
>>
>> 1. non-accessibility and/or performance of resolving engine
>> 2. size of ids inside data, particularly data fragments that can never
>> be sensibly accessed globally, only from within the context of some
>> larger blob. E.g. it doesn't make sense to access a single ELEMENT in 
>> a
>> CEN CLUSTER/ELEMENT tree, so why attach a 20 digit Oid to it?
>>
>>
>> class DV_IDENTIFIER
>> inherit
>> DATA_VALUE
>>
>> feature -- Access
>>
>> issuer: STRING
>> -- Issuing agency of these kind of ids
>>
>> id: STRING
>> -- The identifier value. Often structured, according to 
>> the
>> -- definition of the issuing authority?s rules.
>>
>> type: STRING
>> -- The identifier type, such as ?prescription?, or ?SSN?.
>> -- One day a controlled vocabulary might be possible for 
>> this.
>>
>> invariant
>> issuer_valid: issuer /= Void and not issuer.is_empty
>> id_valid: id /= Void and not id.is_empty
>> type_valid: type /= Void and not type.is_empty
>>
>> end
>>
>>
>> - thomas beale
>>
>>
>> -
>> If you have any questions about using this list,
>> please send a message to d.lloyd at openehr.org
>
> -- 
> Met vriendelijke groet
> Bert Verhees
> ROSA Software
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2630 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/b29ecbf6/attachment.bin>

The Uncertainty Decision was: Dr R LONJON Confidence indicator !

[Gerard Freriks]

The EHR is not invented to describe the real actual health status of 
the patient.
It is there to document what clinicians deemed important to say ABOUT 
the health status of the patient.
It always is an opinion of a professional about something.

He, himself, always makes statements with varying degrees of certainty.
Physicians are no gods that know everything.

Readers of the statements made by others necessarily don't take 
everything for granted what other have stated.
So again at the receiving side things are interpreted in varying 
degrees of certainty.

Answering your question:
> So back to the short answer above.is it really relevant to assert
> ANY confidence factor in the EHR?
>

The answer is YES

Gerard



-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 27 Apr 2005, at 13:01, Arild Faxvaag wrote:

> Tim Cook wrote:
> While it might be an interesting exercise for us to record how 
> confident
> a clinician was at the time of recording a diagnosis, it will have no
> impact on the health care of that patient.  If we were to do this would
> we ask them to do so in 10% steps, 5% steps or .01%
> steps?  I assert that any one of these would seriously impact
> the usability of an EHR in a negative manner and would result in the
> clinician taking the option that presents the least liability on their
> part.
>
> So back to the short answer above.is it really relevant to assert
> ANY confidence factor in the EHR?
>
>
> My opinion is that there indeed is highly relevant to assert a 
> confidence factor in the EHR.
>
> ln decision analysis one talks about treatment thresholds for 
> diagnostic uncertainity as "the probability of disease at which the 
> expected value of treatment and no treatment are exactly equal, and ne 
> ither option is clearly preferable." (Hunik and Glasziiou "Decision 
> making in health and biomedicine"). Factors influencing the treatment 
> threshold are the expected benefit and the expected harm of the 
> treatment.
> Example: Treatment threshold is much lower for pneumonia (treatment: 
> penicillin) than for cancer of the left mamma (treatment: Mastectomy)
>
> Thus: How confident a clinician is at the time of recording a 
> diagnosis has high impact on the health care of that patient.
>
> Comments on this?
>
> regards,
> Arild Faxvaag
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2656 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/c4d3ceb2/attachment.bin>

The Uncertainty Decision was: Dr R LONJON Confidence indicator !

[Gerard Freriks]

Sam,

I agree.

Suggestion
In otherwords any clinical  (or non-clinical) concept model must be 
able to express the view of the author about certainty.
3 states are sufficient for starters:
likely (as default)
not-likely
certain

When a person attaches new information to the EHR and is of the opinion 
that whole or parts of a received  extract (or EHR) need an other 
qualifyer then via versioning he must be able to annotate this by 
adding his beliefs about certainty.


Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 27 Apr 2005, at 23:25, Sam Heard wrote:

> Arild and Tim
>
> This is clearly an issue. In the CIP project the group wanted to be 
> able to say that a diagnosis was a working diagnosis.
>
> We have archetyped a number of concepts that I think will enable the 
> clinician to express these levels of uncertainty without resorting to 
> confidence ratings on all entries in the record. Arild has shown that 
> you could not possibly do a mastectomy without rating your certainty 
> at 100% - or you will be sued. And not treating a pneumonia in a 
> newborn with a certainty of only 20% will probably get you in trouble. 
> These sort of explicit ratings are - in my opinion - very problematic.
>
> The solution lies in the recording constructs used for many years:
>
> 1. To express differential diagnoses (with or without probabilities) 
> and to note key excluded diagnoses as well.
>
> 2. To express a diagnosis as a problem (such as lump in left breast) 
> even if the likelihood of cancer is 100% clinically until the 
> histology is returned.
>
> 3. To be able to label a diagnosis as a working diagnosis - ie it is 
> likely enough to warrant the current management - but not certain. 
> Appendicitis is a good example.
>
> So the archetypes for problem, problem-diagnosis (specialised) and 
> differential diagnosis should meet these needs.
>
> Comments?
>
> Sam
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1999 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050428/2b2579c2/attachment.bin>

RFC - CR-000150 - express language etc as a String

[Gerard Freriks]

My ideas about this are:

- coding systems never will be stable.
- the way to handle change in OpenEHR (and CEN En13606) is via  
archetypes.
- select a coding system and produce a 'ancestor archetype' that uses  
codes from a specific coding system.
- over time a new 'ancestor-archetype' will be produced using a new  
version of the specific coding system or a new coding system altogether.
- the question now is how to handle interoperability. The answer is  
the use for an 'archetype ontology'. One we miss at this moment.
- having this 'archetype ontology' makes it possible to define  
synonyms, anti-nyms, etc, and make semantic interoperability possible.
- for it to work properly we need:
 'ancestor archetypes', that can be inserted in Templates
 an archetype ontology
 an 'archetype editor' that is able to not only produce  
archetypes and templates but also assemble ancestor archetypes and  
normal archetypes into templates but also constrain each of them  
further.

Gerard Freriks

ps: I use sometimes the term 'proto-archetype' for the 'ancestor- 
archetype'
-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

T: +31 71 5181388
M: +31 654 792800


On 20-aug-2005, at 22:45, Rong Chen wrote:

> I agree. We need to have this indirection to handle changes.
>
> Even if we are certain that these codes will not change in the  
> future and we feel the need to hardcode them in the software, some  
> enumeration type instead of string type should be used to implement  
> them since string is not type safe.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050821/464c26a4/attachment.html>

RFC - CR-000150 - express language etc as a String

[Gerard Freriks]

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 21-aug-2005, at 14:38, Thomas Beale wrote:

> Gerard Freriks wrote:
>
> well, in general that's the idea. But the question at hand is about  
> coding in the reference model itself, i.e. for the structural (hard- 
> wired) attributes that have coded values - in other words, things  
> which we have specifically chosen not to archetype.
> There isn't much mileage in archetyping the code-set of  
> ENTRY.language, for example - we don't want to open such a basic  
> thing up to variation in archetypes. Instead we want it controlled  
> inside the reference model and openEHR vocabularies. The original  
> question of CR-150 was whether we should bypass even this  
> flexibility and simply specify that such attributes are of type  
> String (or maybe an enumerated type) and hard code them into the  
> model. In my view, this is problematic in all sorts of ways - the  
> main one is that each implementor will do this in a different,  
> probably in compatible way.

I agree.


>
>
>> - select a coding system and produce a 'ancestor archetype' that  
>> uses codes from a specific coding system.
>>
>
> This topic of 'ancestor archetypes' is a different issue. I am not  
> yet sure what they are - are they any different from a normal  
> specialisation parent archetype?

Certain archetype fragments will be needed. They are the prototypic  
ones. The ones I'm calling 'ancestor archetypes' are the standardised  
starting points we use to derive archetypes of.
They act as the start of families of archetypes.
The ones dealing with observations, the ones expressing measurements,  
etc.



>
>
>> - over time a new 'ancestor-archetype' will be produced using a  
>> new version of the specific coding system or a new coding system  
>> altogether.
>>
>
> well, this already happens for the code-sets fo language and  
> country etc, using the openEHR vocabulary approach for them - that  
> is, we have openEHR_language and openEHR_country vocabularies which  
> wrap the ISO code-sets; this allows us to change what they wrap,  
> add extra codes and so on.
>

Good. Am I correct to see the wrapper as the 'ancestor archetype' and  
the variants as archetypes each constraining the 'ancestor'.

>
>> - the question now is how to handle interoperability. The answer  
>> is the use for an 'archetype ontology'. One we miss at this moment.
>>
>
> in general, that's true, but it wouldn't make any difference for  
> the basic vocabularies of language and territory.

Several parts of the archetype ontology will we extremely simple.  
Other parts will not.


>
> - thomas
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050821/1ab42fd6/attachment.html>

RFC - CR-000150 - express language etc as a String

[Gerard Freriks]

Thomas,

read below.

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 22-aug-2005, at 13:07, Thomas Beale wrote:

> ah, well, you know my view on that! I beieve that basic categories  
> such as Observation, Evaluation, Instruction and Act belong in the  
> reference model, for two reasons:
> a) it proves possible to devise formal models of such concepts  
> which work for all possible specific types of the same concept.  
> This is proven by building archeytpes. For example, no matter what  
> kind of clinical observation we model with an archetype, the  
> openEHR Observation concept still works. In some recent cases  
> described by Grahame Grieve and Sam Heard, there may be a small  
> change needed. This is how these classes can be evolved into solid,  
> invariant definitions which work for all clinical uses.

The items you mention have to be part of a standard. We agree fully.
The reference model or an other place is fine. As long as it is part  
of a standard.

The problem is where? I reserved in my mind part 3 of EHRcom for this.

>
> b) we want to avoid the situation where archetype developers, or  
> even develpers of 'proto-archetypes' are arguing about what an  
> Observation, Evaluation etc are, and producing competing ancestor  
> archetypes of differing versions of the concept. This will not help  
> interoperability, and in any case, isn't even an interesting topic  
> for most clinical people. They want to model concepts like  
> "Haemaglobin A1c measurement", not "Observation". There is already  
> a place for those that do want to debate what an Observation is:  
> the reference model - they can always review that, and propose  
> changes.
>
> Sam and I have a paper under development which provides what we  
> think is a solid theoretical and practical basis for basic types in  
> the reference model, and provides a comprehensive typology of Entry  
> subtypes. I think this will make the matter of what 'proto- 
> archetypes' should and should not be used for clearer.

Looking forward to an early draft.
It will get my full attention.

GF
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050822/261aed1e/attachment.html>

Age and named quantities

[Gerard Freriks]

Sam,

You mean the 'age of a person' and not 'age'.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 31 Jan 2005, at 23:30, Sam Heard wrote:

> Age is time after birth - we are not going to change that.
>
> We have agreed that we need to record one more date in the demographic 
> model - which is 'approximate date of conception', or 'expected date 
> of birth'
>
> Which do people prefer - I chose the latter as it will probably be a 
> cut and paste from the mothers record and does not get into the when 
> did I conceive stuff.
>
> What do others think?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 704 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/da6509b2/attachment.bin>

Age

[Gerard Freriks]

Hi,

Age=: Time since an reference event took place and is expressed as: 
lightyears, years, months, days, minutes, seconds (and parts thereof)
There is one fixed reference point and one changing (non-fixed) 
reference point in time.

e.g.
Event: big bang of our universe -> age of the universe
Event: birth of a person -> age of a person

Puberty=: ???
What is the reference event? Start of sexual development? Certain 
hormonal changes? Or is this the time of birth?
We have two fixed reference points (two fixed referenced events) in 
time and no non-fixed point in time.
This type of concept is clearly different from the 'Age' concept as 
defined above.

My point is:
Concepts like these are expressed in the same manner as 'Age'.
But are different.
Question to be answered: How will we name these two distinct types of 
concepts?
Peter is using the term 'relative age' to indicate things like puberty, 
or menopause.
Both types of concepts are relative since any time measurement is 
relative.
So we need a better term.

In my system of concepts
'Age of a person' is just one  of the  co-ordinates to place an object 
in time-space with its birthdate as reference event

'Age at which a person entered the state of puberty' is not placing a 
person in time-space co-ordinates. It is indicating a change of state 
of the person and the time at which this took place expressed using the 
concept 'age of a person'. It is expressing a functional aspect 
belonging to the person.

Gerard



--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 01 Feb 2005, at 02:45, Elkin, Peter L., M.D. wrote:

> I agree with using date of birth for making the determination of an 
> individual's age, as long as we have support for relative age for 
> concepts such as puberty, menopause, at an age of risk given their 
> family history of a malignance with a first degree relative whose 
> onset of illness was at a certain age.  Relative age also includes 
> number of years since an event like an MI or a CABG which are both 
> medically relevant relative periods of time which are a type of age 
> (years since event) with clinical relevance.
>
> Warm regards,
>
> Peter
>
> Peter L. Elkin, MD
> Professor of Medicine
> Director, Laboratory of Biomedical Informatics
> Department of Internal Medicine
> Mayo Clinic, College of Medicine
> Mayo Clinic, Rochester
> (507) 284-1551
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2517 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050201/867c7508/attachment.bin>

Age

[Gerard Freriks]

Hi,

There are two concepts with the name 'age'.

Age as a number. Age=56
Age as a process. baby, youth, post conception, gestational,

As with many concepts we have two different concepts with the same name 
in daily life.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 26 Jan 2005, at 17:58, Sam Heard wrote:

> Tom and others
>
> The idea of age as a complex notion - post-conception, gestational 
> (LMP) ie it can involve pre-birth periods - even well into life. This 
> apperas to be important for decision support.
>
> I wonder if we need to model this as an archetype for demographics - 
> but it needs to be in the EHR - age crops up in lots of evaluations 
> (problem, family history) so we might need to have it as a formal 
> TYPE! That is - we can use it consistently in various settings.
>
>
> I would argue that gender is of the same nature - with social gender, 
> physical gender and genetic gender as the key concepts.
>
> No doubt there are others but these two are worth thinking about 
> carefully.
>
> Sam
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1264 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050127/df1356f7/attachment.bin>

Age, gender and more

[Gerard Freriks]

Hi,

We need a third type of concept dealing with Age.

-3- After life :-)

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 27 Jan 2005, at 13:32, Sam Heard wrote:

> Hi
>
> Gerard has raised other issues - there are names for age-ranges or 
> phases such as adolescence, neonatal, toddler. It may be too much for 
> us to deal with but age is certainly not just a number - you just have 
> to ask the mother of a small baby - it has units like days, weeks, 
> months.
>
> I think Gerard missed the point of post-conceptual age - it is the 
> time since conception and if a child is born very early, remains the 
> basis on which dosing and milestones are based - sometimes for years 
> after birth.
>
> This was raised as a key issue in systems for paediatricians.
>
> So I was wondering if we should model a class specifically for date of 
> birth.which handles date of birth and age as a function, and which 
> takes arguments like date of conception, date of mothers LMP, Expected 
> Date of Delivery and stores the normal gestational birthdate as well. 
> The class then has a feature called post-conception age as well.
>
> The advantage is that we could even deal with things like 'post-natal' 
> as a function (actual birth to day 28) and other phases in future if 
> appropriate. It would mean that in family history you could enter 
> 'young adulthood' as an age which might be better than guessing 22.
>
> Further, I think in our DateTime class we should store text as well as 
> the date if people want - this would allow us to store "4.30 
> yesterday" if a transcription tool wanted to - and the actual date 
> time. This can make observational data much easier to read when 
> scanning back.
>
> It also means that we can deal with almost impossible fuzzy times like 
> 'last night' in some reasonable fuzzy way without losing the key 
> information.
>
> In our timing specification for workflow the same will have the same 
> issue ie we may need the text as well as the computable data - three 
> times a day might be at 08:00, 16:00 and 00:00, but it is a different 
> instruction than 8 hourly (where there is no flexibility on spacing of 
> doses).
>
> Thats enough for now...but I am thinking of putting a change request 
> together if there is enough interest. The DateOfBirth issue will win a 
> lot of friends in paediatrics...they are really concerned that their 
> absolute requirements are never addressed in systems!
>
> Cheers, Sam
>
>
>
>
> Any more thoughts?
>
> Sam
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2558 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050127/b8ee4363/attachment.bin>

Age

[Gerard Freriks]

Dear Philippe,

Thank you for your reaction.

I'm interested in your model for cyclic events.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 27 Jan 2005, at 20:15, Philippe AMELINE wrote:

> Hi,
>
> In Odyssee, we have made the choice of :
>
> 1) defining the concept "Age" as an ellapsed time value
> 2) defining age related concepts (like "child", "old person"...) as
> fuzzy sets
>
> I think that it is the only way you can manage this kind of thinks.
>
> We also have a (quite) good model for cyclic events ; I can describe it
> further if you want.
>
> Cheers,
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 717 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050128/193aeccc/attachment.bin>

Age

[Gerard Freriks]

Thomas,

What you wrote with respect to age, is absolutely true.
It is a notion defined at the knowledge layer.
But expressed at an information model layer.

On the level of the knowledge layer 'age' is more than a set of numbers 
indicating the time past since an arbitrary point in time.

Next to 'age' there will be more notions that warrant the same 
discussions we have had.

Gerard




--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 29 Jan 2005, at 02:07, Thomas Beale wrote:

> This all suggest strongly to me "knowledge layer" not "information 
> model layer"!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 721 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050129/bc222482/attachment.bin>

Age

[Gerard Freriks]

Dear all,

It is fine for me when we can agree that we mean by 'Age' time after 
birth.

How will we name and define concepts like: youth, post conception, post 
gestation, middel aged, elderly?

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 31 Jan 2005, at 19:10, William E Hammond wrote:

> For an age, I agree that the date of birth is adequate as long as you
> remember people do not age after they die.  It is also convenient to 
> have a
> reference time mark for many things, including conception, start of a
> course of treatment.  Adjectives and nouns are difficult to put into
> algorithms unless the definitions are precise.
>
> Ed Hammond
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 802 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050131/dfe55f71/attachment.bin>

Demographics service

[Gerard Freriks]

Life is simple.

Once we physicians know what to ask and why.

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 05 Mar 2005, at 13:22, Bigpond wrote:

>
> And that's the problem that will keep the technical people in money for
> years to come. Not only must it be feasible it will be demanded by 
> judges
> and courts if the EHR is to ever be truly adopted. Even now we have 
> rules
> that all e-mails where a decision is made must be printed out!
> The paperless world has never been to court.
> It is feasible of course but complex. Flags are set when pages are 
> viewed,
> there are intricate audit trails (terabytes). The fact that no one is 
> doing
> it yet is that the litigation costs haven't risen high enough to 
> balance the
> need to do it. Once a few specialists are sued for activities that can 
> not
> be supported by the record and they known they were innocent then we 
> will
> see some very interesting changes, either a reappearance of paper 
> records
> (personal) or a new paradigm of image capture. IMHO of course.
>
> David
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1174 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050305/55b087ca/attachment.bin>

Demographics service

[Gerard Freriks]

TNO, the institute I work for, is of the opinion that the archiving 
solution is the preferred one.

By the way.
The topic started discussing demographic services.

In general interoperability translates into the need for many shared 
points of reference.
So for identities of persons as wel.
Since persons are recorded in systems using a set of more or less 
unique features and since these unique features vary in time, one 
person will have many digital identities.
This calls for a mechanism that unites all these variations on one 
theme.
Eg the demographic server.


Gerard

--  --
Gerard Freriks
TNO Kwaliteit van Leven
Wassenaarseweg 56
Leiden

Postbus 2215
2301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 05 Mar 2005, at 19:46, lakewood at copper.net wrote:

> Other:
> -If something crucial shows up on your monitor screen, do a Screen 
> dump to a file
> and create a time/date stamped archive. It is a record and a mechanism 
> exists to
> produce a permanent copy easily reproduced on paper.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1095 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050306/fba2a5bc/attachment.bin>

Demographics service

[Gerard Freriks]

Hi,

What is the definition, scope, function of the concept:
" demographic server"
in the context of OPENEHR?

Thomas, Sam, Dipak: HELP!

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 06 Mar 2005, at 19:50, lakewood at copper.net wrote:

> Hi Gerard,
>
> My understanding is that demographic services collect, organize and 
> process the
> characteristics of a 'population'. Presuming this, then I am a member 
> of a large number
> of  'populations' regardless of intent. Narrowed to Healthcare the 
> number of
> 'populations' shrinks but not to one.
>
> Given the fact that modern 'populations' are not 'stationary' it 
> appears that there are
> many of us that can claim or hold membership in multiple Healthcare 
> 'populations'
> which themselves are subject to new additions, e.g., those genetically 
> sensitive to
> drugs of a particlular family.
>
> Identifying the indiviudal may have to be a separate operation. 
> Identifying whether the individual
> is a member of a 'population', or 'populations's a subsequent task.
>
> A 'demographic server' is likely to be specific and limited in scope 
> to address
> 'super populations', e.g., persons residing within the boundaries of a 
> specific geographical
> region, e.g., Africa. A 'network' of such server could provide 
> additional coverage.
>
> Since one can apply a variety of rules to the specification of an 
> individual 'population',
> the 'rules' become significant especially where the 'rules' are chosen 
> to affect results,
> all Diabetes Patients in the London area. Due to a number of reasons 
> one may not be able
> to claim that London-area Diabetes Patients are the same as those in 
> other regions, and, of course, that the Healthcare systems are the 
> same or equivalent.
>
> Foundational is 'personal identification'. Without it a 'demographic 
> server' is handicapped.
> Hence a good test for the server is a seriously injured person 
> arriving at a Healthcare
> facility unable to communicate with no other form of identification.
>
> Since there are many other 'issues' and 'factors' important to the 
> design, development and
> deployment of a 'demographic server'  one may have to accept 
> discussions that attempt
> to integrate topics. They are valuable R&D efforts are 
> results-oriented expectations are
> very likely to increase quickly.
>
> Regards!
>
> -Thomas Clark
>
> BTW: I tried to avoid bringing 'Public Health' into a discussion about 
> 'demographic servers'.
> That would have been lengthy!
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2567 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050306/5bb8ff52/attachment.bin>

Demographics service

[Gerard Freriks]

HI Thomas,

Thanks.
I know for certain we (and possibly OpenEHR) is using the term  
'Demographic server" for other notions.

SO lets wait for the other Thomas to tell us what OpenEHR means.

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 06 Mar 2005, at 21:46, lakewood at copper.net wrote:

> Hi Gerard,
>
> Some possible applications and sources:
>
> 'coronary and stroke event rates in the population' (project-oriented)
> http://www.ktl.fi/publications/monica/demoqa/demoqa.htm#Discussion
>
> Deaths - lethal Dosage
> http://www.ohd.hr.state.or.us/chs/pas/ar-tbl-1.pdf
>
> UN Statistics
> http://unstats.un.org/unsd/demographic/sconcerns/disability/ 
> disform.asp?studyid=223
>
> Hearing:
> http://gri.gallaudet.edu/Demographics/factsheet.html
>
> Center for Demographic Study
> http://cds.duke.edu/publications/search/search_results_ALE.htm
>
> HIV/AIDS:
> http://www.dph.sf.ca.us/HIVPrevPlan/HPPC01FnlRpt/ch3p61~1.pdf
>
> RAND/HEALTH:
> http://www.rand.org/health/archive/sociodemographic/
>
> Center for the Advancement of Health:
> http://www.hbns.org/newsrelease/after8-8-00.cfm
>
> Where related to Healthcare demographics the EHRs may have to  
> incorporate the
> demographics.
>
> Regards!
>
> -Thomas Clark
>
> Gerard Freriks wrote:
>
>> Hi,
>>
>> What is the definition, scope, function of the concept:
>> " demographic server"
>> in the context of OPENEHR?
>>
>> Thomas, Sam, Dipak: HELP!
>>
>> Gerard
>>
>> --  --
>> Gerard Freriks, arts
>> Huigsloterdijk 378
>> 2158 LR Buitenkaag
>> The Netherlands
>>
>> +31 252 544896
>> +31 654 792800
>> On 06 Mar 2005, at 19:50, lakewood at copper.net wrote:
>>
>> Hi Gerard,
>>
>> My understanding is that demographic services collect, organize
>> and process the
>> characteristics of a 'population'. Presuming this, then I am a
>> member of a large number
>> of 'populations' regardless of intent. Narrowed to Healthcare the
>> number of
>> 'populations' shrinks but not to one.
>>
>> Given the fact that modern 'populations' are not 'stationary' it
>> appears that there are
>> many of us that can claim or hold membership in multiple
>> Healthcare 'populations'
>> which themselves are subject to new additions, e.g., those
>> genetically sensitive to
>> drugs of a particlular family.
>>
>> Identifying the indiviudal may have to be a separate operation.
>> Identifying whether the individual
>> is a member of a 'population', or 'populations's a subsequent  
>> task.
>>
>> A 'demographic server' is likely to be specific and limited in
>> scope to address
>> 'super populations', e.g., persons residing within the boundaries
>> of a specific geographical
>> region, e.g., Africa. A 'network' of such server could provide
>> additional coverage.
>>
>> Since one can apply a variety of rules to the specification of an
>> individual 'population',
>> the 'rules' become significant especially where the 'rules' are
>> chosen to affect results,
>> all Diabetes Patients in the London area. Due to a number of
>> reasons one may not be able
>> to claim that London-area Diabetes Patients are the same as those
>> in other regions, and, of course, that the Healthcare systems are
>> the same or equivalent.
>>
>> Foundational is 'personal identification'. Without it a
>> 'demographic server' is handicapped.
>> Hence a good test for the server is a seriously injured person
>> arriving at a Healthcare
>> facility unable to communicate with no other form of  
>> identification.
>>
>> Since there are many other 'issues' and 'factors' important to the
>> design, development and
>> deployment of a 'demographic server' one may have to accept
>> discussions that attempt
>> to integrate topics. They are valuable R&D efforts are
>> results-oriented expectations are
>> very likely to increase quickly.
>>
>> Regards!
>>
>> -Thomas Clark
>>
>> BTW: I tried to avoid bringing 'Public Health' into a discussion
>> about 'demographic servers'.
>> That would have been lengthy!
>>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4206 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050306/b49bbe63/attachment.bin>

Authenticity Issues [was: Re: Demographics service]

[Gerard Freriks]

Hi,

It is known for quite some time that digital signatures are not the  
best solution to encrypt information that has to be archived.
For functions like this we need a real person/organisation that  
provides this archiving function.

see by Ross Anderson:
http://www.usenix.org/publications/library/proceedings/ec98/ 
full_papers/anderson/anderson.pdf

Gerard


--  --
Gerard Freriks
TNO Kwaliteit van Leven
Wassenaarseweg 56
Leiden

Postbus 2215
2301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 07 Mar 2005, at 02:02, Sebastian Garde wrote:

> Hi,
>
> There is another issue with digital signatures in the context of EHRs:
> Their value decreases over time and with them the value of digitally
> signed documents as legal evidence.
> In other words: securely signed documents don't necessarily provide a
> secure basis for verifying authenticity for the required time-span of
> EHRs (30 and more years).
>
> This is due to the following reasons:
>  - the employed cryptographic algorithms and the keys lose their
> security qualification in the course of time. (algorithm may found to  
> be
> insecure, key length may be too short for increased computer power,..)
> - It cannot be guaranteed that the directories and documents needed for
> the verification of the underlying certificates are available for 30
> years or more.
>
> In addition, the use of digital signing procedures is often insecure  
> and
> information for the subsequent evaluation of the actual security is
> missing.
> To achieve high conclusiveness of digitally signed documents and to
> realize their integration into practical use, the documents complete
> life cycle ranging from generation of the document, generation of the
> signature, presentation, communication to (long-time-)archiving and
> later use have to be taken into account in a comprehensive way.
>
> For a truly long-term-solution for EHRs, a solution must be provided  
> for
> this problem.
> If you are interested in details, see http://www.archisig.de/english
>
> Further, signed data may - of course - not be changed in order to keep
> electronic signatures valid. But when data has to be exchanged across
> networks, or in context of systems migration, such changes are
> inevitably occuring. Trying to avoid this with the help of new
> standardized and stable data formats contradicts experiences (although
> openEHR itself might be a solution for this problem).
> So, procedures are necessary to convert signed documents and preserve
> their evidence value (legally secure transformation). See
> http://www.transidok.de/index-en.html for details.
>
> Regards,
> Sebastian
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2674 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050307/1216af1f/attachment.bin>

archetypes and class constraints

[Gerard Freriks]

The beauty of OpenEHR (and CEN/TC251 EN 13606) is the fact that we have 
a reference document model that because of its stability help store and 
retrieve persistent documents over long periods of time.

Being able to change the reference document model will create problems 
by to much divergence.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 08 Mar 2005, at 01:58, Carl Mattocks wrote:

>
> I vote for the pragmatic approach when we don't control the reference 
> model
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 633 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050309/18564377/attachment.bin>

EntityNameParts

[Gerard Freriks]

Hi,


As convenor of CEN/TC251wg1 responsible for the EN13606 EHR standard 
I'm reading with interest the e-mail exchanges.

It is good to understand that:
- the EN13606 EHR standard is a European standard that contains several 
open ends (optionalities, abstract data types instead of implementable 
data types, etc)
- the application of the standard needs an Implementation Specification 
that is valid in a certain domain.

Discussions like these between implementers are very valuable.
a) they result in implementation specifications.
b) they inform the standards makers and help improve the standard.

I support Thomas idea to summarise important threads and store them in 
a FAQ repository.
This will help produce localised Implementation Specifications.

Gerard Freriks

ps: Hopefully an national  implementation  process will this year start 
in the Netherlands.
The proposal is to produce a Controlled Open Source Reference 
Implementation of OpenEHR that will be conformant to CEN/Tc 251 
EN13606.
(Today the Dutch Government is discussing it)
When that implementation process starts, I expect that more discussions 
will arrise.

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 10 Mar 2005, at 00:48, Bert Verhees wrote:

> My two cents are that in fact the system is good, you need qualifiers 
> for automated processing, same problem as with OID.
>
> The case is, I am implementing it in a commercial product. These are 
> only minor issues, but you run against them quick. I have no time to 
> wait what will come out in years to follow. The questions I ask are so 
> much at hand. In the first twenty lines of code, you run against a 
> entityName, or a II-object.
>
> If I start interpreting the standard for my own needs, were or when 
> must I end doing that.
> As a programmer, I am used to exact thinking, this byte is there and 
> that is there.
> I am used to standards exactly telling me what or how to do something. 
> Thinking should already have been done.
>
> I did not see one line of code written by someone else, that is 
> implementing the CEN standard, and even if I did see that, how could I 
> trust it, if there is so much confusion in minor issues. I am spoiled 
> by open source communities were tons of source-code (often too much) 
> are available.
>
> Anyway, thanks for your suggestions.
>
> Regards
> Bert Verhees
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2515 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050310/9a876870/attachment.bin>

EntityNameParts

[Gerard Freriks]

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 11 Mar 2005, at 01:26, Thomas Beale wrote:

>
> You will be unsurprised to learn that we agree with USM Bish, and that  
> names and other demographic entities should be archetyped. We don't  
> seem to have a person name archetype yet, but you will get the idea  
> from the location address one at  
> http://www.openehr.org/repositories/archetype-dev/latest/adl/ 
> archetypes/openehr/demographic/openehr-demographic- 
> address.location_address.draft.html.
>
> I believe the approach of trying to have these as types in a RIM is  
> problematic, for exactly the reasons Bert mentions.
>
> - thomas beale
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 777 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/c4be573e/attachment.bin>

EntityNameParts

[Gerard Freriks]

CEN/TC251 has an european standard: General Purpose Information  
Components.
These 170 GPICS are proto-archetypes that can be contrained into  
archetypes.

One of those is the proto-archetype for Patient demographic information.

In the institute where I work we used the GPICS to make an information  
domain model of one sector in Dutch Healthcare: pediatrics.
All the GPICS we needed we available.
One GPIC had to be changed in order to become usable in the  
Netherlands: the demographic one!

Gerard



--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 11 Mar 2005, at 01:26, Thomas Beale wrote:

>
> You will be unsurprised to learn that we agree with USM Bish, and that  
> names and other demographic entities should be archetyped. We don't  
> seem to have a person name archetype yet, but you will get the idea  
> from the location address one at  
> http://www.openehr.org/repositories/archetype-dev/latest/adl/ 
> archetypes/openehr/demographic/openehr-demographic- 
> address.location_address.draft.html.
>
> I believe the approach of trying to have these as types in a RIM is  
> problematic, for exactly the reasons Bert mentions.
>
> - thomas beale
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1385 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f3b8d219/attachment.bin>

EntityNameParts

[Gerard Freriks]

Dear colleagues,

The CEN standards as told before, are consensus products at an abstract 
level.
This implicates that they need an Implementation specification in order 
to be usable.

You and others must produce those.
OpenEHR is such a forum.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 11 Mar 2005, at 09:09, Bert Verhees wrote:

>
> My problem is not that there are areas which are not covered by a 
> GPIC. But I
> am not the person to judge that. I am a programmer with some 
> experience in
> medical informatics.
> My problems are in the area of technical implications about how 
> details are
> worked out, or not worked out.
>
> The problems I mention are minor issues about details. I have more 
> then I
> mentioned on this list.
>
> And it is impossible to wait for a committee to finish discussions and 
> being
> uncertain about the outcome.
>
> Let me see how much time the responsible committees need to address the
> problems I mentioned. I can afford to wait three days. My projects are 
> under
> time pressure.
>
> Medical Informatics in the Netherlands is a very much closed society. 
> A lot of
> people do not discuss much, do not help each other, are not honest, 
> hide
> their weaknesses and misunderstanding.
>
> A GP in the Netherlands who writes once in a while to a mailinglist, 
> which is
> (not surprisingly) called "Openkaart" (meaning: Open Information 
> Exchange),
> which of course it is not, he wrote: "ICT is an Image of reality, this 
> makes
> painfully clear a lot about the Dutch healthcare"
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1662 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/f963a139/attachment.bin>

EntityNameParts

[Gerard Freriks]

Extending qualifiers is allowed.

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 11 Mar 2005, at 13:42, Bert Verhees wrote:

> Op vrijdag 11 maart 2005 12:36, schreef Karsten Hilbert:
>> I forgot to mention one solution we could use in GnuMed:
>>
>> Attach another name to a person (they can have any number of
>> names), put the initials in one of the fields and mark that
>> name (eg set the comment) to be only initials.
>
> This is done really smart in CEN, they have an EntityName, which 
> consists of a
> set of EntityNameParts, the number is unlimited, but the
> qualifier-possibilities are limited. The only way is to add a 
> qualifier, that
> is extending the standard
>>
>> Not clean but doable.
>>
>> Karsten
>
> -- 
> Met vriendelijke groet
> Bert Verhees
> ROSA Software
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1057 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050311/8f12cede/attachment.bin>

ADL to XML Schema

[Gerard Freriks]

Hi,

I'm only the convenor of the CEN/TC251 wg1.
For more detailed information you need to read the e-mails by Dipak 
Kalra, Thomas Beale and Sam Heard.

In the text below soem comments.
-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 10 Mar 2005, at 18:29, Jose Alberto Maldonado wrote:

> Hello,
>
> We have just read the message bellow and honestly we do not understand
> anything now. We supposed that EN13606-1 reference model could be used 
> as
> reference model for developing archetypes.

EN13606 part 1 is a generic model of any document, with versioning and 
attestation.

EN13606 contains an UML model of the Archetype.


> You can read in prEN13606-2 (last version  February 2005), section 
> 1.3. Communicating archetypes: "It is
> the intention of both CEN and HL7 that HL7 Templates and EN13606
> archetypes be interoperable". One question arises are these EN13606
> archetypes different from OPENEHR archetypes?.

Archetypes are archetypes at the clinical level.
And can have facets. An EN13606 facet when constraints are applied to 
the EN13606 kernel and an OpenEHR facet when constraints are applied to 
the OpenEHR kernel.




> Could you show some examples of clinical concepts that can not be
> expressed as archetypes derived from EN13606-1 reference model?.
>
> thanks in advance
>
>
>
>
>
>
>
>
> On dj, 2005-03-10 at 17:19, Thom
>
>
>
> Thomas Beale escribi?:
>
>> Alfonso Mata wrote:
>>
>>> Hello everybody,
>>>
>>> We're working at University of Zaragoza (Spain) on a EHR system. We
>>> want to conform to 13606 and make use of ADL-based archetypes. We are
>>> just starting and we have lots of doubts about how to implement and
>>> apply all concepts. These are our questions:
>>>
>>> - How 13606 is applied to built ADL archetypes? Is it already 
>>> possible?
>>> - Is it possible to obtain a XML-Schema based on 13606 from an ADL 
>>> file?
>>> - Is ADL parser in openEHR site the only one to make use of it?
>>>
>> It does not make any real sense to make archetypes literally based on 
>> CEN 13606. Archetypes have a very important requirement: to be 
>> targetted to an informatoin model which acts as a "base ontology". In 
>> openEHR we use the openEHR reference model fr this purpose. This is 
>> what allows you to write an archetype for somehting like "Apgar 
>> result", which needs to use concepts like OBSERVATION (with 
>> properties data, state and protocol), HISTORY (with properties 
>> events, origin), EVENT (property data), and varous data structure 
>> types, like TREE, LIST, TABLE and SINGLE.
>>
>> EN 13606 is not designed directly to support archetyping; it is 
>> designed as a lowest-common denominator EHR data interoperability 
>> model, with support for transmitting archetyped information.
>>
>> This is not the same as providing sufficient ontological definitoins 
>> to support the building or use of archetypes. If you were to use 
>> EN13606 literally for archetypes, you could only use ENTRY, CLUSTER 
>> and ELEMENT; you will see that trying to define most clinical 
>> concepts with such a weak ontology will be annoying difficult, 
>> error-prone, and ultimately will not engage clinical professionals.
>>
>> So openEHR currently offers at least part of a base ontology for 
>> building archetypes, with concepts of sufficient strength to make 
>> higher-level clinical concepts easily expressible. In the near 
>> future, we intend to propose the creation of an agreed "base level 
>> ontology" reference model, expressed in UML, for use by everybody for 
>> buiulding archetypes. We will include the core of the openEHR 
>> reference model for this (from COMPOSITION down); but we want other 
>> organisations to think about what they need to see in this. There are 
>> other reference models such as the Danish G-EPJ which have clean 
>> concepts which may need to be in this base ontology; also ENV 13940 
>> (continuity of care) models need to be analysed for possible 
>> contributions. We will propose this base ontology at the next CEN 
>> working group meeting. I believe people will agree in principle.
>>
>> A data mapping is also being defined between openEHR (and later, the 
>> common base ontology) and EN13606. This wll enable 13606 to fulfull 
>> its purpose, which is to move  data faithfully between EHR sites, 
>> including data which has been archetyped in those sites.
>&g

ADL to XML Schema

[Gerard Freriks]

Read the text below.

Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 10 Mar 2005, at 22:21, Sam Heard wrote:

> Jose
>
> Hi - this is a difficult time with the 13606 standard about to hit the 
> streets and the technology having been developed in the openEHR space. 
> The openEHR approach is now considerably richer than 13606 and will, 
> we hope, be the development space.
>
> You can do pretty much everything in 13606 that you can do in openEHR, 
> BUT there is no standard way to express many things that have been 
> shown to be worthwhile such as:
>
> A time series - this will be lots of entries in 13606
> The state (e.g. patient sitting) and protocol (e.g. used wide cuff) 
> information - this will clutter the data and make display rules 
> difficult
> The openEHR work that is going on with instructions - which will allow 
> following a process and linking with workflow and decision support - 
> will have to be done with clusters and elements - and it will not be 
> sure how to do it exactly except to write it down.
>

And this is the reason why we at CEN must develop a series of basic 
archetypes that become part of the EN13606 part 3.
These basic archetypes will prescribe a uniform way of using time 
series.


> So, we are hoping that people will look to the openEHR collaboration 
> as the space to define clinical concepts and then generate 13606 
> archetypes for use with this standard - rather than everyone going 
> their own way.
>
> Further, collaboration is required in this area - it is difficult to 
> get people working together but Thomas and others have put a huge 
> effort into making this feasible.
>
> I hope this is helpful.
>
> Sam Heard
>> Hello,
>> We have just read the message bellow and honestly we do not understand
>> anything now. We supposed that EN13606-1 reference model could be 
>> used as
>> reference model for developing archetypes.
>> You can read in prEN13606-2 (last version  February 2005), section 
>> 1.3. Communicating archetypes: "It is
>> the intention of both CEN and HL7 that HL7 Templates and EN13606
>> archetypes be interoperable". One question arises are these EN13606
>> archetypes different from OPENEHR archetypes?.
>> Could you show some examples of clinical concepts that can not be
>> expressed as archetypes derived from EN13606-1 reference model?.
>> thanks in advance
>> On dj, 2005-03-10 at 17:19, Thom
>> Thomas Beale escribi?:
>>> Alfonso Mata wrote:
>>>
>>>> Hello everybody,
>>>>
>>>> We're working at University of Zaragoza (Spain) on a EHR system. We
>>>> want to conform to 13606 and make use of ADL-based archetypes. We 
>>>> are
>>>> just starting and we have lots of doubts about how to implement and
>>>> apply all concepts. These are our questions:
>>>>
>>>> - How 13606 is applied to built ADL archetypes? Is it already 
>>>> possible?
>>>> - Is it possible to obtain a XML-Schema based on 13606 from an ADL 
>>>> file?
>>>> - Is ADL parser in openEHR site the only one to make use of it?
>>>>
>>> It does not make any real sense to make archetypes literally based 
>>> on CEN 13606. Archetypes have a very important requirement: to be 
>>> targetted to an informatoin model which acts as a "base ontology". 
>>> In openEHR we use the openEHR reference model fr this purpose. This 
>>> is what allows you to write an archetype for somehting like "Apgar 
>>> result", which needs to use concepts like OBSERVATION (with 
>>> properties data, state and protocol), HISTORY (with properties 
>>> events, origin), EVENT (property data), and varous data structure 
>>> types, like TREE, LIST, TABLE and SINGLE.
>>>
>>> EN 13606 is not designed directly to support archetyping; it is 
>>> designed as a lowest-common denominator EHR data interoperability 
>>> model, with support for transmitting archetyped information.
>>>
>>> This is not the same as providing sufficient ontological definitoins 
>>> to support the building or use of archetypes. If you were to use 
>>> EN13606 literally for archetypes, you could only use ENTRY, CLUSTER 
>>> and ELEMENT; you will see that trying to define most clinical 
>>> concepts with such a weak ontology will be annoying difficult, 
>>> error-prone, and ultimately will not engage clinical professionals.
>>>
>>> 

EntityNameParts

[Gerard Freriks]

What are names?
What are names used for?

Names are nothing but a set of strings consisting of characters.
What are names used for?

Most often we need them to add new information to the correct file. 
(Correct meaning the file of the same person we saw the previous time)
Names are to add a new document to other documents. And this collection 
of documents are about the same person.

Sometimes we need a name in order to be able to attach it to a person.
We need a name because we have to use the correct name to send the bill.

Sometimes we really need to know the real identity of a person.

In most cases the real identity is not important.
We only need an identifier to locate documents.

In other words what is the use case we are talking about?
Once we know this, we know  what we are talking about.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 12 Mar 2005, at 20:11, lakewood at copper.net wrote:

> Names are unusual. We have 'official' names (e.g., birth certificate) 
> and 'unofficial' names
> (e.g., those we choose ourselves and others we are given). A brother 
> migrated to the
> Southern US states, married and had four children. I remember 'Gator' 
> and 'Armadillo';
> I can't remember the official names and they probably do not like 
> using them.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1427 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050312/b49dda8c/attachment.bin>

EntityNameParts

[Gerard Freriks]

Hi,

When I buy a loaf of bread nobody needs my name.
And this is true for many transactions in society.

When I need stitching up a wound, they don't need to know my rel 
identity.
And this is true for many situations in real life.


Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 13 Mar 2005, at 16:57, lakewood at copper.net wrote:

> Actually, even beyond Healthcare issues, at all times we need to know 
> the
> 'real identity of a person'. Exception for Intelligence Services and 
> others whose can
> function only with deceit.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 687 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050313/1853bb4e/attachment.bin>

DV_MULTIMEDIA

[Gerard Freriks]

Hi,

Instead of a lot of attention to arcane things like name, identity, etc
we need to know whether the patient belongs to a stored document, and 
vice versa.

So a jpeg is an excellent way to do just that.
A jpeg is infinitly better than a strange number.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 13 Mar 2005, at 23:52, Sam Heard wrote:

> Dear All
>
> I have been working with DV_MULTIMEDIA and feel that the thumbnail 
> feature should be a JPEG rather than a DV_MULTIMEDIA.
>
> I believe this is the way to go as although it restricts the thumbnail 
> to an image - it means that everyone can view the thumbnails. It also 
> means we do not have a cyclical definition.
>
> The danger is fixing to a particular technology - but I think in this 
> case it is worth it.
>
> Thoughts?
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 937 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050314/3695c317/attachment.bin>

EntityNameParts

[Gerard Freriks]

Bert,

In what way do you suggest should CEN change the standard.

Now is the time to make a proposal.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800
On 15 Mar 2005, at 16:14, Bert Verhees wrote:

> This is done really smart in CEN, they have an EntityName, which 
> consists of a
> set of EntityNameParts, the number is unlimited, but the
> qualifier-possibilities are limited. The only way is to add a 
> qualifier, that
> is extending the standard
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 605 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050315/721797f9/attachment.bin>

SubjectOfInvestigation

[Gerard Freriks]

Dear Tom and Bert,

The QA was done primarily by Edgar in his project.

When improvements are needed I see two processes.
-1- in CEN a new version.
-2- in ISO in the work on CIC's.

In the mean time we can maintain a file with the lists of proposed and 
the agreed changes.

Who will maintain these lists?

Gerard
]
-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

+31 71 5181388
+31 654 792800
On 23 May 2005, at 18:21, Tom Marley wrote:

> Bert,
> ?
> Although very busy I am looking into this area.?
> ?
> The underlying problem may be that there was so little QA at the time 
> and I feel very strongly that as structures are used there needs to be 
> a proces which allows corrections/improvements and a dissemination of 
> these.
> ?
> Whatever we decide in this area will be 'informally' distributed 
> throughout the TC251 community.
> ?
> I will be in touch and we can discuss options.
> ?
> ?
> Regards
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1066 bytes
Desc: not available
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050524/bc640446/attachment.bin>

The Uncertainty Decision was: Dr R LONJON Confidence indicator !

[Gerard Freriks]

On May 7, 2005, at 3:12 PM, Thomas Beale wrote:

> ...so it seems to me that the indicator of what to do next when a  
> differential diagnosis is recorded relates strongly to the innate  
> characteristics of the conditions recorded, not just the doctor's  
> opinion of how likely it might be. If angina pectoris is a possible  
> diagnosis for "burning chest pain" at 5%, with the most probable  
> diagnosis (in the opinion of the physician) being "gastric reflux"  
> at 95%, and it is a 55-yo with a family history of coronary heart  
> disease, I presume that the angina pectoris possibility is the one  
> that drives the next steps? How are the confidences really decided?

In all cases what is recorded is the personal opinion of the  
healthcare provider.
-- next part --
An HTML attachment was scrubbed...
URL: 

openEHR-EHR-COMPOSITION.Report.v1draft

[Gerard Freriks]

Andrew,

What you describe is an Organiser Archetype.
An yes they belong to an reference model.
But not the ref Model EN13606 part 1.

They are derived from the meta-Archetype model.
This Organiser Archetype will define all the things you wrote.
The Organiser Archetype will be constrained from a more generic Any- 
Report Organiser Archetype.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

On May 26, 2005, at 2:48 AM, Andrew Goodchild wrote:

> Hi,
>
>
> I was looking at the composition archetype for ?report? that comes  
> with the archetype editor.
>
>
> The archetype constrains a composition to include information about  
> a request identifier, requesting clinician, contact details,  
> request date, report identifier, copies to and referrals to.
>
> Many of these things are also in common with standard tags in CDA.
>
>
> It seems to me that many of these fields actually belong in the  
> reference model and not in an archetype.
>
>
> Does anyone think we need to extend the reference model instead?
>
>
>
> -Andrew
>
>
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/0b6d2f49/attachment.html>

The semantics of archetype Specialization

[Gerard Freriks]

Or only against the meta-Archetype model

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

On May 26, 2005, at 2:37 AM, Andrew Goodchild wrote:

> Hi,
>
>
> Does anyone know what it actually means to specialize an archetype?  
> And what the rules are?
>
>
> I looked at the archetype editor and created a specialized  
> archetype of another.  The editor seemed to just copy the parent  
> archetype and then allowed the user to change anything about the  
> archetype.
>
> For example, I can now make a mandatory field optional, or I can  
> extend a parent archetype with new mandatory fields that don?t  
> exist as optional fields in the parent archetype
>
>
> To me this particular example is not safe as one of the basic rules  
> of specializing archetypes is you should be able to validate any  
> new specialized EHR data against the parent archetype.
>
>
> -Andrew
>
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050527/8581ea13/attachment.html>

Issue 1

[Gerard Freriks]

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

On Apr 28, 2005, at 10:15 AM, Thomas Beale wrote:

> 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 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
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050528/b5de9fcc/attachment.html>

uncertainty in medical problem solving and decision making (Was: Dr R LONJON Confidence indicator !

[Gerard Freriks]

On Apr 27, 2005, at 8:19 AM, Arild Faxvaag wrote:

> We could say that physicians _infer_ diagnostic hypotheses based on
> - knowledge of the tentative underlying disease,
> - the patients subjective experiences
> - phenomena registered in the patients body

In any case it is a subjective statement and is  a professional  
opinion based on more (lab results, x-rays) or less (patient history)  
objective data.

>
> Phrases such as  "cannot be exluded" might be due to", "probably",  
> "definitely", "beyond doubt"  are statements of probability of the  
> inferrence being correct (and what to do next).

Inferrences expressed in the subjective statements documenting the  
treatment of the patient.

>
> Can one say that diagnoses belong to the class of statements  
> whereas the disease itself belong to the class of natural phenomena?

Disease is an abstraction of reality that for the moment, for the  
next decision is considered to represent the reality about the health  
of the patient.
Diagnosis is the professional but subjective opinion about a disease  
of a patient.

There is a continuum:
Real pathological, fysiologiscal phenomena in a patient.
Certain manifestations of these phenomena.
That are (or are not) experienecd by the patient of an other person.
The arrousal of distress, anxiety, etc, triggering a visit to a  
physisian.
What is said (or not) about the manifestations of the phenomena  
during the visit.
And how it is said.
How it is measured and documented.
What is understood  of what was said or measured about the  
manifestations of the phenomena.
How all this was mached to the state-of-the art knowledge, or  
interpreted in the context of a limited amount of available knowledge.
What was recorded about all these steps above.
How the same person (or others) interpret the recorded 'facts' at a  
later stage

So what do we record in an EHR?
And what do we interpret readingan EHR?
Then ...
What is certain?
And what is uncertain?
Certain or uncertain in what domain, in what line above, at what  
level of the whole described continuum?

In ?25% of the extremely wel researched patients in one University  
Hospital we not diagnosed correctly during their life time.
As could be concluded after an autopsy.
So what do we really know about disease and complaints?

What is certainty?
What is it refering to?

Do we understand this mine field well enough?


>
> The diagnosis establishes a relation between the subjective  
> experiences / phenomena and the disease that induces those symptoms  
> and findings.
> Example:
> Experiences and phenomena: Pain in the wrist joints, feeling of  
> joint stiffness, joint tenderness, joint swelling, elevated  
> sedimentation rate.
> Diagnostic inferrence:  Rheumatoid arthritis.
> Relation: Might be induced by/due to
>
> Can statements of probability be considered statements regarding  
> the strength of these relations??

This is what they are at best.

>
> Comments on this?

-- next part --
An HTML attachment was scrubbed...
URL: 

Templates - should we record which are used?

[Gerard Freriks]

Dear Sam,

When a Template is shared by to communicating parties we will have to  
record this in the EHR.
This is because this is the Information part of the "contract" the  
communicating parties have. It is one that pertains to their  
communications.
When the Template is used to store information I consider this a  
"contract" as well.

The Template either has an ID or is identified by the tree of  
constituting archetypes.

Gerard Freriks

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

T: +31 71 5181388
M: +31 654 792800


On 20-okt-2005, at 9:55, Sam Heard wrote:

> Dear All,
>
> We have been discussing the issue of templates and whether we keep  
> an identifier of a template in the data. My concern has been that  
> this ID might be seen as an absolute constraint on the data,  
> whereas the precedence of constraint must be:
> The data must conform to the reference model
> The data must conform to the archetypes
> The data must be complete
> The template can be invoked to ease data entry.
> What this means is that when data is already present, even if it  
> does not conform to a template (which may have been used as a guide  
> when entering data) it must be allowed. Clearly an application may  
> restrict data entry to the template (this is an application issue)  
> but it cannot impose a template on data already gathered.
>
> Keeping a template identifier in the EHR is then a statement only  
> that a template of some sort was used in creating the data. This  
> template may be in a form that is generally available (eg ADL) or a  
> specific local template implementation - there is no need to use a  
> generalisable form of template within the openEHR framework -  
> though it has advantages.
>
> Having said that, it is clear that it may be useful and I would  
> suggest that we consider an optional string attribute at the  
> composition level that allows recording the id of a template used  
> to form the composition.
>
> What do others think?
>
> Cheers, Sam
> -- 
> Dr. Sam Heard
> MBBS, FRACGP, MRCGP, DRCOG, FACHI
>
> CEO and Clinical Director
> Ocean Informatics Pty. Ltd.
> Adjunct Professor, Health Informatics, Central Queensland University
> Senior Visiting Research Fellow, CHIME, University College London
> Chair, Standards Australia, EHR Working Group (IT14-9-2)
> Ph: +61 (0)4 1783 8808
> Fx: +61 (0)8 8948 0215
>
> - If you have any questions about using this list, please send a  
> message to d.lloyd at openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20051020/8b6a3de3/attachment.html>

Templates - should we record which are used?

[Gerard Freriks]

Hi Christian,

I try to digest what you have said.

See in the text.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 27-okt-2005, at 17:49, Christian Heller wrote:

> Nevertheless, I think that these ontology definitions are not that
> important if talking about knowledge modelling in general.
> Every knowledge model (I use "model" to not conflict with different
> definitions of "template") is a subjective abstraction of the real
> world anyway. It does not matter whether the abstraction is simplified
> a lot (like an ontology of information) for a specific context or less
> (ontology of the real world) -- it is always an abstract model and as
> such simplified. Nobody can model the real world in complete anyway.


1- The real world. Very complex and we don't know all about it.
Both patient and healthcare provider operate in this world.
This is where illness, and physical signs, molecules, atoms do their  
thing.

2- The model of the real world. People all have a simplified model of  
this real world.
This is based on the knowledge and expertise of people. The knowledge  
and expertise is ever growing.
This knowledge and expertise is formed using a system of concepts.  
Some of these are completely shared, others partially, between  
communicating parties.
Concepts are defined within a context and with a purpose.
People use various collections of concepts depending on context and  
purpose.
The system of concepts is known as Ontology or model of the real world.

3- Registration/documentation of the healthcare process
This takes place in the real world using real world events using real  
world physical objects.
Each healthcare provider has the need or obligation to record what he  
has done while treating patients with problems, symptoms.

The healthcare process from the documentation point of view (context)  
is the collection of facts of what is heard, seen, felt, smelled,  
thought during this healthcare process.
Data is collected and documented. On the basis of expertise and  
knowledge the healthcare provider (professional) forms a professional  
opinion supported by a series of collected data.
The production of a professional opinion about the real world  
phenomena (see bullit number 1) is from the registration/ 
documentation point of view one important function of any healthcare  
professional. In addition he performs/orders certain procedures that  
need to be registered and documented.
The documentation of collected real world facts and real world  
procedures plus the production  of the professional opinion and some  
orders or the execution of procedures is what gets done and documented.
All the facts are expressed by the patient using his own model of the  
real world. (bullit number 2) and subsequently interpreted by the  
healthcare professional using his own bullit point number 2 model.
And then it gets documented in a registrative system (paper and  
pencil or computers) using a collection of concepts designed for this  
purpose.
e.g. Archetypes.

For this we need an Archetype ontology (aka model of information,  
domain information model) as an abstract model that is very much  
simplified and distorted as compared with the models of bullet points  
1 and 2.

Many of the problems we have dealing with information in computer  
systems is that the same concept is used in several contexts/ 
ontologies and ends up in a "universal" archetype that gets  
instantiated and becomes a non-universal. This state change confuses  
many systems (and persons).
An other confusion is the fact that at one point something is a  
professional opinion and after transfer to the next healthcare  
provider a fact and no longer the professional opinion.
What I mean is: a blood sample is drawn. It is very physical and is  
part of the bullet point 1 world. This fact is documented as facts  
(data) using concepts from bullet point 3.
On the basis of a sub-set of the bullet point 2 model the facts are  
interpreted and end up in the professional opinion. This opinion is  
described in terms of the bullet point 3 ontology. But when sent to  
an other healthcare provider this opinion becomes a fact in his system.



>
> To me, ontology of information as you use it in form of archetypes
> sounds more useful than the other kind. The ontology of the real world
> sounds like what terminologies want to achieve, right?

We need those terminologies.
They are the words (codes) used the express concepts.

Archetypes are the constructs of "what can or must be said/ 
documented" in the course of the provision of healthcare.


> I guess you had some difference of opinion with terminology people and
> therefore introduced those two differing definitions.
> If you use these two kinds of ontology to distinguish between  
> archetypes
> (ontology of

Authorisation

[Gerard Freriks]

Bert,

" GP sends the patient to the hospital"

What do you mean:
Is he referred to a specialist? Then implicitly, at least in the  
Netherlands, both the GP and specialist have access rights.
Is he referred to a lab-service in the hospital? Then the same  
reasoning can be applied.
Always the patient has the rights to limit the access rights of  
others, including him self and the GP.

The whole business of co-operating physicians is dealth with in a  
coming European Standard:
"System of Concepts for Continuity of Care", ContSys)

In the whole chain of events: Identification, Authentication,  
Authorisation, Access Control and Logging.
What you describe is, are problems at the level of Access Control  
where the Patient mandate is executed against the rights granted in  
the authorization phase.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 14-apr-2006, at 13:12, Bert Verhees wrote:

> A GP a few days ago was thinking of the following situation
>
> A patient goes to the GP, the GP sends the patient to the hospital,  
> in the hospital there are some tests.
> The results of these tests can arrive in the openehr system,
> possiblities
> - the GP may not be allowed to see the results of these tests,  
> because the specialist thinks the GP is not qualified to judge the  
> outcome
> - the GP may not be allowed to see the results of these tests  
> because the patient does not want him to see them
> - the GP is allowed to see the results because the specialist and  
> the patient allow him to see the result.
>
> As I understand, in this case, the committer of the composition is  
> the specialist
> --
> As I understand this, a authorization application keeping track of  
> authorizations and group-definitions is needed to support the  
> openehr-using application.
> Are there any thoughts about this?
> Can I read some more about this, anybody know where
>
> And also other thoughts about authorization by other ways are welcome.
>
> I was thinking of authorizations on the use of archetypes.
> In the above example, the specialist could have used a specially  
> prepared archetype to post the test-results in case he did not want  
> the GP to see the results, and another archetype if he grants the  
> GP to see the results, then there would be only one extra  
> authorization necessary, the patient must allow the GP to use all  
> the archetypes, he as a GP is entitled to use.
>
> But maybe, very well possible, I am overlooking a lot, so
>
> Please help me thinkig about this
>
> Thanks
>
> Bert Verhees

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060414/d9b33ac6/attachment.html>

removal of data

[Gerard Freriks]

There is the situation of an EHR-system and the situation of an EHR- 
extract.

In an EHR-system physical deletion MUST NOT be possible. Deletion  
after attestation will be in all situations legally not allowed.
Because of rights citizens have it must be possible to logically  
delete them.
A new version must be created depicting the new situation.

When information is sent between two EHR-systems the EHR-extract is  
used.
Here are two situations:
- a handover of a complete patient file because of a change of  
practitioner.
- a document produced by one practitioner is transported to an other  
practitioner.

In the first situation the complete record is transported. Including  
all logically deleted parts.
In the second situation only the 'active' parts are transported. All  
logically deleted parts are not sent in the EHR-extract.

What is exactly in the openEHR specs I don't know.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 16-apr-2006, at 11:13, Bert Verhees wrote:

> Let me enlighten my question
>
> Bert Verhees schreef:
>> Thanks again for the help with the authorization-question, I was  
>> lost in the wrong document of the specs.
>> I must say, reading the specs, really is not something for a rainy  
>> afternoon, but it is worth it.
>>
>> I have another question, probably it also is in the specs, but I  
>> didn't find it.
>> --
>> Is it possible to delete a composition in a way that is not  
>> traceable anymore?
> What happens on deletion of a composition, will there be created a  
> new version, which indicates the non-existence, and are old  
> versions kept?
> Or is it possible to delete all versions of a compositions.
>
> I guess, this is not possible, but I am not sure
>
> (I mean this when using the openehr structure)
>
> Thanks,
> Bert Verhees

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060416/0c93de9b/attachment.html>

removal of data

[Gerard Freriks]

I agree that is very seldom.

For many (technical) reasons it is completely impossible to remove  
all information as if it was never written.

for example:
- The information is communicated with others before it has to be  
removed
- the information is part of an archive on CD-ROM
- the information is indexed somewhere

Laws (as far as I know) cannot force healthcare providers to change  
the history of things.
Each healthcare provider has the obligation to document itself.
The law, my personal opinion, most often is written by legal persons.
Therefor what they prescribe is legally correct but many times  
impossible to execute.

My solution is to translate the legal terms in a requirement to  
LOGICALLY remove the information,
It is there.
But it is not used any longer.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 16-apr-2006, at 23:53, Mikael Nystr?m wrote:

>> [...]
>
>> In an EHR-system physical deletion MUST NOT be possible.
>> Deletion after attestation will be in all situations legally not  
>> allowed.
>
>
> In fact that isn't true in Sweden! There are some very special  
> occasions
> when a health record or parts of it should be able to be completely
> destroyed as if the information never had been written and signed. The
> situation happens very seldom, but still we need to be able to  
> handle it.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060417/9fa2a57f/attachment.html>

removal of data

[Gerard Freriks]

Bert,

Ik heb dat nergens gelezen.

Het verwijderen is altijd onderworpen aan de beslissing van de arts.

De termijn waarna gegevens moeten worden verwijderd is nu 15 jaar.
En dan is het ook nog onderworpen aan beperkende bepalingen.

Universitaire klinieken moeten het 115 jaar bewaren.

Kijk op:
http://www.zonmw.nl/nl/programmas/programma-informatie/informatie-en- 
communicatietechnologie-in-de-zorg-icz.html
voor info van het Juridisch lab.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 18-apr-2006, at 9:47, Bert Verhees wrote:

> Now I discovered today, there is a law in the Netherlands which  
> obliges
> care-takers (GP's etc) to remove all records for patients demanding  
> this
> (within 3 months of demand, and after some years of not visiting  
> that GP)

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060418/b8636334/attachment.html>

removal of data

[Gerard Freriks]

Dear all,

In the paper world, I know, it is clear.

A document with legal implications can never be destroyed without any  
trace.
A document with legal implications can be removed from a registry in  
one place and moved to a special registry, folder, cupboard, etc.

And the same is true for data entered (and attestedand therefor with  
leagal implications) in the paper file.
What is in it, stays in it.
It is explicitly forbidden to remove, scratch out, made unreadable, etc.
The only way is to annotate incorrect data/information and not use it  
or send  it to others.

In other words, in the paper world in the Netherlands, we only know  
the logical delete.

What has happened, has happened, we can not falsify history, is the  
bottom line.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 21-apr-2006, at 23:11, Thomas Beale wrote:

> William E Hammond wrote:

> Result, we need to have the ability to remove data physically and
> completely from the EHR.  To leave the data is a breach of privacy.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/eb3df418/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Gerard Freriks]

Folks,

I will repeat myself.

You are talking about a data type.
This DV_Quantity is a number.
The question is how do we embellish this data type and the number it  
presents with extra codes/numbers to indicate: types of certainty/ 
uncertainty, and statistical distributions.

The only real meaning of an extra attribute as part of DV-Quantity  
pertains to the number given and not the meaning (interpretation).
The extra attribute in DV-Quantity will  provide information about  
the precision of the number, only.

Any extra information is a property of the concept in which DV- 
Quantity is used. E.g. certainty/uncertainty, distribution, etc.
It is related to the specific concept and its context that is being  
expressed and not the expression of a number/data type.

~, statistical distributions, etc will have to be expressed at  the  
level of Concept definition and therefore the Archetype.

Greetings


Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 21-apr-2006, at 17:12, Thomas Beale wrote:

> this seems pretty close to a correct model. Slight corrections I  
> would suggest are:
> - I am still uncomfortable with '~', since it seems to mean  
> "approximate", but "we don't know how approximate"...
> - does "None" mean a) none recorded (i.e. don't know, i.e. same as  
> '~') or b) no accuracy, i.e. an exact value (reasonable for some  
> things, e.g. the answer to the question "number of previous  
> pregnancies")?
> - in the case of a statistical distribution, one value may not be  
> enough to characterise the limits, since the distribution may be  
> asymmetric (I don't remember enough beyond normal/T/Chi2 to  
> remember if there are distributions that need even more parameters).
>
> The question for us in openEHR is how much to implement of such a  
> model: we have to be driven by real use cases.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/0fc646a3/attachment.html>

removal of data

[Gerard Freriks]

Dear Bert,

Reading again a thick report by our Royal Dutch Medical Association  
about the interpretation of this pecific Dutch law my opinion is NOT  
changed.
In a separate e-mail you can read some relevant pages.

In summary. 'Information can be destroyed' is the text.

There are two important conditions when it is not allowed to destroy  
information:
- because of legal reasons
- because of a substantial interest for others not to destroy it. An  
example is a legal process, or genetic information.
What is not explicitly discussed in this report is the use case where  
decisions have been made on the basis of information that the patient  
wants to remove. In my opinion in this use case the information can  
never be removed physically or logically in the context of these  
decisions and the legal implications. But it must be removed  
logically in the context of information that can be transmitted to  
others.

Later in the report there is a chapter on the EHR and deletion.
They explicitly mention that deletion in the electronic sense means  
destruction of the hard disk and CD-rom, etc.
This is not possible. A pragmatic solutions in terms of a well  
behaved Information system, implicating logical delete plus specific  
business rules, is the optimal solution.




Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 22-apr-2006, at 10:20, Bert Verhees wrote:

> Gerard Freriks schreef:
>> Dear all,
>>
>> In the paper world, I know, it is clear.
>>
>> A document with legal implications can never be destroyed without  
>> any trace.
>> A document with legal implications can be removed from a registry  
>> in one place and moved to a special registry, folder, cupboard, etc.
>>
>> And the same is true for data entered (and attestedand therefor  
>> with leagal implications) in the paper file.
>> What is in it, stays in it.
>> It is explicitly forbidden to remove, scratch out, made  
>> unreadable, etc.
> Sorry Gerard, in my opinion you are wrong, article 455 of WGBO (law  
> of protection of personal data) states very explicitly that a  
> patient can demand destroying of his record.
> I wrote this two days ago. The holder of this record must obey  
> within 3 months after demanding, and there are some exclusions, but  
> the fact is that there are situations where those exclusions do not  
> apply.
> So permanent deletion of records is a demand of the law.
>
> Bert
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/47908ed5/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Gerard Freriks]

I agree. A workshop, moment of reflexion, is needed.
We must understand better the real facts, the use cases, the  
requirements, before we come to wrong constructs in the wrong models  
or the correct ones.

Next we need to use the same definitions for:
Data Type,
Composit Data Type,
Archetype.

We need a common understanding of the function and meaning of  Class,  
its Attributes, and Data Types.
(Data Types are used to define the interface at the field/number/text  
level with other system components)

Gerard


Data Type, (e.g. a Floating Point Number)
Composit Data Type, (e.g. Floating Point number, plus truncation)
Archetype, (e.g. Measurement and its interpretation: ~,  <,  <<,   
 >>,  >, good, bad, not to be trusted, etc, etc)


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 22-apr-2006, at 10:13, Thomas Beale wrote:

> Tim,
>
> I agree with the workshop idea, and assume that it could at least  
> be done in Australia as a starting point. Thus, for the short term,  
> I am inclined to add only the very simple "<, >, <=, >=, ="  
> indicator, and possibly consider the "~" one (since these at least  
> allow us to properly represent very low and very high path test  
> values that are sent as "<5" and similar). The complex stuff that  
> Tim has described below needs proper modelling and in the end will  
> lead to new data types (and as Gerard says, it may well lead to  
> something in the archetypes). As with everything, we need to really  
> understand the exact requirements first, and that probably won't  
> happen without a workshop.
>
> - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060422/372e9677/attachment.html>

removal of data

[Gerard Freriks]

Friends,

Data, information and knowlegde exists, can be interpreted in a  
spefic context, only.

Data, information and knowledge without a context can be considered  
garbage.
It can not be interpreted faithfully.
It is nothing more than a string of codes.

Always data, information, knowledge will be used outside the original  
context.
It will be very difficult to erase it completely.

The consequence is that when the context is removed from the data it  
can no longer be interpreted faithfully and therfor be used correctly.
Logical removal is an example of this.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 24-apr-2006, at 9:23, Bert Verhees wrote:

> It would be possibe to gather all records (this always confuses me:  
> an EHR is
> something as one single composition?) belonging to a patient and  
> remove them,
> without leaving evidence it ever existed?
>
> Because, that is what the Dutch law demands to be possible.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060424/9c99493e/attachment.html>

Pathology numeric values not supported in DV_Quantity

[Gerard Freriks]

Dear all,

The CEN EN13606 EHRcom standard is using an attribute to indicate  
that 'something is going on' and that precautions must be taken.  
Resulting most often in the need for human intervention.
Is such an attribute a possible intermediate solution for the problem  
here?

Gerard
--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 26-apr-2006, at 15:24, Karsten Hilbert wrote:

> Much to my dismay a quick grep over a couple hundred results
> idling in files on my machine doesn't yield a "<=" or ">="
> offhand but I'm positive I've seen it before. When I come
> across one I'll post it to the list.
>
> Checking the lab data transmission specs confirms that the
> result can be a free-text field which easily allows for any
> of the discussed accuracy modifiers.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060426/6b6eb88e/attachment.html>

Normal and other ranges

[Gerard Freriks]

Hi,

My personal thoughts.

In general the normal range is dependent on the type of lab method  
and specific lab and valid in a particular context (male, female,  
old, young, time, etc)
So the information can be provided by the lab only. They know (should  
know) what all the normal ranges in all relevant contexts are.

Of course for the purpose of providing lab results archetypes will be  
produced.
In these lab-reporting archetypes there must be a spot where this  
type of information can be provided.

IT techies think many times that absolute figures are very important.
In general trends provide more useful information than single  
absolute figures

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 653 108732



-- work --
Gerard Freriks, arts
TNO ICT
Brassersplein 2
Delft, the Netherlands
T:  +31 15 2857105
M: +31 653 108732

Gerard.Freriks at TNO.nl





On 31-aug-2006, at 19:20, Thomas Beale wrote:

>>
> technically there is nothing stopping it, but it would almost  
> always be the wrong thing to do, since the normal range of a  
> Quantity is there to carry the actual normal range for the  
> particular analyte in question, for the lab, and for the patient.  
> So if it is serum sodium, the range will still depend on all of  
> these things, and cannot be archetyped. The intention is not to use  
> archetypes to standardise these values, but to provide a place for  
> labs to put the specific normal range values that applied for each  
> analyte, for the particular patient, and remembering that each lab  
> has slightly different instrument settings.
>
> Probably what you are looking for is the normal range reference  
> data - like what you see in a pathology book, or what any physician  
> knows for all of the main vital signs and other measurable things.  
> We consider this to be reference information, like terminology, but  
> for quantified values. While much of it is published in paper form,  
> as far as I know there is no recognised way to represent  
> quantitative range data in a standard computable form (i.e. in the  
> way that you can get Snomed or ICD10 in a computable format). This  
> is needed. But archetypes are not the place to standardise this -  
> archetypes are about defining content structures, not domain  
> reference knowledge.
>
> - thomas beale

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060831/7cba880b/attachment.html>

Term binding in Archetype Editor: Definitions, Rules, Quality Control

[Gerard Freriks]

Dear all,

A few thoughts about this topic of Terminology Binding and Archetypes.
In essence it is the topic of "the Boundary Problem".
Archetypes are a solution for this problem.
But in order to do so we need agreements on a few things.

We mus be extremely clear what we mean when speaking about binding  
terminologies in archetypes.
Are we talking about Archetypes or Templates? (design-time versus  
almost run-time? Generic structures versus locally agreed structures?)
Are we talking about 'Label' or ' Data fields' or ' Archetype slots'?
Are we talking about Internal or External coding systems?
Are we talking about General External Coding Systems or specially  
edited sub sets of External Coding Systems, like Oceans Terminology  
Server and editor provide?
(Oceans product creates sub sets of a coding system to be used in a  
specific context. And acts at as a new refined, restricted, external  
coding system derived from a feeding general external coding system)

What will be rules that govern these things and prevent hazards for  
patients and healthcare providers?

Using the archetype editor we can provide bindings to Generic Basic  
Archetypes, Specialised Archetypes but also to Templates (Organising  
Archetypes) and Specialised Templates.
Specialisations can be made for specific clinical (sub-)domains or  
legal jurisdictions.
Archetypes define what maximally can be recorded about a clinical  
concept.
Templates define what minimally must be recorded in a specific  
context, as the agreement between two or more communicating partners.  
Most (refined) constraints will be applied in Templates.

Archetypes need some terminological bindings. Since they are general  
it can not be fixed fully at design time to what external  
terminologies they can be bound.
Primarily they will use internal codes. In particular controlled  
circumstances a clinical domain might adopt a specific external  
coding system to be used in Archetypes designed for that domain.
Most codes (internal and external) used in Archetypes will code  
'labels' and less data fields.
When data fields are bound to a specific external coding systems  
there will arrise the need for a similar Archetype but bound to an  
other coding system. This will need an Archetype Ontology where we  
can create a mechanism that establishes that two archetypes express  
the same clinical concept but in a different way, using an other  
(internal or external) coding system.

In the world of Templates things are different. This is a space that  
is much less controlled. Local/regional/national agreements have to  
be made on the finest detail. Most codes will be used in data fields.  
A lot of local freedom will be necessary.

I have not extended the discussion of binding Archetype Slots to a  
coding system that is used in connection to  'The Archetype Ontology'.

Archetypes and specialised archetypes have to be subjected to quality  
control in order to prevent hazards, because of errors and non- 
interoperability.
EuroRec (the European Institute for Health records) is executing an  
Europ[ean project: Q-Rec. Q-Rec will, among others, will realise an  
Archetype and Template Registry.
Its main purpose is to realise: Quality Labeling and Certification of  
EHR-systems. This will have to include Archetypes.
Eurorec will organise quality control of the archetypes and templates  
to be published. It might be a good idea to involve them.

Helpful in this respect is that:
- there is an agreement between OceanInformatics and EuroRec,
- several players from OpenEHR and CEN/tc251 EN13606 are members of  
the Q-Rec consortium and EuroRec,
- persons active in EuroRec and OpenEHR take part in worldwide  
developments on Archetypes/templates, Semantic Interoperability,  
discussions on the deployment of coding systems.


Greetings,

Gerard

--   --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 653 108732

Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 19-dec-2006, at 9:56, Williamtfgoossen at cs.com wrote:

> In een bericht met de datum 18-12-2006 20:44:14 West-Europa  
> (standaardtijd), schrijft Thomas.Beale at OceanInformatics.biz:
>
>
>> This is not an unreasonable request - it would not be particularly
>> difficult to implement in the specs or the tools, if we know what to
>> implement. We have to be careful with Snomed licensing issues however
>> when the terminology is snomed...
>
>
> I think there is no reason to be careful if within a realm. Key is  
> to take care where to apply and where not. My earlier comments on  
> binding not only to one terminology but to have mapping tables with  
> synonyms applies here too.
>
> William

-- next part -

ontology, information models, archetypes - a perspective

[Gerard Freriks]

Thomas,

Thanks.

What you are saying is:
- we have the real and other worlds with objects and our present  
understanding of it,
- and we have the world where we document what has happened or will  
happen.

Gerard


--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 7-jan-2006, at 5:03, Thomas Beale wrote:

>
> Dear all,
>
> for those interested in how ontologies (like snomed-ct for  
> example), information models (like openEHR RM), and mediating  
> elements (archetypes, templates) can be understood in perspective,  
> I have produced a short powerpoint slideshow on the topic. See  
> http://www.deepthought.com.au/health/tb_ontologies.ppt.
>
> - thomas beale
>
> -- 
> __ 
> _
> CTO Ocean Informatics (http://www.OceanInformatics.biz)
> Research Fellow, University College London (http:// 
> www.chime.ucl.ac.uk)
> Chair Architectural Review Board, openEHR (http://www.openEHR.org)
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060107/4561bcce/attachment.html>

[GPCG_TALK] Archetype Maintenance

[Gerard Freriks]

What XML DTD's or XML-schema's are for characters/text
are
Archetypes for Information.
Therefore both Information and the Archetype much be stored locally.


Gerard

-- 
-- 
Gerard Freriks, MD
Convenor CEN/TC251 WG1

TNO Quality of Life
Wassenaarseweg 56
Leiden

PostBox 2215
22301CE Leiden
The Netherlands

T: +31 71 5181388
M: +31 654 792800


On 8-jan-2006, at 10:17, Tim Churches wrote:

> Thus, archetypes need to be stored, permanently, with the data. This
> implies that each and every openEHR/archetypes storage system must be
> able to permanently cache (that is, archive) each version of every
> archetype definition it has ever used to store any data.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/bf91731e/attachment.html>

[GPCG_TALK] Archetype Maintenance

[Gerard Freriks]

Information is exchanged in communities.
All clinical information belongs to the healthcare domain.

When clinical concept models (Archetypes) are expressed using an Open  
International Standard like the CEN/tc251 Archetypes,
  both the Archetype expression and  the constituting clinical  
concept models are not owned in a commercial sense.

Gerard

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 8-jan-2006, at 10:17, Tim Churches wrote:

> If the argument above - that there is a need to permanent cache or
> archive copies of archetype definitions with the data which relies on
> them - then all archetype definitions need to be licensed in a manner
> which permits users to keep permanent copies of them. My (limited)
> understanding of copyright law is that such rights are not  
> automatically
> or implicitly granted - thus an explicit license to keep permanent
> copies of archetype definitions will always be needed on every  
> archetype
> definition. Furthermore, if an end user wants to transfer
> his/her data which happens to be stored using an archetype definition
> for which the copyright is held by someone else (which will usually be
> the case, since end users will rarely author their own archetype
> definitions, especially de novo ones), then the archetype definition
> used to store the end user's data must be licensed in a way that  
> permits
> the end user to redistribute that archetype definition to third  
> parties,
> without the need to ask permission from the copyright holder of that
> archetype definition.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/845bb6ed/attachment.html>

[GPCG_TALK] Archetype Maintenance

[Gerard Freriks]

If enough Archetypes are produced by scientific communities and  
associations and published IP free,
then what is the problem?

Gerard



--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252 544896
M: +31 654 792800


On 8-jan-2006, at 21:49, Tim Churches wrote:

> Gerard Freriks wrote:
>> Information is exchanged in communities.
>> All clinical information belongs to the healthcare domain.
>>
>> When clinical concept models (Archetypes) are expressed using an Open
>> International Standard like the CEN/tc251 Archetypes,
>>  both the Archetype expression and  the constituting clinical   
>> concept
>> models are not owned in a commercial sense.
>
> Certainly most of us would like that to be true. I was just wondering
> aloud whether it was true in a strict legal sense. I suspect that  
> it is
> an issue which requires expert legal advice, and the situation may be
> subtely different in each country due to differences in copyright law.
> It just seems like a good idea to investigate such issues when  
> adopting
> a new paradigm for storing and communicating data.
>
> Tim C
>
>> On 8-jan-2006, at 10:17, Tim Churches wrote:
>>
>>> If the argument above - that there is a need to permanent cache or
>>> archive copies of archetype definitions with the data which  
>>> relies on
>>> them - then all archetype definitions need to be licensed in a  
>>> manner
>>> which permits users to keep permanent copies of them. My (limited)
>>> understanding of copyright law is that such rights are not   
>>> automatically
>>> or implicitly granted - thus an explicit license to keep permanent
>>> copies of archetype definitions will always be needed on every   
>>> archetype
>>> definition. Furthermore, if an end user wants to transfer
>>> his/her data which happens to be stored using an archetype  
>>> definition
>>> for which the copyright is held by someone else (which will  
>>> usually be
>>> the case, since end users will rarely author their own archetype
>>> definitions, especially de novo ones), then the archetype definition
>>> used to store the end user's data must be licensed in a way that   
>>> permits
>>> the end user to redistribute that archetype definition to third   
>>> parties,
>>> without the need to ask permission from the copyright holder of that
>>> archetype definition.
>>
>>
>>
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060108/d4c18933/attachment.html>