Individual Involvement Meeting 2010-06-03

From Direct Project
Jump to navigation Jump to search

Notes from Individual Involvement Workgroup
Date: June 3, 2010
Time: 1:00pm-2:00 pm
Attendees: Jackie Key, Richard Elmore, John George, Paul Saxman, John Moehrke, Sean Nolan, Arien Malec, David Tao

Actions from this Week
n/a
Actions from last Week

#
Date
Action
Status
Owner
Due Date
20
5/27/10

Look through the Concrete Implementation capabilities worksheet and review them with respect to patient engagement in order to discuss at the meeting on 6/3/10.

REST http://nhindirect.org/REST+Implementation+Capabilities+Worksheet
SMTP [1]
IHE http://nhindirect.org/IHE+Concrete+Implementation+Capability+Worksheet
XMPP http://nhindirect.org/XMPP+Implementation+Capability+Worksheet

 Open
WG
6/3/10
21
5/27/10
Decided on updated meeting schedule. Meeting on the 3rd to review capability worksheets. No meeting on the week of the face to face meeting, bi-weekly meetings only if there are any actions/decisions to discuss.
Closed
WG
n/a



Agenda

  • Review action items from last week
  • Discussion: Review the concrete implementation capability worksheets and consider what they might mean from an individual involvement perspective
  • Next Steps


Notes
REST Overview
Comment from Paul Saxman

  • So far the REST team has put together demonstration HISPs that communicate with one another via HTTP on the backbone
  • Google is putting together a Google Health destination and Medplus is putting together a source

Comment from Arien Malec

  • REST facilitates the patient giving his/her provider an address. This has an embedded trust model allowing the provider to enter the address for that patient and have their EHR automate pushing information to the address without a lot of configuration
    • Assumes EHR ability to push to an address
    • Work for provider is simply to enter the patient address into the EHR and initiate a push transaction

Comment from Paul Saxman

  • REST protocol is very lightweight and easy to integrate with the system from a destination/source standpoint
  • REST communication protocols are easy to work with


Feedback on REST Implementation

Name
Feedback/Comment
John George
no comment
John Moehrke
no comment
Sean Nolan
  • As we think about compliance, is the REST group assuming use of a PHR provider?
  • Arien Malec - There is no protocol that will drive toward PHR vs non-PHR, but our trust model will demand a service that enables the assumptions we’ve established in the S&T WG
    • There is a benefit to the lightweight nature of the REST client
    • A lot of the heavy lifting is not in transport, but in enforcing the trust model/satisfying the conditions for our message handling policy model
  • Paul Saxman - Agree with Arien’s statement. Also would add that REST team used a standards-based approach to the interfaces, which lends to ease of integration.
David Tao
  • Current REST worksheet implies that a PHR is the vehicle. If this was not the intent, this should be reworded. Keep in mind that many patients do not have PHRs.
  • Arien Malec – Agree, the language should be generalized


SMTP Overview
Comment from Sean Nolan

  • As with REST, largest aspect of how patients will interact with NHIN Direct lies within the trust model
  • People will likely participate in NHIN Direct through large PHR providers
  • An organization offering a purely email-based mechanism would be compelling based on familiarity with email concepts
  • Attachments are the primary model by which structured content will be included
  • When data is received at a PHR, you can extract certain types of data


Feedback on SMTP Implementation

Name
Feedback/Comment
John George
no comment
John Moehrke
  • Is the SMTP interface behind the scenes of a PHR?
  • Sean Nolan - Yes, we’ll start there and the tools may evolve over time(more detailed discussion continued below)
David Tao
no comment

Comment from John Moehrke

  • Any of these concrete models could likely be behind the scenes of a PHR, is there anything about SMTP that would make this easier for the PHR?
    • Sean Nolan – No, not particularly compared to the other approaches
  • A typical email client for a consumer may not support S/MIME, but if the expectation is that the PHR will take care of this behind the scenes, then this wouldn’t be an issue
    • Sean Nolan – Many email clients will rely on a service provider


IHE/SOAP Overview
Comment from John Moehrke

  • IHE model leverages protocols that IHE has developed. Primary part of the solution is a SOAP-based XDR transaction
  • IHE team is looking to demonstrate IHE interaction with other protocols
  • From the perspective of a consumer, there is an expectation that the consumer would use a commercial PHR
    • Trust relationship is easier if a PHR hosts multiple patients
    • IHE approach does require this PHR-fronted service
  • Some of the important attributes for consumer involvement are part of metadata in the content package, such as attestations about who authored the package and document
  • Patient can be a document author or can be a carrier of documents authored elsewhere
  • Digital signatures on these documents can help to validate authorship
  • XDM file system format will allow for transmission via email zip or USB
  • IHE offers a more intensive set of protocols, but with a PHR/EHR on the front-end


Feedback on IHE/SOAP Implementation

Name
Feedback/Comment
John George
no comment
Paul Saxman
  • What does it take to have a PHR to be a HISP in this situation? Would the PHR have to speak the backbone protocols?
  • John Moehrke – A HISP would only need to speak the backbone protocol
Sean Nolan
  • What would a patient address look like?
  • John Moehrke – We’re using the NHIN Direct addressing specification email format (more detailed discussion continued below)

Comment from Sean Nolan

  • How are errors handled?
  • John Moehrke – There are minimum metadata values. These are mandatory items that are required to be filled in. A SOAP fault is given in response if these are not filled in.
    • This metadata isn’t intended to be burdensome, but it is helpful to have metadata elements present and have a specified way to fill these out if available
    • There are ways to degrade gracefully based on the availability of metadata

Comment from Richard Elmore

  • Could you address the construction of minimal metadata?
  • Arien Malec – Is a CDA document required?
  • John Moehrke –Would be optional

Comment from Richard Elmore

  • Interested in how easy it would be for a provider to send an unstructured message. Does that fit within the structure described by John?
  • John Moehrke – It can be done, though the original IHE use cases were more focused on publication of finalized documentations.
  • Richard Elmore - How does IHE address individual involvement issues?
  • John Moehrke – The original vision of IHE’s XDS included PHRs
    • While doing NHIN Direct implementation, have realized that IHE change proposals may be required to better handle the NHIN Direct workflows
    • For example, the intended recipient value is embedded in the rich metadata as opposed to in a separate envelope layer


XMPP Overview
Comment from Arien Malec

  • XMPP proposal uses standard, out of the box XMPP, likely will use one of many possible open source XMPP libraries to perform hooks
  • Benefit of XMPP is that it will allow for synchronous as well as asynchronous communications
  • Paul Saxman – A member of the Google security team noted that there are easy mechanisms within XMPP to keep transaction logs


Feedback on XMPP Implementation and Comparison Between Approaches

Name
Feedback/Comment
John George
More focused on IHE implementation. IHE standards can incorporate some of the other protocols as mentioned earlier.
Paul Saxman
Curious about the barriers for integration if you are a small company or start-up EHR/PHR. What would it take to get plugged into NHIN Direct? Since REST is lightweight, the barrier is minimal.
John Moehrke
In favor of the IHE model. XMPP would likely work behind an EHR/PHR
Sean Nolan
Sounds like all models will support a PHR/EHR fronted experience, but need to understand the overlap of DURSA requirements for IHE. Out of box nature of SMTP will be appealing based on its familiarity. However, none of the approaches seem like they will prevent positive engagement by patients
David Tao
Have been working more closely on the IHE team. Each approach recognizes the existence of other protocols and the need for bridges between the protocols.


Comment from Arien Malec

  • IHE team has done a good job of showing bridges and the REST team will do something similar
  • In summary:
    • It’s not hard to develop basic way to interact with edge systems
    • From the patient experience perspective, the hardest thing is the trust model, not transport. Transport is relatively invisible and everything gets wrapped up in an address.


Comment from Richard Elmore

  • Concerned about providers without much technology who are trying to figure out how to connect with patients
  • Should the demos next week look at ease of provider engagement?
  • Arien Malec – This is part of the evaluation criteria, though not particularly from the standpoint of individual involvement
    • The issue is getting an address and a technology that supports addressing
    • No real difference from an individual involvement perspective once you have this
  • John Moehrke – IHE model may not look good on this front because they are taking existing EHR/PHR products in the field and transforming them to do a push model
    • Ease/transparency of implementation may not be a good evaluation criteria unless this is scoped properly
  • David Tao – For the concrete implementation comparison, the user interface should be ignored, the protocols are what are important
  • Sean Nolan – Would be valuable to identify aspects of an existing transport that make it easier to use
Retrieved from "https://directproject.mywikis.wiki/w139/index.php?title=Individual_Involvement_Meeting_2010-06-03&oldid=522"