[cis-wg] Complexity, killer apps and other conundrums of health information was: cis-wg Digest, Vol 37, Issue 12 (Juliana Brixey)

[Dr_CHEUNG_Ngai_Tseun (Dr CHEUNG Ngai Tseung)]

Dear Ed,

I think these abstract models have huge value - in commoditizing the understanding of health care data, and in providing a framework for interoperability. However, I am quite skeptical of the ability to build highly scalable and extensible systems using these abstract models.

Our approach in the Hospital Authority has been on a level of a simple Entity-Attribute-Value model (which allows you to represent anything), and to add one layer of organization (patient records & data forms), somewhat like a simpler version of CEN13606. The key here is that we are trying to represent just the patient record, and not all the administrative data and all the processes within a healthcare system. Like a classic 80-20 rule (or in this case possibly 99-1), we believe that managing the patient record efficiently and effectively gives us most of the value for a lot less complexity.

To manage the semantics we also manage both the entity definitions (LOINC-type concept) and the terminology contained in the values (SNOMED-type concept). This web of metadata is what makes the data captured in the record reusable and computable.

As you say, real world models are what count. We have been running a multiterabyte clinical record store for >90% of the 7 million citizens of Hong Kong since 2000, achieving subsecond response times and >99.99% availability. Most importantly, the model allows any new clinical data to be captured without any programming, and this data is managed from input to storage to extraction, presentation and aggregation. I would be most interested to see how this could be achieved using the complex abstract models that are floating around.

Regards

Dr Ngai-Tseung Cheung
Health Informatics
Hong Kong Hospital Authority

[thomas.beale]

Gerard Freriks wrote:

Dear all,

Let me make a statement to be proven wrong:
*The openEHR Reference Model is so generic that it can be deployed in all sectors of business's that deal with dossiers and documents.*

this might be going a little bit far - probably I would say that it is
general enough to deal with any application that has the concept of a
'record of a subject of care'. Subjects of care include:
- human beings (health)
- animals (health)
- cars (maintenance)
- buildings (maintenance)
- materials & plant assets such as water pipes, power lines, etc
- forests

In short, anything with a 'care' or 'maintenance' concept would be a
candidate.

- thomas beale

[thomas.beale]

William E Hammond wrote:

Tim,

I appreciate the response. The question is what do we do with the
alternate choices to the two level openEHR model. The HL7 RIM was never
intended to be the data model for healthcare, but a reference model. I do
think that other m,odels, including work out of CDISC (and HL7) including
the BRIDG model is useful and usuable. Also work by caBIG has value. My
question is is there any give in which we can blend efforts rather than
compete. A real world model will not come pout of an abstract model. It
will result only from and by people who are actually engaged in real world
scenarios. We need to engage those people.

Ed Hammond

Hi Ed,

I have had a look at caBIG, and my impression is that it is like a
library of atomic definitions for building reporting data sets. I
couldn't see any constraints not covered by openEHR on a cursory look.
The main difference seemed to be that there was no reference model per
se, and no larger encapsulation granularities. I wonder how we could get
quickly educated on caBIG and BRIDG in this community?

In terms of real-world models and abstract models, you may have observed
that the archetypes library is growing fast now - see
http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html
these to my mind are real-world models, and they are based on the
abstract reference model of openEHR (see e.g. the UML
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml_start_view.html)
- but it may be that you didn't mean these words in this way. In any
case, a lot of these newer archetypes are coming from NHS clinical
people, so I assume they qualify as being 'actually engaged'.

My feeling is that if good quality clinical models can be built then the
underlying reference model and machinery is functioning well. The
openEHR reference model (what you would call an information model - see
the UML above) is doing pretty well in this respect today, but it wasn't
always so - we made changes (sometime radical) for quite a few years (no
doubt driving at least some people up the wall) before the reference
model started 'working' properly. There will be some need for changes in
the future, but I expect mainly additions. Anyway, the point is that the
'abstract' part of openEHR only got to where it is today by being
heavily modified over time using the feedback of clinical modellers (not
IT methodologists). In addition, the archetype language and machinery
seem to work pretty well, having themselves been the subject of some
years of progressive refinement. There will be much more to come in this
space I am sure.

Finding common ground for all these abstract and concrete models has to
be done on the basis of requirements. What would we try to achieve?
Would a synthesis make sense for the whole world (I am inclined to think
not, as the differences between hospital-centric/distributed shared care
and transcription-based/structured input environments don't abstract
away very well in models I have seen)? Which applications should we
attempt to work on? If we say 'EHR' then we already have a world of
difference between US/non-US in the meaning of that term. If we say
'decision support' it gets a bit more precise. I'm wondering how we
would start...

- thomas beale

[Tim_Cook3 (Tim Cook)]

I think these abstract models have huge value - in commoditizing the
understanding of health care data, and in providing a framework for
interoperability. However, I am quite skeptical of the ability to
build highly scalable and extensible systems using these abstract
models.

Skepticism is a good thing. It helps to provide for worst case
scenarios.

Our approach in the Hospital Authority has been on a level of a simple
Entity-Attribute-Value model (which allows you to represent anything),
and to add one layer of organization (patient records & data forms),
somewhat like a simpler version of CEN13606. The key here is that we
are trying to represent just the patient record, and not all the
administrative data and all the processes within a healthcare system.
Like a classic 80-20 rule (or in this case possibly 99-1), we believe
that managing the patient record efficiently and effectively gives us
most of the value for a lot less complexity.

Simple is the operative word here. There are many fundamental things
wrong with the EAV approach (it is not a data model in the formal
sense). When you use the EAV approach you essentially remove typing from
your data. Lab values, prescription instructions, etc. are turned into
simple strings. You also loose the ability to manage data integrity and
data quality. While you may think you do not require re-programming you
have either not used any constraints in your application (you have
already defined that there are essentially none in the database) or you
must develop more and more intelligent queries with more and more
complex joins in order to perform any computations on the stored data.
The queries are necessarily more complex over time since attribute/value
slicing must be done to analyze the content of the generic variables and
convert strings back into their appropriate types for computing.

Think public health needs as well as longitudinal patient condition
analysis.

The scary part here is that you will (if not already) have a system that
doesn't tell you what you don't already know. Very simply; this is a
dangerous route when dealing with patient records.

To manage the semantics we also manage both the entity definitions
(LOINC-type concept) and the terminology contained in the values
(SNOMED-type concept). This web of metadata is what makes the data
captured in the record reusable and computable.

Of course I haven't seen your structure but I can guess that you have
removed the ability to do automatic updates to terminologies? Do you
have people do this manually? Or, do you mean you have your own
terminologies? In which case you can't share any data with other
entities.

As you say, real world models are what count.

Real world models that lock health care 'information' into 'data' silos
do not reveal the 'information' contained in that 'data'. The longer
this trend continues the more work that will be required to fix it
later.

We have been running a multiterabyte clinical record store for >90% of
the 7 million citizens of Hong Kong since 2000, achieving subsecond
response times and >99.99% availability. Most importantly, the model
allows *any* new clinical data to be captured without any programming,
and this data is managed from input to storage to extraction,
presentation and aggregation. I would be most interested to see how
this could be achieved using the complex abstract models that are
floating around.

I would be most interested in seeing data quality measures from your
database.

The size and response times you mention are very impressive indeed. If
you are using an EAV approach then I assume you have a staff of SQL
experts that continue to get knowledge updates from clinical staff about
what is in the database so they can provide the necessary queries when
new concepts are added? I doubt everyday users are expected to run
their own queries in this environment?

"Subsecond response times" ... Hmmmm, must have some awesome hardware.
You do realize that Moore's Law is really just an observation and not a
prediction of (long term) future trends in hardware development?

As I said earlier; skepticism is a good thing.

Cheers,
Tim

[Philippe_AMELINE]

Hi Tim,

You answered what most people involved in 2 level modeling would have said.

Of course, trying to tell somebody's health journey just filling a list
of EAV seems strange enough for us to guess that their goal is far more
limited than that.

Of course again, 2 level modeling has a price to pay in term of response
speed. But maybe we could understand the way they build an EAV from a
"genuine semantic path" as a kind of indexing.
They just need to move from EAV to EAVP by adding a pointer to the "node
in the tree" and their super-fast engine can be turned into an indexing
system for most often used queries.

Just my 2 cents.

Philippe

Tim Cook wrote:

[Tim_Cook3 (Tim Cook)]

I'm afraid this simply isn't true. EAV models don't have to remove data
typing. There's no reason why one couldn't make columns for each data
type within the primary stacked (observation) table. Additionally, well
done EAV models can have constraints, and I'd argue that they can be more
rigorous in terms of data integrity. Especially when vocabularies are
used to define both the clinical concepts and their corresponding answers.

See: http://openmrs.org/wiki/Obs_Table_Primer for one such example.

I'm afraid my statements are exactly true. While the items don't have to
be stored as strings they typically are. They could be lists, hashes,
encoded objects, etc. But the fact remains that they must be decomposed
before any computation can take place.

In your link above you describe an entity-relationship approach. A much
better approach (in my opinion). However, you have the exact issues
with schema drift that EAV was meant to avoid.

Please see:

http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pubmed&pubmedid=9824799

for information on what EAV really looks like.

> The scary part here is that you will (if not already) have a system that
> doesn't tell you what you don't already know. Very simply; this is a
> dangerous route when dealing with patient records.

This seems like a bit of an overstatement. EAV by no means is the panacea
of clinical database design, but it's far from dangerous.

I'm surprised a physician would say this. IMHO, anytime you don't know,
what you don't know; people's lives can be at risk.

  It's all about how you design it.

I'm interested in seeing your EAV design.

Regards,
Tim

"Make everything as simple as possible, but not simpler." -
  -- Albert Einstein

[Tim_Cook3 (Tim Cook)]

The misinformation in this thread led me to do a bit of Google searching
for reinforcement. Of course I have no idea what the qualifications of
the participants are but one can imagine that they are mostly DBAs at
some level.

See the short conversation at:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=57307

Cheers,
Tim

[Tim_Cook3 (Tim Cook)]

Tim, I have no intention of getting into an email argument with you. The
only reason I replied is because I believed you were using FUD to make a
point.

I didn't know we were arguing. I thought we were still are) having a
technical discussion regarding a major factor in clinical information
systems design and implementation.

There is no hard and fast definition to an EAV data model, outside
of the fact that a single piece of data is the unit of storage within a
row. See: http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

Thanks. The example used here makes my point precisely.

We can quibble re: whether you think that what I linked to before is an
EAV model, but you know what my point was.

I am not quibbling (1.an instance of the use of ambiguous,
prevaricating, or irrelevant language or arguments to evade a point at
issue.). I was merely correcting your misunderstanding of the two
different approaches.

Just because the items are
"typically strings" in most designs, doesn't mean they have to be.
Designs can be enforced that allow for a datum per row, and still maintain
datatype integrity / constraints. Most large scale repositories that
attempt EAV, that I've laid eyes on do so.

"By de facto definition"; this simply is not possible. If you have
examples that you have laid eyes on, that maintain datatype integrity /
constraints in the database, then they are NOT an EAV approach. That
would have to be done in the application or in stored procedures which
by all accounts would be part of the application code.

I suppose if there were an infinite number of datatypes to clinical
information, perhaps there would be this "schema drift" that you refer to,
but once again, I think you overstate your case a bit too strongly.

You may continue to think I over state my case or you can review a few
papers on persistence of complex data, i.e. clinical information
systems, GIS applications, etc.

I think I've missed your point. Is there a system around that "knows"
everything about patients?

Of course not. I apparently did not describe my point in enough detail.

The point is that users make assumptions about the knowledge contained
in an application. This is based on many things such as types of data
they have personally entered. When data is entered without constraints
and queries are executed based on assumptions then information can be
missed quite easily. While this seems naive on the surface it is a
reality in designs that use approaches like EAV.

> I'm interested in seeing your EAV design.

I didn't write to this list to speak on behalf of our work.

Neither was I critiquing it. I made a technical observation regarding
the information at the URL you provided. One can clearly see the
differences in the examples from your wikipedia link and the example on
the OpenMRS link. I understand it is a very good application and it's
certainly from a prestigious institution.

I did find it interesting that OpenMRS uses an abstraction approach to
reduce the complexity issues of clinical data persistence. It would
seem natural that the design team of OpenMRS would embrace the concepts
of openEHR. Just my interpretation of course.

I merely saw something I knew wasn't fully true, and I felt the need to clarify.

I'm unclear as to what part(s) of my statements are untrue. If you have
discovered factual errors on my part I would like to have them
corrected. Please validate your assertions with something a little
better than wikipedia.

If you're interested in continuing the discussion, feel free to write me
privately, as this seems to be getting off topic somewhat.

I fail to see how a discussion of the validity of various persistence
models of clinical data is off topic for these two mailing lists. I was
going to change the subject line of the thread but actually I believe
the subject I entered earlier in the thread is still the topic of this
conversation.

If other list members do not see value in our discussion then they
should feel free to speak up. On the contrary, I hope others with
expertise in this area do join in.

Cheers,
Tim

[Tim_Cook3 (Tim Cook)]

This is clearly a point where we will continue to disagree.

I believe words mean certain things and things have definitions. Maybe
my view is a little too black and white?

EAV, EAV/CR, E-R, etc. seem to me to be all 'different' approaches to
modeling application data. Apparently, you believe they are all the
same?

BTW: I wasn't 'attacking' Dr. Cheung's patient record system. But if it
is based on the approach that I believe is EAV. I am first amazed at
it's scale (and would like to know more about it) and secondly I am
concerned about the data quality.

Now if you consider it none of my business then fine. I happen to
believe that if, as a professional, I have a founded concern about
something as important as data quality in a patient record system. Then
I have a duty to mention it. If the folks in Hong Kong are happy with
their approach to insuring data quality then I am happy for them. I've
done my duty and they've done theirs.

Cheers,
Tim

[Tim_Cook3 (Tim Cook)]

Dr. Cheung,

I notice you take issue with our approach being simple. I find that
simple is usually better than complicated. Way better. Occam's Razor
comes to mind.

In the words of a modern era pragmatist;
"Everything should be made as simple as possible, but not simpler."
-Einstein

It may be hard to believe, but we have indeed constructed a tool which
lets normal users query across our multiterabyte clinical warehouse
for any concept which is captured in the system, including new
concepts as they are introduced. No programming is required to define
the data capture, the data storage, or the data retrieval.

As I said before; this is a very amazing accomplishment and you and your
team are to be commended. In view of the importance of this
accomplishment it would benefit the entire world if you could publish
your structure and some documentation on a public server. Maybe even on
SourceForge? I realize that this requires man-hours. But it would help
if everyone could emulate it. It is a shame to see so many people
reinventing something that already works so well. We could all move on
to more important things like building a tool to translate a written
clinical guideline into a computable form.

Another very important point which people often forget is that there
is a difference between building a scalable, sustainable system and
communicating between systems.

Very true. But both are important.

As I said, things like HL7V3 may be a good framework for
interoperability as information is very clearly defined. But there is
nothing presenting the HKHA - using a very simple EAV type approach -
from sending out our data in HL7V3 format.

Well, apparently I did not understand the definition(s) of the EAV
approach and there are multiple EMRs around the world using this
approach to data modeling with great success.

I just wouldn't want to build our entire system based on it.

I would want to build an entire system based on HL7V3 either.

Thanks for your reply and I look forward to reading more details about
your system.

Kind Regards,
Tim

[William_E_Hammond]

I received this and will try to get back with an answer. This group is
rather independent and is coverigna lot of ground. They are now beginning
to build structures as well.

I look for opportunities. I also have had only limited success in getting
them involved with HL7. Chris Chute is connected with them/

Ed

             Thomas Beale
             <Thomas.Beale@Oce
             anInformatics.biz To
             > For openEHR technical discussions
             Sent by: <openehr-technical@openehr.org>
             openehr-technical cc
             -bounces@openehr. AMIA CIS WG
             org <cis-wg@mailman.amia.org>
                                                                   Subject
                                       Re: [cis-wg] Complexity, killer
             03/26/2007 06:29 apps and other conundrums of
             AM health information was: cis-wg
                                       Digest, Vol 37, Issue 12 (Juliana
                                       Brixey)
             Please respond to
                For openEHR
                 technical
                discussions
             <openehr-technica
              l@openehr.org>
                                                                           
William E Hammond wrote:

Tim,

I appreciate the response. The question is what do we do with the
alternate choices to the two level openEHR model. The HL7 RIM was never
intended to be the data model for healthcare, but a reference model. I

do

think that other m,odels, including work out of CDISC (and HL7) including
the BRIDG model is useful and usuable. Also work by caBIG has value. My
question is is there any give in which we can blend efforts rather than
compete. A real world model will not come pout of an abstract model. It
will result only from and by people who are actually engaged in real

world

scenarios. We need to engage those people.

Ed Hammond

Hi Ed,

I have had a look at caBIG, and my impression is that it is like a
library of atomic definitions for building reporting data sets. I
couldn't see any constraints not covered by openEHR on a cursory look.
The main difference seemed to be that there was no reference model per
se, and no larger encapsulation granularities. I wonder how we could get
quickly educated on caBIG and BRIDG in this community?

In terms of real-world models and abstract models, you may have observed
that the archetypes library is growing fast now - see
http://svn.openehr.org/knowledge/archetypes/dev/html/en/ArchetypeMap.html
these to my mind are real-world models, and they are based on the
abstract reference model of openEHR (see e.g. the UML
http://svn.openehr.org/specification/BRANCHES/Release-1.1-candidate/publishing/architecture/computable/UML/uml_start_view.html
)
- but it may be that you didn't mean these words in this way. In any
case, a lot of these newer archetypes are coming from NHS clinical
people, so I assume they qualify as being 'actually engaged'.

My feeling is that if good quality clinical models can be built then the
underlying reference model and machinery is functioning well. The
openEHR reference model (what you would call an information model - see
the UML above) is doing pretty well in this respect today, but it wasn't
always so - we made changes (sometime radical) for quite a few years (no
doubt driving at least some people up the wall) before the reference
model started 'working' properly. There will be some need for changes in
the future, but I expect mainly additions. Anyway, the point is that the
'abstract' part of openEHR only got to where it is today by being
heavily modified over time using the feedback of clinical modellers (not
IT methodologists). In addition, the archetype language and machinery
seem to work pretty well, having themselves been the subject of some
years of progressive refinement. There will be much more to come in this
space I am sure.

Finding common ground for all these abstract and concrete models has to
be done on the basis of requirements. What would we try to achieve?
Would a synthesis make sense for the whole world (I am inclined to think
not, as the differences between hospital-centric/distributed shared care
and transcription-based/structured input environments don't abstract
away very well in models I have seen)? Which applications should we
attempt to work on? If we say 'EHR' then we already have a world of
difference between US/non-US in the meaning of that term. If we say
'decision support' it gets a bit more precise. I'm wondering how we
would start...

- thomas beale