"Robert R. Hausam" wrote:
>
> As a physician, I agree with Thomas's comments. See additional comments below.
>
> At 11:46 AM 1/24/2000 +1000, you wrote:
>
> >"John S. Gage" wrote:
> >
> > > Brian Bray wrote:
> > > >
> > > > The more I think about EMR, the more I think of a document for each
> > > > patient. No database or middleware needed ;-)
> >
> >Well, except for:
> >
> >- physician access (as noted by John)
> >- administrative access
> >- data filtering, querying and searching
> >- security, encryption
> >- visual filtering
> >- multimedia
> >- automated processing of populations of records
>
> I might also add:
>
> - real-time clinical decision support (typically rule-based systems -
> generally requires structured data and use of a controlled vocabulary)
> - recalls and reminders (probably subsumed in a couple of the categories above)
>
> There are probably others, but these lists likely cover most of the major
> categories.
>
The little winking smiley face ";-)" (turn your head to the left 90
degrees) usually indicates a joke or in this case, a tongue in cheek
comment.
Even if you conceive of medical records as documents, you are going to
want to index them (ie: use a database) and you if you are accessing
them from a distance, you will want to be able to request selected
portions only (ie: have some middleware).
Also, no EMR exists in isolation. Doctors want to get paid, so they
need to codify things and handle financial transactions. There is no
"magic bullet" that's going to eliminate databases and middleware from
our lives.
I'm surprised, however, at the reaction to the document concept. This
is not new -- my understanding is that there are are number of groups
(including one in HL7) that have been working on SGML document type
definitions for medical information for years now.
Consider the same reasoning in an accounting context. There are even
stronger arguments that all accounting data should be kept in
databases. But accountants have a document format -- the speadsheet.
It's easily transmittable. There are a lot of tools for dealing with
speadsheets. It's conceptually simple. It's flexible enough for an
extremely wide range of accounting needs. You would be foolish to try
and store the accounts receivable for a major corporation in a
speadsheet, but you would be equally foolish to write a custom database
application to do a small budget. Each tool has it's use.
When I say documents, I'm not talking about a simple text file !
I'm really thinking about a structured XML document meeting a standard
for medical records. This type of document can contain codified values,
pictures, special processing code, etc. Really, it's a way of encoding
object instances in a portable and durable format. What things would it
be good at?
1) Transmission.
2) Long term storage. The format can be stable over a very long time
frame. The format can be read manually with a simple text editor. Some
information can be extracted from partial records. It is self
documenting to some extent and contains or links to it's formal
definition.
3) Interface to legacy systems. The format is trivial to generate and
relatively simple to input. There is widely available source code for
doing this.
4) Universal viewing. There are an increasing number of tools that
could view records in this format -- Browsers and major word processors
are among this number.
5) Good match to the problem domain. I can see how someone in an
accountants office could believe that the whole world could be modelled
with tables containing rows and columns, but how can you look at a
medical chart like this? XML is a natural fit with the object models
now being developed in health care.
6) Widespread tools. In addition to viewing, there are an increasing
number of tools to do other things with XML documents. This includes a
query language, transformation tools, format conversions, large scale
storage and management tools, etc.
7) Standarized APIs. DOM is the standard. According to earlier mail on
this list, Corbamed COAS is related.
8) Robustness, transparency, and conceptual simplicy. Documents are
easy to understand. There is a direct correspondence to the paper
world.
9) Simple load distribution and easy to understand security.
What about the supposed drawbacks? I'll concede that some of them are
valid if the documents are literally stored as separate files in a
directory. But even then it really depends on the number of records
you've got and what you are trying to accomplish. A small family
practice is probably doable this way.
Physician access: I suggest that a file you can read with Micosoft Word
or Netscape is way more accessible to physicians than an object or
relational database. A system that could produce such records gives
physicians a lot more real control over their data. Regardless of how
the documents are stored, I suggest that the "document per patient"
model is how most physicians really think and work. It's certainly how
the paper world works.
Administrative access: Please tell me why this is harder?
Data filtering, querying and searching: Have indices. Filtering is
easy and fast in this format.
Security, encryption: Simple security is easier (encrypt the files).
More complex security models end up moving the data into a database.
Thinking of it as a set of documents and presenting that logical view to
users, is still valuable.
Visual filtering. XML separates information and its structure from how
it is presented. It is perfectly conceivable to have multiple views of
the record and to have specialized views for specific parts of the
record.
Multimedia. XML is a net technology. It's already light years ahead of
most database systems at multimedia. Links to other systems are
possible.
Automated processing of populations of records. Simple things go a long
way with smaller data sets. I have 15,000 files -- about 800Meg -- in
my home directory -- about 60,000 bytes per file. I can find all the
files that changed in the last day in a few seconds (less than 5). I
can read them all and do some processing (line count) in under a
minute. How much processing of record populations is done in a family
practice?
- real-time clinical decision support. No problem here. In fact, a
common structured file format would make rules and rule processing
systems *way* more transportable than at present. From everything I've
seen rules are either very specific to a single system or have some
"mapping" definitions that may or may not match the actual data model.
- recalls and reminders. I'd add billing, scheduling, orders, payroll,
... There are lots of things beyond the medical record.
As a thought experiment this is an interesting model. All of the other
proposals I've seen have drawbacks against this simple scheme for some
uses. The biggest one is that we are often creating records to last a
lifetime and then storing them on a hard disk in physical formats that
are largely undocumented and have no expectations of durability. The
second one is that every system is monolithic and an island -- wouldn't
it be nice to have a set of modular tools that could be applied in more
than one context.
-Brian
