Geographies Meeting 2010-08-04

Notes from Implementation Geographies Workgroup
Date: August 4, 2010
Time: 12pm-1pm
Attendees: Susan Torzewski, Chris Voigt, Didi Davis, Andy Heeren, Hank Fanberg, David Kibbe, Douglas Arnold, John Moehrke, Noam Arzt, Karen Donovan, Leroy Jones, Umesh Madan, Kate Nixon, Will Ross, Gary Christensen, Michele Darnell, David Tao, Sri Koka, Pat Pyette, Don Jorgenson

Action Items:

ID	Date	Action	Status	Owner	Due Date
29	8/4/2010	Update Implementation Geographies Checklist	Open	Paul Tuten	8/11/2010

Paul Tuten

• Quick update on pilot briefs
• Minimum items that constitute a pilot

Gary Christensen

• carved out budget and have a project manager.
• Had one conversation around a HISP support.

Doug Arnold

• Microsoft HealthVault, eClinicalWorks and largest community health center in Connecticut.
• Microsoft and MedPlus will be HISP.
• Hoping by next week that Emdeon will be participating.
• Had number of technical meetings. Kim Long from Quest is co-leading the pilot.
• 
  

Lee Jones

• We updated last week. Since then, confirmed ECWs participation. Still have two or three vendors that haven't been confirmed.
• Still need to identify target providers.

Susan from CareSpark

• In process of lining up providers so they understand requirements. Still in discussions. Will have another meeting this week.

David Tao

• There used to be a preliminary draft on the wiki.

Didi Davis

• State of Tennessee is working with us on the pilot implementation. Want to see if other players will be added. Tennessee HIE has joined us.

Will Ross

• Started looking a couple days ago for putting something up.
• Talked with Jonah Frohlich from State HIE.
• Presenting concept to Cal eConnect to make sure there's an NHIN Direct pilot demonstration in the state.
• Redwood Mednet is an operational HIE and deliver information to providers in the region.
• Approaching this from line of business perspective - another service our HIE can offer. We have already downloaded the Cerner Agent and did a live demo interacting with Microsoft showing early demonstration.
• Looking at how to get the participants in the area technically capable of doing this to do it.

Paul Tuten

• Any other members planning on posting?

David Tao

• Umesh from Microsoft posted something about interest for having anyone sending something through HealthVault. Raises possibility you may have an isolated provider to be able to do this. Would you consider that to be able to qualify?

Arien Malec

• Would love to learn about those kinds of experiences.

David Tao

• Different logistics involved. Not sure what the HISP would be.

Paul Tuten

• Good topic because it fits in with recurring theme with what makes a good or bad pilot.
• One issue is whether or not the pilot needs to be truly in production. Can there be a demonstration using fake patient data. Is that acceptable or not?

David Tao

• I posted a link off of the pilot checklist page.

Doug Arnold

• If we have individual physicians who are working within our area or other physicians want to participate that.

Round the Room: What is the minimum threshold for being a pilot? Part of the criteria that Kim Long is proposing is: has to have real patient data with real exchange, the pilot is intended to go into production,minimum number of use cases. What are the preconditions for a pilot being a real pilot?
Can there be or does there have to be more than one HISP? Does the backbone protocol have to be SMTP?

Susan Torzewski	Production intent is definitely what i would consider a requirement. Number of providers is dependent. Backbone protocol depends on reference implementation. To go through all the levels of consensus using real patients in the real phase is probably not possible. The next step after that would be to go through real patients. One of the intended participants is the VA and multiple levels of approval needed.
Didi Davis	Our exchange is based on NHIN exchange and that hasn't been finalized yet. So not possible to do that. Arien - I can update people on the current thoughts from privacy and security tiger team.
Andy Heeren	In terms of real patients, I agree. Number of HISPs, 2 would be minimum. Use cases and providers, as long as decent representation, don't know if we need minimum or maximum.
David Kibbe	I don't think we should put a lot of limitations. If a single physician wants to start sending NHIN Direct messages to even a small number of patients and there's a HISP somewhere, we should allow that. Can be viral - recruit others as well. As long using real data, why limit?
Doug Arnold	Agree with what was said. Don't want limitations for individual providers.
John Moehrke	The point of having pilots is to get feedback on direction. I don't think we should have a size constraint. Should be on if you're using specification. Real patient data is a problem.We should require real providers. The problem with real patient data is that you have to go through workflow that patient is going through. Security and privacy concerns. If people can use real patient data, then that's fine. The intention is not just a demo but legitimately evaluating for use. Biggest concern is discussion around HISP. The protocol is what we are specifying, not the deployment architecture around the HISP. Does implementation geography succeed if only one solution is used? I think you need to have two or more implementations - i.e. Outlook vs. Thunderbird. Need to have two or more.
Noam Arzt	Nothing to add.
Karen Donovan	Nothing to add.
Leroy Jones	Don't think needs to have size restrictions.
Umesh Madan	Want to echo David Kibbe's comments. Why put constraints? If we didn't use real patient data, what are the pilots accomplishing? Without real data this may not be useful.
Kate Nixon	For our project, we are planning on launching on larger scale. What it depends on is the timeline for the pilots.
Will Ross	Will use real data. Would love to have other HISPs in some of our use cases, but one is enough to prove NHIN Direct protocol. Regarding consent, we are interested in what the Tiger team is up to. Looking at modified participation agreement. We do exchange data currently and we have a comprehensive security and privacy framework. We are talking about creating a light participation agreement for NHIN Direct. Paul Tuten - Can you make light agreement available? Will Ross - Currently a conversation, but understand the DURSA and understand the agreement we use.
Gary Christensen	I think it's a continuum. I think the pilots will start with testing and as parts come in place, we can move to real patient data and production. I don't agree that we need more than one HISP, nor do I feel like we have to test all cases in every pilot. I think it's important that the pilots in aggregate are testing all the use cases. I don't think every individual pilot needs to have all moving parts. I'm really testing the business capability. Is this implementation turn into an actual solution more than a test of the protocol?
Michelle Darnell	I agree with comments earlier. If real data then that would be great.
David Tao	Many good comments. Turn it into production is key. As Gary just said, if you do that, you'll be using real patient data at that time. That means that during the pilot, the production intent brings the real patient data in. I agree, no limitations. Number of HISPs shouldn't be a requirement as long as using NHIN Direct protocol and at least one user story.
Sri Koka	I think intent to production with real production data is good. There are a lot of moving parts. Testing of all scenarios is the key. HISP to HISP is proof. Real production. We have to take steps to get there. The backbone protocol should be flexible
Don Jorgenson	No size restrictions. It might be useful to talk about phases - one where we declare tests and then migrate to pilots.
Chris Voigt	I'm going to follow on with comments said earlier.
Arien Malec	I like Gary's approach to this. The key is production intent. Production intent is likely to go along a continuum from testing to early deployment to wide scale deployment. Also agree with Will - we're testing two different things. We're testing the specification to make sure it's implemetnable in a variety of contexts. Great to test a provider whose using end to end encryption. It would be great to test a HISP model where HISP doing verification on user's behalf. Great to test combinations of those. On other hand, we also need to test the business outcome. That outcome is based on real data and real collaboration. We should think about these pilots as testing two different things. With regard to number of participants, if I have a provider in middle of Kansas and also has desire to incorporate patients and send information two ways, that would be great. I get worried when you have provider in the middle of nowhere, you hook them up to a HISP, and they don't do anything. We need to test the business value.
Paul Tuten	This is helpful. I will take on responsibility to update the checklist. Welcome comments.

Arien Malec
 

• Privacy and security Tiger team has been looking at issue of consent last week. They have published a presentation that is still in draft mode outlining the handling of consent. The approach they have taken is to say there is a set of trigger conditions that require consent.
• Direct exchange doesn't hit those factors. There are cases where they would, but most of the trigger factors deal with sensitive information or exposure of information to non parties of the exchange. If I am a HISP and my entire function is to relay lab messages from lab to provider and don't retain data for secondary use and don't pass data to third party, then unless state law requires additional consent, the policy framework would not require consent. If as an intermediary, you are taking lab data and passing it on to patient's payer or retaining for analysis, this would trigger necessity for consent.
• Much of this depends on directed exchange as long as between HIPAA authorized parties and not retaining for other purposes.
• With regard to sending sensitive information, the current thinking of Tiger team is that should be governed by state law. No explicit requirement for consent outside of state law.
• These recommendations have yet to be submitted to policy committee but do represent diverse opinions.

John Moehrke

• Early to know where Tiger team is going. Currently outlining.
• Did raise issue of cost for consent being mandatory.
• Was gratified that the Tiger team's recommendations did not go over the top.

Arien Malec

• One of the trigger conditions explicitly recognizes aggregating inside an IDN and ICO. If aggregating fine, if merging across multiple centers of care, then concern.

John Moehrke

• Sender's responsibility to have already done checks and balances.

David Kibbe	I want to make one further comment. As we think about these pilots going forward, we should remember that there are lots of physicians communicating via email, of course, not securely. Maybe we can reach out to those physicians and help them use NHIN Direct as a substitute.
Doug Arnold	Need to be careful about unintended access.
John Moehrke	Agree with David. Let's bring those people using common email today.
Noam Arzt	Nothing to add.
Didi Davis	All are valid comments. Need to make sure there's some understanding. I would only add bidirectional feedback to Tiger Team.
Andy Heeren	Agree with previous comments.
Noam Arzt	Nothing to add
Umesh Madan	Regardless of what the Tiger team recommends, can individual organizations still proceed? Arien Malec - The law of the land is HIPAA and state law. That being said, it would be useful for these pilots to be a process test.
Hank Fanberg	Want to make sure we can exchange information with one off provider.Couple of general comments. Texas released HIE plan yesterday. There is concern around privacy and confidentiality. Anything we do probably won't extend beyond state of Texas.
Will Ross	Nothing to add.

Arien Malec

• Would like to call out that there have been updates to the Technology section for the pilots. I would encourage members to enter information then.