Less about Competition and more about Cooperation
8 views
Skip to first unread message
Moehrke, John (GE Healthcare)
Jun 14, 2010, 10:11:07 AM6/14/10
to nhindirect-discuss
I really don’t think we will be successful if we continue to make this an “us vs them”. The IHE group tried hard to reach out, but we were pushed into our own camp. Yes I know the groups were all open, but there is limited bandwidth and it was clear that we needed to explain the IHE model. So we were forced to spend time re-validating the IHE approach. This competition made it very hard to even monitor the other groups. This competition made ‘not working with the other groups’ almost ‘the right thing to do’. I hated this approach; I prefer to help people out.
The good news is that we did find some problems that can and will be submitted to IHE. The bad news is that we humans still have not communicated and seem to be separating into the same groups.
The IHE group (and large organization group, and HIE group) have a legitimate concern that what ever we do for the very-small-doctor-office will affect the larger organizations. I seem to recall that this was part of our kickoff principles, and is even represented in some of our user-stories. So, can we please focus on the needs of the very-small-doctor-office while also considering (may be secondary priority) the needs of the larger organizations. I am not suggesting that we make the solution just as easy for a large organization as a small, we all know that large organizations can apply more resources. I am just asking that we be fair to their needs too.
So my suggestion: we have only two teams: RESTful, and SMTP. That both teams include people knowledgeable in IHE and HIE. Let’s keep the solution simple and primarily focused on the very-small-doctor-office, but lets include some of the concerns of the larger audience.
To me this mostly means that the RESTful and SMTP solutions only need have a clear way to carry XDM.zip. There are other things that we will discover as we move forward ‘cooperatively’.
John Moehrke
Principal Engineer: Interoperability and Security
GE Healthcare
John.M...@med.ge.com
www.gehealthcare.com
productsecurity.gehealthcare.com
3200 N. Grandview Blvd
Mail stop: WT-881
Waukesha, WI 53188
GE imagination at work
agro...@gmail.com
Jun 14, 2010, 10:51:12 AM6/14/10
to nhindirect-discuss
This is promising.
As we're discussing toward the end of "Another Straw Man", a
destination that prefers or requires XDM.zip must be able to request
it just like one that prefers a CCR must be able to request that. In
this way, HIEs that depend on CCD and IHE metadata can connect and
other service providers that depend on CCR can connect as well.
This does not preclude one's HISP from providing conversion services
but it does force anyone that stores Meaningful Use data about a
patient in a format other than the original they received, to produce
either a CCD or a CCR on demand. I would word this policy carefully to
ensure that it covers both HIPAA-covered entities and RHIOs who choose
to aggregate patient data into a registry / repository.
Adrian
On Jun 14, 10:11 am, "Moehrke, John (GE Healthcare)"
> John.Moeh...@med.ge.com <mailto:John.Moeh...@med.ge.com>www.gehealthcare.com<http://www.gehealthcare.com>
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
As we're discussing toward the end of "Another Straw Man", a
destination that prefers or requires XDM.zip must be able to request
it just like one that prefers a CCR must be able to request that. In
this way, HIEs that depend on CCD and IHE metadata can connect and
other service providers that depend on CCR can connect as well.
This does not preclude one's HISP from providing conversion services
but it does force anyone that stores Meaningful Use data about a
patient in a format other than the original they received, to produce
either a CCD or a CCR on demand. I would word this policy carefully to
ensure that it covers both HIPAA-covered entities and RHIOs who choose
to aggregate patient data into a registry / repository.
Adrian
On Jun 14, 10:11 am, "Moehrke, John (GE Healthcare)"
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
Wes Rishel
Jun 14, 2010, 11:48:32 AM6/14/10
to agro...@gmail.com, nhindirect-discuss
This is indeed promising, but I do want to express some concerns.
--
Wes Rishel
a) the term "request" could be meant to imply a request-response transaction pattern. For a long time some spokespeople for IHE have held that request-reply and a variation (subscribe) were the only patterns that met the requirements of health health information exchange. It would be good to validate that Adrian is not meaning to imply that request-reply or publish-subscribe are a necessary component for NHIN-direct. This is a concern because these transaction patterns raise issues about consent that we are trying to avoid.
b) an alternative pattern for meeting the requirement that Adrian has stated would be endpoint-to-endpoint interface discovery (presumably based on UDDI). This is an issue that raises considerable concern for those that wish to take this in the direction of simplifying the role of the intermediary and including physicians that don't have EHRs in the group of potential beneficiaries of this effort.
Going into this project some of the advocates, including me, have been thinking of another approach to the problem of achieving compatibility of format among senders and receivers. Instead of having the complexity of a computer-mediated negotiation prior to sending a message, why not employ MIME in a manner that it has long been used, to include two levels of representation for a message: one that can be interpreted by any recipient (e.g., text or XML that can be reliably represented in text using a publicly available style sheet) and one that comprises to some public profile such as those that were produced by the HITSP tiger team.
The latter form would only be available from sources that have the capability to create it, and sources that could not would not be precluded from initiating messages. Market forces, such as the requirement that 80% of labs be received in structured form, would drive increased use of the structured format.
Finally, my theory suggests no dynamic enforcement enforcement that the structured packages be limited to approved standard formats. For example, researchers working on advanced problems not covered by approved public format (and having IRB and patient consent to exchange protected health information) should be able to use ad hoc formats of their own design.
In response to some concerns that have been raised any such approach should include the feature that the claimed format of the structured part of a transmission should be available to interface software without decryption. Therefore an entity that wants to reject messages that do not contain the structured format they want should be able to reject such incoming messages at the interface.
While it would be more elegant -- and more useful -- to have brokered interfaces or another means for dynamic negotiation of content, my own sense is that this is the kind of complexity to be avoided for early roll-out.
--
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.
--
Wes Rishel
Vassil Peytchev
Jun 14, 2010, 11:51:20 AM6/14/10
to agro...@gmail.com, nhindirect-discuss
I am not sure what the purpose of "must be able to request" is - it seems to add complexity to the "simple push" messaging pattern that we are trying to accomplish. If there are variations that occur at the end points, all must be supported, or there will be no interoperability.
This is promising.
Adrian
--
agro...@gmail.com
Jun 14, 2010, 12:08:55 PM6/14/10
to nhindirect-discuss
Wes,
Indeed, I am not suggesting a request-response transaction pattern.
The ability to process a particular format changes very rarely. It
could simply be an attribute of the certificate associated with an
endpoint or it could be posted to the directory where said certificate
is found. As far as I know, none of this raises any privacy issues and
the complexity of implementing the HISP does not increase
significantly.
"Nice" senders are always free to include alternative MIME types. What
I'm suggesting is more of a policy decision that says that all EHRs
and Registries that do not preserve the original document MUST produce
both of the federally mandated Meaningful Use formats. Nice EHRs might
choose to just send both by default and ignore the recipient
preference.
I'm not suggesting innovation be limited in any way either statically
or dynamically. I'm simply proposing a relatively obvious way to move
forward within the regulatory context that we have as it relates to
the two mandated formats.
Adrian
Indeed, I am not suggesting a request-response transaction pattern.
The ability to process a particular format changes very rarely. It
could simply be an attribute of the certificate associated with an
endpoint or it could be posted to the directory where said certificate
is found. As far as I know, none of this raises any privacy issues and
the complexity of implementing the HISP does not increase
significantly.
"Nice" senders are always free to include alternative MIME types. What
I'm suggesting is more of a policy decision that says that all EHRs
and Registries that do not preserve the original document MUST produce
both of the federally mandated Meaningful Use formats. Nice EHRs might
choose to just send both by default and ignore the recipient
preference.
I'm not suggesting innovation be limited in any way either statically
or dynamically. I'm simply proposing a relatively obvious way to move
forward within the regulatory context that we have as it relates to
the two mandated formats.
Adrian
Brian Ahier
Jun 14, 2010, 1:46:20 PM6/14/10
to nhindirect-discuss
This looks to be a very solid approach. Thank you John for your
inspiration!
~Brian Ahier
On Jun 14, 7:11 am, "Moehrke, John (GE Healthcare)"
> M+1 920 912 8451
inspiration!
~Brian Ahier
On Jun 14, 7:11 am, "Moehrke, John (GE Healthcare)"
>
> John.Moeh...@med.ge.com <mailto:John.Moeh...@med.ge.com>www.gehealthcare.com<http://www.gehealthcare.com>
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
>
> John.Moeh...@med.ge.com <mailto:John.Moeh...@med.ge.com>www.gehealthcare.com<http://www.gehealthcare.com>
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
>
David Tao
Jun 14, 2010, 9:21:19 PM6/14/10
to nhindirect-discuss
Many good points in this thread. Thanks, John, for kicking it off. I
think when time is cramped, it is easy to get stuck in one "silo team"
despite your best intentions. I would like to see it further fleshed
out (not sure I fully understand it, and after all John didn't do a
new "capability worksheet" in his post). I totally agree that the ND
focus is on the small providers, but John's point about the larger
organizations (like hospitals) is valid too, but not just because "big
organizations have feelings too" but because the clinician population
is largely inseparable.
There are lots of patients whose attending and consulting physicians
in the hospital turn out to be "from small practices." I go to a
family practice that has only three docs. They are in process of
implementing an EHR, but that's immaterial to my point, which is that
the same doc will often need to use more than one HIT system (perhaps
one or more hospital systems, probably a practice management system
and possibly ambulatory EHR or EHR-lite, plus e-mail and web browser).
So Peter Devault's point last Friday, that "those small practices are
the same ones that our customers want us to communicate with" is right
on! I was in admitted through the ER last December, and was treated by
a hospitalist, consulted by a specialist (who is part of a practice
with <5 docs), and the results and summary were sent to my PCP in the
family practice (alas, not electronically yet). So we need a connected
healthcare SYSTEM in order to be really patient-centric, not two
parallel worlds. If small doc practices only communicated with each
other, and hospitals only communicated with other hospitals or large
clinics, that would be parallel worlds, but there's a lot of "Karen's
cross" going on already, both in the paper/fax world, and hopefully in
the electronic world. In the past two years, two of my children have
also been in two ERs, then followed up in visits to small physician
practices.
As someone who works for an EHR vendor, I know the thousands of
physician users of our systems don't want us to only serve them in
their "hospital" role, but want us to care about their needs
holistically. And as a patient, I want my hospital EHR and all my
physicians' ambulatory EHRs and/or e-mail systems to communicate as
seamlessly as possible.
I'm not saying this to endorse a particular technology, only stating
things as I see them as a patient, and as I hear from the physicians
who use our EHR and many other EHRs. So yes, let's help the simple
push referral between providers, small and otherwise.
David
think when time is cramped, it is easy to get stuck in one "silo team"
despite your best intentions. I would like to see it further fleshed
out (not sure I fully understand it, and after all John didn't do a
new "capability worksheet" in his post). I totally agree that the ND
focus is on the small providers, but John's point about the larger
organizations (like hospitals) is valid too, but not just because "big
organizations have feelings too" but because the clinician population
is largely inseparable.
There are lots of patients whose attending and consulting physicians
in the hospital turn out to be "from small practices." I go to a
family practice that has only three docs. They are in process of
implementing an EHR, but that's immaterial to my point, which is that
the same doc will often need to use more than one HIT system (perhaps
one or more hospital systems, probably a practice management system
and possibly ambulatory EHR or EHR-lite, plus e-mail and web browser).
So Peter Devault's point last Friday, that "those small practices are
the same ones that our customers want us to communicate with" is right
on! I was in admitted through the ER last December, and was treated by
a hospitalist, consulted by a specialist (who is part of a practice
with <5 docs), and the results and summary were sent to my PCP in the
family practice (alas, not electronically yet). So we need a connected
healthcare SYSTEM in order to be really patient-centric, not two
parallel worlds. If small doc practices only communicated with each
other, and hospitals only communicated with other hospitals or large
clinics, that would be parallel worlds, but there's a lot of "Karen's
cross" going on already, both in the paper/fax world, and hopefully in
the electronic world. In the past two years, two of my children have
also been in two ERs, then followed up in visits to small physician
practices.
As someone who works for an EHR vendor, I know the thousands of
physician users of our systems don't want us to only serve them in
their "hospital" role, but want us to care about their needs
holistically. And as a patient, I want my hospital EHR and all my
physicians' ambulatory EHRs and/or e-mail systems to communicate as
seamlessly as possible.
I'm not saying this to endorse a particular technology, only stating
things as I see them as a patient, and as I hear from the physicians
who use our EHR and many other EHRs. So yes, let's help the simple
push referral between providers, small and otherwise.
David
David Kibbe
Jun 15, 2010, 11:18:45 AM6/15/10
to nhindirect-discuss
Yes, promising. I'd like to make a comment about the "small
practices" issue. What some people aren't seeing, still, is that NHIN
Direct must help physicians in small and medium size medical practices
become Meaningful Users, and that means that our efforts ought to be
primarily directed at the 80% of docs in the practices who either:
a) don't have an EHR or EHR module(s) yet, but do have email and
Internet connection.....
b) have an EHR or EHR modules+email+Internet connection, AND whose
EHR vendor/version won't permit them to do health data exchange
Both of these populations are likely to stand on the sidelines of MU
EHR incentives for 2010 and 2011 unless adoption is very easy and low
cost
and for their patients, who either:
a) have a PHR platform available to them from their provider
organization
b) are willing to open a PHR account at Google Health, MSFT
HealthVault, etc.
Please don't make the assumption that it requires a low tech mindset
to find the SMTP backbone protocol, with the agent, etc. for NHIN
Direct to be useful. All it really requires is that adoption of EHR
technology on a pathway towards Meaningful Use is made substantially
easier and more affordable in the next year or so for a large group of
providers and patients in the populations above, as these are the
populations that are unlikely to be encouraged to along that pathway
via large enterprise solutions.
To almost anyone in a large provider enterprise or one of their
vendors, this seems like "crawling" when you've already been walking
briskly. But the numbers are there to prove that a "crawling, then
walking" solution for NHIN Direct would be a substantial plus in the
interest of health care reform.
Regards, DCK
On Jun 14, 10:11 am, "Moehrke, John (GE Healthcare)"
practices" issue. What some people aren't seeing, still, is that NHIN
Direct must help physicians in small and medium size medical practices
become Meaningful Users, and that means that our efforts ought to be
primarily directed at the 80% of docs in the practices who either:
a) don't have an EHR or EHR module(s) yet, but do have email and
Internet connection.....
b) have an EHR or EHR modules+email+Internet connection, AND whose
EHR vendor/version won't permit them to do health data exchange
Both of these populations are likely to stand on the sidelines of MU
EHR incentives for 2010 and 2011 unless adoption is very easy and low
cost
and for their patients, who either:
a) have a PHR platform available to them from their provider
organization
b) are willing to open a PHR account at Google Health, MSFT
HealthVault, etc.
Please don't make the assumption that it requires a low tech mindset
to find the SMTP backbone protocol, with the agent, etc. for NHIN
Direct to be useful. All it really requires is that adoption of EHR
technology on a pathway towards Meaningful Use is made substantially
easier and more affordable in the next year or so for a large group of
providers and patients in the populations above, as these are the
populations that are unlikely to be encouraged to along that pathway
via large enterprise solutions.
To almost anyone in a large provider enterprise or one of their
vendors, this seems like "crawling" when you've already been walking
briskly. But the numbers are there to prove that a "crawling, then
walking" solution for NHIN Direct would be a substantial plus in the
interest of health care reform.
Regards, DCK
On Jun 14, 10:11 am, "Moehrke, John (GE Healthcare)"
> John.Moeh...@med.ge.com <mailto:John.Moeh...@med.ge.com>www.gehealthcare.com<http://www.gehealthcare.com>
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
>
>
> productsecurity.gehealthcare.com
> <http://productsecurity.gehealthcare.com/>
>
David Tao
Jun 15, 2010, 11:27:23 AM6/15/10
to nhindirect-discuss
Yes, Dr Kibbe, I agree. But I think you left out something on the
patient side, which has its parallel to your item (a) on the doctor
side.
>>>and for their patients, who either:
>>>a) have a PHR platform available to them from their provider organization
>>>b) are willing to open a PHR account at Google Health, MSFT HealthVault, etc.
Just like we're talking about physicians who don't have EHRs yet (the
large majority), we are also talking about patients who don't or won't
have PHRs (an even larger majority!). So I suggest it should say:
patients who...
a) have only e-mail or web browser, but not PHR
b) have a PHR platform available to them from their provider
organization
c) are willing to open a PHR account at Google Health, MSFT
HealthVault, etc.
with a) being the largest number. Even with ARRA HITECH stimulus
funds, providers who qualify in 2011 will provide "electronic access"
and/or "electronic copy" but that may not necessarily be a PHR.
Thanks,
David
> > GE imagination at work- Hide quoted text -
>
> - Show quoted text -
patient side, which has its parallel to your item (a) on the doctor
side.
>>>and for their patients, who either:
>>>a) have a PHR platform available to them from their provider organization
>>>b) are willing to open a PHR account at Google Health, MSFT HealthVault, etc.
large majority), we are also talking about patients who don't or won't
have PHRs (an even larger majority!). So I suggest it should say:
patients who...
a) have only e-mail or web browser, but not PHR
b) have a PHR platform available to them from their provider
organization
c) are willing to open a PHR account at Google Health, MSFT
HealthVault, etc.
with a) being the largest number. Even with ARRA HITECH stimulus
funds, providers who qualify in 2011 will provide "electronic access"
and/or "electronic copy" but that may not necessarily be a PHR.
Thanks,
David
>
> - Show quoted text -
Wes Rishel
Jun 15, 2010, 1:32:47 PM6/15/10
to David Kibbe, nhindirect-discuss
"What DCK said" plus this.
--
Wes Rishel
In my hopes, it is as much about communications that go beyond the specific mandates for meaningful use "incentive" payments. It's also about novel and as-yet nonspecific ways of using those communications. When ever you make up examples of "novel" things you risk the example becoming the subject of the discussion which is not my intent. Nevetheless, here are somehwat arbitrary novel ideas:
- a dictation service that creates CCR or CCD files and offers the physician a portal where they can see the files in folders by patients, the same files in different folders based on referral mechanisms. Reports can be forwarded as PDFs or CCRs to other physicians. The user of the service keeps an address book for common trading partners that ways which format to use.
- New "home-care" practices as anticipated under healthcare reform that must deal with SNFs that do not have EHRs and have no immediate funding to get them. The same org dealing with home-care professionals that are independent contractors for overload, and whose main form of electronic communication will be their smart phone.
- an independent physician association that offers a "day in the city" scheduling service for patients that want to schedule several appointments on the same day, when their grandson is available to drive them around.
--
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.
--
Wes Rishel
David Tao
Jun 16, 2010, 9:57:43 AM6/16/10
to nhindirect-discuss
Totally agree with you Wes. Just because MU "mandates" certain
structured formats such as CCD or CCR, plus HL7 for other purposes
(immunizations, labs), there is nothing that says that those formats
are EVERYTHING, or even a significant percentage of, what is
exchanged. There is plenty of already existing and useful information
in different structured and unstructured formats, such as those you
mention (dictation/transcription being a huge example) that is is
worth sharing. I've heard some rumblings that some organizations want
nonstandard formats "transformed" into standard formats (like CCD or
CCR), which to me totally doesn't make sense. Let's exchange what we
HAVE regardless of format, and incrementally evolve towards more
structured data and vocabularies, in a reasonable time frame. I'm glad
that ND is "content-agnostic" even though CCR and CCD are mentioned a
lot as examples of the payload, hopefully no one in ND thinks that
they have anything to do with the transport. To my knowledge, none of
the approaches proposed would have trouble delivering any kind of
payload.
But the main point I gleaned from your post was that we shouldn't let
MU and incentives totally limit our thinking about what can and should
be exchanged, and that the ND direction should open the door for
innovation and other types of exchange.
Thanks,
David
On Jun 15, 1:32 pm, Wes Rishel <wris...@gmail.com> wrote:
> "What DCK said" plus this.
>
> In my hopes, it is as much about communications that go beyond the specific
> mandates for meaningful use "incentive" payments. It's also about novel and
> as-yet nonspecific ways of using those communications. When ever you make up
> examples of "novel" things you risk the example becoming the subject of the
> discussion which is not my intent. Nevetheless, here are somehwat arbitrary
> novel ideas:
>
> - a dictation service that creates CCR or CCD files and offers the
> > nhindirect-disc...@googlegroups.com<nhindirect-discuss%2Bunsu...@googlegroups.com>
> > .
structured formats such as CCD or CCR, plus HL7 for other purposes
(immunizations, labs), there is nothing that says that those formats
are EVERYTHING, or even a significant percentage of, what is
exchanged. There is plenty of already existing and useful information
in different structured and unstructured formats, such as those you
mention (dictation/transcription being a huge example) that is is
worth sharing. I've heard some rumblings that some organizations want
nonstandard formats "transformed" into standard formats (like CCD or
CCR), which to me totally doesn't make sense. Let's exchange what we
HAVE regardless of format, and incrementally evolve towards more
structured data and vocabularies, in a reasonable time frame. I'm glad
that ND is "content-agnostic" even though CCR and CCD are mentioned a
lot as examples of the payload, hopefully no one in ND thinks that
they have anything to do with the transport. To my knowledge, none of
the approaches proposed would have trouble delivering any kind of
payload.
But the main point I gleaned from your post was that we shouldn't let
MU and incentives totally limit our thinking about what can and should
be exchanged, and that the ND direction should open the door for
innovation and other types of exchange.
Thanks,
David
On Jun 15, 1:32 pm, Wes Rishel <wris...@gmail.com> wrote:
> "What DCK said" plus this.
>
> In my hopes, it is as much about communications that go beyond the specific
> mandates for meaningful use "incentive" payments. It's also about novel and
> as-yet nonspecific ways of using those communications. When ever you make up
> examples of "novel" things you risk the example becoming the subject of the
> discussion which is not my intent. Nevetheless, here are somehwat arbitrary
> novel ideas:
>
> physician a portal where they can see the files in folders by patients, the
> same files in different folders based on referral mechanisms. Reports can be
> forwarded as PDFs or CCRs to other physicians. The user of the service keeps
> an address book for common trading partners that ways which format to use.
> - New "home-care" practices as anticipated under healthcare reform that
> same files in different folders based on referral mechanisms. Reports can be
> forwarded as PDFs or CCRs to other physicians. The user of the service keeps
> an address book for common trading partners that ways which format to use.
> must deal with SNFs that do not have EHRs and have no immediate funding to
> get them. The same org dealing with home-care professionals that are
> independent contractors for overload, and whose main form of electronic
> communication will be their smart phone.
> - an independent physician association that offers a "day in the city"
> get them. The same org dealing with home-care professionals that are
> independent contractors for overload, and whose main form of electronic
> communication will be their smart phone.
> > .
Reply all
Reply to author
Forward
0 new messages