# Distributed Records - An approach

**URL:** <https://discourse.openehr.org/t/distributed-records-an-approach/15753>\
**Category:** Technical (archive)\
**Created:** [5 August 2003 15:28 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753 "2003-08-05T15:28:30Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Christopher\_Feahr](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/f04885/32.png) [@Christopher\_Feahr](https://discourse.openehr.org/u/Christopher_Feahr)\
**Post date:** [5 August 2003 15:28 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/1 "2003-08-05T15:28:30Z")

</div>

Thomas,  
This sounds workable to me. If I am understanding you correctly, we  
need one (and only one??) registry in which anyone, anywhere (who is  
authorized, of course) could look up a patient and determine which  
"region" had master control at the moment over his record. If I'm a  
provider living in the region where the records are primarily managed,  
then when my system attempted to look up, say, the date of his last  
Tetanus vaccination, it would find it immediately. If I was a provider  
visited while the patient was traveling outside his "home" region, then  
the same local query about his tetanus shot would tell me: "hold on a  
minute, while we search all known registries to see where this guy's  
home-region is... where his most current records will be located". ...  
and then my region does a full record update from the current home  
region? or just try to display his tetanus vaccination history?

One of the problems alluded to is that different regions might be using  
very different EHR structures. Thus a simple "record refresh" in region  
B from the information stored in Region A is not so simple. It would  
involve mappings at least, and possibly even data transformation. The  
inability to assume an overarching authority seems to be the Achilles  
heel. After a dozen record "movements" from one region to the next,  
many little mapping and transformation errors may have accumulated to  
thoroughly hose up the medical information in the patient's "master"  
record.

One way around the central record managing authority would be to have  
VERY FEW regions... each with a well organized regional authority... who  
come together under a global organization and work out a very tight  
choreography for these refresh/hand-off operations. But this sounds  
harder and no more likely to be created as one single authority such as  
the UN imposing the requirements on all regions.

I believe that the most critical point for global standardization and  
what we must aim for (first) is the information in the record. When the  
world has settled into that (something that will ALSO require a central  
authority, but just for standardizing what the information elements  
mean, not for choreographing complex record-merge operations), people  
will gradually come around to the idea of moving to the next level of  
system interoperability, with standard record structures.

With only the information standardized globally, two large and  
cooperative regions (say, US and Australia) could still choose to create  
a US-Aus. information authority and orchestrate a high level of  
interoperability for patients and providers floating anywhere within our  
two countries. If the "functional regions" initially were more along  
the sizes of counties and states, then we'd have a lot more hassle and  
negotiating. So I would suggest the world start with the largest sized  
regions that could be reasonably managed with the same EHR structure.

The critical issue for all regional participants would be a strong,  
competent regional authority... that operated in conformance to a set of  
well defined "regional authority rules"... maintained by the UN??

Christopher J. Feahr, O.D.  
Optiserv Consulting (Vision Industry)  
Office: (707) 579-4984  
Cell: (707) 529-2268  
[http://Optiserv.com](http://Optiserv.com)  
[http://VisionDataStandard.org](http://VisionDataStandard.org)

---

<div class="post-metadata">

**Author:** ![Norbert\_Lipszyc](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/n/b782af/32.png) [@Norbert\_Lipszyc](https://discourse.openehr.org/u/Norbert_Lipszyc)\
**Post date:** [6 August 2003 08:23 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/2 "2003-08-06T08:23:43Z")

</div>

The remarks of Christopher Feahr are very adequate, but they overlook the  
fact that in many areas, patients will have the decision as to where they  
want their records to be kept (trusted third parties for example, as in the  
case of electronic signatures). therefore his conclusions are even more  
appropriate as they allow this freedom which is essential in many countries,  
France in particular.  
Norbert Lipszyc  
----- Message d'origine -----

---

<div class="post-metadata">

**Author:** ![Thomas\_Clark](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@Thomas\_Clark](https://discourse.openehr.org/u/Thomas_Clark)\
**Post date:** [7 August 2003 17:54 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/3 "2003-08-07T17:54:50Z")

</div>

Hi Chris,

Unfortunately the uncertainty in the HIPAA environment at this time is  
sufficient to cause large Providers, e.g., Kaiser Permanente, to move  
records  
based operations offshore, i.e., to India. I am uncertain as to their  
reasoning  
but it may well be a situation where the records will reside beyond the  
jurisdiction of US courts.

The Provider may then have only the transitory records to contend with.  
I haven't seen a paper on this concept but I can bet that KP has already  
been  
down this trail. On this one only a qualified attorney can hazard a guess.

The following is certain, however, (1)the security features designed into  
OpenEHR  
records are of MAJOR importance and (2)where the records reside may  
ultimately affect the 'choice of laws' applied.

As OpenEHR proceeds it is likely to encounter may more of these legal  
issues and, even after deployment, may have to adapt to changing legal  
requirements. My hope is that one day we will see international law  
covering such topics, e.g., security and privacy of healthcare records  
transmitted and stored internationally.

APPROACH: Make it the 'best' you know how and maybe people and  
governments will buy into it. My suspicion is that the gov has documented  
HIPAA  
as well as it can and is letting the healthcare community tell it what it  
said.

-Thomas Clark

---

<div class="post-metadata">

**Author:** ![Christopher\_Feahr](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/f04885/32.png) [@Christopher\_Feahr](https://discourse.openehr.org/u/Christopher_Feahr)\
**Post date:** [7 August 2003 19:33 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/4 "2003-08-07T19:33:47Z")

</div>

Thomas,  
You have described the situation succinctly with your statement: "My  
suspicion is that the gov has documented HIPAA as well as it can and is  
letting the healthcare community tell it what it said."

I sense that our security experts are fairly happy with the HIPAA  
Security Rule... that it goes far enough, but does not stifle  
development or unreasonably increase costs... that it is essentially a  
codification of what most would consider "best practice". Same for  
HIPAA Privacy, really. We are hearing some consumer groups (the  
paranoid fringe) arguing for even more restrictive privacy policy than  
HIPAA... but I can tell you that my patients are more inclined to regard  
the whole thing as gross overkill and a waste of doctor's time. I would  
not quite agree with the latter because a good deal of the "security and  
privacy" that patients presently enjoy is afforded by their health  
information being scribbled into paper records and trapped in the  
doctor's back room. That DOES keep the information safe from prying  
eyes... of even the people who need to see it!

The rule that needs to be changed and is causing all the grief at the  
moment is the transaction rule. If our goal is to force lower  
operational cost with a regulation then, in my opinion, the regulation  
only need to FORCE representation of provider needs at the SDO level.  
Then common sense and the requirement that SDOs abide by a consensus  
process, should result in a standard that doctors can live with.  
Representing the diverse requirements of all care domains at the SDO  
level, however, will require a substantially different labor/funding  
model for the SDO, and some heavy-duty automation/tools to handle the  
extensive vetting requirements with our dispersed (global) provider  
community. We also need more online collaboration tools and FEWER  
expensive, face-to-face SDO meetings.

Using a govt. regulation to force a specific communication paradigm like  
X12-style EDI is simply the wrong place to apply the regulation. There  
is no "one size fits all" model for EDI. This has induced smaller plans  
and virtually all providers to simply push their EDI connection  
headaches onto the clearinghouse industry. I call it the "dueling  
leaf-blower problem". The CH-industry is glad for all the new business  
this is blowing its way... but I'm not convinced that it knows what it  
will do with all the leaves!

Christopher J. Feahr, O.D.  
Optiserv Consulting (Vision Industry)  
Office: (707) 579-4984  
Cell: (707) 529-2268  
[http://Optiserv.com](http://Optiserv.com)  
[http://VisionDataStandard.org](http://VisionDataStandard.org)

---

<div class="post-metadata">

**Author:** ![Sam](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discourse.openehr.org/u/Sam)\
**Post date:** [7 August 2003 20:06 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/5 "2003-08-07T20:06:36Z")

</div>

Christopher

It has been good to read this thread - but I have to wade in here. In  
designing openEHR I have had a few principles in mind.

1. The technical solution should impose no constraints on social behaviour.  
This means to me that if we want one EHR for each person that is patient  
held or one repository for the entire country the system should work.

2. Linking records is non-existant at the moment and we can move  
incrementally towards an environment where we know where health information  
about an individual resides. Once you start to send EHR data from one site  
to another in openEHR then the links will build automatically. Remember,  
sometimes the patient will not want their information to flow! and while the  
technical view of security checks seems omnipotent, partitioning will always  
be safer.

3. openEHR offers a one to one transform for all information in EHRs. Our  
idea is that openEHR servers will retain the comprehensive information that  
comes from legacy or specific systems. Other systems will develop their read  
and write interfaces with openEHR and that will be all they need (at some  
future date) to operate and interoperate with EHR systems. Could be fantacy  
but it looks sweet - we are moving to a real-time trial of this approach in  
Australia.

Cheers, Sam

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [7 August 2003 20:48 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/6 "2003-08-07T20:48:42Z")

</div>

> Christopher
> 
> It has been good to read this thread - but I have to wade in here. In  
> designing openEHR I have had a few principles in mind.
> 
> 1. The technical solution should impose no constraints on social behaviour.  
> This means to me that if we want one EHR for each person that is patient  
> held or one repository for the entire country the system should work.

This is the only correct approach. Small, limited scope EHRs can always  
be amalgamated later to create larger scope EHRs. However, grand,  
all-encompassing EHR schemes are, at this stage, in most countries,  
bound to flounder on both socio-political and technical rocks. We should  
be worry about crawling across the room competently first, but forearmed  
with the knowledge that in a decade or so we will be running marathons  
(and hence should start out with an approach which can go the distance  
apologies for the mixed metaphors there).

> 2. Linking records is non-existant at the moment and we can move  
> incrementally towards an environment where we know where health information  
> about an individual resides. Once you start to send EHR data from one site  
> to another in openEHR then the links will build automatically. Remember,  
> sometimes the patient will not want their information to flow! and while the  
> technical view of security checks seems omnipotent, partitioning will always  
> be safer.

Every Monday morning, anyone working in this field should re-read the  
BMA criteria for privacy of patient data, as drawn up by Ross Anderson  
in the mid 1990s - see  
[http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html](http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html)

A few moments reflection on these principles reveals that there are many  
very complex problems for which definitive or even satisfactory  
solutions don't yet exist - for example, if a patient consents to access  
to their EHR by clinician A, under what circumstance can that consent be  
extended to other clinicians, and is the extension of consent  
transitive, and/or commutative? This extends to knowledge that an EHR  
record for a patient exists (or even that the patient exists), not just  
to the contents of that EHR. Very tricky stuff indeed, which is usually  
swept under the carpet in an intra-institutional setting, and  
increasingly in vertically integrated healthcare organisations - but  
organisation won't be able to do that forever, and these issues  
certainly can't be ignored for community-wide EHRs. It will take many,  
many years, and many many (probably failed) attempts before  
well-accepted solutions to these problems are available. In the  
meantime, start small...

> 3. openEHR offers a one to one transform for all information in EHRs. Our  
> idea is that openEHR servers will retain the comprehensive information that  
> comes from legacy or specific systems. Other systems will develop their read  
> and write interfaces with openEHR and that will be all they need (at some  
> future date) to operate and interoperate with EHR systems. Could be fantacy  
> but it looks sweet - we are moving to a real-time trial of this approach in  
> Australia.

Which means that release of a production-quality open source openEHR  
kernel is approximately how many years away, more or less?

Tim C

---

<div class="post-metadata">

**Author:** ![Denis\_Nosworthy](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/d/ba9def/32.png) [@Denis\_Nosworthy](https://discourse.openehr.org/u/Denis_Nosworthy)\
**Post date:** [7 August 2003 23:05 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/7 "2003-08-07T23:05:41Z")

</div>

I have been reading these threads with interest over the last few days and I  
think the majority of the comments are extermely value and add to the  
debate. The focus is obviously on the structure and some of the mechanics of  
the process but let me throw something else into the melting pot that is an  
issue which does not seem to have received much airplay in the recent past  
anyway.

It is the issue of identification and matching of clients.

Far be it from me to raise the Australia Card issue again but the EHR ain't  
(excuse my English) going to work unless the industry can crack this nut in  
such a way that it is universally accepted by most Australians.

Research that we have done over the past couple of years has indicated  
clearly that the majority of people we have surveyed (upwards of 3000 as  
part of another project) appear to have little concern about using an EHR  
however enacting the implementation of an "Australia Card' is another issue  
altogether.

I would be interested in the comments from those who have been close to the  
action about what their own views are and what they perceive the client view  
to be.

Regards,

Denis Nosworthy.  
CIO, South Western Sydney Area Health Service

---

<div class="post-metadata">

**Author:** ![Christopher\_Feahr](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/f04885/32.png) [@Christopher\_Feahr](https://discourse.openehr.org/u/Christopher_Feahr)\
**Post date:** [8 August 2003 00:37 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/8 "2003-08-08T00:37:03Z")

</div>

I'm not familiar with the "Australia Card", but I agree that unique,  
global identifiers are required for patients. Americans, however are  
very resistant to the idea of being uniquely identified in almost any  
context. There is a deeply ingrained belief that there is safety in  
anonymity and some sort of inherent danger in absolute identity. I  
think the basis for the global fear is that the theoretical computer  
security will fail... or could fail. Of course, the benefits to them of  
a unique ID far outweigh the almost non-existent dangers... but it's a  
very tough sell in the US. A paper describing some of the reasons for  
scrapping the US plan for a National Patient Identifier a couple years  
ago, can be seen at:  
[http://visiondatastandard.org/HIPAA/Unique%20Health%20Identifier%20for%20Individuals.htm](http://visiondatastandard.org/HIPAA/Unique%20Health%20Identifier%20for%20Individuals.htm) .  
Perhaps there are some helpful lessons in it. (not sure who the author  
was... must have wanted to remain anonymous!)

Christopher J. Feahr, O.D.  
Optiserv Consulting (Vision Industry)  
Office: (707) 579-4984  
Cell: (707) 529-2268  
[http://Optiserv.com](http://Optiserv.com)  
[http://VisionDataStandard.org](http://VisionDataStandard.org)

---

<div class="post-metadata">

**Author:** ![Bhupinder\_Singh](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/6f9a4e/32.png) [@Bhupinder\_Singh](https://discourse.openehr.org/u/Bhupinder_Singh)\
**Post date:** [8 August 2003 03:12 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/9 "2003-08-08T03:12:15Z")

</div>

I have been following the issues with interest. There is an area on which I  
would like to have the views of all who have had to handle the electronic  
management Of the History.

The concept of modelling the symptoms in a genric manner manner and have  
these called up whenever there is a need to record the details.  
How is possible to capture the the chief complaints and the details relating  
to the same in a manner that the information is available for datamining and  
analysis at a later point of time. I would like to have the thaughts of all  
as to can we not model the symptoms in a manner so as to make it a global  
element and then have the question set called up for recording the  
information pertaining to that element(Symptoms).

An argument that may be advanced is that the symptoms can not be managed in  
a preprared template. I do believe that the present manner of capture of  
history in the Free text form is not adequate and cannot be effectively  
manipulated. If the symptoms are modelled they will be able to give the  
clinicians a protocol that may allow the capture of the symptoms in an  
appropriate manner to enable the clinicians to capture the information  
relating to each symptoms.

The thaughts of all are welcome as to how the issue of capture of the  
details relating to Symptoms in the history data set need to be addressed.

Dr B S Grewal  
Domain Expert  
PGIMER

---

<div class="post-metadata">

**Author:** ![Norbert\_Lipszyc](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/n/b782af/32.png) [@Norbert\_Lipszyc](https://discourse.openehr.org/u/Norbert_Lipszyc)\
**Post date:** [8 August 2003 07:05 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/10 "2003-08-08T07:05:35Z")

</div>

Dear all,

The update of Sam Heard is most important and I totally agree with him.  
The added advantage of openEHR is that it will help structure EHR systems to  
facilitate exchanges. As governments and health insurance authorities  
(whether public or private) are pushing towards interopearability existing  
systems will have to evolve and the openEHR will make it easier and safer to  
evolve.  
Norbert Lipszyc  
----- Message d'origine -----

---

<div class="post-metadata">

**Author:** ![Norbert\_Lipszyc](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/n/b782af/32.png) [@Norbert\_Lipszyc](https://discourse.openehr.org/u/Norbert_Lipszyc)\
**Post date:** [8 August 2003 07:22 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/11 "2003-08-08T07:22:43Z")

</div>

Identification, and authentication, has the been the subject of many  
EUropean projects recently, mostly based on the use of smart cards. As one  
example I can cite Smart-IS AM (an IST project of the European COmmission)  
which has defined a "common smart-card module for authentication" and  
another one for electronic signature. Therefore the technical ways of  
solving this problem exist. The problem is social. In those countries where  
a national identity card exist, there is acceptance for a unique  
identification for health records also. In the others, such as the UK, there  
is a lot of resistance and this will be solved only wen patients actually  
see the advantage for their health to have a unique identification. Once  
again, this will come only slowly. There was one tragic example of the need  
for a positive unique authentication tool in France where in a public  
hospital came two women with the same, identical demographics (names, birth  
date and place town of residence). One came for a normal check on her  
pregnancy, the other for abortion and ablation of ovaries due to a medical  
condition, and the hospital made the mistake. This only points to the need,  
not the aceptance of a positive authentication tool for people, but such  
examples can emphasize to the public the reason for the need, mostly if the  
identificaiton is different for health systems and other types of needs.  
In short the technical tools are now available through the results of  
several European projects.  
Norbert Lipszyc

----- Message d'origine -----

---

<div class="post-metadata">

**Author:** ![lakewood](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@lakewood](https://discourse.openehr.org/u/lakewood)\
**Post date:** [8 August 2003 14:07 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/12 "2003-08-08T14:07:52Z")

</div>

Hi Norbert,

Excellent example! It is easy to imagine that a poll taken in the US would  
show that a majority of the public would believe this could not happen.

-Thomas Clark

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 August 2003 01:17 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/13 "2003-08-09T01:17:18Z")

</div>

Christopher Feahr wrote:

> Thomas,  
> You have described the situation succinctly with your statement: "My  
> suspicion is that the gov has documented HIPAA as well as it can and is  
> letting the healthcare community tell it what it said."
> 
> I sense that our security experts are fairly happy with the HIPAA  
> Security Rule... that it goes far enough, but does not stifle  
> development or unreasonably increase costs... that it is essentially a  
> codification of what most would consider "best practice". Same for  
> HIPAA Privacy, really. We are hearing some consumer groups (the  
> paranoid fringe) arguing for even more restrictive privacy policy than  
> HIPAA... but I can tell you that my patients are more inclined to regard  
> the whole thing as gross overkill and a waste of doctor's time. I would  
> not quite agree with the latter because a good deal of the "security and  
> privacy" that patients presently enjoy is afforded by their health  
> information being scribbled into paper records and trapped in the  
> doctor's back room. That DOES keep the information safe from prying  
> eyes... of even the people who need to see it!

we should always keep in mind this point, as a benchmark of privacy management of elecrnic patient information - from the patient's point of view, if they see their information escaping more easily than it does now (due to beig stuck in folders in the back room) then we are in trouble.

> The rule that needs to be changed and is causing all the grief at the  
> moment is the transaction rule. If our goal is to force lower  
> operational cost with a regulation then, in my opinion, the regulation  
> only need to FORCE representation of provider needs at the SDO level.  
> Then common sense and the requirement that SDOs abide by a consensus  
> process, should result in a standard that doctors can live with.

but the world does not work that way unfortunately - regulators can only regulate actual things - delivered systems.

> Representing the diverse requirements of all care domains at the SDO  
> level, however, will require a substantially different labor/funding  
> model for the SDO, and some heavy-duty automation/tools to handle the  
> extensive vetting requirements with our dispersed (global) provider  
> community. We also need more online collaboration tools and FEWER  
> expensive, face-to-face SDO meetings.

I have argued before that the current paradigm of standards development (of technical / information standards) is broken at the core anyway. Here's why:

- the SDOs in IT/technical areas are in the business of producing technical specifications - what software engineers would call "requirements", "analysis models", and other such things.

- however, these things are not developed by any recognised software engineering methodology, and often without any discipline whatsoever. Instead they are developed by ad hoc argumentation in conference rooms, by whoever happens to turn up, with whatever skills (often many skills, but few relevant ones). Sometimes whoever shouts the loudest wins.

- the current results of many technical standards definition efforts are often arbitrary, contain bad modelling, and do not have proper statements of the problem or rigourously developed technical artifacts.

- the problem does not stop there. As people in software development know, the best to test a design is o try to build it. Modern developers understand the idea of "living documenation" - the docuemntation is never finished, and is always under modification due to feedback from implementation and actual use. That's why systems get rebuilt 2 or 3 times before they are really good. This doesn't happen with standards. They are published as static documents, and the available feedback processes are so slow as to be nearly useless. Many standards processes continue as talk/documentation fests for years before anyone seriously tries to validate the models or designs. Professor David Ingram (UCL, the inventor of the term "openEHR") has a mantra: "implementation, implementation, implementation". He says this not because he is obsessed with programming but because of the crucial value of feedback processes in validating and improving specifications.

- conclusion: any standards development process that is not a "live" process with impleemntation and use and feedback loops, is not worthwhile.

OpenEHR is far from perfect, but it is (trying to be) one thing: a process, not a thing. The process is more akin to a software engineering process, conducted in the open, rather than a staandards development process. So in response to the above, some face to face meetings are good, but they need to occur as design workshops, with competent modellers and specifiers, and there needs to be implementation testing of the results.

> Using a govt. regulation to force a specific communication paradigm like  
> X12-style EDI is simply the wrong place to apply the regulation.

I agree - this is like regulating that everyone must communicate with a certain brand of mobile phone.

> There  
> is no "one size fits all" model for EDI. This has induced smaller plans  
> and virtually all providers to simply push their EDI connection  
> headaches onto the clearinghouse industry. I call it the "dueling  
> leaf-blower problem".

that's a beautiful analogy! I'm sure I'm going to have to quote you on this one day....

- thomas beale

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 August 2003 01:23 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/14 "2003-08-09T01:23:18Z")

</div>

Sam Heard wrote:

> Christopher
> 
> 3. openEHR offers a one to one transform for all information in EHRs. Our  
> idea is that openEHR servers will retain the comprehensive information that  
> comes from legacy or specific systems. Other systems will develop their read  
> and write interfaces with openEHR and that will be all they need (at some  
> future date) to operate and interoperate with EHR systems. Could be fantacy  
> but it looks sweet - we are moving to a real-time trial of this approach in  
> Australia.

and it should be mentioned that trials in the UK and Australia show that it works.

- t

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [9 August 2003 01:32 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/15 "2003-08-09T01:32:46Z")

</div>

Christopher Feahr wrote:

> I'm not familiar with the "Australia Card", but I agree that unique,  
> global identifiers are required for patients. Americans, however are  
> very resistant to the idea of being uniquely identified in almost any  
> context. There is a deeply ingrained belief that there is safety in  
> anonymity and some sort of inherent danger in absolute identity. I  
> think the basis for the global fear is that the theoretical computer  
> security will fail... or could fail.

This ingrained belief in Australia I think is due to lack of trust more than anything. Australia was a nation of convicts and rough soldiers once, many of them Irish. What better combination could there be for a deeply held distrust of authority?!

But - the psychology is probably different with the EHR. When we talk "Australia Card" (insert your country name here), what the population sees is a national id card but with no reasons attached - no stated concrete benefit or system. So they see it as the "thin edgeof the wedge". But if the government comes along with a persuasive EHR solution and can show the 20 benefits to consumers, and yes, there will need to be a national identifier \*for this purpose\* then I think people will view it differently. (Note to oppressive governments: don't try to introduce identity cards on their own; make them ride on the back of something else;-)

- thomas beale

---

<div class="post-metadata">

**Author:** ![Christopher\_Feahr](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/c/f04885/32.png) [@Christopher\_Feahr](https://discourse.openehr.org/u/Christopher_Feahr)\
**Post date:** [9 August 2003 07:21 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/16 "2003-08-09T07:21:54Z")

</div>

Thomas,  
This is interesting... I had not given much thought to the importance of  
implementation experience feedback. It never occurred to me to consider  
it \*part\* of standards development process...although, it seems rather  
obvious now that you have pointed it out. My own experience is actually  
quite strange and somewhat unlikely, having been so concentrated on the  
planning aspects of application development for the last 7 years,  
without having ever built a real application! Because of my  
"human-relationship" orientation to the problems that drove me into the  
software world in the first place, I've been almost more focused on the  
fairness and equity issues surrounding standards development than on the  
deployment of an actual application. I thought we just needed a better  
standards develomnent machine.

Here are a few highlights from my strange, 4-year odyssey, in search of  
the Holy Standard...

I gained an excruciatingly detailed understanding of healthcare business  
processes from 20+ years of attempting to practice optometry in  
Information Hell. The driver to finally "learn about application  
development" in late 1996 was the realization that I was probably going  
to have to build the component that was obviously missing... and that  
none of my trading partners apparently had any interest in building for  
me: some kind of internet-based "hub" that would allow any doctor to  
have efficient business connectivity to all desired trading partners and  
point-of-sale access to increasingly complex information about an  
expanding universe of 50,000 eyewear products.

The need to "learn about standards development", however, came 3 years  
later, along with the realization that the uniquely unbalanced,  
competitive dynamics of our corner of the healthcare jungle were NEVER  
going to allow ANYONE'S proprietary, industry-wide communication  
paradigm to even function, let alone resolve a significant part of the  
doctors IT-headaches. The browser-based garbage that was being foisted  
on to doctors in the name of "technology" was actually increasing my  
labor costs, in comparison to handwritten paper forms!

So I abandoned the design work on the 'hub" concept, which by then had  
become a [model of] a full-fledged ASP practice management system on the  
doctor's end. Clearly, a reliable standard was going to be needed to  
give any investor the confidence to fund something this complex... for  
such a small market. It seemed to be either that, however, or the  
entire industry would have to "surrender" to one of the dozen or so  
proprietary models attempting to cash in on dot-com-fever. Or the  
industry would have to agree on a standard.

So in late 1999, I took up my machete and embarked on a mission to find  
the part of the jungle where the standards I needed were being cooked  
up. Buoyed by the Utopian promise of the HIPAA Transaction Rule, I was  
determined to create some kind of acceptable "open standards floor" in  
the vision industry... come hell or high water. The HIPAA rule seemed  
to say that providers had the right to such a standard (for at least the  
insurance part of my headache) and payers were under a federal mandate  
to implement it. Unfortunately, no one in the vision industry had heard  
of HIPAA!

Of course, as soon as I figured out how to read an X12 implementation  
guide, it became obvious that the HIPAA transactions were hopelessly  
"broken" for eyeglass plans... causing me to spend the next 2 years  
getting X12, HL7, the feds, and the vision industry to understand and  
eventually acknowledge that fact. The most intractable HIPAA EDI  
problems for the vision industry are still clustered around terminology  
issues with frame and lens products... that the manufacturers and labs  
had not been able to resolve, despite 19 years of meetings... largely  
because they lacked the technical leadership and arcane knowledge that  
only seemed to exist in the parallel universe of Standards Land.

In early 2001, I finally persuaded our largest payers, the AOA, and a  
few PMS vendors to undertake a series of meetings with HIPAA officials  
to determine what could be done, at least about the eyeglass claim  
problem. (by that time, the greater provider community had pretty much  
given up hope for eligibility queries and payment advice. The looming  
deadline had focused nearly everyone on the "money transaction",  
claims). That's when I became engulfed in the next layer of  
intractable, small provider problems around HIPAA: Routing, addressing,  
and identifier issues. Even if a provider managed to cobble together an  
"837" claim, how was he supposed to get it to the payer?? And how would  
a payer (or anyone) fling anything (like an acknowledgement or error  
message, for example) back to the provider?? Ooops!

After a 6 months of work in the WEDI "routing and identifiers" group, I  
discovered the final nail in the HIPAA-EDI-coffin: apparently, there  
was no standard way to represent the convoluted situational logic in the  
HIPAA imp. guides... in an unambiguous or computer-understandable form!  
Great! By then, the entire HIPAA implementation community had  
unanimously endorsed the Anal Retentive Theory of "HIPAA compliance"...  
meaning that all "required" elements HAD to be populated in EVERY  
transaction. If a data element was marked "situational", and the  
situation was true, then that sucker was REQUIRED! "Accepting and  
processing" a transaction with even one "required" element missing,  
would cause both scofflaw trading partners to be immediately shackled  
and hauled to HIPAA-jail!

The "conformance nightmare" sparked a very heated, summer-long slugfest  
on the WEDI listserves last year and even spawned a whole new non-profit  
organization called HCCO. The core problem was that every  
translator/validator vendor had essentially cooked up his own way of  
coding the IG-logic into his EDI tools... and some had sorta glossed  
over (and occasionally misunderstood) the situational logic, described  
only in plain English in the .PDF versions of the IGs. (The "table  
data" form expresses only the base standard... none of the logic in the  
modified IG that was stipulated in the Rule). In fact, an X12 committee  
started combing through all the HIPAA guides around that time and  
documented hundreds of examples of inconsistent use of the X12 data  
element dictionary terms (because separate committees had worked on each  
transaction and the DED itself, was hopelessly non-normalized). Some of  
the situational requirements were ambiguous and a few were  
self-contradictory!

Bottom line is that by the time the industry had gotten itself to the  
point of EDI testing, no two validator engines could agree whether test  
files were "hipaa compliant" or not. In accordance with the Anal  
Retentive Theory of HIPAA Compliance, however, payers had all programmed  
their inbound claim "edits" to be in absolute conformance to what THEIR  
OWN translator/validator considered to be "HIPAA compliant". That's  
when we started hearing the train whistles in the distance... here is a  
site one of my co-conspirators erected to explain the "HIPAA Train  
Wreck", if you are interested:  
[http://www.aptigroup.com/TrainWreck/index.htm](http://www.aptigroup.com/TrainWreck/index.htm) ... only 10 weeks to go!

The Other HIPAA  
In early May, I published my "dead parrot" letter to the industry,  
suggesting that EDI for 400,000 providers was as bereft of life as John  
Cleese's Norwegian Blue... and that we should declare it so and move on.  
President Bush's ambitious E-Gov initiative includes the Consolidated  
Health Informatics (CHI) initiative that makes the HIPAA Transaction  
Rule look puny by comparison... and HL7 has been clearly designated as  
the lead SDO for CHI. While people still prefer not to talk about  
"starting over" after 8 years of trying to implement the old HIPAA, I  
suspect that HIPAA Second Edition will evolve within HL7... hopefully,  
out of the flurry of federally-inspired activity that began this spring  
around the EHR initiative.

Hope springs eternal!.

With that, I believe it's time to call it a day! Have a great  
weekend... and thanks for reading.

Christopher J. Feahr, O.D.  
Optiserv Consulting (Vision Industry)  
Office: (707) 579-4984  
Cell: (707) 529-2268  
[http://Optiserv.com](http://Optiserv.com)  
[http://VisionDataStandard.org](http://VisionDataStandard.org)

---

<div class="post-metadata">

**Author:** ![Barry\_Barber](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/3ab097/32.png) [@Barry\_Barber](https://discourse.openehr.org/u/Barry_Barber)\
**Post date:** [9 August 2003 14:51 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/17 "2003-08-09T14:51:35Z")

</div>

I am amazed by the concerns that modellers seem to have about the  
implementation of the standard Data Protection requirements. Too often  
these requirements appear to be thought of as "obstructions" to be watered  
down or circumvented rather than as the key to user acceptance in a world  
where one's Personal Health [and other] Data is increasingly plastered all  
over the cyber-globe and accessed quite inappropriately by innumerable  
governmental and private agencies. The privacy of the Open EHR should not  
be worse than the current wreckage of paper systems

I am afraid that I gave up on HIPPA after downloading from a site suggested  
by Charles Safran one Christmas. I subsequently printed 700 pages before  
realising that it was from a 1500 page document......and it took me three  
months before I plucked up the courage to throw away those pages rather than  
print a further 800! However, 95/46/EC should be regarded as the reference  
standard.  
&nbsp;&nbsp;&nbsp;&nbsp;Barry Barber

Health Data Protection Ltd  
Great Malvern

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [9 August 2003 20:59 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/18 "2003-08-09T20:59:36Z")

</div>

> Christopher Feahr wrote:
> 
> \>I'm not familiar with the "Australia Card", but I agree that unique,  
> \>global identifiers are required for patients. Americans, however are  
> \>very resistant to the idea of being uniquely identified in almost any  
> \>context. There is a deeply ingrained belief that there is safety in  
> \>anonymity and some sort of inherent danger in absolute identity. I  
> \>think the basis for the global fear is that the theoretical computer  
> \>security will fail... or could fail.

But that is not an unreasonable fear. Security of computer system is not  
perfect, although improving, but there are still large, unaddressed  
problems - the biggest being the threat from "insiders" - people with  
privileged access to the the system. No-one likes to talk about this,  
because it means having to doubt the integrity of colleagues, or  
oneself. Experience in the national security and intelligence domains  
has shown that rigorous screening and checking do not prevent major  
security breeches by insiders. Thus, attention and effort needs to be  
paid to designing failsafe security - by a number of means: first of  
all, use of trusted systems with mandatory access control, so not even  
teh sysadmin or dbadmin can see what s/he is not supposed to see.  
Possibly storage of data in encrypted form using a lattice of keys  
(still very theoretical, and hard to engineer securely). Almost  
ceratinly using distributed and partitioned storage (on physically and  
administratively distinct computer systems) of the consolidated database  
(the central EHR).

The fundamental problem is that security only improves asymptotically as  
you throw resources at the problem (and hence, the risk of a security  
breech also declines only asymptotically, and never reaches zero),  
whereas the hazard increases at lest linearly, and arguably as a power  
function, as you consolidate the records of more and more people in one  
system.

That is why I think (and this is my personal view) that EHRs should  
start small, at the local or regional level. EHRs at this level have the  
greatest impact - because the majority of the need for shared records  
occurs between local providers, and the socio-political issues are much  
more tractable, particularly when all the providers and a significant  
number of consumer representatives who will be participating can fit in  
a single meeting room to thrash out issues. However, the prevailing view  
is that it is possible to jump straight from some very limited pilots to  
large scale consolifated EHRs containing records of millions of people  
in a single step.

> \>  
> This ingrained belief in Australia I think is due to lack of trust more  
> than anything. Australia was a nation of convicts and rough soldiers  
> once, many of them Irish. What better combination could there be for a  
> deeply held distrust of authority?!

Not to mention the continent of indigenous nations which existed before  
that.

> But - the psychology is probably different with the EHR. When we talk  
> "Australia Card" (insert your country name here), what the population  
> sees is a national id card but with no reasons attached - no stated  
> concrete benefit or system. So they see it as the "thin edgeof the  
> wedge". But if the government comes along with a persuasive EHR solution  
> and can show the 20 benefits to consumers, and yes, there will need to  
> be a national identifier \*for this purpose\* then I think people will  
> view it differently. (Note to oppressive governments: don't try to  
> introduce identity cards on their own; make them ride on the back of  
> something else;-)

Yes, I agree. There are two approaches to making this work: the first is  
national legislation, establishing such a single purpose identitifier  
and making it illegal to use it for any other purpose. The main problem  
with that approach is defining the scope of the permitted purposes.  
Direct patient care? But not billing? But not research? But not health  
services performance monitoring? Clearly much debate is needed on these  
issues, but a reasonable and workable compromise can probably be  
reached.

The second approach is to use a series of surrogate unique identifiers,  
each with a limited scope, but mapped to each other by a central agency  
which operates under tight rules (preferrably legislated). A full albeit  
somewhat discursive description of this approach, written from the point  
of view of disease registers and research databases, but equally  
applicable to EHRs, can be found at  
[http://www.biomedcentral.com/1471-2288/3/1](http://www.biomedcentral.com/1471-2288/3/1)

This latter approach implies the ability to reliably map from common,  
non-unique partial identifiers such as name, date of birth, address etc  
to these surrogate unique identifiers. There is quite a lot of research  
going on around the world on this problems - see for example  
[http://datamining.anu.edu.au/projects/linkage.html](http://datamining.anu.edu.au/projects/linkage.html)

---

<div class="post-metadata">

**Author:** ![Tim\_Churches](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/839c29/32.png) [@Tim\_Churches](https://discourse.openehr.org/u/Tim_Churches)\
**Post date:** [9 August 2003 21:32 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/19 "2003-08-09T21:32:57Z")

</div>

> we should always keep in mind this point, as a benchmark of privacy  
> management of elecrnic patient information - from the patient's point of  
> view, if they see their information escaping more easily than it does  
> now (due to beig stuck in folders in the back room) then we are in trouble.

Another test is asking those who are familiar with the actual, real-life  
vagaries, deficiencies and potential pratfalls of fielded EHR systems to  
pretend that they had some highly confidential medical condition or  
medical history, for which loss of privacy would be devastating, and  
then ask them to say truthfully if they would be prepared to entrust  
that medical record to the EHR system in question, using their real  
identity. Good candidates are senior IT people whose colleagues or  
employees are sysadmins or dbadmins of that EHR, system analysts, and  
security experts. Such a test needs to be carried out with an assurance  
of confidentiality so that participants feel free to fess up that things  
might not be a absolutely foolproof and watertight as everyone likes to  
think. I haven't devised a suitable punishment for those who say 'yes, I  
trust the system enough to have my highly confidential, potentially  
devastating medical history recorded in it under my identity'...

> I have argued before that the current paradigm of standards development  
> (of technical / information standards) is broken at the core anyway.  
> Here's why:
> 
> - the SDOs in IT/technical areas are in the business of producing  
> technical specifications - what software engineers would call  
> "requirements", "analysis models", and other such things.
> 
> - however, these things are not developed by any recognised software  
> engineering methodology, and often without any discipline whatsoever.  
> Instead they are developed by ad hoc argumentation in conference rooms,  
> by whoever happens to turn up, with whatever skills (often many skills,  
> but few relevant ones). Sometimes whoever shouts the loudest wins.
> 
> - the current results of many technical standards definition efforts are  
> often arbitrary, contain bad modelling, and do not have proper  
> statements of the problem or rigourously developed technical artifacts.
> 
> - the problem does not stop there. As people in software development  
> know, the best to test a design is o try to build it. Modern developers  
> understand the idea of "living documenation" - the docuemntation is  
> never finished, and is always under modification due to feedback from  
> implementation and actual use. That's why systems get rebuilt 2 or 3  
> times before they are really good. This doesn't happen with standards.  
> They are published as static documents, and the available feedback  
> processes are so slow as to be nearly useless. Many standards processes  
> continue as talk/documentation fests for years before anyone seriously  
> tries to validate the models or designs. Professor David Ingram (UCL,  
> the inventor of the term "openEHR") has a mantra: "implementation,  
> implementation, implementation". He says this not because he is obsessed  
> with programming but because of the crucial value of feedback processes  
> in validating and improving specifications.
> 
> - conclusion: any standards development process that is not a "live"  
> process with impleemntation and use and feedback loops, is not worthwhile.

Hear, hear! What a great summary of everything that is wrong with  
standards development. Can you publish that as a short essay on your Web  
site, or can I quote it with attribution elsewhere? Prototype, pilot,  
refactor, pilot again, start again, prototype, test, etc. No standard  
should be accepted unless its developers can admit that the first three  
versions turned out to be wrong when tested in real-life situations.

> OpenEHR is far from perfect, but it is (trying to be) one thing: a  
> process, not a thing. The process is more akin to a software engineering  
> process, conducted in the open, rather than a staandards development  
> process. So in response to the above, some face to face meetings are  
> good, but they need to occur as design workshops, with competent  
> modellers and specifiers, and there needs to be implementation testing  
> of the results.

Yup, and openEHR must be congratulated on this. My only criticism is  
that it has taken too long for openEHR to release working prototypes. I  
know these exist - but they need to be made public and readily useable  
for exploratory purposes, even if they are incomplete. Perfectionism is  
a curse.

> \> I call it the "dueling leaf-blower problem".  
> \>  
> that's a beautiful analogy! I'm sure I'm going to have to quote you on  
> this one day....

Indeed! I can think of a number of projects and organisations which  
appear to have nitromethane-burning supercharged V8-powered  
leaf-blowers...

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [10 August 2003 11:55 UTC](https://discourse.openehr.org/t/distributed-records-an-approach/15753/20 "2003-08-10T11:55:47Z")

</div>

> The concept of modelling the symptoms in a genric manner manner and have  
> these called up whenever there is a need to record the details.

I am not sure I fully understand what you want to say. What do  
you mean by "modelling the symptoms" ?

Symptoms could be recorded as free text. This approach you  
describe as inadequate. It \*is\* inadequate if the goal is to  
process the input computationally. The solution is not,  
however, to use (inadequate) coding systems as is discussed in  
Slee, Slee, Schmidt, "The Endangered Medical Record" (excerpt  
available from [http://www.tringa.com](http://www.tringa.com) ).

Another approach would be to really \*model\* symptoms based on  
openEHR archetypes. This promises to offer some degree of  
computationality yet preserve the free text. Others in this  
list have more experience with that.

Data-mining, however, shouldn't be the aim of an EMR. It  
should be focussed on patient care. Data-mining will occur  
with aggregates of extracts \*from\* EMRs.

Karsten Hilbert, MD

[Next page](https://discourse.openehr.org/t/distributed-records-an-approach/15753.md?page=2)