use cases

Clinical (archive)
1

Dear all,

Could you help me with some clinical use cases to demonstrate the
differences between an 'EHR' based on standardized messages and an
EHR based on a standardized information architecture/ reference model.

As you might be aware here in the Netherlands our government has
chosen, for now, to use standardized messages in combination with a
central 'switch point'. Basically this provides a communication
infrastructure which deals with identification and authorization en
provides a look-up function so data can be found in other systems.
Data remains de-central in legacy systems and vendors translate their
legacy data to these standardized messages in XML so those bits of
information can be shared between the health care providers connected
to the switch point.

Recently within NEN (the Dutch partner of CEN) we've completed an
inventarisation with regard to the existing standards in this area.
Goal is to provide an overview and some guidance for the NEN members
wrt to these standards.

In short the conclusion is that the HL7 and EN13606 standards should
be seen as complementary. HL7 has proven it's use for the exchange of
messages and will be around for some time since legacy systems will
use this to communicate with each-other. EN13606 defines an
information architecture which assures semantic interoperability
between information systems based on that standard. Both systems can
(and in the Netherlands will) use the 'switch point infrastructure
and with regard of the exchange of information between information
systems HL7 v3 can be used as the envelope for the information. Since
openEHR isn't an CEN/ISO standard yet, we've left this out for now.
Next year we'll do an re-inventarisation and hopefully we can add
openEHR to the list (We'll take small steps at the time. This was
already quite a big step within the Netherlands).

Now there is a request to provide a document which can be used by a
broader public (especially decision makers, healthcare providers and
vendors of health care applications/systems) which explains in more
detail where we're heading for, what choices can be made and what the
consequences of those choices could be.

Our idea is to explain this with a couple of clear use cases and from
there zoom in on the technical requirements/ choices to be made/
consequences.
We're looking for use cases for which standardized messages is a
sufficient solution and use cases for which one really needs
information systems which provide semantic interoperability.

Of course other suggestions are more than welcome.

Cheers,

Stef

2

Hi!

A couple of months ago a similar investigation was conducted in Sweden
(written in Swedish though). The decision made after the report was
delivered was to go for the EN13606/openEHR approach.

Formally I believe the decision was EN13606, but I believe any project
with reasonably limited deadlines would benefit from start using
openEHR 1.0.1 internally and then possibly convert to 13606 on demand
if such use cases arise. There is not enough implementation experience
and tools available for EN13606 yet.

One of the arguments for the EN13606/openEHR approach is that deeper
semantic interoperability requires shared semantics at the point of
entry (not necessarily shared exactly entry user interface though).
Otherwise (if you allow any kind of semantics at the entry point) you
can not guarantee that semantic conversions between entry semantics
and message semantics are algorithmically solvable and thus
technically implementable in a patient safe manner. This is not
obvious to all messaging advocates if the main messages in mind are
traditionally well structured and fairly similar things such as lab
tests etc instead of arbitrary parts of an EHR that are usually
exchanged using faxed papers read by humans.

This said, having a central 'switch point' is possible with both the
HL7 and openEHR approaches, maintenance of nationally shared semantics
affecting the point of entry will likely be a lot easier using the
openEHR that was designed with that in mind.

Best regards,
Erik Sundvall
erisu@imt.liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-227579

3

I have started a wiki page to help answer some of these questions - see
http://www.openehr.org/wiki/display/resources/EHR+versus+Messages

I will try to fill this in over the next few days. One important point
to note about messages versus EHRs is that messages come from the era of
hand-defined content, whereas EHRs, certainly the CEN/openEHR idea of an
EHR assumes that content is defined in archetypes that are then used to
shape concrete expressions of the information such as in: persistent
store, screen view, data capture screens, messages, various forms of
output including XML, HTML, PDF and so on. In other words
define-once-use-many. Conversions can be made from messages to generate
EHR content, some more painful than others.

However, as a strategy for the future I don't believe manually defined
messages make much sense. They need to be generated artefacts based on
archetypes and templates. (The openEHR way of doing this is called the
'template data schema' and has been discussed here recently. Some
description of this will go up on the wiki when time permits).

- thomas

Stef Verlinden wrote:

4

Hello everybody,
Let me try if I understand this correctly, :

An EHR in the openEHR sense holds ALL data about a patient, in archetyped
form. As Thomas mentions you then go and "shape concrete expressions" for
certain well defined purposes, by combining these pieces in a meaningful
way.

USECASE A: openEHR type of EHR in communities with close cooperation
In a typical situation today an openEHR type EHR could be situated within a
healthcare organization, where all employees fill in data as they provide
their special bit of care. Many of this is unstable and intermediate, as
caregivers get deeper into diagnosis and treatment, within days or even
hours. There is full detail. Some data is not fact, but assumption, to be
refined and tested further. This data is often not intended to be
communicated outside the own organization. ALL data about a patient is
available within a single organisation without severe data protection
issues.

Finally, at the end of a treatment phase, someone would typically generate a
"concrete expression", e.g. a discharge summary, to be used by someone else
OUTSIDE the own organization, maybe a resident doctor who continues the
treatment of the patient.
This is where the data protection laws come in.

USECASE B: "message based", between partners who are more loosely coupled
What we now think of as a typical "EHR" on a national level, for example in
Austria and in the Netherlands, is something different: It does not hold ALL
information about a single patient, it just holds the "concrete
expressions", e.g. the discharge letters that someone generated for a
certain purpose, to be used by someone at a completely different place.
Information must be complete, stable and reliable, filtered, and give the
complete picture, with interpretations, not too much details, more on the
summarizing side.

The lawyers and the public healthcare authorities today are used to deal
with "concrete expressions", as you find them in this type of communication.
Documents are usually signed and legally binding in many countries, and that
is the only type of cross enterprise communication that "a wider audience"
is familiar with today.

Within the next decades we may hopefully see that ALL EHRs change to the
openEHR type. There is no way around that, as the healthcare process gets
more interconnected, and caregivers become more and more closely coupled,
and therefore willing to share intermediate observations that they now need
to keep secret. I guess it will take some time to change the heads of
caregivers and healthcare authorities.

Did I get this right? Comments welcome, and greetings from Austria,
Stefan Sauermann

5

Hi Eric,

6

Stefan Sauermann wrote:

Hello everybody,
Let me try if I understand this correctly, :

An EHR in the openEHR sense holds ALL data about a patient, in archetyped
form. As Thomas mentions you then go and "shape concrete expressions" for
certain well defined purposes, by combining these pieces in a meaningful
way.
  
well let's say, all the data of interest to those performing the care
delivery process. This includes the patient, and any data from devices
they use. But there are lots of data generated in a hospital that relate
to the patient that are of no interest to the physicians or nurses -
that do not need to be in the EHR - examples: movements of the patient,
of drugs from the pharmacy etc.

USECASE A: openEHR type of EHR in communities with close cooperation
In a typical situation today an openEHR type EHR could be situated within a
healthcare organization, where all employees fill in data as they provide
their special bit of care. Many of this is unstable and intermediate, as
caregivers get deeper into diagnosis and treatment, within days or even
hours. There is full detail. Some data is not fact, but assumption, to be
refined and tested further. This data is often not intended to be
communicated outside the own organization. ALL data about a patient is
available within a single organisation without severe data protection
issues.

Finally, at the end of a treatment phase, someone would typically generate a
"concrete expression", e.g. a discharge summary, to be used by someone else
OUTSIDE the own organization, maybe a resident doctor who continues the
treatment of the patient.
This is where the data protection laws come in.
  
I should be clearer about what I meant by 'concrete expression' - I
meant technically concrete expressions of the RM & content models, such as:
- persistence schemas/models
- UI form models, e.g. in Xform, XAML etc
- UI display expressions, in XML, HTML, PDF
- message output definitions
- code fragments

In other words, the content models should be a single source of
definition of all concrete uses of such content, whether in a message,
database or on the screen.

Stefan, what you understood by 'concrete expression' is something more
like a 'summary record content' or so...

USECASE B: "message based", between partners who are more loosely coupled
What we now think of as a typical "EHR" on a national level, for example in
Austria and in the Netherlands, is something different: It does not hold ALL
information about a single patient, it just holds the "concrete
expressions", e.g. the discharge letters that someone generated for a
certain purpose, to be used by someone at a completely different place.
Information must be complete, stable and reliable, filtered, and give the
complete picture, with interpretations, not too much details, more on the
summarizing side.
  
this is of course normal for an initial version of an EHR - it is not
enough on its own to do full care, but it is useful to physicians.

- thomas

7

Hi Thomas

I have started a wiki page to help answer some of these questions - see
http://www.openehr.org/wiki/display/resources/EHR+versus+Messages

Thanks this is very helpful.

From the discussion we seen so far (at least here in the Netherlands) the following will ‘fire up’ the discussion. So in between I’ve put some questions. I guess many more will follow:-)

Can messages be used to build an EHR?

A common idea among some people in health ICT is that an EHR can be constructed as a series of accumulated messages. This idea seems particularly prevalent in government, for the obvious reason that if messages, which already exist, could be aggregated within a central database, nothing more would be needed to create an EHR. However, an inspection of what is needed in an EHR and what messages provide show that this is not the case. The following sections explain why.

Messages come from more than one source

In any non-trivial health information environment, messages come from multiple sources - at least multiple pathology laboratories. The general case is that each such source uses slightly (or maybe radically) different message structures to transmit the same information. Often the software at some sources implement a different version of the same message, while other sources use a different system of messaging altogether.

[SV] I don’t know if this hold true (and I want to be prepared for the discussion), but one could argue that since the messages used are centrally organized and everybody has to use the same messages if they want to be connected to the switch point/ communication infrastructure this issue is tackled.

Isn’t one of the arguments that in order to create an (longitudinal) EHR based on data/information stored in different systems, these systems themselves have to be based on a common architecture in order to deal with these (differences in) versions/content and the medico legal issues arising from that.

How about context? Obviously a message can be as large as one chooses, but is it technically possible to add all the relevant context in a message.

Clearly using a collection of such disparate as an EHR will not work. At a minimum, format, version and message system conversions would have to be made.

[SV] is there any literature or are there reports/presentations which support this? It might be easier to ‘see’ this when it’s backed up with examples/ literature.

Cheers,

Stef

8

Hi Stef,

Interesting topic I will use the Scottish NHS experience as an
examplar of the advantages and limitations I have seen of the
messaging based approach.

Scotland (in contrast to England) has never used HL7, opting for a
home grown messaging standard, SCI-XML, based on EN13606 and using
Read codes as a terminology. We were fortunate in having advice from
one of the originators of XML Schema, who at the time was a visiting
professor at Edinburgh University. A number of high level COMPOSITION
type messages were defined, such as Discharge , Referral, Lab Test and
all of these are currently in use. One of the keys to the relative
success of SCI-XML was a library of XSD components called general.xsd,
which are very archetype like and promote a considerable degree of
re-use e.g Medication, Diagnosis, Patient problem.

So far, so good!! Now to the problems...

These XSD fragments are hand-crafted and there are only 2 or 3 people
in Scotland who have the skills and experience to extend the current
schema in a coherent fashion, and the demand for new structures or
variations far outstrips the capacity to supply.

We do have a Data Standards unit NCDDP, whose remit is to define
clinical data standards, to be incorporated into vendor products and,
of course, SCI-XML but the output of NCDDP is not in any usable
formalism that can be automatically mapped to SCI-XML, nor does it use
SCI-XML as a reference model.

Interestingly, there appears to be a very similar position in Denmark
i.e a technical disconnect between the standards documentation and
implementation, and I would guess that this maybe an almost universal
issue.

Although moving to HL7v3 would widen the available skillset, due to
the well-known difficulties in authoring clinical content in V3, we
would probably be worse off in the significant roadblock in clinical
content definition.

The NHS England experience of openEHR for clinical content definition
is that it has proved far easier than using HL7v3.

Even if HL7v3 resolved these difficulties and through better tools or
a leaner ref model became clinician-friendly, it is my belief that the
archetype 'maximal dataset' approach has a very profound
socio-technical effect on modelling and implementation

Minimal dataset definitions, as used by most Clinical modelling,
whether the Scottish NCDDP or HL7v3 message definitions, work fairly
well where a high degree of consensus (or enforcement) can be
acheived. Unfortunately, beyond some fairly simple clinical entites,
such consensus is often impossible to acheive - a minimum is agreed
and anything else is held to be 'out-of-scope'. The problem now is
that, in due course, some of these out-of-scope concepts need to be
interoperable. Since they are hidden from the shared modelling space,
it is likely that there has been even more drift in the way that the
new concept has been expressed and re-alignment is awkward and costly.
Similarly, new and innovative ideas will have been modelled privately,
perhaps by several different vendors/ research teams.

By using the maximal dataset archetype approach, we create a shared
space where different approaches to a very tightly defined clinical
concept can be explored and modelled but always in a highly visible
fashion. Genuine innovation can be encouraged, messy semantic overlaps
can be discouraged or prohibited.

This will be particularly powerful in the currently very difficult
area of community multi-disciplinary assessment where consensus is
extremely difficult to achieve.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll

Consultant - Ocean Informatics ian.mcnicoll@oceaninformatics.com
Consultant - IRIS GP Accounts

Member of BCS Primary Health Care Specialist Group – www.phcsg.org

9

Tom,
Thanks for the explanations, and indeed it would help a lot if you could
give more information about what 'concrete expressions' are and how they are
generated and used.

I must admit that "technically concrete expressions of the RM & content
models, such as:
- persistence schemas/models..." does not give me a clear idea what this
actually feels like.

Thanks for your comments, this is very helpful. I do need to tell others
around here why this all is really worth wile. I do know somehow, but we
need to get this across.

Stefan Sauermann

10

From a non-clinical background I would make these statements - not

sure if they are correct or particularly relevant but I'll throw it
out there and see if anyone agrees.

(1)
A message standard is a commitment between two parties
to 'understand' a set of data at a defined level. This is why
maximal data modelling at a message level doesn't really make
sense - noone can write computer systems that 'understand'
all the data in a maximal model. Complete semantic understanding
of the content of the message is a _requirement_ for health messaging
systems (I may not totally understand every field of a message but
I at least have to have an agreement between the two parties as
to which fields I am allowed to ignore!)

(2)
An EHR standard is a commitment to faithfully record data
meeting a defined level of structure. Maximal data modelling
makes sense because the EHR is committing just to the storage
of the data, and to allow its retrieval in a standardised way. The
EHR doesn't necessarily have to 'understand' the data, merely
has to be able to retrieve and present it. Any semantic understanding
that the EHR achieves through archetypes etc is
a bonus.

(1) and (2) are very different use cases - there may be value in
sharing common artifacts or bases for the two (ala the template
definitions from Ocean seem to me to be a mechanism to
allow the definition of (1) but in a way that reliably and easily
transforms into something suitable for (2))

Andrew

11

This is as good a summary as any. To go a bit further: some particular
instances of EHR content will clash with competing message definitions
relating to the same topic - the latter manually defined. Further, the
EHR structures can be used to machine-generate message defintions for
all the EHR content, not just particular ones that were chosen by
message design teams - and in particular including messages with
numerous slight variations from ones that may have been manually
modelled. This is the situation in which we find ourselves today. We
obviously need to deal with existing messages, e.g. HL7v2 and EDIFACT,
but hand-building messages is not an appropriate strategy for the
future. It creates the situation where the definition of the 'line
packet' now dictates to systems what their data should be, and in an
inflexible , non reusable way.

- thomas

Andrew Patterson wrote:

12

Stef Verlinden wrote:

*Messages come from more than one source*

In any non-trivial health information environment, messages come from
multiple sources - at least multiple pathology laboratories. The
general case is that each such source uses slightly (or maybe
radically) different message structures to transmit the same
information. Often the software at some sources implement a different
version of the same message, while other sources use a different
system of messaging altogether.

[SV] I don't know if this hold true (and I want to be prepared for the
discussion), but one could argue that since the messages used are
centrally organized and everybody has to use the same messages if they
want to be connected to the switch point/ communication infrastructure
this issue is tackled.

there are undoubtedly places where there is only a single central
message switch, but there are many places where this is not the case - I
know this from personal experience, and conversations with message
system implementers. I would expect that health computing environments
where the messages sources have been centralised and converted into
correct versions, correct coding, correct identifiers etc would be in
the minority. I don't know if there are any surveys on this, but in the
first instance it would be useful if people onthis list were to respond
with their experience of the level of use of centralised message switches.

Isn't one of the arguments that in order to create an (longitudinal)
EHR based on data/information stored in different systems, these
systems themselves have to be based on a common architecture in order
to deal with these (differences in) versions/content and the medico
legal issues arising from that.

How about context? Obviously a message can be as large as one chooses,
but is it technically possible to add all the relevant context in a
message.

it is, the problem is rationalising the context from each message with
that recorded in other rmessages in order to get a coherent picture of
some aspect of the patient situation. This gets difficult very quickly
if there is not a standardised approach to modelling context in
messages, or if messages modelled by different groups including
differing levels of context information.

- thomas

13
  • thomas

And killing any innovation.

Use case:

  • Dr X and the diabetic nurse Y and the Specialist Z decide to test whether a new regime of new therapy and coordination works better than the previous regime.
    They want to improve their key figures they have to report to the insurance company each year.

Each of them will take care in slightly different ways of the treatment of all diabetics they are responsible for.
A new clinical pathway is designed, reflecting the new responsibilities and ways to cooperate.

Each has an EHR-system produced by a different vendor.

Messaging solution:
Each addresses its own vendor.
Since each vendor in the country receives hundreds of request for new messages and all a bit different, almost each request is turned down.
It takes far to many resources to produce a message for all those local groups of cooperating healthcare providers.

The venders united in an organisation decide to get consensus between all clinicians involved. This takes 1 year to produce a new message specification.
Together the venders start the IHE process. So it takes 1.5 years to have one new implementable and tested specification.
After another six months all healthcare providers get a new version of the diabetic clinical pathway.

Most healthcare providers feel unhappy with a message that is not reflecting the local arrangements for cooperation.
And more so since in these 3 years new medications and preferred regimes have been reported in the literature.
They decide to leave things as they are and wait for better times with better IT solutions.

Archetypes/Templates solution:
Each of them has an other vendor but with a system conforming to EN13606/openEHR, the National-, European- and International standard.

They use Clinical Modelling Tools based on the European EHR standard and openEHR implementable specifications.
And produce the collection of templates they need in order to support their local new clinical pathway.

The European Institute for Health Records together with the openEHR organisation host the European collection of Archetypes.
The Dutch ProRec center is responsible for the Dutch Archetypes.
Archetypes express what clinicians want to document about any clinical (and non-clinical) topic.
Templates define what at the local level needs to be documented, retrieved and exchanged.
The templates they need are produced using these essential shared resources.

Within seconds these new templates are implemented in all systems.
After an evaluation after one week, they decide that certain aspects need to be more fine tuned. That same hour all their systems have implemented those changes.

Each month they produce a report with the figures they have to report on later that year.
After 6 months things are improving, they are on the right track.

I hope that this is a compelling use case many will understand.

Gerard

Electronic Record Company B.V.

Distributor of Ocean Informatics

for Europe and the Middle East

Leidsevaart 594-596
NL-2014HT Haarlem
PO Box: 376, NL-2300AJ Leiden

the Netherlands

M: +31 620347088
E: g.freriks@e-RecordCompany.EU

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

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

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

14

Gerard,

This is fine, and I agree that the Archetypes/Templates solution is to be preferred.

However there is one fundamental weakness in it: It is based on the assumption that everybody runs an archetype / Templates enabled system. This is definitely not the case now.

One of the major weaknesses of the “Messaging solution” is that it takes 3 years to get going: true.

I guess we must accept the fact that an “Archetypes/Templates solution” might take even more than that.

Greetings from Vienna,

Stefan Sauermann

15

Dear Stephan.

Ocean has taken care of much of these interoperability problems.
We all know that working systems at present talk Edifact, HL7 or other formats.

From the experience we have in one hospital in the Netherlands is that it was relatively easy (days) to interface an EHR based on Ocean to HL7 Lab results
and a GP Medication Summary Edifact message.

Gerard

ps: the three years needed to implement messages is very optimistic.
Five to six is more in line with large scale implementations.

Read also the opinion of the former boss op the NHS-England National project.
He discusses their experiences with HL7 but more importantly the vendor lock-in of systems.

http://www.publications.parliament.uk/pa/cm200607/cmselect/cmhealth/422/7042605.htm Q78 Jim Dowd: Given the scale of the undertaking, as you have described it, given the novelty of a lot of the approaches, how much of your system’s software is dot zero releases in the operating systems that are out there?
Mr Granger: None of the operating systems, because they are either industry standard proprietary systems or LINUX. In terms of
the application software, almost all of the applications that are being delivered are systems that have been deployed extensively
previously or are incremental upgrades of things which were deployed previously. In terms of the core Spine infrastructure, there was
some mythology in the Health Informatics Community that the standards existed, HL7 was mature, and so forth. That was completely
untrue. We have had to put an awful lot of effort into specifying the standards for messages, around demographics, around booking,
around prescriptions, and then the software that BT have built with a number of sub-contractors is brand new software that has been
custom-built for the NHS; so that is high-risk, new build software. There was no other way of doing it. I am very pleased a number of
other jurisdictions are getting very interested in using that. What I do not want us to end up with in the NHS is a situation we have in
a number of other areas of civil administration where we expend a significant amount of money building something which, when it
comes up for re-tender, we have a unique supplier and we either have to pay to get other people to come in and bid in order to have
a competition for the replacement, or we are held to ransom at the point of replacement. What we need to get to is a sufficiency of
open standards, which we are leading a lot of jurisdictions on, so that when we come to re-tender these systems at the end of the
contract there is a vibrant market of suppliers in a number of jurisdictions and we do not face that risk on an enduring basis because
we are sharing software that is used in other places. I think, in particular, the Welsh Assembly will have some very interesting choices
when we turn off the systems on which they are dependent, starting next year, as to whether they use the English solution or they go
and build from scratch something that does the same thing.

Gerard,
This is fine, and I agree that the Archetypes/Templates solution is to be preferred.
However there is one fundamental weakness in it: It is based on the assumption that everybody runs an archetype / Templates enabled system. This is definitely not the case now.

One of the major weaknesses of the “Messaging solution” is that it takes 3 years to get going: true.
I guess we must accept the fact that an “Archetypes/Templates solution” might take even more than that.

Greetings from Vienna,

Stefan Sauermann

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

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

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

16

Stefan Sauermann wrote:

Gerard,

This is fine, and I agree that the Archetypes/Templates solution is to
be preferred.

However there is one fundamental weakness in it: It is based on the
assumption that everybody runs an archetype / Templates enabled
system. This is definitely not the case now.

One of the major weaknesses of the “Messaging solution” is that it
takes 3 years to get going: true.

I guess we must accept the fact that an “Archetypes/Templates
solution” might take even more than that.

Greetings from Vienna,

Stefan Sauermann

*Actually Stefan,

this is one of the big advantages of archetypes and templates - you can
deploy the systems that use them on day one, and slowly grow your
archetypes and templates over time. The system doesn't need changes
(except possibly in the GUI). And in any case I would guess 2 more years
international work will have created archetypes for 80% of medicine that
you can just use.

Also: a conversion framework to/from messages exists, based on the
Template Data Schema, which will be offered to openEHR.

Also: in the UK, where archetypes and templates are being used, no
suppliers have openEHR-based systems. There are ways being developed to
give templates to suppliers in a form they can directly use.

I can guarantee we are completely realists here - there is no fantasy of
doing greenfield systems.

- thomas

17

Hy Thomas,
history will show when these things are going to become reality. I guess all
we can do at the moment is to move ourselves and those around us further on,
and see where this gets us. It looks like evolution to me, and you cannot
force it.
May the force be with us!

Greetings from Vienna,
Stefan

18

Without vision there never is progress.

Gerard

Hy Thomas,
history will show when these things are going to become reality. I guess all
we can do at the moment is to move ourselves and those around us further on,
and see where this gets us. It looks like evolution to me, and you cannot
force it.
May the force be with us!

Greetings from Vienna,
Stefan

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

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

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