This could be a huge mistake!
MikeG
issues with HIEs and state-wide efforts. By allowing this simplistic
one-to-one communications NHIN Direct allows providers to take the
easy road to both Meaningful Use and data communications. This is not
a good thing. Making data more useful for everyone requires some heavy
lifting in the use of standards data formats, data semantics and data
paths through a central hub that can intercept data for exchange. I
attended the session at HIMSS and asked this question and the answer I
got was completely naive. They suggested that there are some simple
use cases that can be solved with this solution and that it can
integrate with state-wide efforts. However once the genie is out of
the bottle providers are going to push to allow more transactions and
the logical conclusion is that we will have created a giant point-to-
point network that will make HIE much harder. I have more to learn
about this project but so far I think it is a mistake!
will ross
conclusion, that this type of breakthrough is urgently needed for
several reasons. 1. the AHIC use cases are deeply flawed. 2. AHIC and
the current NHIN specs are "pull" only. 3. we need a "push"
solution. 4. we need a "publish/subscribe" solution. 5. waiting for
semantic interoperability will take too long, patients are dying now.
6. push/pull/pub-sub all need to be supported, and message routing
will fail if there is no appropriate health message DNS. 7. privacy
and security issues for health data are non-trivial, but are best
solved by an open process such as this. 8. this process is ideally
complementary to CONNECT, which is dramatically simplifying endpoint
complexity for NHIN participation. [wr]
- - - - - - - -
MikeG
the capabilities of NHIN Direct
it is with how it is being implemented. I am helping design the
Michigan Health Information Network (MiHIN) and
we are planning all the use cases described under NHIN Direct within
the MiHIN. We plan to do "push" messaging,
publish/subscribe, security services and pull technologies. If NHIN
Direct gives our providers an easy way to simply
"check the box" for Meaningful Use by bypassing the MiHIN this could
be a problem. Let me give you an example, if a reference lab
reports a result to a provider that we want to track for
biosurveillance I do not have access to it from NHIN Direct. But if
this
same result went through the MiHIN I could flag this and capture the
information for this purpose.
Arien Malec
I think there's a category confusion here. The NHIN Direct effort is
to provide the standards and services descriptions for the push model
of communication. Multiple organizations will enable those standards
and services, and I would expect that MiHIN would be one of those
enabling organizations for providers in Michigan. The goal of the NHIN
Direct project is *not* to stand up an HIO providing the services.
Instead, the goal is to standardize the mechanics, including:
1) How providers are addressed
2) How edge systems (installed EHRs, LISs, etc.) connect (send/receive
information for an address)
3) How enabling organization (server systems, including MiHIN) route
and
4) How content is packaged for transport (not what the content is, but
what the content wrapper is)
Arien
jmmitchellmd
Regarding #4 - Are you, and this project, truly committed to the
separation of content standards from transport standards? I have not
seen that as the MO of the NHIN thus far. It would be quite refreshing
and may even renew my faith in federal HIT intervention.
Jason
Arien Malec
--
You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
To post to this group, send email to nhindirec...@googlegroups.com.
To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.
--
Arien Malec
Coordinator, NHIN Direct
arien...@nhindirect.org
(510) 761-6473
will ross
CONNECT v2.4, which includes the XDR push spec.
Can we get some more participation in the wiki?
- - - - - - - -
> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nhindirect-discuss?hl=en.
>
> --
> Arien Malec
> Coordinator, NHIN Direct
Brian Behlendorf
> Btw, next Tuesday Redwood MedNet (the HIE I manage) will be live on
> CONNECT v2.4, which includes the XDR push spec.
That's great! It'll be interesting to hear as that happens whether the
user stories are supported and getting used.
> Can we get some more participation in the wiki?
I hear ya; I've been putting in some effort to make sure the contributions
flow in a somewhat logical way, fixing up names of pages and links.
Meanwhile Arien's rustling up the cavalry, and I expect we'll see more
activity soon. I'd like to make sure the structure of what we want to
build is thoughtful enough so that when that happens we make the most of
everyone's time.
Brian
David Tao
What specifically is "deeply flawed" about "the AHIC use cases?" I'm
not saying they are fine as is, but to make a sweeping generalization
like that doesn't necessarily help. There are over 20 use cases
produced over a four year period, and it is not true that they are
"pull only." Admittedly, basic XDS is pull, but it's been augmented by
other IHE and HITSP specs including push (XDR), media and e-mail
(XDM), publish-subscribe (DSUB), all of which are mentioned in AHIC
use cases (e.g., the "Common Data Transport" which covers many types
of patterns, including those you mention). I agree that there should
be simpler alternatives to "semantic interoperability" and those have
ALSO been published long ago, e.g., the IHE XDS-SD unstructured
document and HITSP capability 120. I agree that exchanging
unstructured (or perhaps partially structured but not codified) data
is definitely a step forward for the industry and for patients,
compared to absence of sharing or paper only. But I would also say
that this IS ALREADY covered by vetted standards.
Content and transport have been separated for a long time in the HITSP
specs, though of course they can be "packaged" together for particular
purposes (you need the full stack to actually exchange information).
I am not against simplicity, and in fact am strongly for it, and
believe there's lots of room to improve that simplicity,
accessibility, and understandability of specifications. I'm glad to
start participating in this Wiki and discussion forum. I'm also not
saying HITSP was perfect or simple enough, and that's water under the
bridge since a new organization and process to succeed HITSP will be
forthcoming per the ONC RFPs. But let's not throw the baby (of
previous consensus work from a lot of knowledgeable and dedicated
volunteers) out with the bathwater (the complexity), and let's not say
that things don't exist when they in fact do!
Thanks,
David
Arien Malec
I agree with most of what's here, and I can assure there's no intent
for gratuitous invention. There's also no desire or goal to bash the
past (the title of a recent email) at all.
I've done an exercise in mapping XD* to the user stories and the
abstract model on the wiki, and would appreciate feedback and review
of that work.
Brian Ahier
state-level HIE and those trying to stand up HIOs have a clear
understanding of what this project is about.
See recent article: http://gcn.com/articles/2010/03/29/hhs-wiki-on-nhin-direct-airs-concerns-about-state-impacts.aspx
~Brian Ahier
Arien Malec
states. I have proposed a formal representation from the states, since
getting individual HIO involvement is probably non-scalable. I'm
highly supportive of this -- I want to find a mechanism that works.
> --
> You received this message because you are subscribed to the Google Groups "nhindirect-discuss" group.
> To post to this group, send email to nhindirec...@googlegroups.com.
> To unsubscribe from this group, send email to nhindirect-disc...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nhindirect-discuss?hl=en.
>
>
--
Arien Malec
Coordinator, NHIN Direct