Lifestyle: substance_use archetype

[Bill Walton]

Gerard Freriks wrote:


> Irrespective of a regular drug, herbal tea,
> food additive, smog, self medicated, prescribed,
> or taken by an involuntary action one always want
> to record the same things.  Isn't it?

My sentiments, precisely.

> So why not a generic Archetypes:  "Observation: Substance Use"

Because, IMHO, the information would be more appropriately recorded under 
"Medications".  The other "Observation" archetypes are much different than 
the "Substance Use" archetype.  I can see where it would be appropriate to 
include info on 'substances' in that section when, for example, a urine test 
for the presence / absence of that substance needs to be recorded.  But in 
lieu of test results, it seems to me that 1) the info Sam's included in the 
archetype isn't the same type of info as that included in the other 
Observation archetypes, and 2) adding this info to the EHR using the 
Medications archetypes would be both natural and a simple matter.

Just my $0.02.

Best regards,
Bill 

Lifestyle: substance_use archetype

[Bill Walton]

Hi Karsten,

Karsten Hilbert wrote:
>
> Recording "substance use" is more intended to record a
> *fact* about the lifestyle of an individual rather than an
> *intent to treat* as with prescription drugs.
>
> There's a fine line as always: herbal teas, OTC drugs etc
> may or may not have been intended to be treatment by the
> provider. However, disambiguating such in a given case is at
> the discreetion of the provider/patient in question. OpenEHR
> needs to provide facilities for both.

It seems to me that 1) we want to provide a mechanism for recording _all_ 
substances used, and 2) for each, we want to record who 'prescribed' it. 
Patients "intend to treat" when they ingest herbal teas, OTC drugs, etc.. 
While I definitely see the value in recording the 'prescriber', I still 
don't see the value in creating a seperate archetype for 'substances' that 
are not provider prescribed.  In fact, it seems to me to create unnecessary 
complexity.

Example... A patient is undergoing chemotherapy.  The patient finds that 
smoking marijuana helps control the nausea.  If the patient lives in 
California their physician can prescribe the use of marijuana.  It they live 
in Texas, its use cannot be prescribed.

Another example... A patient wants to quit smoking cigarettes.  The 
physician prescribes Nicorette gum.  Then the FDA approves Nicorette for OTC 
sale.

What would be the information value of recording this information with 
different archetypes?  What would seperate archetypes allow me to do that I 
couldn't do as easily with a single archetype with a 'prescriber' attribute 
that could accomodate a value of 'self'?

Thanks,
Bill 

Lifestyle: substance_use archetype

[Bill Walton]

Hi Sam,

Could you say more about the need for 'substance use' archetypes?  I'm not sure 
I understand why it would be a good idea to record alcohol consumption 
differently from, for example, consumption of herbal teas.  Or prescription 
drugs for that matter.  I'm sure I'm missing something.

Thanks,
Bill
  - Original Message - 
  From: Sam Heard 
  To: Openehr-clinical 
  Sent: Tuesday, May 09, 2006 10:54 PM
  Subject: Lifestyle: substance_use archetype


  Dear All

  I have been working on the archetypes for lifestyle and have approached them 
with trepidation. I am aware that there are lots of things that a person might 
like to record, and a lot of preferences. So we need to have a rich model for 
these things.

  The first one I have published is substance use and as designed includes 
alcohol, tobacco, caffeine and others - it is possible to nominate the others 
and have as many as you wish.

  The substance archetype is on the Ocean site:
  
http://oceaninformatics.biz/archetypes/openEHR-EHR-OBSERVATION.substance_use.v1.html
  There is a link to the ADL on that page (second row)

  You will notice that I have not completed the descriptions in places, 
apologies.

  The question I have is whether it is best to deal with this as a broad 
archetype (deals with a number of substances although each slightly 
differently) or as specialisations. The current archetype is the former, but it 
would be possible to deal with these as three archetypes:

  Substance use
 \ _Alcohol
 \_Tobacco

  The advantage would be that you could look in the same place for the 
information and then see what the substance was, while the specialisation would 
provide the different recordings favoured for the different substances.

  The problem with this latter approach is that many people would probably use 
the unspecialised archetype for everything, and it would be difficult to get 
meaningful data about the most common substances leading to harm. For this 
reason, and the simplicity of use for software (templates mean that there could 
be three different templates that provided the same functionality), I favour 
the inclusive approach.

  I am interested in your thoughts, 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



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

Fwd: Msg#6 - Archetypes for mathematicians?

[Bill Walton]

- Original Message -
From: "Greg Woodhouse" 
To: "Hardhats" ; "Openhealth"

Sent: 2006-04-10 11:54 AM
Subject: [Hardhats-members] Archetypes for mathematicians?


> Forgive the cross-post, but the topic of archetypes has come up
> Hardhats, and once again, I find the language used to describe the
> concept vague and (at times) mysterious. If you'll forgive me for the
> use of some mathematical jargon here, I'd like to revisit the concept
> of abstracting measurements away from a particular choice of units. A
> familiar mathematical structure used to discuss the concept of distance
> is the metric space, defined as follows:
>
> A metric space (X, d) consists of a set X and map d: X x X --> R
> satisfying
>
> 1) d(x, y) >= 0
> 2) d(x, y) = 0 if and only if x = y
> 3) d(x, y) = d(y, x)
> 4) d(x, z) <= d(x, y) + d(y, z) (triangle inequality)
>
> Now, there are many metrics, not all of them arrising from Euclidean
> geometry, but certainly if X = R^2, the normal Euclidean metric
> provides a metric that we want to think of as independent of any
> particular scaling transformation. In particular, if alpha > 0, then
>
> d2(x, y) = alpha * d(x, y)
>
> is a perfectly good metric giving rise to a geometry that is
> essentially the same. In fact, a useful interpretation of the
> difference between d and d2 is that each represents a different set of
> units for the *same* metric space. But note that we "cheated" by
> introducing *two* metric spaces and then declared them to be the same,
> only having different units of measurement.
>
> Is there any other way to capture this sameness? Well, in truth, if you
> change the function d, then you have defined an entrirely new metric
> space, but the are not unrelated!
>
> Given spaces (X, d) and (Y, d) we say a function f: X --> Y is an
> isometry if
>
> 1) it is one to one and onto
> 2) for all x1, x2 in X, f(d(x1, x2) = d(f(x1), f(x2))
>
> If there exists an isometry (any isometry) between two spaces, we say
> they are *isometric*. It turns out that isometry is an equivalence
> relationship; i.e., it satisfies
>
> a) a ~ a
> b) if a ~ b then b ~ a
> c) if a ~ b and b ~ c, then a ~ c
>
> (where = is just a name for the relation in question).
>
> Mathematically, it seems natural to abstract distance away from a
> particular choice of units by passing to the equivalance class of
> spaces equivalent under isometry (written X/~). But there is a problem:
> The map pi : X --> X/~ associating earch metric space with its
> equivalence class destroys any privileged status a metric space in the
> equivalence class might have. If you like, for x in X/~ the fiber over
> x (pi^-1(x)) is just a set with no distinguished elements.
>
> So, what can be done? How can we hold onto the idea that there are
> parti cular units of measurement in which we might be interested
> (inches, centimeters, cubits) without sacrificing the idea that no
> particular system of units is privileged above the others?
>
> It seems a little formal, but one possibility is to define 1 as "the"
> set with one element. In fact, there are many, many such sets, but all
> of what follows can be shown to be independent of that choice. A
> "pointed" set is just a nondegenerate map 1 --> X, that is a function
> that picks out a distinguished element of the category of sets.By
> fixing a map 1 --> X, you are essenrially selecting units for your
> metric space. Now, if 1 in R is the number 1, then you can actually
> draw a communtative diagram
>
> X x X > R
>   | |
>   v v
> 1 x 1 > R
>
> Now, given an isometry X --> Y, is it possible to choose units in a
> natural way, so that change of units will give you a new isometry? The
> answer is yes and, in fact if f : X --> X is a change of unit, what is
> required is a *functor* T tranforming f to T(f) (making the above into
> a commutative cube!) in such a way that an isometry between metric
> spaces can be naturally viewed as an isometry between pointed spaces
> (spaces with units). Such a thing is called a natural transformation
> and it gives content to the vague assertion that the choice of 1 really
> doesn't matter.
>
> Intuitively, what this all means is that it's not enough to just choose
> units of meansurement, you need to be able to describe how that choice
> fits into the rest of your system. In practice, you need to fix a
> representation for storage, but that representation must not be
> privileged, and that can be avoided by describing in mathematical terms
> how a concrete model is transormed when the choice of representation
> changes.
>
> I do not know if I've missed the point of archetypes, but it does seem
> to me that functorial language can at least clarify what it means to
> get a value "through an archetype". To an outsider, this makes little
> sense because it seems to be mixing categories, and because an
> archetype should not really depend up on particular choice of
> represntation (units).
>
> ===
> Gregory Woodhouse  
>

Fwd: Msg#5 - Software Archetypes - single vs double systems

[Bill Walton]

- Original Message -
From: "Bill Walton" 
To: 
Sent: 2006-04-10 11:05 AM
Subject: Re: [Hardhats-members] Software Archetypes - single vs double
systems


> Hi Greg,
>
> Greg Woodhouse wrote:
>
> > What I find most frustrating about discussion of
> > archetypes is that it is so often vague and intuitive
> > in nature, making it rather hard to decipher.
>
> I didn't know what level of detail was desired.  Also, I'm not an expert
on
> archetypes and, as you'll see below, have no intention of putting myself
> forward as such.  Just thought I'd provide what information I could.  I
> didn't mean to frustrate, nor to offend.  Sorry if I did.
>
> > --- Bill Walton  wrote:
> >
> > > Archetypes provide a capability that's very familiar to programmers,
> > > but take it to the next level.  At the most basic level, it's about
> > > decoupling.
> 
> > > Archetypes (which I believe do not depend on an RDBMS
> > > implementation) provide a similar capability, but take it to the
domain
> level.
> >
> > By domain do you mean application domain?
>
> Not sure exactly what you mean by "application."   It may be too
low-level.
> I think of 'domain' as a place where we can, in general, use the same
words
> without having to worry about being misunderstood.  So, domain as in
> "domain-specific set of concepts" like medicine or aerospace.  Weight, for
> example, is a fairly unambiguous term in medicine, requiring at most I'd
> think, a qualifier for unit of measure.  That's because there's an
implicit
> assumption: the domain is "medicine as practiced on the planet Earth."
For
> aerospace folks, however, you might need to provide additional information
> about mass and gravitational field to get to a similar level of (lack of)
> ambiguity.
>
> 
>
> > >
> > > When working with an archetype-enabled system, programs / programmers
> > > work directly with domain concepts like blood pressure or height or
> > > weight.  The underlying data is stored / accessed through the
> > > archetype.
> >
> > But what does this mean?
>
> As suggested by your sig, I'll forward your email to the experts and get
> back to you with their response(s).
>
> Best regards,
> Bill
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Hardhats-members mailing list
> Hardhats-members at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members

Fwd: Msg#4 - Software Archetypes - single vs double systems

[Bill Walton]

- Original Message -
From: "Greg Woodhouse" 
To: 
Sent: 2006-04-10 10:46 AM
Subject: Re: [Hardhats-members] Software Archetypes - single vs double
systems


> What I find most frustrating about discussion of archetypes is that it
> is so often vague and intuitive in nature, making it rather hard to
> decipher.
>
> --- Bill Walton  wrote:
>
> > Software Archetypes - single vs double systemsHi Lorie,
> >
> > Archetypes provide a capability that's very familiar to programmers,
> > but take it to the next level.  At the most basic level, it's about
> > decoupling.  An RDBMS shields programs from the need to know about
> > the underlying structure of the data.  A program needs only know
> > about the db schema.  Views provide another level of abstraction,
> > shielding programs from changes in the schema.  Archetypes (which I
> > believe do not depend on an RDBMS implementation) provide a similar
> > capability, but take it to the domain level.
>
> By domain do you mean application domain? Or are you referring to
> domains in their technical sense in database theory (as a set of
> values)? At any rate, it is clear that you are trying to abstract away
> from a particular set of units, treating the quantity itself as a value
> (not how it might be represented).
>
> >
> > When working with an archetype-enabled system, programs / programmers
> > work directly with domain concepts like blood pressure or height or
> > weight.  The underlying data is stored / accessed through the
> > archetype.
>
> But what does this mean? It suggests that an archetype is realizable as
> a computational object (much as a schema may be realized as a set of
> relations, or a class instantiated to form an object). I suspect that
> this is the point at which an important concept is missing: The
> integers are a ring, but when I add two numbers, I'm not using the +
> operation of the category Ring, but rather of a specific member of that
> category, namely Z.
>
> > A trivial example of the benefits would be lbs. vs. kgs..
> >  In an archetype-enabled system, the program has no knowledge of the
> > unit-of-weight measure used to store the data.  Programs access the
> > data store with statements like (no representation made re: syntax)
> > store_weight(220, lbs) and patient_weight =
> > retrieve_weight(patient_id, kgs).
>
> Okay, here is some concrete syntax, but what are you really doing? Is
> kgs a flag or map (or something else altogether)? From a mathematical
> point of view, it's natural to think of it as a scaling transformation
> (a map). But that's  confusing, too, because it implies the existence
> of some reference instance out there (say kilograms) that is somehow
> privileged among other possible choices, and that your kgs flag is
> simply the scaling factor (isomorphism) you need to apply to get your
> chosen representation.
> >
> > You might want to take a look at
> > http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html for
> > a better, high-level understanding of the above.  This, and a good
> > deal of the related stuff, will be migrated shortly to the openEHR
> > site.
> >
> > Be happy to provide / get you more in-depth info if desired.
> >
> > hth,
> >
>
>
> ===
> Gregory Woodhouse  
>
> "It is foolish to answer a question that
> you do not understand."
> --G. Polya ("How to Solve It")
>
>
> ---
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
language
> that extends applications into web and mobile media. Attend the live
webcast
> and join the prime developer group breaking into this new coding
territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> ___
> Hardhats-members mailing list
> Hardhats-members at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/hardhats-members

Fwd: Msg#3 - Software Archetypes - single vs double systems

[Bill Walton]

Software Archetypes - single vs double systems
- Original Message - 
From: Bill Walton 
To: hardhats-members at lists.sourceforge.net 
Sent: 2006-04-10 9:02 AM
Subject: Re: [Hardhats-members] Software Archetypes - single vs double systems


Hi Lorie,

Archetypes provide a capability that's very familiar to programmers, but take 
it to the next level.  At the most basic level, it's about decoupling.  An 
RDBMS shields programs from the need to know about the underlying structure of 
the data.  A program needs only know about the db schema.  Views provide 
another level of abstraction, shielding programs from changes in the schema.  
Archetypes (which I believe do not depend on an RDBMS implementation) provide a 
similar capability, but take it to the domain level.  

When working with an archetype-enabled system, programs / programmers work 
directly with domain concepts like blood pressure or height or weight.  The 
underlying data is stored / accessed through the archetype.  A trivial example 
of the benefits would be lbs. vs. kgs..  In an archetype-enabled system, the 
program has no knowledge of the unit-of-weight measure used to store the data.  
Programs access the data store with statements like (no representation made re: 
syntax) store_weight(220, lbs) and patient_weight = retrieve_weight(patient_id, 
kgs).

You might want to take a look at 
http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html for a better, 
high-level understanding of the above.  This, and a good deal of the related 
stuff, will be migrated shortly to the openEHR site.

Be happy to provide / get you more in-depth info if desired.

hth,



- Original Message - 
  From: Lorie Obal 
  To: hardhats-members at lists.sourceforge.net 
  Sent: 2006-04-10 12:12 AM
  Subject: [Hardhats-members] Software Archetypes - single vs double systems


  Can anyone clarify/comment on the architecture principles called "archetypes" 
and "two-level" methodologies used in the openEHR project and openVistA? See:
  
http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf

  The openEHR docs imply that this is a significant departure from previous 
methodologies. I'm trying to compare/contrast this with vistA in a comparison 
framework. Any enlightenment appreciated.

  More info on openEHR & archetypes can be found at:
  http://www.openehr.org/publications/archetypes/t_archetypes.htm

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

Fwd: Msg#2 - Software Archetypes - single vs double systems

[Bill Walton]

- Original Message - 
From: Gregory Woodhouse 
To: hardhats-members at lists.sourceforge.net 
Sent: 2006-04-10 7:03 AM
Subject: Re: [Hardhats-members] Software Archetypes - single vs double systems




On Apr 9, 2006, at 10:12 PM, Lorie Obal wrote:


  Can anyone clarify/comment on the architecture principles called "archetypes" 
and "two-level" methodologies used in the openEHR project and openVistA? See:
  
http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf

  The openEHR docs imply that this is a significant departure from previous 
methodologies. I'm trying to compare/contrast this with vistA in a comparison 
framework. Any enlightenment appreciated.

  More info on openEHR & archetypes can be found at:
  http://www.openehr.org/publications/archetypes/t_archetypes.htm

  -Lorie 



I'm really mot familiar with this approach (frankly, I find the presentation 
hard to follow, though the longer paper 
http://www.deepthought.com.au/it/archetypes/archetypes.pdf, is easier to 
follow), but the problem is certainly a familiar one. A significant problem 
with VistA (and just about any other EHR) is that domain specific knowledge is 
embedded into code or intermixed with operational data all over the place.VistA 
has attempted (with some success) to add a layer of abstraction using 
mechanisms such as protocols, templates, or even options. Personally, I think 
VistA would very much benefit from a mechanism such as this (though from the 
technical side, I still have questions).


This is my (quite possibly incorrect) take on archetypes: In many ways, they 
are similar to the class models familiar from object oriented languages like 
Java or Python, but go further. Classes, such as Person, LaboratoryTest, or 
Organization are traditionally defined in terms of attributes and methods 
(functions). Attributes are well understood (a person has a name, test results 
must be measured in some units), but that's not enough, we need to be able to 
express how these concepts or classes are interrelated. In traditional object 
oriented development, this kind of knowledge (!) is encoded in methods written 
in a conventional programming language. For example, 4 and 5 may be members of 
the Number class, but to deduce that 4 < 5 (4 is less than 5), you need to use 
something like a compareWith method, which will most likely just be a wrapper 
around the usual comparison operator in the underlying language, so you're back 
to using code to express relationships.


Of course, ultimately, you do need to resort to writing code (programmer's 
jargon for writing programs in some language), but the question is whether you 
should do it sooner rather than later. In mathematics, for example, we have the 
concept of a total order. A relationship < is a total order if


1. It is not true that a < a (irreflexivity)
2. If a is not equal to be (often written a != b or a /= b), then either a < b 
or b < a (trichotomy)
3. If a < b and b < c, then a < c (transitivity)


These rules (axioms) represent what a programmer might call a constraint. 
Constraints are usually enforced by requiring some bit of code to evaluate to 
true. But there are problems with this approach: it is not very reusable, it is 
typically hidden deep in the implementation, and perhaps most importantly, it 
is difficult to reason formally about code.  It is by abstracting away from the 
(very general) concept of relationship and asking how constraints can actually 
be built (constructed) that we are able to reason more formally about them.


In fact, this is just what programming language types are. Starting with basic 
types like Number, Boolean, Character, etc. we can use familiar type 
constructors like Pair, List, Function to get types like Pair(Number, Number), 
List(Character) or Function(Number,r Number), and it turns out that types 
provide a very powerful method of reasoning about computer programs that can 
generally be performed automatically (which has obvious implications for 
program reliability).


Perhaps a more familiar example of the same concept is what is sometimes called 
dimensional analysis in chemistry or physics. We're all familiar with Newton's 
second law, F = ma. Can a given quantity be a force? Well, we know that mass is 
measured in kilograms (dimensions of mass) and acceleration is measured in 
units of meters per second squared (with dimensions of length/time^2), so the 
dimensions of force must be just the product mass*length/time^2. Now, suppose I 
work out that some number, say T, is the elapsed time between the moment I get 
up in the morning (guess what time of day it is here) and the time I arrive at 
the office. The dimensions of T are time, so if I write an equation setting it 
equal to a force, then something has obviously gone wrong.  But despite all its 
usefulness, dimensional analysis is still only a special case of the more 
general concept of type inference.


Another example of a constrai

Fwd: Msg #1 - Software Archetypes - single vs double systems

[Bill Walton]

Software Archetypes - single vs double systemsGreetings,

The posting below showed up on the hardhats list this morning.  I responded 
(after a brief, confirmatory exchange with Thomas) with a brief, high-level 
explanation of what archetypes "bring to the party".  That triggered a couple 
of additional exchanges with another poster (the original poster has yet to 
respond).  As you'll see, the additional exchanges led to a committment on my 
part to ask the experts (that's you folks).  I'll be forwarding those postings 
here in hopes you can / will answer some of the questions and so educate both 
them and me on the importance / value of using archetypes.

Best regards,
Bill

- Original Message - 
From: Lorie Obal 
To: hardhats-members at lists.sourceforge.net 
Sent: 2006-04-10 12:12 AM
Subject: [Hardhats-members] Software Archetypes - single vs double systems


Can anyone clarify/comment on the architecture principles called "archetypes" 
and "two-level" methodologies used in the openEHR project and openVistA? See:
http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf

The openEHR docs imply that this is a significant departure from previous 
methodologies. I'm trying to compare/contrast this with vistA in a comparison 
framework. Any enlightenment appreciated.

More info on openEHR & archetypes can be found at:
http://www.openehr.org/publications/archetypes/t_archetypes.htm

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

experience / opinions

[Bill Walton]

Hi Tim,

Tim Cook wrote:

> I *do* think it makes sense to use existing,
> tried and tested frameworks/components
> as part of an infrastructure where possible.

Do you include Ruby/Rails in your list of components/frameworks that make
sense to use?

Best regards,
Bill

experience / opinions

[Bill Walton]

Does anyone have any experience with / opinions about the suitability of Ruby 
and Rails as implementation platforms for openEHR?

Thanks,
Bill
-- next part --
An HTML attachment was scrubbed...
URL: 

difficulties starting an implementation

[Bill Walton]

Ed,

Are you planning to publish your paper?  Sounds like a lot of work and I'd
be interested in reading it.

Thanks,
Bill

- Original Message -
From: "William E Hammond" 
To: 
Sent: Thursday, January 19, 2006 8:22 AM
Subject: Re: difficulties starting an implementation


> Ian,
>
> I am writing a paper on national mandates for HIT and on nation adoptions
> of the EHR.  Can you point me to some documentation on Scotlands plans?
>
> Thanks
>
> Ed Hammond
>
>
>
>
>   Ian McNicoll MMS
>  To:
openehr-technical at openehr.org
>   Sent by:cc:
>   owner-openehr-technical@Subject:  Re:
difficulties starting an implementation
>   openehr.org
>
>
>   01/18/2006 03:47 PM
>   Please respond to
>   openehr-technical
>
>
>
>
>
>
> Hello again Rong,
>
> Glad to hear things are progressing. Do you have any thoughts about
> persistence layer options?
>
> In Scotland there is a hope to move to a single EHR for the whole
> country across all specialities. Personally I remain unconvinced that
> this is totally achievable, but if it is, it will demand a highly
> flexible and extensible architecture, backed by an equally structured
> complex persistence layer - the traditional relational DB will simply
> not work.
>
> Regards,
> Ian
>
>
> >
> > As I promised to reply to your post on the list, here I am. :)
> >
> > Personally I am convinced it is possible to implement the openEHR
> > specification even at this stage. We, at Acode, already proved it by
> > building a pilot EHR system which meets real-life requirement. Of
> > course, it wasn't easy since we started from scratch with the Java
> > implementation (kernel, parser, persistence, GUI), but also the
> > specification has been a moving target. After the version 1.0
> > specification is released, the situation will be quite different. Since
> > then, there won't be any major changes on the reference model which
> > really is the foundation of interoperable EHRs. This will hopefully
> > encourage more open source or commercial development on openEHR in the
> > near future.
> >
> > Cheers,
> >
>
>

Age

[Bill Walton]

Hi Thomas,

Thomas Beale:


> Bill Walton wrote:
>
> >It seems to me, although I'm not a physician, that there are, or we might
> >learn that, there are medical problems that crop up later in life that
are
> >related to whether or not a person was born full-term or not.  If so, or
it
> >it's a possibility, then perhaps that needs to be recorded.  Is there
some
> >sort of problem, either technical or philosophical, with recording both
DOB
> >and [estimated] DOC?
> >
> >
> Sam says that rather than estimated DOC, estimated date of delivery
> should be actually recorded, since if a DOC is estimated then recorded
> and it turns out that e.g. the father was known to still be in Canada
> that week on business, it can create all kinds of problems - when the
> explanation is probably compltely innocent. So he suggests that
> estimated DOC should be always computed from estimated DOD, rather than
> being stored. But the result is the same at the application level - a
> 0-offset age from the (approximate) moment of conception (for those
> patients for whom this is relevant obviously).

Please forgive my density ;-)

I understand what Sam's saying, but I don't see how that provides the
information to which I was referring.  Specifically, how would it be
recorded that a person was born at something (perhaps significantly) less
than full-term?

Thanks,
Bill

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

Age

[Bill Walton]

USM Bish wrote:

> > On Sat, Jan 29, 2005 at 01:07:06AM +, Thomas Beale wrote:
> >
> > I think it's a given that we assume that "age" is not literally
> > recorded in the db  - the question is whether date  of birth is
> > good enough.
> >
>
> If  the EHR  is  designed is  to be  developed  for a  'patient
> centric'  database  where  data  is  appended  from  the  first
> registration onwards to ad-infinetum till  his/ her death,  the
> only thing needed is DOB.

It seems to me, although I'm not a physician, that there are, or we might
learn that, there are medical problems that crop up later in life that are
related to whether or not a person was born full-term or not.  If so, or it
it's a possibility, then perhaps that needs to be recorded.  Is there some
sort of problem, either technical or philosophical, with recording both DOB
and [estimated] DOC?

Best regards,
Bill

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

Modelling Episodes in openEHR

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:
>
> Someone could come along later in the same
> institution, and define a new kind of episode, and
> retrospectively create all the Folders for that kind
> of episode in certain EHRs. This also won't
> change any of the underlying data. Episode
> Folders could also be removed, renamed, their
> references added to or removed - none of this
> changes any of the data either.

Do you envision this being done manually?  Or is there a programmatic
solution?  The question this thread has raised in my mind is well
illustrated by your comment below.

>
> 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?

Thanks,
Bill

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

Latest ADL workAtlanta bench and Clinical Archetype Editor

[Bill Walton]

Peter,

Elkin, Peter L., M.D. wrote:
>
> Also, I would recommend taking a
> look at the ebXML registry which is
> a federated Open Source registry which
> is currently available.  Also, Sun is
> implementing OWL support within the
> registry (which may be handy for users
> interested in direct reasoning from
> Archetypes).

Sorry for not responding to this sooner.  In all honesty, I didn't 'get'
your point at first.  Heck, I may still not be getting it ;-)  But having
given it some thought and *trying* to understand it, I do have some thoughts
and questions.  Before I get started, though, let me ask for clarification
on a couple of things.

As I read the ebXML.org site, they do not have a registry currently
available.  What they have available is a *specification* for a registry.
The way I read the site, they expect others to actually implement
registries.  If I've missed something, could you point me to it?  Were you
citing the ebXML registry as a mechanism we should look at using?  If so, in
what way?

Again as I read the site, what the ebXML registry registers is companies and
information about them that allows other companies to identify them for the
purpose of doing business with them electronically.  Sellers publish their
"Collaboration Protocol Profile or CPP as defined by [ebCPP] to the
Registry.  The CPP describes the seller, the role it plays, the services it
offers and the technical details on how those services may be accessed.  ...
The buyer browses the Registry ... to discover a suitable seller.  For
example the buyer may look for all parties that are in the Automotive
Industry, play a seller role, support the RosettaNet PIP3A4 [Purchase Order
business protocol] process and sell Car Stereos.  The buyer discovers the
seller's CPP and decides to engage in a partnership with the seller." (p.
16, "OASIS/ebXML Registry Services Specification v2.5)  The definition and
registry of the *protocols* (think Archetypes) used by the companies
registered within an ebXML registry is a seperate issue, handled by
organizations like RosettaNet.  It seems to me that the next issue we'll
face (perhaps very soon) WRT Archetypes is more like the one tackled by
RosettaNet than the one tackled by ebXML.  The ebXML-type provider registry
looks like an issue that won't come up until after the first one is
resolved.  I'd apprecite hearing your thoughts.

Best regards,
Bill

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

Latest ADL workAtlanta bench and Clinical Archetype Editor

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:


> Bill Walton wrote:
>
/snip/
> >
> You are right, and actually, having someone think
> about test plans and construct test cases / procedures
> would be a very useful thing.

Excellent.  Count me in.

> We would need to dicuss how to do this exactly

Development of the Test strategy should always, IME, be given explicit
attention. Would you like to have that discussion here or offline?  Also,
please let me know if it would be helpful to you and/or the team to have a
copy of my resume.  I'll be happy to send it along.

/snip/

> or debugging help pages (or maybe
> even writing them?)

Count me in here too.  On either or both fronts.

I look forward to participating in these and any other areas where I might
be able to provide some small value.

Best regards,
Bill

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

Latest ADL workAtlanta bench and Clinical Archetype Editor

[Bill Walton]

Thomas Beale wrote:

> Bill Walton wrote:
>
> >Is the development effort going to be
> >open to outside developers who want
> >to contribute?  If so, how will that work?
> >
/snip/
>
> We will publish a roadmap for other
> developers to read and discuss within
> the next 6-8 weeks. I encourage people
> on this list who would like to be involved
> in development, or might have resources
> to offer to discuss their interests here.
>
> I hope this answers your question.

Indeed it does.  Thanks.

I would like very much to become involved, but make no pretenses about being
able to contribute as a developer.  I've been managing projects / products /
programs / people for the last 15 years.  "Back in the day" I was judged to
be a good technical hand (C, Basic, and X86 Assembler), but I've only
recently begun working on getting my programming skills back (now working on
learning Java).

My experience tells me, though, that there's always lots of "grunt work" to
be done in bringing a product to market.  Testing and documentation are two
skills I can still credibly claim to have, and I'd be very happy to
contribute in those areas.  Or any other areas where having some outside
help would let the developers remain focused on producing working code.

Please let me know.

Best regards,
Bill

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

Open source implementation?

[Bill Walton]

Sam Heard wrote on Wednesday, January 14, 2004 2:50 PM:
Subject: RE: Open source implementation?


> Vincenzo
>
> The workplan in Australia has been delayed due to hefty negotiations and
the
> extension of a trial to involve 3 hospitals and 100 general practices. The
> contract still involves Java based work and is still to be published as
open
> source material - hopefully under openEHR. This large contract should be
> signed this week. I am not sure of the time line to release of the code,
> exactly what code will be released - we should know when the contract is
> finally signed.
>
> So...hold your breath!
>
> Cheers, Sam

Hi Sam,

What's the status of this?Has the contract been signed?  The decisions
reached?  I'm potentially interested in constructing an automated test suite
once the code's released.  Has that already been accounted for?

Thanks,
Bill

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

use case documents from the health care domain - ROLES

[Bill Walton]

Sam,

My response to Arild was in the context of use cases as information
gathering mechanisms.  You are, it seems to me, proposing use cases as
material that show both context and how to set up / use the ACL given that
context.  I agree that they would be valuable for the latter.  On the other
hand, you've demonstrated the problem of developing a single mechanism that
functions across different contexts very nicely.

The "Health Care Facility Nominated Trusted Clinician" section on page 5
contains the sentence "This access will be on a 'need to know' basis."  Here
in the U.S., HIPAA has specifically rejected "need to know" as a valid basis
for access.  A user of the EHR may only access information the patient has
granted them the right to access.  This complicates Access Control
considerably since it requires not only control of levels of information but
also specific health care episodes.  Take for example the case of a
businessman who contracts an STD on a trip to the Far East and receives
treatment upon returning home.  Here in the U.S. the patient, assuming he
paid cash for the treatment, has the right to deny access to even header
information disclosing the treatment ever occurred to anyone but himself and
the physician who rendered treatment.

I still wonder whether the Access Control Mechanism can't be made
configurable in terms of both Roles defined and Access Rights per Role.
Perhaps that's too complicated, especially for Version 1.  At any rate...
thanks for sharing.

Best regards,
Bill

----- Original Message -
From: "Sam Heard" 
To: "Bill Walton" ; 
Sent: Tuesday, November 18, 2003 12:26 AM
Subject: RE: use case documents from the health care domain - ROLES


> Bill
>
> I believe that we have to define roles in a standard manner that can work
in
> all settings - and that patients can understand when they go from place to
> place - it is a massive simplification - a little strange - but I think it
> can work. It requires that all policies are written using the same roles -
> patients can then give individuals specific roles - or more usually,
> hopefully, accept the local policy.
>
> I attach a paper that has had some positive response in different
> situations.
>
> Cheers, Sam
>
> > -Original Message-
> > From: owner-openehr-technical at openehr.org
> > [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill Walton
> > Sent: Tuesday, 18 November 2003 2:17 AM
> > To: openehr-technical at openehr.org
> > Subject: Re: use case documents from the health care domain]
> >
> >
> > Arild Faxvaag wrote:
> >
> > > Has someone tried to establish a collection of use case documents with
> > > descriptions of information-related tasks by health care workers?
> > >
> > > Would you developers consider it useful if such a collection existed?
> >
> > It seems to me that question of "context" needs to be addressed
> > before those
> > task descriptions will have much value.  I'm thinking that Roles
> > differ from
> > country to country, and in most cases, by health-care setting within a
> > country.  So just starting here we have a three-level hierarchy
> > (Country ->
> > Setting -> Role).  Once that's established, Responsibilities and
Authority
> > can be mapped.  Exceptions to Authority would need to be mapped.
> > Now we're
> > at five levels, perhaps six depending on the approach to mapping
> > exceptions.
> >
> > I wouldn't suggest even attempting to extend this to descriptions of the
> > tasks.  Just establishing the taxonomy above would be a huge job; forget
> > about the effort to maintain it over time.  Task descriptions would,
IMO,
> > make the maintenance task impossible.
> >
> > It seems to me that the value of such a collection would extend _much_
> > further than the development community.
> >
> > Best regards,
> > Bill
> >
> > -
> > 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

use case documents from the health care domain]

[Bill Walton]

Arild Faxvaag wrote:

> Has someone tried to establish a collection of use case documents with
> descriptions of information-related tasks by health care workers?
>
> Would you developers consider it useful if such a collection existed?

It seems to me that question of "context" needs to be addressed before those
task descriptions will have much value.  I'm thinking that Roles differ from
country to country, and in most cases, by health-care setting within a
country.  So just starting here we have a three-level hierarchy (Country ->
Setting -> Role).  Once that's established, Responsibilities and Authority
can be mapped.  Exceptions to Authority would need to be mapped.  Now we're
at five levels, perhaps six depending on the approach to mapping exceptions.

I wouldn't suggest even attempting to extend this to descriptions of the
tasks.  Just establishing the taxonomy above would be a huge job; forget
about the effort to maintain it over time.  Task descriptions would, IMO,
make the maintenance task impossible.

It seems to me that the value of such a collection would extend _much_
further than the development community.

Best regards,
Bill

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

What HIPAA means to you - a brief description

[Bill Walton]

Hi Thomas,

Thomas Clark wrote:

/snip/

> It was enacted to keep the payers happy and not the Patients.

I've studied both the HIPAA regs and the Preambles and come away with a
completely different impression.  It's probably OT for the list but I'd be
interested in going offline to get your perspective on this.  I've included
my email address below.

/snip/

> BTW: Findlaw is used as a reference, however bad, for the current state
> of the interpreted law within the US.

I know.  That's why I felt compelled to write the editors about the article.

> Your response is right on and should illustrate the need for a Uniform
> Model Code for ElHRs especially since this scenario will be repeated in
> many countries across the globe.
>
> If the US can have national and international model codes for Commerce
> it should have the same for Healthcare and EHRs. In essence the
> governments need a guiding light lest they visit another one like HIPAA
> on the populace!

With respect to the US, I don't disagree about the need for uniform
treatment and definitions.  HIPAA is, IMO, a good start on that.  Not
perfect by any means, but at least it raises the debate to the national
level.  HHS has charged HL7 and HIMSS with taking the next step; identifying
those things (functions and data) that are essential vs. desirable
components of an EHR system.  I think, though, that we should expect these
things to evolve over time.  The debate has just started.

With respect to the international scene, I respectfully disagree about the
desirability of a uniform set of rules.  The norms and mores of a medical
community must be in synch with those of the larger culture within which
that community exists.  I value diversity as a generator of alternative,
competing solutions.

Best regards,
Bill
bill.walton at jstats.com

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

What HIPAA means to you - a brief description

[Bill Walton]

Thomas Clark wrote:

> Hi All,
>
> The following link is to a FindLaw reference regarding what HIPAA means
> to Patients:
>
>
http://articles.corporate.findlaw.com/articles/file/00081/002452/title/Subje
ct/topic/Health%20Law_HIPAA/filename/healthlaw_1_335
>


This article contains an egregious error.

Under the section headed "Patient Rights Obligations" the author states that
"HHS had initially proposed allowing routine disclosures without advance
patient consent for treatment, payment and administrative operations, but
the final rule requires informed patient consent for even these routine
disclosures."

This is not true.  The final Privacy Rule *PERMITS* covered entities
(providers,  payers, clearinghouses) to obtain consent for use and
disclosure of protected information in treatment, payment, and operations
(there is some restriction in psychotherapy notes).  It does NOT require
consent for these uses.  At best the author did not read the Preamble where
this modification was clearly articulated to provide an option for those
providers who were fearful of missteps and preferred to err on the side of
caution.  Unforunately I find it hard to give the author the benefit of the
doubt and have written to the editors of FindLaw.com complaining about this
article.  HIPAA, like Y2K, has been the focus of far too many bottom feeding
lawyers creating self-serving FUD among the US healthcare community.

The US healthcare system has a bad enough rep without "help" like this.


Best regards,
Bill

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

HISTORY DATA SET IN EPR

[Bill Walton]

Hi Christopher,

Christopher Feahr wrote:

> For this reason, the Institute of Medicine content recommendations
> (reflected in the present version 1.0 of the HL7 EHR ballot) includes 4
> main care settings: in-patient, out-patient, nursing home, and "personal
> health record".  The last is the patient's view of the record...

I think I'm a little lost here.  I've read HIPPA, the regs and the preample,
and my understanding is that the patient now has a legal right to copies of
his medical record and a right to contest the contents of that record.  Are
you saying that the IOM / HL7 are taking the position that the physician can
decide to withhold portions of that record?  Where can I find out more about
this?

Best regards,
Bill

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

list management Q

[Bill Walton]

I support the change.

Best regards,
Bill
- Original Message - 
From: "Thomas Beale" 
To: 
Sent: Friday, August 08, 2003 8:21 PM
Subject: list management Q


> 
> Who would prefer that the openehr list manager be changed to the mode 
> where just hitting "reply" always sends back to the list (i.e. the list 
> manager sets 'reply-to')? I for one prefer that, and would like to 
> reduce teh duplicate posts that come with the "reply-all" method.
> 
> please RESPOND IF YOU WANT IT CHANGED, and if there are a lot of 
> responses, we can get it changed, else it will remain the way it is.
> 
> - thomas beale
> 
> 
> -
> 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

certification and verification of OpenEHR

[Bill Walton]

/big snip/

> OPINION: Would like to see a tool that can access/breakdown different
types
> of EHRs, support information transfer and synthesis of additional records,
> even a modified EHR.
>
> Are there others on the list interested in this topic?
>
> -Thomas Clark

Definitely.

Best regards,
Bill

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

Activity

[Bill Walton]

Just wondering why there's been so little activity on the list over the last
couple of months.  Also about progress on version 0.9.  Any info?

Best regards,
Bill

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

Patient Privacy: Impact of Outsourcing

[Bill Walton]

Hi Tom,

I'm not sure I'd call this a dead horse.  The HIPAA Security Rule talks a
bit about the need for sanctions as a component of achieving compliance at
68 FR 8347 (first column).

"The sanction policy is a required implementation specification because --
(1) the statute requires covered entities to have safeguards to ensure
compliance by officers and employees; (2) a negative consequence to
noncompliance enhances the likelihood of compliance; and (3) sanction
policies are recognized as a usual and necessary component of an adequate
security program."

Surely, moving the protected health information to a location and putting it
in the control of people outside U.S. jurisdiction compromises the ability
to impose sanctions in the event that security is compromised.  Especially
since the outsourcer would be a Business Associate and, under the HIPAA
rules, Kaiser would not be held responsible for their actions.

The downside is that the Security Rule doesn't go into effect until April
20, 2005.  On the other hand, Kaiser's moving that data offshore might be
seen as a preemptive move to avoid the Security Rule and, given that Health
Care is likely to be an issue in the upcoming Presidential campaign, it
might be something the politicians here would latch on to.  I think Kaiser
covers about 50 million Americans.  That's a lot of potentially pissed off
voters.  Hmmm.  Might be a Cause here.

Best regards,
Bill

- Original Message -
From: 
To: 
Sent: Saturday, May 17, 2003 2:08 AM
Subject: Patient Privacy: Impact of Outsourcing


> Hi All,
>
> The following link is to an article appearing in the San Francisco
Chronicle
> online version, May 14, 2003 entitled:
>
> LAZARUS AT LARGE
> Kaiser exporting privacy
>
>
http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2003/05/14
> /BU307139.DTL&type=tech
>
> Unfortunately this has been predicted by many. Rushing out to contact
> members of the US congress requesting a new privacy and security bill
would
> be too late and probably wasted effort. It should highlight the need for
> very stringent security mechanisms and procedures that continually monitor
> and track data transmission and storage at a minimum.
>
> In previous emails 'Secure Data Store' facilities have been mentioned.
This
> is just one example why they are needed.
>
> -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

openEHR security; Directed to Thomas Beale

[Bill Walton]

Tim Churches wrote:
/snip/

> Maybe I've missed something much earlier on this thread, but don't you
need a
> target security policy and associated threat model before you start
designing
> ways to implement it? The problem, of course, is that there is no single
agreed
> policy, even in broad terms. But to me, the best starting point is still
Ross
> Anderson's exposition of the policy he developed for the British Medical
> Association - for the CiteSeer reference see
> http://citeseer.nj.nec.com/anderson96security.html

/snip/

> Anyway, the Anderson paper is worth a read, or a re-read.

Thanks for the link.  I definitely found it worthwhile.  Anderson has a page
at Cambridge that's got a lot of good stuff worth spending some time on.
His work on Medical Records (and other stuff too) is at
http://www.cl.cam.ac.uk/~rja14/#Med

Best regards,
Bill

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

interesting article

[Bill Walton]

Thought some of you might find the article at the link below interesting re: 
the increased realization of the need for interoperability in medical records 
systems.

http://www.baselinemag.com/article2/0,3959,1054863,00.asp

Best regards,
Bill
-- next part --
An HTML attachment was scrubbed...
URL: 

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Bill Walton]

Hi Alby,

Alby Creevey wrote:


> There a many other products that will provide the same sort of Secure
> Message Delivery as well. (HIPPA ain't an insignificant piece of work,,,
but
> hey,, they might not have it right)

I'll be checking into it.  The test phase for HIPAA compliance re: the
Transaction Rules has just started and should yield some publicly available
information in short order.

> Guys,,,Don't get bogged down in the technical detail, define the business
> process and rules first,, and the rest will follow.

HHS (Dept.of Health and Human Services of the U.S. Food and Drug
Administration) has, through the promulgation of the HIPAA Privacy Rule
(compliance date of 4/14/03), Transaction Rule (compliance date of
10/16/03), and Security Rule (compliance date of 4/20/05) defined a new set
of business rules for Health care providers, plans, and clearinghouses here
in the U.S..  The new rules are seen by practioners as introducing new costs
and risks in a business that's already under attack on many fronts.  If
automation emerges that can help them reduce the costs and risks, the
likelihood is that they'll adopt it quickly.  This is being viewed as an
important opportunity by EHR vendors, one that could see the rapid and
widespread adoption of EHR systems.  IMO, it's an even larger opportunity
for the open source community given the financial pressures the provider
community are already under.  So now it's time to see if we're up to the
task.

Best regards,
Bill

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

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Bill Walton]

Hi Thomas,

Thanks for the link.  I've enjoyed your posts.

Best regards,
Bill

- Original Message -
From: "Thomas Clark" 
To: "Bill Walton" ; ;
"Thomas Beale" 
Sent: Sunday, May 04, 2003 10:54 PM
Subject: Re: Access controls and Audit trails (was Re: openEHR security);
Bill Walton


> Hi Bill.
>
> The following link might be appropriate for ftp-based messaging solutions:
>
> http://www.linuxmednews.com/linuxmednews/1046134538/index_html
>
> TITLE: "... and open-source Electronic Data Interchange"
>
> NOTES:
> -"... SolAce Server was designed to do reliable, secure messaging in
> compliance with the HIPAA Security Rule ..."
>
> -written in Java
>
> -Thomas Clark
>
> - Original Message -
> From: "Bill Walton" 
> To: ; "Thomas Beale"
> 
> Sent: Sunday, May 04, 2003 8:14 PM
> Subject: Re: Access controls and Audit trails (was Re: openEHR security)
>
>
> > Hi Thomas,
> >
> > Thomas Beale wrote:
> > >
> > > Bill Walton wrote:
> > > >
> > > > > > BW:  Further, it looks like the EHR access history should
include
> > > > reads as well as writes.  That way, the trail would lead to the
> > > > providers that have, with permission, made copies of the EHR within
> > > > their own systems.
> > > >
> > > > > SH: True - it will only be able to be stored as an HTML rendition
> > > > unless there is an extract in openEHR - but you are right - this
could
> > > > be saved - this is difficult to police.
> > > >
> > > > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > > > specifies, under the Transaction Rules that go into effect in
October
> > > > of this year, a number of EDI transactions between systems that
would
> > > > require this.  HTML will not be sufficient.
> > >
> > > Can anyone clarify this bit of the debate - I have lost track of what
is
> > > being said here!
> >
> > I was inquiring about the audit trail capabilities intended to be
> > incorporated in v1.0 of openEHR and Sam was very graciously trying to
> > enlighten me.  His commment re: HTML made me expand the question to
> > extracts.  I'm not sure I was sufficiently clear about my line of
> > questioning, and comments by others make me wonder whether or not I
should
> > take this off-line.  I am specifically trying to ascertain the
> applicability
> > of openEHR to the emerging requirements here in the U.S. and do not wish
> to
> > infringe on the group's bandwidth if there is a less intrusive way to
> handle
> > my questions.  Please let me know how you'd like me to proceed.  And
thank
> > you all for your patience to date.
> >
> > Best regards,
> > Bill
> >
> > -
> > 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

Access controls and Audit trails (was Re: openEHR security)

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:
>
> Bill Walton wrote:
> >
> > > > BW:  Further, it looks like the EHR access history should include
> > reads as well as writes.  That way, the trail would lead to the
> > providers that have, with permission, made copies of the EHR within
> > their own systems.
> >
> > > SH: True - it will only be able to be stored as an HTML rendition
> > unless there is an extract in openEHR - but you are right - this could
> > be saved - this is difficult to police.
> >
> > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > specifies, under the Transaction Rules that go into effect in October
> > of this year, a number of EDI transactions between systems that would
> > require this.  HTML will not be sufficient.
>
> Can anyone clarify this bit of the debate - I have lost track of what is
> being said here!

I was inquiring about the audit trail capabilities intended to be
incorporated in v1.0 of openEHR and Sam was very graciously trying to
enlighten me.  His commment re: HTML made me expand the question to
extracts.  I'm not sure I was sufficiently clear about my line of
questioning, and comments by others make me wonder whether or not I should
take this off-line.  I am specifically trying to ascertain the applicability
of openEHR to the emerging requirements here in the U.S. and do not wish to
infringe on the group's bandwidth if there is a less intrusive way to handle
my questions.  Please let me know how you'd like me to proceed.  And thank
you all for your patience to date.

Best regards,
Bill

-
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

[Bill Walton]

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.  The "appropriateness" of an access to a record
can only be determined ex post facto in many cases.  An example may help.
Suppose a nurse prints a copy of one of her patient's records during her
shift.  Is this appropriate access?  On it's face, at the time of access, it
would appear so.  Suppose further,  though, that the nurse later sells that
copy to a third party who uses it to the patient's disadvantage.  Now it's
clear that the access was for inappropriate purposes.  No system can
pre-judge intent.  If the access is not logged, there will be no trail to
the event that led to the inappropriate disclosure and the system will have
contributed to the patient's disadvantage.  Further, unless the list of
accesses is maintained as part of the EHR, there's no guarantee that the
patient will have access to that information.  Thus, I believe the audit
trail functionality must be "in scope" for openEHR, at least to the extent
that the group intends it to be viable here in the U.S..

Best regards,
Bill


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

GEHR philosophical background info

[Bill Walton]

Hi Paul,

I can't tell where you're located but if you're here in the U.S., HIPAA's 
Privacy Rule went into effect on the 14th of this month and went a long way 
toward resolving this problem.  Your case is a good example of the reason HIPAA 
was instituted.  Although it doesn't clearly address the ownership question, 
it's pretty comprehensive in terms of the "use and disclosure" of individually 
identifiable health information.  I'm not an attorney but, from my reading of 
HIPAA, the situation you describe would have a different outcome in the U.S. 
today.

Best regards,
Bill
  - Original Message - 
  From: Paul Juarez 
  To: bill.walton at jstats.com ; openehr-technical at openehr.org 
  Sent: Monday, April 28, 2003 3:48 PM
  Subject: Re: GEHR philosophical background info


  Bill,
   
  Without federal legislation or some consensus upon formally adapted 
professional standards there will be much room for interpretation of ownership 
of patient records.  I was in a situation about two years ago where I was 
working with a university affiliated primary clinic in which the university 
claimed ownership of the records and wanted open access to all patient records 
(they were on a fishing expedition).  Clinic staff took the position that any 
access to the medical records other than where there was a "right to know" 
(e.g. defined audit) required patient consent.  The judge ruled in favor of the 
University and levied a hefty fine against clinic staff (myself included) for 
blocking access to the University's records  My point is that until  the 
issue of ownership is clearly spelled out, questions of access are going to be 
left to the discretion of judges and attorneys! 
   
  Paul Juarez


  >>> "Bill Walton"  04/28/03 01:32PM >>>

  Hi Paul,

  I agree completely that the ownership question is fundamental.  Until 
recently I was under the mistaken impression that everybody agreed that the 
patient owned their medical records and that physicians were simply the 
stewards.  Then I discovered that, as of the early '90's, fewer than one third 
of the states here U.S. even had laws that required that patients be given 
access to their records.  So yes, I think that clearing up the question of 
ownership is ultimately necessary.  And I'm hoping that the move to electronic 
form will, at least in part, both precipitate that discussion and facilitate 
the implementation of what I perceive to be to be the obvious answer.

  Best regards,
  Bill
- Original Message - 
From: Paul Juarez 
To: bill.walton at jstats.com ; openehr-technical at openehr.org 
Sent: Monday, April 28, 2003 3:04 PM
Subject: Re: GEHR philosophical background info


I've been following these discussions with a lot of interest.  So I guess 
it's time for me to put in my two bits.  While I've seen a couple of references 
to ownership of the medical record, I havent seen anything definitive that 
defines it (e.g. patient, provider, legal custiodian of record, etc., or some 
combination).  It seems like this question needs to be clearly agreed on before 
issues of access can be identified.  (It also could be a partial solution to 
distinguishing between the terms EMR, EHR, EPR).  HIPAA aside, it seems that 
there may be some different legal issues about ownership that would also have 
implications for access.  Any thoughts?


>>> "Bill Walton"  04/28/03 12:32PM >>>

Hi Sam,

> > BW:  This is a really interesting problem space to me.  I've been 
studying HIPAA (the Health care Information Portability and Accountability Act) 
and have become 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.
 
> > SH:  I agree - it is fascinating. Can I point you to our (original work 
on this - quite philosophical) which I wrote with Len Doyal - a professor of 
medical ethics in London. 
http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8
 
I hate to ask this, but is there one deliverable you could point me to that 
contains the philosophical stuff?  I'm up to my eyeballs right now and I can 
see there's a whole bunch of good stuff at the Chime site on GEHR that I'll 
have to get to asap.

Thanks,
Bill
  > 
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030428/abb5f672/attachment.html>

openEHR security

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:


/snip/

> So. What do we know?
> - role-based access control is required. To make it work properly in a
> shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> nursing care, social workers etc etc) then the roles need to be defined
> congruently. I seem to remember some Canadian project coming to the
> conclusion that really the roles need to be defined the same across the
> entire (national) health care system. I think this is both correct and a
> the same time unrealistic.

With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
correct.  (Pragmatism R Us ;-) )

I'd like to offer food for thought.  The fundamental assumption at work here
seems to be that care givers will access the same system, thus driving the
need for all users of the system to be assigned roles that are defined
congruently.  Let's consider an alternative model.

When I travel from the U.S. to the U.K., I (the physical being) move from
one socio-cultural-legal model to another.  That does not change who / what
I am, but it does change my behavior because I operate under a different set
of norms and mores in the new environment.  I accept new forms of
interaction and find that familiar forms are no longer available.

Why should it be any different for the information about me than it is for
me?

If we work from a perspective that posits that health information will move
from system to system and be used / modified based on the rule sets in place
within the various systems, does that make the problem more amenable to
solution?

> I think we will be able to find ways of
> having diversely defined roles without every health care facility having
> incompatible definitions of "consultant", "treating physician" etc.
> Bernd's work on this area is pretty detailed.

I thank Bernd for opening my eyes to what should have been obvious to me at
a much earlier stage.  The security problem with EHR systems is
fundamentally the same problem faced in OLAP databases.  Or perhaps I should
say that it's the OLAP security problem with a twist.  At least OLAP
databases are typically confined to one environment / business.  It's clear
that the EHR problem is more difficult in that EHR's must, IMO, be capable
of moving between environments.  Perhaps, by requiring a more generalized
solution, the EHR problem will actually be easier to solve.

I don't know if you've checked out Mike Mair's paper but it implicitly poses
a very interesting question.  "Is a biologically-based security model
fundamentally better aligned with the needs of an information system about
biological entities than alternative models?"  I'm hopeful the list will
have some comments on Mike's paper.  I think the question is worth some
thought / discussion.

/snip/

Best regards,
Bill

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

GEHR philosophical background info

[Bill Walton]

Hi Paul,

I agree completely that the ownership question is fundamental.  Until recently 
I was under the mistaken impression that everybody agreed that the patient 
owned their medical records and that physicians were simply the stewards.  Then 
I discovered that, as of the early '90's, fewer than one third of the states 
here U.S. even had laws that required that patients be given access to their 
records.  So yes, I think that clearing up the question of ownership is 
ultimately necessary.  And I'm hoping that the move to electronic form will, at 
least in part, both precipitate that discussion and facilitate the 
implementation of what I perceive to be to be the obvious answer.

Best regards,
Bill
  - Original Message - 
  From: Paul Juarez 
  To: bill.walton at jstats.com ; openehr-technical at openehr.org 
  Sent: Monday, April 28, 2003 3:04 PM
  Subject: Re: GEHR philosophical background info


  I've been following these discussions with a lot of interest.  So I guess 
it's time for me to put in my two bits.  While I've seen a couple of references 
to ownership of the medical record, I havent seen anything definitive that 
defines it (e.g. patient, provider, legal custiodian of record, etc., or some 
combination).  It seems like this question needs to be clearly agreed on before 
issues of access can be identified.  (It also could be a partial solution to 
distinguishing between the terms EMR, EHR, EPR).  HIPAA aside, it seems that 
there may be some different legal issues about ownership that would also have 
implications for access.  Any thoughts?


  >>> "Bill Walton"  04/28/03 12:32PM >>>

  Hi Sam,

  > > BW:  This is a really interesting problem space to me.  I've been 
studying HIPAA (the Health care Information Portability and Accountability Act) 
and have become 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.
   
  > > SH:  I agree - it is fascinating. Can I point you to our (original work 
on this - quite philosophical) which I wrote with Len Doyal - a professor of 
medical ethics in London. 
  http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8
   
  I hate to ask this, but is there one deliverable you could point me to that 
contains the philosophical stuff?  I'm up to my eyeballs right now and I can 
see there's a whole bunch of good stuff at the Chime site on GEHR that I'll 
have to get to asap.

  Thanks,
  Bill
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20030428/62b6d36a/attachment.html>

GEHR philosophical background info

[Bill Walton]

Hi Sam,
 
> > BW:  This is a really interesting problem space to me.  I've been studying 
> > HIPAA (the Health care Information Portability and Accountability Act) and 
> > have become 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.
 
> > SH:  I agree - it is fascinating. Can I point you to our (original work on 
> > this - quite philosophical) which I wrote with Len Doyal - a professor of 
> > medical ethics in London. 
http://www.chime.ucl.ac.uk/work-areas/ehrs/GEHR/Deliverables.htm#D8
 
I hate to ask this, but is there one deliverable you could point me to that 
contains the philosophical stuff?  I'm up to my eyeballs right now and I can 
see there's a whole bunch of good stuff at the Chime site on GEHR that I'll 
have to get to asap.

Thanks,
Bill
-- next part --
An HTML attachment was scrubbed...
URL: 

EPR vs. EHR

[Bill Walton]

Hi Sam,

> >  BW:  What's an EPR, what's in it, and what, if any, information overlap 
> > does it have with an associated EHR?  You introduce EPR in the first 
> > example, but there's no definition provided and no reference to an external 
> > source. 
 
> SH: Again, we have had a lot to say about this over the years. In openEHR - 
> it is the EHR - so the boundary is the model itself. There is a real problem 
> in the federated approach with addressing this - but I think openEHR gives a 
> clean approach.

I just want to make sure I'm understanding this correctly.  If I understand 
your response above, you're saying that EPR and EHR are one and the same.  The 
reason I ask again is that the second example in Appendix A of "Access to 
Electronic Health Records" seems to imply that they are different in the 
following sense.  It looks like the EPR is a record of a specific transaction 
and that the EHR is a compliation of EPR's over time.

Thanks,
Bill
-- next part --
An HTML attachment was scrubbed...
URL: 

normalizing access vs. normalizing denial (was openEHR security)

[Bill Walton]

HI Sam,
 
> > BW:  Related to all of the above, it seems like there are probably a number 
> > of circumstances that would require that the control of the Access Control 
> > list itself be capable of being over-ridden or delegated.  It looks to me 
> > like, as currently defined, the only roles that could grant access would be 
> > the patient and Next of Kin roles.  But assume, for example, that a patient 
> > is hospitalized, needs a test performed that can't be performed in the 
> > facility, and has designated a Next of Kin that's not present.  Perhaps 
> > it's just a difference between our systems, but in the U.S. I can imagine a 
> > need to delegate the right to change the Access Control list without 
> > delegating some of the other decisions (e.g., "pull the plug") that are 
> > associated with Next of Kin here.  Again, as long as the Audit Trails are 
> > in place it seems that fears of inappropriate access might be effectively 
> > balanced against the needs of providers re: access to the records for the 
> > purpose of delivering the appropriate care.  Or perhaps I'm 
> > misunderstanding the Next of Kin role.
 
> SH: The whole approach is to normalise access rather than normalise denial - 
> so a transfer of a record (or part there-of) would almost always mean that 
> the person giving permission for the transfer was happy with the hospital 
> policy - as advertised under these 6 roles. The access control list would 
> have to be changed by an authorative person when parts of the record required 
> for ongoing care had been limited a clinician who had left. Logging these 
> things is far more important than being highly restrictive - the latter being 
> possible if the patient wants this.

It looks to me like maybe there needs to be rights to change the Access Control 
List associated with each of the roles currently defined.  Or maybe there 
already are and I've just misunderstood.  I completely agree that logging is 
far more important than being restrictive.  We certainly can't hamper the 
timely provision of care.

Thanks,
Bill
 

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

Access controls and Audit trails (was Re: openEHR security)

[Bill Walton]

Hi Sam,

Sam Heard wrote:

> > BW: First, and perhaps you consider this a seperate issue that's out of 
> > scope for Access Control, but what about Audit Trails? 
 
> SH: openEHR has full version control of all components so we have this 
> thoroughly covered. If you are talking about auditing what is viewed, our 
> research in the early 90s suggested that clinicians were totally against this 
> - and it is very difficult to be sure what is seen unless refresh times, 
> screen size and scrolling are all monitored - the idea is terrifying!

I'm talking here about logging system activity at run-time, not version 
control.  Also, I note that there seems to be concern about the phrase Audit 
Trails.  I agree that it's way out of scope to try to log exactly what's seen.  
What's accessed (at the file or field level) is another question.  I'll have 
more to say about this in another email in response to / support of Thomas 
Clark's comments.
 
> > BW: In addition to the choices / decisions you summarize on Page 3, I 
> > believe there's a key question the system needs to be able to answer: "Who 
> > has had what access to my records?" 
 
> SH: We do believe that it is essential to log access - but not to what unless 
> there is an over-ride on the constraints set by the patient. This could 
> result in an automatic email to the patient in the future. But not policing 
> what the clinician who has access looks at.

Hmmm  I'm guessing this may be a difference at the national level in how 
the medical delivery systems work.  I'll have more to say about this in the 
email response anticipated by the above, but here are some of the new 
requirements we having to come to grips with here in the U.S  Under HIPAA, 
the patient has the right to request an accounting of disclosures and the 
physician must furnish that accounting.  Moreover, HIPAA requires that 
disclosures of protected health information, even to others within the 
physician's office, be kept to the minimum needed by the requestor to fulfill 
their job duties.  In addition, the patient has a right to request that 
specific information be kept confidential.  Along with the Privacy and Security 
standards, HIPAA contains enforcement provisions and the commentary has been 
very explicit that sanctions are an essential component of any security scheme. 
 It appears to me that, here in the U.S., we have to anticipate maintaining a 
log of accesses to allow a reviewer to determine whether or not HIPAA's 
requirements have been adhered to.
 
> > BW:  To answer this question it looks to me like the system needs to 
> > maintain two types of information: 1) a history of the changes to the 
> > Access Control List,  
 
> SH: In openEHR this is versioned like anything else...

Excellent.  So past Access Control Lists are kept and could be reused?  This 
will become important for us (in the U.S.) because the fact that a physician 
had access to a patient's full medical history in the past does not mean they 
continue to have that level of access.
 
> > BW:  and 2) a history of accesses to the EHR itself. 
 
> SH: I agree as long as we are talking access - that is logged - and 
> over-rides and who authorised them and for what reason ( perhaps unconscious 
> in Emergency is appropriate. Patients could set the over-ride capability to 
> be turned off.

More on this in other emails, but I think there's more to it than over-rides.
 
> > BW:  Further, it looks like the EHR access history should include reads as 
> > well as writes.  That way, the trail would lead to the providers that have, 
> > with permission, made copies of the EHR within their own systems. 
 
> SH: True - it will only be able to be stored as an HTML rendition unless 
> there is an extract in openEHR - but you are right - this could be saved - 
> this is difficult to police. 

Oops!  I'd assumed there would be extracts in openEHR.  HIPAA specifies, under 
the Transaction Rules that go into effect in October of this year, a number of 
EDI transactions between systems that would require this.  HTML will not be 
sufficient.

> > BW:  This is tied to the first question I think, but how does the system 
> > deal with the needs of Consulting Physicians and Researchers who are not 
> > going to provide care, but may need read access to the full record?  If I 
> > read this correctly, the mechanism controls what information can be 
> > accessed, but not the type of access permitted (i.e., read vs. write). 
 
> SH: The fact is, unlike usual systems, there will be  more restraints on 
> reads than writes. 

I'm taking this to mean that there will be configurable permissions on type of 
access.  Yes?

> SH: Research access will be via the kernel with an approved program unless it 
> is one-to-one reading of records when the patient's consent is required 
> anyway.

Hmmm  Again, perhaps a difference at the national level.  Research here is 
the U.S. typically requires extracted data to be transferred f

openEHR security

[Bill Walton]

Bernd Blobel wrote:

> Dear Bill, dear Sam
>
> Meanwhile, security constraint modelling succeeds. This concerns policy
> modelling, policy negotiation, privilege management, access control,
> object security categorisation. Unfortunately, the preparation of EU 6th
> Framework proposals was so time comsuming that I had no time to continue
> and to distribute the results. The modelling is also part of the EU
> modEHRa proposal OIA (Thomas and Sam) will be involved in.

Bernd,

I'd not previously studied security constraint modeling but a quick Google
put me onto some interesting research.  If you have any links to share, I'd
appreciate it.  Thanks for the new (to me) tack.

Best regards,
Bill

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

openEHR security

[Bill Walton]

Sam,

Thanks much for sending that along.  I haven't made my way through all the 
examples yet, but I like where you're going.  A few questions / comments if you 
don't mind.

First, and perhaps you consider this a seperate issue that's out of scope for 
Access Control, but what about Audit Trails?  In addition to the choices / 
decisions you summarize on Page 3, I believe there's a key question the system 
needs to be able to answer: "Who has had what access to my records?"   To 
answer this question it looks to me like the system needs to maintain two types 
of information: 1) a history of the changes to the Access Control List, and 2) 
a history of accesses to the EHR itself.  Further, it looks like the EHR access 
history should include reads as well as writes.  That way, the trail would lead 
to the providers that have, with permission, made copies of the EHR within 
their own systems.

This is tied to the first question I think, but how does the system deal with 
the needs of Consulting Physicians and Researchers who are not going to provide 
care, but may need read access to the full record?  If I read this correctly, 
the mechanism controls what information can be accessed, but not the type of 
access permitted (i.e., read vs. write).

How do Emergency medicine providers get access to the records?  It looks like 
there needs to be an override to allow the timely delivery of service in 
Emergency situations.  It would seem to me that the existence of the Audit 
Trails above might calm fears of inappropriate access.

Related to all of the above, it seems like there are probably a number of 
circumstances that would require that the control of the Access Control list 
itself be capable of being over-ridden or delegated.  It looks to me like, as 
currently defined, the only roles that could grant access would be the patient 
and Next of Kin roles.  But assume, for example, that a patient is 
hospitalized, needs a test performed that can't be performed in the facility, 
and has designated a Next of Kin that's not present.  Perhaps it's just a 
difference between our systems, but in the U.S. I can imagine a need to 
delegate the right to change the Access Control list without delegating some of 
the other decisions (e.g., "pull the plug") that are associated with Next of 
Kin here.  Again, as long as the Audit Trails are in place it seems that fears 
of inappropriate access might be effectively balanced against the needs of 
providers re: access to the records for the purpose of delivering the 
appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.

What's an EPR, what's in it, and what, if any, information overlap does it have 
with an associated EHR?  You introduce EPR in the first example, but there's no 
definition provided and no reference to an external source.

This is a really interesting problem space to me.  I've been studying HIPAA 
(the Health care Information Portability and Accountability Act) and have 
become 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 
  To: Bill Walton ; 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 fi

VistA knowledge / comments

[Bill Walton]

> -Original Message-
> From: Bill Walton
> To: openehr-technical at openehr.org
> Sent: 4/23/2003 6:00 PM
> Subject: VistA knowledge / comments
>
> Is anyone here familiar enough with the open source VistA system here in
> the U.S. to offer any comments about it in general and specifically
> about it's storage subsystem?  There's info on VistA at
> http://www.va.gov/vista_monograph/ <http://www.va.gov/vista_monograph/>


Todd Smith wrote:
> Hello Bill,
>
> You would be better off going to http://www.hardhats.org and subscribing
to
> the hardhats mailing list.  That is where the real VistA experts are.
>

Tim Cook wrote:
> You may want to start (open source wise anyway) with a study of GT.M
> from Sanchez http://www.sanchez-gtm.com/
>
> The next layer up is the Fileman modules:
> http://www.hardhats.org/fileman/FMmain.html
>

Hi Todd, Tim;

Thanks for your replies.  I joined the Hardhats list about three weeks ago
and have been lurking there to get a feel for what's going on,
development-wise, with VistA at this point.  I've also checked out the
Fileman docs although I haven't dug into the implementation details.

I apologize for not stating my question more directly.  Basically, it's
this.  Given that VistA exists as an open source system with an architecture
that includes a logically seperate storage subsystem with a database API
that looks, at first glance, like it could be pretty easily implemented as
an independent service, what drives this group to develop the openEHR server
rather than simply seperate and potentially extend Fileman?

If you'll permit me to make an uninformed guess, it looks to me (again, with
open admission that I haven't researched VistA sufficiently) like there are
at least a couple of motivations.  First, openEHR seems to implement a
higher level of abstraction than Fileman, moving more of the knowledge of
content and structure (and access rights if what Sam's forwarded me gets
implemented) of an EHR to the server and out of the application.  Second, as
a result of that, openEHR seems to allow more decoupling and simplification
of the application than Fileman by allowing an application to query the
server about the existence of content rather than requiring the application
to try to access content and then deal with the case where the access fails.

Am I anywhere close?

Thanks in advance for your help.

Best regards,
Bill

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

openEHR security

[Bill Walton]

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
-- next part --
An HTML attachment was scrubbed...
URL: 

VistA knowledge / comments

[Bill Walton]

Is anyone here familiar enough with the open source VistA system here in the 
U.S. to offer any comments about it in general and specifically about it's 
storage subsystem?  There's info on VistA at http://www.va.gov/vista_monograph/

Thanks,
Bill
-- next part --
An HTML attachment was scrubbed...
URL: 

Another introduction and more questions : 'Divide and conquer'

[Bill Walton]

Count me in.  I'll look forward to hearing more when you're ready.

Best regards,
Bill

- Original Message -
From: "Thomas Beale" 
To: "Denis Petrushin" 
Cc: "Bill Walton" ; 
Sent: Saturday, March 29, 2003 12:52 AM
Subject: Re: Another introduction and more questions : 'Divide and conquer'


>
> Ok, this is great - we have two kind professionals with experience with
> change management. I will be very happy for you to review a basic draft
> for change management in openEHR, and work on it together. The timetable
> is about 6-8 weeks. Inside the current 3-4 weeks we hope to have a basic
> set of plans written for comment. THese will be pretty loose, with the
> intention that people such as yourselves can make changes.
>
> I think the aims for change control in openEHR need to:
>
> - be simple and clear. In "heavy weight" software engineering there are
> a lot of quite complex documents describing CM, SQA, test plans etc etc
> (e.g. like the IEEE stds) ; this is fine for software engineers, but we
> don't want to overwhelm the many people in the community who are not
> engineers
>
> - there will be a set of plans relating to the official specifications -
> this is what we are developing here. It needs to be recognised that that
> change management, release plans for any outside given project based on
> openEHR will usually be outside these plans - e.g. it may be done by a
> group on sourceforge, using completely different guidelines. I think
> this is fine. We just have to be clear on what is official openEHR IP
> and what is not. (Anything can become openEHR IP by donation. The
> consequence is that the work gets taken care of, even if the donor
> doesn't have the resoruces to do anything further with it, and it will
> be guaranteed to be freely available forever, according to the openEHR
> open source licence. I'm not sure of the official rules, but there will
> be some published).
>
> - we do need to be fairly careful with how we identify releases and
> sub-releases, particularly so that any new change is put into the
> correct release, and also so that any outside project can get a clean
> baseline for any release and know that it is based on "openEHR v1.3" or
> whatever. I'm sure Denis and Bill will have good ideas here, by the
> sound of their experience.
>
> Anyway, we are aiming to have something in place inside the next 8 weeks.
>
> - thomas beale
>
> Denis Petrushin wrote:
>
> >Greetings,
> >
> >Could somebody kindly provide a sample or link to what is done already
for
> >the OpenEHR.
> >
> >>From my side I'd like to apply my experience in developing of change
> >request/ trouble report handling system that is implemented at Ericsson.
> >
> >Trusting the above to your entire satisfaction, would you accept my
> >distinguished wishes. =)
> >
> >Denis
> >
> >
> >
>
>
>

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

openEHR roadmap

[Bill Walton]

Thomas Beale wrote:
>
> It occurred to me after the recent exchanges that there may be some
> people out there who do not realise something basic about openEHR, which
> is that it is working at two levels. The first level is "abstract
> specifications" - i.e. the technology- and platform-independent
> specifications mentioned by  Dave and Tom C. earlier.

/snip/

> Anything to do with expressions in certain languages like XML, C++, Java
> or whatever, are all in the second level - "Implementation Technology
> Specifications" - ITSs (this is the term HL7 uses for the same purpose
> by the way, and in the interests of reducing jargon, we use it too). So
> - any actual system or data model is an ITS, not a abstract specification.

 /big snip/

Another thing, perhaps even more fundamental, that wasn't clear to me is
that the openEHR software is an EHR server, not the client applications that
will access it.  Many thanks to Sam H. for making that clear to me.

Bill

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

Another introduction and more questions

[Bill Walton]

Clearly true, but not clear ;-)
  - Original Message - 
  From: HOPTIMIS at aol.com 
  To: bill.walton at jstats.com ; thomas at deepthought.com.au ; 
openehr-technical at openehr.org 
  Sent: Monday, March 24, 2003 10:50 AM
  Subject: Re: Another introduction and more questions


  It is nice to have dreams... 
-- next part --
An HTML attachment was scrubbed...
URL: 

Another introduction and more questions

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:
>
> Bill Walton wrote:
>
/snip/
> >
> >1) Is it your intention that openEHR eventually become a viable
alternative
> >to commercial offerings, or is openEHR intended as an academic / research
> >tool?
> >
> well, I can say two things:
> a) the core people currently involved in developing the specifications
> intend to try to change clinical computing - everywhere.
> b) as more people become more active in openEHR, they will bring their
> interests to the table. Most of the ones I know of are interested in
> changing clinical outcomes in the real world.
> c) academia and research contexts are of course important, and are where
> a lot of innovation comes from. So we should not discount these. But the
> real aim is to change things (rather than just talking about it, to
> paraphrase Marx;-)

That's three things ;-)  Seriously though, it sounds like we're on the same
page.  Getting the system into day-to-day use in clinical settings is the
objective.  Yes?

>
> >2) Does the openEHR Foundation exist yet or is it still under formation?
> >
> It does exist as a legal non-profit organisation, but as an
> international foundation, incorporated in the UK. The "openEHR" name and
> other special marks (e.g. "conforms to openEHR vX.X" etc) are also
> protected, ensuring that they are used for truly conformant systems and
> applications.

Excellent.

> >3) I may simply not have discovered it yet, but I expected to find a
place
> >on your site where developers were engaged in conversation about the
> >components of the system they were developing.  Could you share a little
> >about your operating model, particularly with respect to new developers
> >interested in contributing?
> >
> A number of developments are coming online. There is work being done in
> C#, Java, Eiffel and XML-schema that I know of. Some of this will become
> visible on the website in the next month or two.

I assume this work is being done by some of the founding members and that
they're communicating back-channel.  Yes?

> It is still early days, so how implementation work and collaboration pans
> out is not entirely forseeable.

Understandable.

> However, it is planned to get more people involved to give
> of their expertise on collaborative software development, developing
> test cases, conformance criteria and so on.

I managed a test automation group from '95-'00.  As a consultant /
contractor, I'm typically engaged as a Project Manager with a technical
focus in requirements definition and testing.  I'll look forward to the
opportunity to contribute once you've got the mechanisms defined.

> The main effort to this
> point has been to get a set of specificatinos good enough to start work
> on. It is believed that the current ones are, and a baseline will appear
> soon.

Saw your earlier note on timeframes and was encouraged.

> Mechanisms for submitting change requests etc will also appear
> soon, but of course, none of this work is instant!

Let me know if I can be of assistance.  Process definition is a substantial
component of what I do.

Best regards,
Bill

>
> - thomas beale
>
>
> -
> 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

Another introduction and more questions

[Bill Walton]

Greetings,

I'm an IT consultant / contractor in the U.S. and am currently engaged with
a group of seven of neurology practices in the evaluation of EMR/EHR
systems.  We have reduced the field of vendors under consideration to three
and intend to make a selection from that set within the next couple of
months.  We have recently begun evaluating the prospect that a viable open
source system will become available within a relatively short (i.e., < 24
months) period of time.  If this were the case, the acquisition could be put
on hold.  A couple of questions...

1) Is it your intention that openEHR eventually become a viable alternative
to commercial offerings, or is openEHR intended as an academic / research
tool?

2) Does the openEHR Foundation exist yet or is it still under formation?

3) I may simply not have discovered it yet, but I expected to find a place
on your site where developers were engaged in conversation about the
components of the system they were developing.  Could you share a little
about your operating model, particularly with respect to new developers
interested in contributing?

Thanks in advance for your assistance in understanding more about the
openEHR initiative.

Best regards,
Bill Walton
http://www.jstats.com

- Original Message -
From: "Thomas Beale" 
To: "Vincenzo Della Mea" 
Cc: 
Sent: Friday, March 21, 2003 11:47 PM
Subject: Re: Introducing myself + question


>
>
> Vincenzo Della Mea wrote:
>
> > Dear list members,
> >
> > my name is Vincenzo Della Mea, I'm researcher (Medical Informatics)
> > at  the University of Udine, Italy, with interests until now directed
> > to  telemedicine.
> >
> > I'm investigating now how to use OpenEHR as a teaching aid for a
> > Medical Informatics course: as a model, I think is very well
> > developed  and educational for what regards the correct implementation
> > of EHRs.
> > So, my question is: I read on the web site that there will be some
> > Java  implementation available sooner or later. Do you now, at least
> > in  principle, when?
>
> there are a couple of Java implementations underway.
>
> The timetable for openEHR is roughly as follows:
>
> - stable release "0.9" by end April (validated by formal tools); will
> include specifications and XML schemas.
> - The validation is done by Eiffel tools, and an Eiffel expression of
> the specification will also be available around this time
> - initial C# and Java implementations will probably start being released
> around this time, e..g for datatypes, demographics and so on.
>
> - thomas beale
>
> -
> 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