aus health it

Clinical (archive)
21

Of course it is bad news in this community if the same principles of 13606 / Open EHR are applied in HL7 v3 Patient Care and that it works.

I think the debate of either or standard is the scientific debate of last century. The work of this century is to standardise clinical content in small discrete archetypes to be used in any IT solution.

Lot of work goes in sorting out the clinical stuff and an appropriate binding to vocabulary and determination of appropriate datatypes. See earlier points made by Cecil Lynch

Then an agnostic modeling serves very well to facilitate implementation in several technical systems, either EHR or message.

Breakthrugh work in this sence is the linkage of HL7 v2 messages and OpenEHR archetype identifiers in the message that specify the clinical content.
This methodology can be used in HL7 v3 messages in a similar way (refer in the XML tags to the appropriate archetype / template).
Tooling is underway. Transformation form standard A to B or B to A a piece of cake if all hard clinical consensusbuilding and specification has been done.

Since we have so many ( I envision in the tenth of thousands, even up to hundreds of thousands discrete and small molecular archetypes, given experiences in about a dozen of projects involving clinicians, having dealt with about 10.000 discrite variables, organised in every possible grouping), the most dramatic problem to be solved is the repository of these things called GPICs, CMETs, archetypes, R-MIM, care information models, detailed clinical models, templates.

It is nice to have a big book of all kinds of requirements for archetypes specification such as the Iso 13606-2 archetype language, but if nobody worries about the content itself it is waste of time and effort of 10 years of research in both CEN / OpenEHR and HL7 v.3
Finding a way to organise, maintain and update archetypes/templates/care information models is the real challenge.

So I think this community should re-read the blog by David More carefully and see similar worries that I have given 3 years of submitting content to both standards organisations, all acknowledging that it is important and all asap ignoring it.

So what we need is a repository of clinical templates, maintained well, that basically ignores the specific technical implementation in either OpenEHR or HL7 CDA or v3 messages. We can apply similar systems as the ISO OID registry to identify sources and content.

William Goossen

22

Tim Churches wrote:

Yes indeed. But two (or more) wrongs (or absences of evidence) don't
make a right. My view is that the practice of health informatics needs,
desperately, to become evidence-based, otherwise we will continue to see
hundreds of millions or billions of dollars being poured into the
deployment of health information systems based on what is in the sales
brochure, or based on tender responses, which tend to be just more
elaborate versions of the sales brochures.
  

I want to point out a more unfortunate situation still happening in
Medicine: Not even in such an established and trusted profession has
truly embraced so called Evidence Based Medicine (EBM) or even Problem
Based Learning in their medical education curricula! I had been taught
that the facts (Science of Medicine) in some thousand page terrifying
textbooks/boring journals or the "Art of Medicine" as taught in clinical
wards by word of mouth or mostly stored in brains of older clinicians. I
strongly disagree that Medicine is an "artistic" profession in essence;
I hope that it is truly "Scientific". This is some philosophic part of
my research but shortly I found out that there are two sources of
knowledge in Medicine: Research LABs and Clinical Wards. And most of
this knowledge is generated in the latter by digesting and discovering
new knowledge from years of accumulated information from patient
encounters. Why it is kept unstructured? Mainly because they don't
really materialize these and they become "insights". Or not infrequently
of course most do not need to formalize and disseminate it as it
professionally brings him some strategic advantage. Maybe write some
papers giving pinpoint part of it but never expressing the "whole
picture" as needed. And believe me these are not bad people at all; it
is how they are trained. Well I guess an extensive IS capturing
structured and sharable data from these wards will make most of this
information available for processing and this will yield vast amount of
new knowledge I very much hope. Apart from pratical purposes of sharing
health data, I am much more interested in this aspect.

Although I agree with the idea of evidence based health informatics, I
feel sorry that my life span won't be good to see that :frowning: However a
realistic and medium term solution might be first having of course the
"essential" standardization work finalized, digested and implemented.
But more important is making sure that people/industry "obey" these. And
this can only happen (by free-will of course) if health informatics
becomes a "real" profession by implying some sort of control over
practice and education. Hehe very practically, even though I am in love
with what I do, I have hard time to explain to my Mom or other
"normal/ordinary" people what I do :smiley: She keeps on saying: Oh my son you
have studied medicine and now this computer thing, what are you waiting
to be a real successful (moneywise) man?? Funny ha...

One criticism I want to make for long time is that, for openEHR and
possibly other innovations in the open source domain, it shouln't take
sooo much time to see "real" reference implementations publicly
accessible somewhere. As time goes by, this is unfortunately the case
for cutting-edge R&D that they start "loosing-blood" because there are
many other sharks out there...I guess the patient has not died, or even
near to that but I know that it will take much longer now to fully
recover. Also one important warning is that, being open source/spec is
not a complete protection as in many cases of FOSS products, propriety
products are still preferred for mainly three reasons: 1) There is a
switching-cost, 2) Integration issues with other apps around 3) In most
cases total cost of ownership is lower in propriety products in short to
medium term. Of course these are my ideas again.

As a last comment and a wish, I really think the main body of industry
will jump into openEHR based products after seeing for themselves some
big reference implementations; not just R&D projects. I don't think the
end-users or buying organizations will have much influence on their
decision. Because an openEHR based system is expected to do "at least"
what is currently being done and "plus" more...And this plus will take
some time to materialize in people's mind. So the users will not see
much change when using their Hospital IS. An important "buying point" is
that I am sure openEHR will let most of these vendors do these things
more consistently and cheaper and also offer totally new features (such
as on the fly translation, or provide context sensitive decision
assistance) So to cut short: High impact industrial "reference"
implementations are needed.

Well I hope I did not bore you all....

Best regards,

Koray Atalag, M.D.

23

David,

I won’t argue about the standards thing. The openEHR Foundation is not a standards body, and does not offer its specifications to standards bodies. If anything is heading towards ISO, it is because people in CEN and ISO groups decided that it would be a good idea - it’s not in any way an outcome of openEHR processes.

The question of relative utility of decision support versus interoperability is an interesting one. I am far from competent to answer properly (not being a clinical professional), but my experience over the last 13 years of being involved in this area is this:

  • proper decision support is almost non-existent
  • this is because there are almost no longitudinal patient-centred records available for inspection - which most medical decision support needs to make any kind of safe inferences
  • the key to getting longitudinal patient-centric records (or constructed views that have the same effect) is interoperability - being able to share, convert, integrate data, or to be able to computationally construct views from heterogeous data that has the equivalent effect
  • interoperability that is not “semantic intoperability” is of no use to computers, only to humans, and therefore cannot support decision support

So interoperability doesn’t just serve the needs of shared care, but is crucial for decision support. In recent years it has become clear that health authorities would like something else before they get decision support - they would like patient workflow, i.e. care pathways to be managed by the IT. This means being able to managed distributed, heterogeneous data in such a way that the software knows where the patient is, what the last medications were, and what the next scheduled steps are. This all requires an interoperability basis as well.

I can’t argue about the relative importance of clinical decision support (you may well be right), but I can say this: it won’t happen without interoperable systems - to put it concretely, if my CDS software can’t read the blood pressures in the EHR in a standardised way, how is it going to be able to infer hypertension?

  • thomas

David More wrote:

24

Tim Churches wrote:

I also think that semantic precision and, related to that, semanic interoperabilty is a sine qua non for a generalised clinical decision support system infrastructure or ecosystem - otherwise we are doomed to forever creating one-off, specific decision support systems which only work with specific health information system installations. But whether openEHR is the answer, or a sufficient answer, to the problem of semantic interoperability remains to be demonstrated, from my perspective. It looks promising, but more experience with it in real-life and pilot situations on a  wider range of clinical problems is needed, and that experience needs to be formally assessed and evaluated and reported if at all possible. Again, perhaps it is just a matter of time.

Tim C

for those interested at a technical level, making CDS work requires two things:
a) interoperable systems, so as to get a standardised view of the data
b) a way of querying the data.

In openEHR, we have done something called archetypes + templates to help the first.Ocean Informatics has also developed a query language based on SQL + archetype paths to intelligently query the data. This will be published in MedInfo 2007, and will be offered to openEHR as a candidate for an openEHR query language. Other approaches to solving the problem exist at UCL and elsewhere, and choosing among proposed solutions we hope will be done in a similar process to OMG.

  • thomas
25

Dear Colleagues,

It has been suggested that I should cross-cost my long reply to David
More on this list, so here it is. There has been a little further
correspondence between us on the blog site since.

Dear David,

Thank you for setting up this blog as a window through which to air
your concerns. As the primary author of the section of prEN13606-2
that you quote, I am surprised and a little disappointed to find that
you are so critical of something which rather transparently admits
its limitations and points to the wider challenge of which it is a part.

The goal of defining data structures to represent key clinical
information in systematic ways is an old one, going back decades, and
is vigorously being accelerated now in many national eHealth
programmes such as yours (Data Groups etc.). These bodies are finding
many of the challenges you describe: how to contain the number of
data structures whilst catering for as much of real clinical
diversity as is wise, how to bind record structures with new-
generation large terminology such as SNOMED-CT, how to define
editorial and governance policies and publishing infrastructures for
these data structures and data sets, how to maintain them in the
light of evolving practice, and how to deliver a coherent set of
distributed knowledge services to support authorship and EHR systems.
Despite these many challenges, it is recognised that this kind of
approach is necessary if we are to aspire towards even modest
semantic interoperability of health records.

One key problem is that all such sets of defintions internationally
use rather ad hoc representation formalisms. Part 2 of 13606 is
therefore an important stepping-stone contribution towards
harmonisation in this area, drawing as it does on the openEHR
Archetype approach. The ability to foster an international standard
for how such data structures can be represented and shared has been
widely supported by many of the nations who are already building up
such data structure libraries (including the UK and Australia, voting
positively for 13606-2 in historic ballots). It is recognised that
the challenge of building up content needs to be internationally
shared, and that vendors (often being global) wishing to exploit such
knowledge artefacts would in general prefer a single standarised
representation.

The truth is that this is an area in which research, standardisation
and productisation need to proceed hand in hand. The solutions cannot
be found by waiting for research alone to finish, because research
needs to learn from wide scale practical experience and vice versa.

You will know, I am sure, that 13606 Part 1 does not require the use
of archetypes i.e. it is recognised that much useful EHR sharing can
and will take place before archetypes become widely used. Part 2 is
seeking to standardise that part of the archetype approach that is
reasonably well established (a comprehensive representation of what
needs to be specified when a data structure is defined). Future
standards will be able to address most of the other areas you raise,
but we are not yet at a point where best practice is established for
those areas. The openEHR Foundation and its Clinical Review Board,
and a new Detailed Clincial Models Collaborative of openEHR plus HL7,
are seeking to build up an understanding of best practice in these
other areas. There are also many running systems (some research and
some commercial products) that have adopted an archetype-like
approach from which we can learn. And there are substantial national
efforts, such as the Dutch work that William refers to, which are
identifying important issues and solutions.

I hope therefore that you can use your efforts, given that you have
taken the trouble to study the field, to help contribute to the
future learning we still need to make. If you do have specific
rewordings to propose to 13606 Part 2 I am very happy to receive
them, and to put them into the consensus standardisation process for
consideration.

I hope that you and your readers can recognise that the various
organisations, be it a national effort like the Australian or Dutch,
a standard like 13606 or HL7 Templates, or research like openEHR's or
our own at UCL, are all working rather unusually closely and
harmoniously towards tackling these difficult challenges. I hope you
will also find that, as a community, we are open to constructive
critique and to fresh inputs from others.

I look forward to your reply.

With best wishes,

Dipak

26

Indeed Semantic interoperability is crucial to develop
really useful IT based systems. It is not possible to
make safe healthcare IT systems unless we work in a
way that computers work and make use of that ability.
Computers are far more accurate than our brain and is
not affected by extraneous factors, does not lie and
does not tire etc. Therfore they have a place in safe
medicine.

Decision support is never going to be simple as it is
based on EBM and CPG (Clinical Practice Guidelines)
and will have multiple algorithms even for the same
conditions. Their integration into the system of care
can only be attained if there is semantic
interoperability. The process of the audit cycle will
also depend on the above and patient care pathways and
again, needs interoperability to work - audit should
show if we are following clinical practice guidelines,
and if not, put this information into processing to be
researched into depending on patient outcomes by
comparison of the deviated practice as opposed to the
evidece-based pathway.

OpenEMR archetypes is the only way I can see that will
make the above possible.

Theories are always incomplete and need to be tested
and improved and the OpenEMR allows for this. The work
is tedious and long drawn, but not stupid and
impractical. It is best to use it now and improve it
until we get what we want from it, rather than wait
until somebody uses it and proves it is impractical or
brilliant!

I too have studied it but not used it, yet. Therefore
I am not qualified to call it stupid or anything. But
i have some faith in the underlying reasons for its
development.

Nandalal

Nandalal Gunaratne MS FRCS(Eng.) MRACS(Aus.)
Urological Surgeon
Sri Lanka
--- Thomas Beale <Thomas.Beale@OceanInformatics.biz>
wrote:

27

Dear William,

You write:

Interesting view Gerard,
…
My point is: again: we are arguing the wrong case, namely that of the ‘best’ standard. None is the best, both work depending on the goal.

My reaction:
We are having the wrong discussion.

I’m NOT talking about the ‘best’ standard.
My argument was/is that standards are much more peer-reviewed than many papers in journals.
And in the case of OpenEHR implementable specifications have been produced and peer-reviewed, including working software that ism published.
So what more proof can you get.
That was my argument.

The discussion of what is the best standard and standardisation process, is futile.
We both know our own answers and will not change opinions.
So be it. That is a discussion I’m not interested in.

With regards,

Gerard

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

28

Hi Tom,

My quoting seems to misbehave, so I will put comments in the text.

See below

Cheers

David

29

David More wrote:

  • this is because there are almost no longitudinal patient-centred records available for inspection - which most medical decision support needs to make any
    kind of safe inferences
  • the key to getting longitudinal patient-centric records (or constructed views that have the same effect) is interoperability - being able to share,
    convert, integrate data, or to be able to computationally construct views from heterogeous data that has the equivalent effect
  • interoperability that is not “semantic intoperability” is of no use to computers, only to humans, and therefore cannot support decision support

This is where I part company - taking a purist view you are dead right..but there are a set of middle steps that can be taken that can make a substantial difference. (e.g. within one well designed client providing effective basic prescribing decision support based on some basic information and a little history etc).

well, that is more or less what products like Prodigy do. Prodigy only works because a) it knows that the target system is EMIS (a heavily used GP system in the UK), and b) that READ2 coding is used throughout. This is an example where sufficient (defacto) standardisation and longitudinal data exist to support safe-ish inferencing. And in the UK, this situation only exists because a) the government was smart enough to financially encourage MDs to get computerised b) the solution providers like EMIS actually build pretty good systems, and c) patients have to stick to one GP here in the UK. Elsewhere, in general, none of these factors hold. You couldn’t run Prodigy with Medical Director in Australia for example because the notes are not coded, mostly narrative, not structured, and in general are too arbitrary to do computing with. And that’s assuming the GP uses MD to write her notes anyway. And then there is the problem that any person in Australia (like many other countries) has fragmentary clinical records in multiple GP sites (not to mention hospital records).

One thing that could be achieved fairly soon is medication decision support based on a current medications list. But just obtaining that is hard in many places. So what we are doing in openEHR is making it possible for this sort of information to be standardised and shared. We are not trying to do this kind of decision support - there is nothing standing in the way of it being done, assuming the data can be obtained. That is for other people, products etc. We see our job as making the data available.

I believe your completed solutions are a good few years off and I see it as being worthwhile to take some small interim pragmatic steps and get some basics going.

well, actually, deployments are a good deal closer than you realise…

Trying to “boil the ocean” has typically proved both slow and ultimately maybe impossible - but we could make a difference to ordinary practice with simpler approaches I believe.

It is undoubtedly true that some tools not being used today could be used in today’s practices. E.g. medication checking could probably be used now with applications like Medical Director - we are not preventing that at all. But it is a lot harder than you think. Just consider the obstacles to making a hypertension evaluatable against Medical Director data…

So interoperability doesn’t just serve the needs of shared care, but is crucial for decision support. In recent years it has become clear that health
authorities would like something else before they get decision support - they would like patient workflow, i.e. care pathways to be managed by the IT. This
means being able to managed distributed, heterogeneous data in such a way that the software knows where the patient is, what the last medications were, and
what the next scheduled steps are. This all requires an interoperability basis as well.

We could start using things like the CCR (ASTM) and then, having learned, do more.

CCR is a kind of mega-template for everything that could go in an encounter note. We have already modelled much of this in archetypes, and in fact the entirety of the CCR can be done in archetypes. The reason to do this is that while the CCR is a reasonable clinical statement of information to be captured, it is not in a useful deployment form (single XLM schema). This provides little or no componentisation, ability to mix and match various pieces of information captured in different settings, ability to dynamically include items not currently in the CCR, ability to use the same definitions as the basis for GUI forms and query expressions and many other things. XML-schema also doesn’t allow the kinds of rich constraints to be expressed that can be done in archetypes.

I can’t argue about the relative importance of clinical decision support (you may well be right), but I can say this: it won’t happen without interoperable
systems - to put it concretely, if my CDS software can’t read the blood pressures in the EHR in a standardised way, how is it going to be able to infer
hypertension?

See above…we can get along the way by basic information capture within a simple system and a simple rules based system and then improving incrementally. We can save lots of lives before we reach the point of true incompatible system interoperation I believe

David, we have been doing “basic information capture” within “simple systems” for 40 years now. What we can do with today’s data is minimal. That’s because none of the content has a semantic definition or common record model. If this weren’t the case, you would see working decision support systems all through clinical practice.

  • thomas
30

Thomas Beale wrote:

David More wrote:

See above...we can get along the way by basic information capture within a
simple system and a simple rules based system and then improving
incrementally. We can save lots of lives before we reach the point of true
incompatible system interoperation I believe

David, we have been doing "basic information capture" within "simple systems"
for 40 years now. What we can do with today's data is minimal.

Well, what computers can do automatically with today's
("computerised"/electronic) health data is minimal.

Humans can do a lot with it, but then humans are very good at resolving
semantic ambiguities and imprecision and incompatibilties, on-the-fly,
without even having to think about it most of the time.

Also, computers can do things automatically with existing data, but they
need to have their semantic hands held by a human on a case-by-case
basis. This is waht happens when, say, a researcher analyses clinical
data collected from heterogenous (or even one) health information
systems - the human needs to put in a lot of effort to resolve and
smooth over the semantic problems in the parts of the data in which they
are interested for their analysis.

That's because
none of the content has a semantic definition or common record model. If this
weren't the case, you would see working decision support systems all through
clinical practice.

I think the problem is that building good, safe and sufficiently capable
clinical decision support systems is very hard and needs a lot of input
and effort from a lot of parties, and thus is expensive. Much of the
effort will be in resolving semantic problems within each system, on a
one-off and specific basis. This means that small-to-medium-sized
vendors/developers of health information systems never have enough
resources to build good DSS for *their* particular product. And of
course the large health system vendors typically don't sell a single
system, rather they sell frameworks on which customised systems can be
built or configured. If you look at how data is captured and represented
in two different, say, CERNER systems in two different countries, or
even two different states of Australia, you will find significant
differences in how data is captured and represented. So again, it is
difficult to achieve the necessary economies of scale to enable good DSS
to be developed.

openEHR archetypes provide a promising technical basis for achieving
shared semantic definition and common record models, but as everyone
agrees, only if a viable and sustainable mechanism for maintaining a
unified set of archetypes definitions (including the terminologies to
which they are bound), can be achieved. It must also allow for the
necessary specialisation of archetypes for local needs. Building such a
mechanism is a politico-sociological endeavour far more than a
technological one. It is achievable, I think, but won't be easy and will
never be as neat and clean as anyone would like. That's life, and is not
a reason not to try.

But I feel that far more evidence that openEHR is the best technical
vehicle for this endeavour is needed before large scale engagement by
lots of parties will occur.

Tim C

31

Tim Churches wrote:

Also, computers can do things automatically with existing data, but they
need to have their semantic hands held by a human on a case-by-case
basis.

Sorry, that should have read:

Also, computers can do things with existing data, but they need to have
their semantic hands held by a human on a case-by-case basis.

Tim C

32

All,

Just a few points.

Regarding doing some simple things before moving on…the evidence from Australia is (from MJA this year) that only 21% or practitioners are properly using the fully electronic capabilities of existing software. Getting this up to some much higher figure would be a good first step.

Generic point is to get what we can do now fully deployed will make a substantial difference.

Also I wonder how many reading here have fully reviewed CERNER’s more advanced capabilities. They do have a pretty decent (flat I know) data model that does allow for quite useful rule based decision support based on clinical information held on the individual patient in the repository. Using this fully could also make a difference while waiting for the advanced system to arrive.

I agree with Tim’s points and while waiting for the enormous change he recognises is needed for practical archetype implementation there is useful stuff we can do today. A dual track approach (do what we can fully while developing the next generation) seems smarter and lower risk to me.

Cheers

David

33

David More wrote:

All,

Just a few points.

Regarding doing some simple things before moving on...the evidence from Australia is (from
MJA this year) that only 21% or practitioners are properly using the fully electronic
capabilities of existing software. Getting this up to some much higher figure would be a
good first step.

Generic point is to get what we can do now fully deployed will make a substantial
difference.

Also I wonder how many reading here have fully reviewed CERNER's more advanced
capabilities. They do have a pretty decent (flat I know) data model that does allow for
quite useful rule based decision support based on clinical information held on the
individual patient in the repository. Using this fully could also make a difference while
waiting for the advanced system to arrive.

Where can one review the CERNER data model, David? Especially if one is
not a CERNER customer? Or even if one works for a large organisation
which is a CERNER customer? Where do we look or whom does one need to
approach to get access to what you describe?

I agree with Tim's points and while waiting for the enormous change he recognises is
needed for practical archetype implementation there is useful stuff we can do today. A
dual track approach (do what we can fully while developing the next generation) seems
smarter and lower risk to me.

Yes, and a multi-pronged approach is exactly what will happen because we
are not discussing a centrally-planned-and-commanded economy here, nor a
single corporate entity. Each R&D group will basically do what they
think best and/or what they can get funds to do. Thus people working on
and promoting openEHR should and will continue to do so, and yes, others
should and will work on more simple-minded short terms stuff.

Tim C

34

Hi Tim and all

My exposure to the Cerner Data Model has been via 2 evaluations for various international and local clients where I have had it shown to me in the sense of how it is used to build their system during imlementation and how data-elements are found to be incorporated in decision support rules - using their Arden Syntax Engine.

I believe it is available to all those involved in building the various applications Cerner provides in a particular implementation and is, as you would appreciate the key to their application integration. It is designed to be provided as a stable core of “data concepts” and there is capability to add specific data elements locally and while customising for different countries etc.

While I don’t have a copy to walk away with or give you (I am pretty sure Cerner sees it as a core part of their IP - the design especially) I am sure any of the major sites in NSW Health would be able to tell you a great deal more and indeed show you how it is used.

Cheers

David.

35

David More wrote:

All,

Also I wonder how many reading here have fully reviewed CERNER’s more advanced capabilities. They do have a pretty decent (flat I know) data model that does allow for quite useful rule based decision support based on clinical information held on the individual patient in the repository. Using this fully could also make a difference while waiting for the advanced system to arrive.

Hmmm. How many GP surgeries will be getting Cerner soon I wonder…

  • thomas
36

Hi Tom,

Hmmm. How many GP surgeries will be getting Cerner soon I wonder…

  • thomas

That is hardly the point - not that it is not being used in a range of ambulatory care environments and that Cerner does not have a GP offering. The point is this actually exists today, works and has literature evaluating it (albiet with a variety or outcomes). The consensus view is that CPOE can save lives and improve quality and has been shown to do so in Hospitals - trouble is only 3-4% currently have it, its is not cheap and hard to implement - due in part to clinician resistance. Get that figure up and we would also save more lives.

Cheers

David

37

David More wrote:

Hi Tim and all

My exposure to the Cerner Data Model has been via 2 evaluations for various international
and local clients where I have had it shown to me in the sense of how it is used to build
their system during imlementation and how data-elements are found to be incorporated in
decision support rules - using their Arden Syntax Engine.

I believe it is available to all those involved in building the various applications
Cerner provides in a particular implementation and is, as you would appreciate the key to
their application integration. It is designed to be provided as a stable core of "data
concepts" and there is capability to add specific data elements locally and while
customising for different countries etc.

Perhaps this is a bit off-topic, but what David describes in CERNER
sounds somewhat akin to the "concept dictionary" which is implemented in
OpenMRS (see http://openmrs.org/wiki/OpenMRS and
http://openmrs.org/wiki/Data_Model and
http://openmrs.org/wiki/Concept_dictionary and
http://openmrs.org/wiki/Dictionary_101 ), which I believe is based on
the Regenstrief Clinic data model which has been used in their systems
for several decades. At its core it uses an EAV (entity-attribute-value)
type of representation, where entities are patients etc, and
"attributes" defined in the second, "soft-coded" level of the data model
have "concept" metadata and constraints associated with them. Thus it is
a typical two-level model. Not nearly as sophisticated as openEHR, but
it has been in the field at Regenstrief for decades and is now in the
field in Africa in several OpenMRS implementations.

I know that Regenstrief has several decision support systems built on
top of this, and there are plans to do the same with OpenMRS.

My view is that openEHR is an attempt at the next generation of
Regenstrief/OpenMRS-style two-level information systems (or
meta-systems, or system frameworks).

Tim C

38

Where can I get an electronic copy of Health informatics — Electronic health record communication — Part 2: Part 2: Archetype interchange specification? I have searched for it, but thus far with no luck.

  • Ole Jørgen Anfindsen

Andrew Patterson wrote:

39

Dear Ole,

You can download the latest version of all 13606 drafts here:

http://www.chime.ucl.ac.uk/~rmhidxk/13606/13606_2006_Drafts.zip

This zip file contains all the parts, and a Readme.

With best wishes,
Dr Dipak Kalra
CHIME, UCL