WVC Meeting Action Items
Dennis Ballance
the phone connection - it seemed impossible to have both the phone
input and the microphone input enabled at the same time.
Nevertheless, the call-in audience was able to participate and added
valuable contributions to the overall meeting.
I have done a considerable amount of collaborative research over the
past month since the initial VetXML meeting in Orlando. The
consequences of that research are that (a) there is general agreement
that data exchange standards are sorely lacking in Vet Med, (b) there
is broad interest in adopting or building standards, and (c) the
veterinary profession by itself does not have the resources to build
to fit its own needs, so leveraging existing standards is essential.
The sticking points that came up were:
(a) is IHE the only standards-agnostic body worth considering for
this role (HIBCC was proposed as an alternative),
(b) is there a clear definition of the problems that standards would
be trying to solve, and
(c) what is the proposed scope definition of a veterinary domain
organization?
The next face-to-face meeting will be at AVMA. Would someone like to
step up to sponsor a room for this? (If nobody volunteers, I'll start
picking on individuals...!)
In the meantime, I will begin working on these, but any additional
research, especially on A and B, would be appreciated.
Dennis
Michael K. Martin
what level of interoperability we need. I've posted an essay on this to
my blog mminformatics.com along with a comment of my own added after
yesterday's call.
Basically I think that if we will ever need true semantic
interoperability then we need to invest the effort to use the work that
has gone into existing standards and use some mechanism like IHE to help
coordinate them. If all we need is functional interoperability (more or
less getting strings of text in a format that can be placed in the right
boxes on a human-readable form) then all this standards stuff may be
overkill. We may actually be better off just defining an ad-hoc set of
XML tags and going with that. We've seen from VetXML/VetEnvoy how
powerful that can be. They are absolutely right that this approach is
much more efficient at what it does if that is all that is needed. On
the other hand, if we go too far down that path, it may be very hard or
impossible to go back and add significant semantic content.
I think you all know which side I put myself on, especially considering
my day job as an epidemiologist, but we as a profession need to come to
some consensus on this basic question before the answers to the rest
will make any sense. So, please think very hard about question b) in
Dennis's post. I think that will drive questions a) and c).
Mike
> .
>
>
--
Michael K. Martin, DVM, MPH, DACVPM
Clemson Livestock Poultry Health
PO Box 102406
Columbia, SC 29224-2406
email: mma...@clemson.edu
personal email: michael.mar...@gmail.com
phone: (803) 788-2260 ext 230
work cell: (803)312-1439 (no personal calls)
personal cell: (803)348-1879 (no work calls)
fax: (803) 736-0885
About the age of fifty the elasticity of the
mental processes on which treatment depends
is, as a rule, lacking. Old people are no
longer educable.
SIGMUND FREUD
(My age: 53 So please forgive my
mental issues.)
Dr James Young
be trying to solve") is the most fundamental issue at hand. Along with that point, as Mike points out the question of "what is driving the initiative".
Dr James Young
President - Atlantic Street Veterinary Hospital Pet Emergency Center
1100 Atlantic Street
Roseville, CA 95678
www.erpetdoctor.com
jyo...@erpetdoctor.com
Michael K. Martin
I believe you are right that population/public health is the main driver of semantic interoperability. That usually means government either paying for or requiring something. So, the stimulus package includes features to pay for some semantic interoperability (meaningful use is the catch phrase) in human EMRs. On the veterinary side, USDA is requiring standard messaging of laboratory data to get paid as a NAHLN laboratory doing national surveillance testing. But we don't have anything like that for veterinary medicine as a whole.
If there was sufficient demand by clients for "personal health records" that could be imported by any PMS/EHR system then you'd have a key requirement that needed semantic interoperability and that someone--the clients--were willing to pay for.
As much as we all consider ourselves to be "good people" these things are too hard to have happen just because they are "the right thing to do."
Mike
Dr James Young
Dennis Ballance
We've already agreed that it makes sense to separate "creation/definition" (SNOMED, HL7, VetXML) from "selection" (IHE), keeping in mind that these two types of entities work as collaborators, not in a parent-child relationship. The focus of IHE is to solve workflow problems related to health data. It makes no provisions (in its current form) for insurance claim processing, product registration, or product catalogues. Similarly, it also tends to stay away from terminology subsets.
Therefore, I believe we need to draw lines between terminology, health data transfer, and product/insurance data transfer. This will have two effects - it will simplify the process of compromising on a priority sequence for problems to resolve, and it will divide the already-small community of interested participants into three groups. This division is not necessarily a bad thing as the groups have completely different focuses with minimal overlap, but it does further emphasize the need to leverage existing standards over building anew.
This conclusion also resolves one of my action items. HIBCC may be a great fit for the product/insurance set, but IHE is clearly the best fit for health data, which is my area of focus. It does not resolve the action item of defining the problem list. Doing that will help clarify if, in fact, a Veterinary domain is even necessary, or if IHE profiles could be implemented "as is" within the veterinary space.
By the way -- my strong support for the IHE approach comes because I have backed into it as the only viable option for health data workflow management. I have no illusions that it will be easy, or that it has all the answers; but, it offers more to our resource-constrained profession than any other approach I have seen. My hope is that you, the reader, find my logic and conclusions to be accurate. And, of course, that if there are flaws or omissions in my conclusions, that you will identify them for me.
Dennis
Julie Green
methods in the three groups you have teased out, Dennis. I would
offer what I think is an important caveat (or maybe caution in a
better word)...
First, terminology is DEFINITELY different than the other two. It is
a tool by which the other two ensure consistency in meaning and
interoperability amongst themselves. It is a "tie that binds" so to
speak. There is danger in complete separation, in that if these
"groups" diverge then they cease to work together and cause
frustration for those who are trying to implement them all. How would
users/vendors/etc respond if both insurance systems and medical data
transfer systems both decide to transmit diagnosis...only the two use
different approaches (maybe one using precoordinated SNOMED concepts
for the full diagnosis, and the other using internal vocabularies to
"build" a diagnosis)? In that hypothetical, a single system could/
would need to handle the same diagnosis with two different terminology
systems. So while insurance systems (which incidentally DO want to
transmit medical data...so they are not COMPLETELY different than
health data transfer systems...the line has some blurry sections) and
health data transfer systems can develop orthogonal to each other,
they MUST stay connected and aware of each other...and BOTH must deal
with terminology, hopefully in the same way.
And secondly, the other two (insurance/billing and health data
transfer) must maintain semantic interoperability. The centerpiece of
semantic interoperability is the information model (terminology a
close second). If they are inherently based on information models
that are not aligned, then there's no way to move between the two for
systems that must do both. An example (seen elsewhere in the group
postings I believe): A large laboratory entity sends an HL7 message
that reports a lab value + low end of range + high end of range (three
tagged values)...another popular veterinary standards group develops
an XML messsage that reports a lab value + range (as two tagged
values). How do you reconcile the two? The one sent as a range
cannot be used to "calculate" without intermediate processing. The
builders of the range message might not care that they couldn't
calculate with it because they haven't encountered the need for it.
However, if they were trying to comply with an information model that
made clear the need for it, then it would be apparent to them that
processing rules would be needed.
So yes, in the practical…what is the message that we send..the two can
be separate. But if there is no common information model for the two
to work from, then you are likely to get divergence that will spell
failure.
Dennis Ballance
Good points.
A practical example of what you describe is the idea of microchip registration. I am confident that there are industry standards for associating RFID tag values with other demographic information (HIBC may well be one). For microchips specifically, IHE has no workflow defined that deals with its needs, yet microchip registrars want species and breed information to be included, so both need to leverage a common terminology.
The challenge is that I don't expect us to change the scope of IHE by bringing product registration into the portfolio, but at the same time I would really want to see product registration leverage the work of health SDOs in selecting interoperable terminology.
Any ideas on some ways to solve this?
Dennis
> --
> To unsubscribe from this group, send email to
> veterinary-health-it-...@googlegroups.com or visit
> http://groups.google.com/group/veterinary-health-it-standards?hl=en
Michael K. Martin
I don't see microchip registration being as far from IHE's mission as it
seems. This is very comparable to the kind of work I was doing on
Master Person Indexes when I was with CHA. Given the permanent failure
to create a universal patient identifier on the human side, there is
going to be a growing need for services that aggregate identifiers of
various types and provide patient-linking. Microchip registration is a
subset of that domain. If IHE isn't playing in the MPI domain, I'll bet
they will be soon.
Mike
>> So yes, in the practical�what is the message that we send..the two can
>> be separate. But if there is no common information model for the two
>> to work from, then you are likely to get divergence that will spell
>> failure.
>>
>>
>>
>>
>>
>>
>> --
>> To unsubscribe from this group, send email to
>> veterinary-health-it-...@googlegroups.com or visit
>> http://groups.google.com/group/veterinary-health-it-standards?hl=en
>>
>
--
Dennis Ballance
Fair enough. Would Insurance claims fit the example better, or do they also fall into the category with microchips of "likely soon to be in the domain"?
Dennis
>>> So yes, in the practical…what is the message that we send..the two can
Michael K. Martin
I'm not sure about insurance. On the human side it varies so much from
country to country that it is hard to get very far with international
standards. In the U.S. insurance claims are usually transmitted using
X12 and--since HIPAA came along--with the more clinical information
"claims attachments" in embedded HL7. I think the details were worked
out directly in negotiations between CMS and X12. So my guess would be
IHE won't do as much there on the human side.
Mike
>>>> So yes, in the practical�what is the message that we send..the two can
Dave Harvey
I agree! IHE does already have an "MPI" profile, but has chosen to tall
it "PIX" - patient identity cross-referencing (I know, as I've been busy
implementing it today!) Put simply, it provides a standardised
mechanism (where the data is available of course!) to do queries from
one identification domain to another. In the human world, this is (in
most countries) to/from a national identity service (e.g. our NHS
numbers in the UK), so use to map between local system patient IDs and
microchip IDs would (at a pure technical level) function straight "out
of the box". I'm sure that some tweaking would be necessary for
veterinary work, but it certainly would be worth considering PIX as a
starting point for vet use.
Dave
> >> So yes, in the practical...what is the message that we send..the
Heidi
Sorry I have been lurking only until now but glad to see such
lively discussion. I'll take a swing at addressing Dennis' original
concern b): " what "problems" do we face that need answering,
ostensibly by standardization? (And, like Julie, I do believe we will
need both standardization of what specific info is transferred as well
as how it is transferred, or we will indeed head down a dead-end
alley. I LOVED Dr. Martin's helpful analogy during the Jan t-
conference...Thanks, Mike.)
The ultimate problem we must solve is: We need data to help us
learn better ways to recognize and treat (and obviously prevent)
disease and injury. This means we need disease incidence, structured
info about treatment options, and follow-up about responses. For those
of us in practice who have ever tried to attain a state of clinical
"Evidence-backed" nirvana, this is nigh impossible. I am delighted
when I even find a study that address a sought-after condition in
something other than a bizarro strain of mouse! We are not even within
view of the "asymptote"-- we are lucky enough to have just left a
baseline of no data, thanks to readily available NLH searches, helpful
medical librarians, and other tech tools. Will the numbers ($$)
support it? Eventually, yes. But that eventually is a lonnnggg way
off. Will business-minded drivers push this? Yes, and I agree it will
have a management "spin" to the solution. Even so, we oughtn't bash
insurance providers and the management and accountant types; they help
provide the $$ all these lofty goals and altruism need. But
practitioners better sit actively and patiently at the table during
development or they'll have no right to complain about how data
interoperability manifests.
The limited reports (and approaching, but sadly not always _hard_
business science either) I have read in AMIA articles show debatable
value at the present in all-digital data systems, however, that is
because much like fax machines, not everyone has these yet and our
"culture" hasn't gotten comfy enough with digital modalities of info
exchange. Younger generations are, and things will improve. So will
interfaces. We are still struggling with lab result summary charts
that read right to left (Epic Systems, used by an oncologist friend of
mine) and other minutiae that impedes workflow. Until these are
optimized, minutes, dollars, and lives will be wasted, and that will
make people rationalize, "Why should we push so hard for this?" But we
here are Google-groupies because we have sipped the KoolAid.
As far as detailed problems we need to solve, they are as numerous
as a cloud of gnats. Sub-clouds include:
1.Medical record content consistency, such that any
practitioner anywhere can carry on care at any point within a patient
encounter seamlessly
2. Large-"n" Information should be available at the point of
need to help scientists and practitioners make evidence-based
decisions, AND the outcomes of these decisions must be easily added to
the body of knowledge
3. This must happen with efficiency (minimal keystrokes or
actions).
Those are some big categories. Smaller sub-needs can be listed. These
could form a basis for various work-groups that can interface with one
another as needed to assure compatibility with solutions each
develops. These groups can and should operate under one collaborative
effort, but don't have to be joined at the hip. Folks in have
interests and expertise that can be devoted to one or a few work-
groups, as they or their employer prioritizes. These were outlined in
broad strokes at the AAHA SWvendor summit last spring,
A. Medical records standardization (content and terminology
both) breeds, microchip ID and other demographics, procedures,
problems/diagnoses, etc
B. Diagnostic equipment interoperability (includes big
subgroups: imaging, reference lab, and in-house data sources)
C. Management standardization (inventory handling, staff
efficiency, workflow enhancement, how many IVPs have been performed by
various docs, e.g.)
D. Insurance communications (if a dedicated category for this is
yet warranted by our insurance needs here in N America)
E. Epidemiologic database contributions (how and what data
should be added to "the body of knowledge" and what that "body" looks
like
My personal vote: A "Veterinary Informatics Standardization
Stewardship" or trusteeship can and should be _one_ group with sub-
work groups focused on specific sub-tasks. What it is "called" matters
not. What it _does_, does.
Dennis, were these the kinds of "problems" we needed to outline or
more specific ones? Heidi
·
Matt Wright DVM DACVR www.animalinsides.com
Julie Green
believe that our problem is larger and more complex than just “pick
the standards and implement them”, which is what the human side of
things gets to do.
I won’t argue for or against IHE, but will remind that IHE is NOT a
health SDO. IHTSDO is the SDO that develops the terminology standard
SNOMED…Regenstrief is the SDO that develops the terminology standard
LOINC, HL7 is the SDO that develops the HL7 RIM (and all its other
parts and pieces). IHE is a framework for users/developers/
stakeholders to use in selecting and implementing existing standards
for use in specific situations. It’s one step removed from standards
development, it’s a path for standards implementation. And this is
working for the human side of things b/c the standards development is
happening elsewhere. HL7, SNOMED, LOINC etc are developed primarily
with human implementation in mind. While they are all OPEN to
veterinary medicine, and in fact are the only ones including any
veterinary content; they are still in need of a lot of development and
testing before “just pick and work out implementation” will work. The
existing standards need to be made functional and responsive and
curated to the needs of veterinary medicine. If the existing
standards fit all of our needs, we’d already be using them. A example
commonly brought up is the “species/breed” problem. Human records,
and therefore human oriented standards don’t need to collect the
taxonomy of their patient, we do. This meant that we needed a place
in the messaging standards to carry it and a terminology to convey
it. In fact, this work has been done… The NAHLN implementation of
the HL7 ORU message does in fact capture taxonomy in the PID segment
of the message…this can be expanded to other areas in the same way.
We have developed the taxonomy within SNOMED CT needed to capture not
only true Linnean taxonomy, but also have developed a way to cope with
common groupings such as ducks, deer, cattle, etc. This new content
lives within the Veterinary Adaptation of SNOMED CT that we have
developed as an extension to SNOMED CT core.
IHE might give us the tools to organize meetings and discussions about
the domain knowledge (what are the problems, ideas for solving them)
needed for making necessary modifications, but that’s not enough.
There has to be a body of people to do the work. Continuing the
example of the taxonomy issues… Working out the problem and talking
through a potential solution was the easy job. The terminology alone
took us almost 2 years, as we had to piece together money to pay
people to do the work of researching and creating the content (tens of
thousands of concepts). There will be MANY other areas like this,
where there will be vital areas that need to be changed and
terminology that needs to be developed before systems can effectively
implement the standards, and if we don’t have the manpower, the work
won’t get done.
I believe that the right solution is based on development of an
information model that covers areas of need for veterinary information
systems, preferably starting with an existing information model (like
HL7’s RIM) and modifying it as needed to carry veterinary
information. Once you have an information model, then you choose and
develop messages and terminologies. Once those have been adopted as
industry standards, then people can base their messages, system
structures, whatever they need on these standards and be
interoperable. It doesn’t matter if it’s product registration or
insurance claims or health records or whatever…if we’ve defined in the
information model how taxonomy should be represented, any of those can
use that structure and be interoperable.
And as Heidi pointed out, what we need is a formal organization for
veterinary stakeholders to learn about and modify existing information
models (such as the HL7 RIM) to the specific needs of veterinary
information, and the pooled resources to hire those that have the
knowledge in these areas. I don’t KNOW if IHE is the right place for
that, as I don’t know their scope, rules, guidelines etc. But I do
know that it is hard and complicated and time consuming etc to get
solutions robust enough to accommodate all situations…that’s why HL7
and SNOMED are so big and so difficult. Call it what you want (we’ve
called it National Veterinary Information Standards Consortium in
proposals we’ve attempted to farm around the government, Gates
foundation, etc etc etc), but getting this done will require a lot of
manpower. Human medicine has the advantage of having money in the
industry so that people can be paid salaries by their hospital/vendor/
wherever and be allowed to “volunteer” their time. Veterinarians
don’t generally have that luxury. Using myself as an example, because
I am employed by the university on “soft money” (meaning not a
university paid, state funded job, but funded on grants), there are
very strict rules on what I can and can’t do. My time has to be
allocated to the grant that I’m on. In fact right now I’m funded by a
single grant, so the university won’t let me do ANYTHING but work on
that project. I can’t even serve on a graduate committee. So I CAN’T
“volunteer”… “Volunteerism” only works if you have someone willing to
pay people salaries while they do this. This is too much work to be
accomplished “nights and weekends”. If we have the interest now so
that organizations/vendors/charitable foundations/governments etc are
ready to invest money into a not-for-profit organization that can
organize the discussions among stakeholders (or use IHE for such) and
hire people to do the work that needs to be done (guided by the
discussions and decisions made by stakeholder meetings like those that
happen in IHE work)…then this standards thing might actually happen
for veterinary medicine.
Julie Green, DVM, MS
Veterinary Terminology Services Laboratory
VRMCVM - Virginia Tech
Dennis Ballance
Thanks for this information. You have both clearly put a lot of thought into this.
I see two distinct needs - to define the content/information models, and to define the way that information is moved around. Frankly, the ideal situation is to have working groups in each of the major SDOs as well as IHE. IHE came into being because the SDOs themselves couldn't solve the workflow problems, and I think we would face the same lack of adoption if we focus on developing content without also exploring and defining the workflows. An overarching veterinary organization would be great, actually. If an IHE domain forms, then it has the VTSL to collaborate on SNOMED issues (sort-of), and the DICOM WG 25 to collaborate on DICOM issues, but a master org could provide a place for participants in all of these groups to come together. I also agree that it doesn't matter what it's called, because it'll be the same collection of people regardless.
Another need that this master org could fill would be to gather and distribute funding for standards activity. It could also be the curator of things like terminology subsets, or ultimately the VTSL domain extensions.
I do think it is important to establish official working relationships within the various human orgs, because without that we have no way to integrate changes other than to beg and plead human-centric folks. DICOM and VTSL have demonstrated the value of direct involvement.
So, how about we pursue these in parallel?
Dennis
Jeff Wilcke
The two missions (standards development and workflow development) must
happen in parallel. Further, there must be interaction and mutual
respect for each other's constraints and needs. We have to recognize
that "standards" and "workflow" are difficult, complicated
undertakings (this isn't rocket science, doing it correctly is
harder). Veterinary medicine has one other special limitation
compared to our human counterparts - desperately limited manpower.
We're trying to find a simplified veterinary path through an
interdependent web of standards and workflow problems.
You are absolutely right that a VERY important need that a master
organization could fill would be to gather and distribute funding for
standards activity. In fact, that might be the PRIMARY function/need
for a master organization. And that just might be the one thing that
would help ensure that this whole effort could be a success. A master
not-for-profit organization with the moral and financial support from
groups like AVMA, AAHA, AAVLD, vendors, USDA, FDACVM, etc, etc, etc
(the broader based the better) staffed with people who know how to
find, manage and distribute funding might provide the political and
financial support that is crucial. The essential funding problem is
that no one segment of veterinary medicine needs all of ANY standard,
but the standards must be robust (able to accommodate all species for
some applications, able to accommodate all specialty practice segments
in others) if they are to work for any of us. As usual the major
questions...who, where and how much $$
As you all know, to this point our (VTSL) primary focus has been
development of SNOMED for veterinary application, but we have also had
experience with HL7 and LOINC as well). If adequate startup funding
could be secured ($5million/$10million?? - an endowment might be best,
but any organization that forms would still be a grant-getting
organization), we would be willing to work towards morphing our
organization to suit the broader purpose. Essentially we would
convert our university lab into a not-for-profit (would require
concessions and buy-in from our university at several levels - but we
already live in corporate space), expand our scope and take over costs
that are currently supported through university overhead. Obviously,
there would be many administrative details to work out (boards of
directors, administrators, geek squad support, etc.). I believe we
CAN do it and we've intended to do it. We have been unsuccessful, so
far, at finding the funding (list of doors already knocked on,
available upon request). Anyone have a buddy at Google? :-) Anybody
treat a dog owned by anybody at Google? :-)
Oh, and one more thought... we need to remember to train those that
wish to adopt the standards and we must also train the next generation
of “standard bearers.”
-Jeff
> ...
>
> read more »
Jeff Wilcke
-Jeff