kuang oon wrote:
While going troppo the past 2 weeks....I managed an occasional
peep at
the traffic at GPCG talk. I had the following thoughts ...
The many issues on this list about coding, messaging and ehr boils
down to one i.e. level 4 interoperability amongst systems / common
API
for medical systems - systems need to ‘talk’ to one another
seamlessly.
I don't think that there needs to be a common API (and there never
will
be). Systems do need to have the ability to exchange information with
other systems using shared syntactic and semantic standards. In
addition, there are many instances in which one system needs to be
able
to cause an action to happen on another system - that is, the
ability to
do remote procedure calls. Theses days these are done by SOAP and
other
Web service standards, which is a shame, because CORBA had it all
worked
out in a much better fashion a decade earlier, but alas never
caught on
(some say it worked rather too well and frightened all the software
vendors). [*]
This quality communication leads presumably to quality healthcare.
That is indeed the presumption. At this stage it is unknown how often
and to what degree it is true, and in what circumstances. In health
informatics circles, it tends to be an article of faith, though, and
there are often good common-sense reasons to believe it. But as we all
know, faith can be misplaced and common sense is sometimes wrong.
There is a similar presumption regarding efficiency gains (as distinct
from "quality" gains). However, most would regard those involving less
of a leap of faith.
The conventional wisdom to achieve this is by the bottoms up
approach
of...1)enforced standardization of data representation of health data
2)enforced standardization of real/virtual medical record
architecture before we hit the nirvana of level 4 system
interoperability.
If these were enforced, then it would not be a bottoms (sic) up
approach, would it?
It is an illusion that a single national enumerated coding system for
health concepts will solve the level 4 interoperability problem.
Proof:
all hospitals in Oz use ICD10AM, yet level 4 interoperability of EHR
across all hospitals is a pipe dream.
Sorry, no proof. Hospitals use ICD10AM to *classify* a small number of
diagnoses only, at patient discharge, purely for administrative and
hospital management purposes (eg tracking activity in hospitals) -
*not*
for clinical purposes (sometimes for secondary epidemiological and
health services research use, but such uses are problematic).
Procedures
are also coded, essentially using the MBS codes - which as a
classification is a dogs breakfast and is very hard to use. Again only
for administrative and health system management, not for clinical
management purposes.
There is no widespread encoding of clinical information in Australian
public sector hospitals for clinical purposes. If there were, ICD10AM
would be a very bad choice for such primary encoding of clinical
information. All that may change with the investments in shared
EHRs and
within hospitals, in shared EMRs. But the changes will take a long
time
- the good part of a decade - and a universally available clinical
coding system/terminology is needed first, as is more R&D in how to
best
use it in clinical settings - hence Jon Patrick's appearance on this
list (and elsewhere).
We have our knickers in knotted forms relying on the above
conventional
wisdom for the past 20 years and may continue to do so if we persist.
A possible solution is to invert the whole process. What we need
is a
grail health protocol that gives us level 4 interoperability from the
top in the first place and let systems adapt downstream.
You've been reading Dan Brown, haven't you Kuangie? Or watching old
Monty Python movies? I'd recommend the latter over the former...
Some thoughts on this "Grail" health protocol....
Ideally...
1)A unified protocol that does any and more of the following
messaging
tasks - consultation, medications, problem summary,lab, radiology
messaging,inter-physician communication, process-process
communication
- with level 4 interoperability as well as perform the role of a
universal programmatic health API. Unfettered medical story telling.
2)Uncoupled from any past or current or future coding systems
(zero-referencing to coding system;coding system obsolescence proof).
Transcending the current issues of hospital/gp coding
mismatch/inability to communicate at level 4.
3)Uncoupled from any EHR architectures/knowledge representation
framework or systems (knowledge/ ehr architecture obsolence proof).
4)The level 4 grail message can be standalone or embedded( as a
mix-in)
in any current or future messaging protocol/email
5)This grail protocol leaves completely intact the intellectual
investment in the software of all the current and future players
in the
Australian medical software scene without major or significant
retooling/changes to schema.
Is this the grail yet? ... or someone please tell me that I have been
getting too much sun.
what? our medical informatics interoperability infrastructure sucks
why? too focused on bottom up approaches, too focused on medical
coding,
too many codes for this and codes for that, too much premature
optimization of data representation of record architecture, too many
jigsaw pieces, too many complicated fixes -the 'herding cats'
metaphor
is apt.
how? New thinking. Simplify from the top - start with a grail
solution
with Level 4 interoperability, begin with the end in sight.
who? possibly SHEEP, simple health electronic exchange protocol -
lets
move form 'herding cats' to 'counting SHEEP' (...or 'riding on the
SHEEP's back' is not too bad).
when? Now. A timely homegrown solution for a pressing problem, the
solution interoperable with any outcome of the international
jigsaw fest.
What, you're not going to tell us what you have in mind as this Grail?
Tim C
[*] Exchanging information and causing actions to happen on remote
system both presuppose one other bit of universal (or at least
universally interoperable) infrastructure - that of party
identification
and authentication. Both for health care providers (in the first
instance) and patients (soon after). And no, HeSA is not a viable
solution here (although some other PKI or PKIs with broader aims
might be).
TC
On 18/01/2006, at 12:05 PM, Tim Churches wrote:
Dr Hugh Nelson <[EMAIL PROTECTED]> wrote:
Isn't this all moot now? It seems that SnowmedCT is going to
sweep all
before it?
SNOMED CT is one means of encoding *semantic* content. But we still
need means of organising this semantic content in standardised and
useful ways - the syntax problem. That's what HL7 and XML-based
messaging standards etc address. openEHR does too, but also
recognises
that syntax without semantics (and v-v) is worth much.
I can't imagine that all this work on SCT has been done without
having
standards for message or record exchange.
There is a lot of truth in Wallace's Observation: Everything is in a
state of utter dishevelment.
Tim C
[EMAIL PROTECTED] wrote:
Quoting Les Ferguson <[EMAIL PROTECTED]>:
I know several of you strongly desire open standards and data
import/export capabilities, but does anybody actually know of a
standard
for sharing patient records between PMS systems?
My preference is for an XML schema, rather than HL7. I also need
something modern that other vendors may incorporate, or
already use.
Any recommendations for a EHR standard, local or otherwise,
that is
likely to be implemented by Australasian PMS vendors?
It appears there is none, other than HL7.
I'd encourage you to consider defining one yourselves, this would
become the
standard.
In the short term the commerical benefit is zero (as it would
be even
if there
were a standard): the main use of the
feature would be to make it easier for practices to move from
MedTech
to
another product. However in the long term, as the market
matures, it's
a plus:
users and potential users of MedTech can feel more confident
knowing
they can
preserve their data.
Think hard about XML, please try to look beyond buzzword value.
There are alternatives which could be programmatically easier,
such as
YAML
(www.yaml.org).
Consider relasing the basic (i.e non-MedTech-specific) parts of
code
under
a liberal licence (such as the BSD licence,
http://www.opensource.org/licenses/bsd-license.php) for the purely
pragmatic reason that it will make it easier (and so more
likely) for
other
vendors to implement.
Ian Haywood
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
