I've talked to Nancy about the need for modularity and extensibility
for precisely the same reasons. I don't think I've ever seen two
products with non-trivial data dictionaries map cleanly to one
another on a semantic level. Even when the mappings look like they
make sense, there are always surprises once actually try to get the
two systems working together. Some people think metadata is the
answer here, and some think the answer is to have more carefully
specified ontologies. I'm not really convinced in either case.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"Before one gets the right answer, one must ask the right question."
-- S. Barry Cooper
On Jun 13, 2005, at 8:54 PM, Ken Stone wrote:
On 6/13/05, Nancy Anthracite <[EMAIL PROTECTED]> wrote:
Ken, there are a few of us looking at what can be done about
creating the CCR
from VistA data which is of particular interest because the roll-
out of
VistA-Office EHR and the release of the CCR are likely to occur at
the same
time, so that functionality within VistA-Office will be needed
quickly.
Have you taken a look at the online demo of CPRS at www.va.gov/
vista? It
would be interesting to hear from you what you think is so bad
about it after
you have "used" it a bit.
Nancy (Anthracite? Cool name!),
The thing that got me geared up (if you want to call it that) about
CCR was simultaneously learning of its pending existence and also
getting the impression that it is meant to serve as a
lowest-common-denominator standard for EHR data exchange. Which is
fine, except that not all EHRs will (or should be)
lowest-common-denominator software.
Obviously standardization is good, to the extent that standardization
can reasonably take place. But there are likely to be a lot of
interesting bits of data that physicians will be wanting to keep track
of someday, many of them not yet even known or invented yet, which is
presumably why everybody in the past wanted to "go play king of the
hill in their separate pigeonholes." As future generations of EHRs
get developed and refined, it would be nice if the old standard for
EHR portability could keep up, and do so in a way that would allow
intelligent programs to adequately encode and (if appropriately
programmed/kept up to date) decode every last possible bit of
information that's meant to be in an EHR. By the fact that people
around here are talking about using XML to encode EHR data, it seems
clear that a number of other people are already well-aware of both the
problem and the general approach that I would have proposed to solve
it.
The only thing I've got to add (or rather, ask) is: does the proposed
CCR standard currently contain standardized fields to allow (a) easy
automatic recognition of the encoding software product (and version),
and (b) easy automatic recognition of the CCR version itself (assuming
possible future refinements of the CCR standard)? If so, then I think
there are sufficient escape hatches built in such that the advocates
of "just go ahead and release the standard already" could be forgiven
their impatience.
-K
(p.s. As to looking at CPRS--maybe after exams. Not right now...)
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can
you shotput
a projector? How fast can you ride your desk chair down the office
luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
