Best Practices Meeting 2010-09-23

Notes from Best Practices WG
Date: September 23, 2010
Time: 1:00 - 2:00pm EST
Attendees:
Nageshwara (Dragon) Bashyam, Greg Chittim, Gary Christensen, Peter Clark, Didi Davis, Richard Elmore, Jack Kemery, David Kibbe, David McCallie, John Moehrke, Patrick Pyette, John Williams, Karen Witting, Uvinie Hettiaratchy, Caitlin Ryan

Actions

Actions for This Week

#	Date	Action	Status	Owner	Due Date
3	09/23/10	Add “priority” column to Open Questions Tracker.	Closed	Uvinie Hettiaratchy	09/30/10
4	09/23/10	Include all questions (from Open Questions Tracker and Policy Questions for Implementations) in one table to easily prioritize.	Open	NHIN Direct Team	09/30/10
5	09/23/10	Review Open Questions Tracker in preparation for next Best Practices WG meeting (2010-09-30)	Open	Best Practices WG members	09/30/10
6	09/23/10	Reach out to Security and Trust WG to form an ad hoc subcommittee to discuss certification management.	Closed	Uvinie Hettiaratchy	09/30/10

Actions from Last Week

#	Date	Action	Status	Owner	Due Date
1	09/16/10	Update Best Practices WG charter to reflect the meeting’s topics of conversation, especially making it easy to implement in the real world.	Open	Arien Malec	09/23/10
2	09/16/10	Will ask Implementation Geographies to come up with list of policy considerations that they believe would be helpful to get best practice guidance on.	Open	Arien Malec	09/23/10

Agenda

• Review list of questions from Implementation Geographies WG (Open Questions Tracker for Pilots) and prioritize.

Notes

Uvinie Hettiaratchy

• In this meeting the Best Practices WG will start to prioritize open questions coming out of the Implementation Geographies WG.
• During last’s weeks meeting it was decided that the Implementation Geographies WG should feed questions to the Best Practices WG, with the common goal of making it as easy as possible to implement NHIN Direct, especially when it comes to meeting MU criteria.
• Asked WG members to view Open Questions Tracker for Pilots (link in Agenda, above).
• At this week’s Implementation and Geographies WG meeting, some of the questions in the Open Questions Tracker were designated as priority questions.
• Asked John Moehrke to discuss the priority questions.

John Moehrke

• Recapping from Implementation Geographies WG meeting (2010-09-22):
• There was a question on combining an NHIN Direct environment with an XDR environment: how does someone using NHIN Direct know they are sending to an XDR end point versus an NHIN Direct endpoint?
• Answer: they should not have to know. The end point is simply an address they are delivering to.
• There is some configuration needed in the gateway between the NHIN Direct sender and XDR end point, because they must verify they are the correct addressee.
• Uses DNS MX record to verify.
• This process is the same for any kind of e-mail. Servers publish that they are the appropriate place to send messages addressed to a particular address.
• The gateway has to, depending on the deployment model, (1) have certificate with the private keys for XDR endpoint, or (2) use the tunnel model as shown in the deployment model.
• Primarily all of the current pilot projects are looking to use the trusted gateway that will take apart the NHIN Direct packaging and reformat it into an XDR transaction to be transported to the ultimate endpoint.
• NHIN Direct sender should not know or care what kind of end point they are sending to.
• This demonstrates the ultimate goal of universal addressability.
• When the sender uses XDR instead of NHIN Direct, they would know which users are using XDR within their system, and can send to them directly. Anything else can be sent through the gateway to get to the ultimate address, which is an NHIN Direct address.
• He updated the Deployment Models.
• Good resource to help understand the process, but is not extensive.

Round the Room:

• Which questions should be made first priority?
• Which questions are Policy (“big p”) questions, and which can be considered smaller implementation guidance questions?

Name	Comment
Rich Elmore	Agreed that Implementation Geographies should prioritize the questions. Sees certificate management as top priority. Views establishing expectations around HISPs as second priority.
Peter Clark	No additional comment.
Didi Davis	Suggested the individual pilot projects give feedback in determining the questions that are most relevant to each of them.
David Kibbe	No additional comment.
John Williams	No additional comment.
John Moehrke	No additional comment.
Nageshwara Bashyam	No additional comment.
Karen Witting	All the listed questions seem important.
Patrick Pyette	Echoing Didi Davis, suggested asking each of the pilots to provide input. He saw certificate management as the top priority.
Jack Kemery	Suggested prioritizing the questions via the wiki so that everyone could provide input. Also wanted to include the implementation geographies themselves in prioritizing questions, because they are the actual implementers.
Gary Christensen	Asked which questions will be critical for implementing? Believes the question of certificates is urgent. Feels addressing guidance could change many times still. Did not view certification of HISP as an immediate question.
Greg Chittim	Agreed that certificates and addressing are the most the pressing policy/best practices decisions that need to be made. Introduced getting the client API started as another priority that will require best practices.
David McCallie	Agreed with Rich Elmore that issues related to certificates are the first priority and issues around how HISPs should work will be the second priority. Acknowledged that all the questions are intertwined and inter-related. Noted that some Policy (“big p”) questions will occur naturally after the implementation geographies start connecting. Suggested getting to a point where we can hook the pipes together and then start to address the policy issues as they arise (“who gets hot water, and who gets cold water”). Open Questions list is good, though some questions are missing around enrollment and authentication of users. Questions that need to be answered: How do we manage the trust assumption during the pilot phase? Will we assume a signed certificate means a HISP has done something we all agree on?
David Kibbe	Agreed with David McCallie. Additional question: Should providers be allowed to have more than one HISP? Already a sub-question elsewhere. For pilot projects, could simply and say yes or no. Felt they could start out with a single HISP to “get the plumbing working,” and not yet complicate certificate issues for now. John Moehrke Asked if there is any reason to rule out using more than one HISP? David Kibbe Senses competition over the administration of HISP services. This could be confusing to NHIN users. Would be easier for them to have a single NHIN address, not three. Doesn’t feel really strongly about this issue, but prefers to keep it simple.

Uvinie Hettiaratchy

• Recapping
• Certificates as main priority.
• Process of prioritizing would be more efficient through the wiki.
• There are still several missing questions.
• As David Tao mentioned on the wiki, there are policy questions from Documentation and Testing WG that are also relevant.
• Suggested putting all questions in open questions tracker to easily prioritize.
• WG can then review table at next meeting.
• Asked for volunteers to write up a first draft of best practices based on the priority questions.

Gary Christensen

• Requested further guidance on the charter of the Best Practices WG.
• Wanted to know how much of the work was policy and how much was “how things work.”
• Intersection with some of the more technical aspects.

John Moehrke

• Explained his view of the WG’s charter:
• The tech guys are saying there are eight different possible ways to issue certificates. To them it doesn’t matter how the certificates are issued or who they are issued to.
• Each implementation geography will need to choose, based on their circumstances, which of those eight certification methods they will use to knit together their trust environment.
• Implementation geographies are trying to put together operational environments and looking for guidance on which of these eight certification methods they should choose.
• Because there isn’t an NHIN Direct operational spec stating, “operationally all NHIN Direct users MUST use X method,” the question will eventually be passed back to NHIN Direct WGs.
• The Best Practices WG can list the pros and cons to each of the eight certification methods.
• For example, does an implementation trust a certificate because it was handed to them? Or do they only authorize certificates issued by a federal PKI bridge? Which is better?
• Or, the Best Practices WG could review all of the certification methods and decide that all eight ways are acceptable, but that before choosing any certification method the implementation geography would have to use some check list to see if they really should trust a certain federal partner system or individual.

Gary Christensen

• Sounds like Best Practices WG will:
• Identify the options,
• Discuss from an operational standpoint the pros and cons of those options and try to come up with some perspective on the various alternatives.

John Moehrke

• There are dozens of books on this subject, each 1000+ pages. This is not a simple topic.
• Everyone asks, “just tell me what to do.” But we can’t, because it isn’t that simple.

Gary Christensen

• Is there anyone on the group who understands those books and can simplify for the group?
• The group does not seem qualified to tee this up without certain pertinent information.

David Kibbe

• Doesn’t want to do busy work.
• Suggested asking Implementation Geographies or another WG where to start.
• Is the list of certification methods already narrowed down somewhat?

John Moehrke

• Can narrow down to 2-3 models.
• Would offer as, “if you do not have an alternative available to you, A or B are two quick and dirty ways to get going.”
• Would need to make it clear that there is no perfect right answer; this is the quickest way for you to get a pilot going but it might not ultimately be the right choice for you.
• Switching these things out is not that difficult. For a short period there would be some trouble, but no long-term difficulties.

David Kibbe

• We are really not creating best practices; we are creating “minimally sufficient practices.”

David McCallie

• Can call them “boot-strapping practices.”
• At a later date can tighten up and loosen them, as pilot projects are implemented.

David Kibbe

• Suggested reaching out to Security and Trust WG, because they put together the technical infrastructure.
• That group has the technical expertise to now put together a boot-strapping best practices document.

John Moehrke

• Reminded WG that Sean Nolan has put Security and Trust WG on hiatus.

David Kibbe

• Suggested that some of the people who contributed to the design (many are on Best Practices WG) could get something circulated.

Rich Elmore

• Thinks WG is on the right track.
• Emphasized importance of participation from the VA.

John Moehrke

• Can work on a certification model.
• Not going to be hard to come up with--the harder part is to coach users very well that the certification method might not be the best, but will get them started.

David McCallie

• Has the impression that a VA model would be very high-barrier, which might be a good thing.
• Asked if assumption is correct?

John Moehrke

• Essentially when dealing with federal partners, they already have federal certificates issued, so it is just a matter of using them as they were intended.
• For non-federal partners, they must take that trust chain model and anoint a federal PKI bridge.
• Then they should reciprocate and create certificates for the non-federal common practitioner that the federal partners can also accept.

David McCallie

• It is easy for trust to flow downhill, but not uphill.
• If the VA has high standards it would be easy for others to trust the VA signer, but getting the VA and other federal partners to trust the common practitioner is more difficult.
• Do we have to meet their level? If so, it is a high barrier.

John Moehrke

• Hopefully we have an implementation geography with a federal partner in it.

David McCallie

• Maybe that is the best way to start, finding the model to fit the most constraining circumstances.
• Another option would be to have different tiers.

Uvinie Hettiaratchy

• Suggested members of Security and Trust WG provide initial guidance on certificate management.

John Moehrke

• Proposed creating a subcommittee by sending out a notice to the membership of Security and Trust WG, explaining the topic of discussion.

Uvinie Hettiaratchy

• Will create a priority column on question tracker,
• Asked WG members to review.
• Will reach out to Security and Trust WG to form an ad hoc subcommittee.

David Kibbe

• Asked about protocol and naming conventions.
• Saw this as a question on the Open Questions Tracker, but thought it had already been decided.
• If this has already been decided, can we eliminate it as a priority?

David McCallie

• Agreed on technical standard that it is an e-mail-like address, but haven’t agreed on if there is a convention for naming the addresses.
• Question remains: Should you be able to see an address and recognize it as an NHIN Direct address?

David Kibbe

• Is there an action item we can take to go back to one of the previous groups and get a best practice on the naming convention?

John Moehrke

• Thinks there should be no naming convention.
• Addressing WG said it is nothing more than ending and domain.

David McCallie

• Agreed.

Jack Kemery

• Yet it might be a good idea to be able to recognize where it is going and what the purpose is simply by looking at the address.
• There might be an advantage to having some level of consistency.
• Is worth exploring as a recommended approach.

John Moehrke

• Could be useful guidance as long as not a mandate, as in “don’t accept a message from an address if it doesn’t have this format.”
• Doesn’t see address naming conventions as a top priority.

<Comment>

• The message could come from any entity, such as large commercial lab.
• Some convention might be beneficial.

John Moehrke

• Differentiating between an individual endpoint and a departmental endpoint might be useful.
• Different: from Oncology Department versus David Kibbe.

Gary Christensen

• Should it be recognizable as an NHIN mailbox?
• Thinking back to a Tiger Team conversation, there was a fear that doctors will get their separate e-mail addresses confused.
• There could be a policy reason why we might want to say that all NHIN Direct addresses have “NHIN” in them or something.

David McCallie

• Conventions might be worthwhile, but security will prevent mixing of e-mails.

John Moehrke

• Security is not based on the address; it is based on the certificate. If someone uses their normal, daily e-mail as their NHIN e-mail, if they have a certificate, there is no reason why they can’t do that.

David McCallie

• If they don’t have a certificate, they cannot send to a secure address.
• It might be confusing but security measures won’t let mistakes happen.

Karen Witting

• Disagreed.
• If she were to use the same e-mail address for both secure and non-secure content, and someone sent her something non-secure, she would accept because her e-mail accepts both secure and non-secure.
• Whether they secure it or not, she would get it.

John Moehrke

• Policy issue: the sender is at fault for sending something non-secure.
• Best practices need to protect the sender, not the receiver.

Karen Witting

• Exactly.
• Receiver might accept both.
• Feels there is policy work that needs to happen on this.
• Thinks WG should recommend not using the same e-mail for both secure and non-secure.

David McCallie

• Wants to cover all cases with the Security Model.
• Thinks NHIN Direct content and non-NHIN Direct content should use separate addresses.

Karen Witting

• When she read the Policy Questions for Implementations, currently out for consensus, she saw that they acknowledged you can use your existing e-mail for NHIN Direct e-mails.

John Moehrke

• Is allowed, but NHIN Direct recommends you do not use for both.

Karen Witting

• Not written that way.
• The best practices should be: “don’t do this; it is a very, very bad idea.”

Rich Elmore

• Asked about if there would be something different between NHIN Direct and regular e-mail.
• Somehow thought providers would know NHIN Direct would be for just them and other providers, not just anyone.
• Is not suggesting this would necessarily be determined by their address.
• Now he is getting the impression that NIHN Direct is becoming secure e-mail over the Internet, and nothing more.
• Are there more constraints that it would be constricted to healthcare stakeholders?

John Moehrke

• In order to work within the lower technology barrier in the very small doctors’ offices, needs to remain as secure e-mail.
• Agreed with recommending using secure email for communicating.
• A lot of providers already do.
• Many social issues go away when you have EHR/PHR automating interface to SMTP protocols.
• No e-mail application in the mix.

David McCallie

• Agreed with John Moehrke.
• Mentioned that the typical use case for the small office would be through a HISP, where a HISP would manager certificates for the provider.
• In this case, security issues would be abstracted away from the user in terms of managing certificates.

John Moehrke

• Deployment Model C shows this.
• Very scalable system.
• Should create an industry of service providers.

Rich Elmore

• Designing to ensure integrity of NHIN Direct.
• Thinks there are important choices to make about how health internet addresses get assigned, how certificates gets assigned.
• The choices we make will determine the social trust that the healthcare community has in NHIN Direct.
• Doesn’t want to skip over and just say “secure e-mail.”

Uvinie Hettiaratchy

• Table discussion and address this during next week’s meeting.
• Will reach out to Security and Trust WG regarding certification.