HISP Rules of the Road Meeting - May 27
Agenda
- (David Kibbe) Introduction and updates on the events of the past week.
- (David McCallie) Introduce and provide context for the recommendations of the Tiger Team task force that came out this week.
- (Sean Nolan) Introduce and provide context for the idea of Direct Communities.
- (All) Do a round on the question of "What's our purpose and way forward given the events of the week?"
Meeting Notes
- David K
- Recommendations from Tiger Team are important
- Key issue are if recommendations from TT actually set bar in appropriate place
- What is impact of Tiger Team?
- David M
- Terminology and concepts are difficult
- Many meetings with Tiger Team to flush out these details
- June 6 or 8 these recommendations will be published to public and then subsequently they would be presented to the ONC
- The spirit of the PowerPoint has not changed but the language will be
- Tiger Team
- What is minimum requirement for a Certificate Authority?
- Providers of certificates – what is cost and complexity with obtaining a cret?
- If you want to join the fed bridge this is very expensive and timely
- But, if you want to issue certs for something like direct this is not quite so complex
- A provider could be gathered from a reseller. This may cost $100/cert/year
- Tiger Team is making assumption that organizational based certs are reasonable and that this does not pose a barrier that the ONC should be worried about
- Third question
- Is Direct part of nationwide health network?
- Short answer is probably yes but this is not confirmed
- Best way to think of Direct is as a Brand
- If you want to say you’re part of NWHIN then you would be using Direct
- This is just David M’s opinion
- Rich – is there differentiation between hardware cert, software cert or cloud based?
- David M - not from Tiger Team
- Rich – DEA requires level 3 control
- David M - not from Tiger Team
- Lightening Round For Questions:
- David K - What is level 3?
- Brett – during debate did anyone analyze cross certified certs? This might have a slight king making effect?
- It was assumed this would result in a competitive marketplace
- Gary – branding, both NWHN and Direct are copyrighted, is there a distinction?
- First read through PowerPoint was that this would just be used to connect to fed agencies
- David M – intent is to limit this policies to organizations operating under NWHIN
- John Odden – Admin simplification
- How do we tell which providers have interest to work with NWHIN and which ones don’t? This may impact their opinion?
- David M – this was discussed. But assumed most orgs would have to work with federal govt
- How do we tell which providers have interest to work with NWHIN and which ones don’t? This may impact their opinion?
- Don – what is appropriate standard sounds like the conversation
- Direct to federal agencies should be there but there are many other opportunities outside of federal agencies
- Sean Nolan
- Introduce and provide context for the idea of Direct Communities
- Tiger Team – instance of direct that will work with federal agencies
- Questions?
- What is Direct technology?
- What are the set of bits, protocols, to do exchange?
- What are the direct communities that are forming?
- Direct Federal
- Direct Citizen Community – engagement with patients
- Technology is built so that a single organization can create one implementation of Direct and use multiple certs to participate in multiple communities
- From perspective at Microsoft this is just a more natural way to proceed
- Adrian – Sean proposed
- That any provider could have multiple certs associated with a Direct address?
- Sean – the one thing to add that this could probably not be Hotmail but it could be one address.
- Through config of mail account you could set this up.
- John Williams
- Totally on board
- Brett – in favor of looking at Direct baseline community
- Two questions
- In context of MU will that impact this?
- In terms of multiple certs would you actually put multiple keys/certs on a message
- David K – MU requirements
- Doesn’t see any requirement why this has to be done to get MU dollars
- David M – tried to get an answer to this question
- No one at ONC would answer this at this time.
- As an EHR vendor it may be useful for them to look into this
- David K – MU requirements
- Two questions
- Gary – model is similar to reseller idea
- The work Direct has gone beyond just a set of protocols
- This is also best practices
- And a paradigm
- And a set of policies
- This is crucial that we stay consistent with the vanilla specs that we have
- Need to be consistent to get broad based adoption
- Need the vanilla specs
- The work Direct has gone beyond just a set of protocols
- David K
- These policies do not define how this needs to be enforced
- Direct Trust.org may still be required. Fed policy will probably not cover this.
- David M will endorse the idea of a Direct citizen
- John Odden – need to do what Sean recommends or we would have trouble
Relevant Email from Sean Nolan
Below is the written version of the "Direct communities" idea we discussed on this call, May 27, 2011. Per our discussion, in the coming week we'll be setting up some structure on the wiki to hopefully provide some clarity around these communities. Important to note that we continue to hope/expect that the "Federal" and "Ecosystem" communities (I'm trying "ecosystem" instead of "baseline" for this term) will converge over time, perhaps even before the federal regulations are fully specified. This construct is simply intended to enable us to move most efficiently into production use in a way that the maximum number of people can get connected in a safe and appropriate manner, and we'll go from there.
---Sean
The proposal is intended to clarify terminology and discussion so that we can effectively "parallelize" different threads of activity in an efficient way.
I'll start by looking back to the beginning of the Direct Project, where we acknowledged that a single set of policies (we called them "trust circles") was unlikely to emerge immediately. While we have always hoped that this would become the case over time, experiences from States, HIE vendors, and DURSA veterans, and others were extremely consistent on the reality of this point. Therefore, we designed the Direct technology so that, with one technology implementation and one single Direct address, a Direct user could simply with configuration participate in multiple "trust circles" --- giving them the broadest universe of connectivity possible (more history on this in the Security & Trust Workgroup consensus overview page).
As we are now actively in discussion about real-world implementations, there is a desire to create the most inclusive "circles" possible --- that was the founding challenge to this workgroup. Because there are many different stakeholders in the process, and because of the timelines and unique needs of the federal government, this is a very difficult task. And more importantly there is a real risk of getting drawn into a "one and only one policy" approach, which might greatly delay Direct implementations, if we are not very methodical about our activities.
It is proposed that we match our "rules of the road" discussions directly to the concepts of "trust circles" (renamed as "communities") --- so that we can have the right conversations in the right context. As part of this we will also reinforce a clear distinction between the Direct technology and specific Direct communities. Note that this is exactly parallel to what has been done in the NwHIN space where the IHE profiles and CONNECT are technologies that can be used in many contexts, and the NwHIN is a federal instance of those technologies that operates under a specific set of policy requirements.
- Direct Technology = the protocols and reference implementations and guidance we built as part of the original Direct Project workgroups. This is just technology --- anybody can use it for whatever they want.
- Direct Communities= organizations or groups of organizations that agree to abide by a set of policies and have some mechanism (which may include self-attestation, formal accrediting or auditing procedures, or others) for enforcement of those policies. It would greatly simplify the use of Direct technology is members of each of the Communities agreed to have their own “anchor bundle” --- the set of one or more certificates that represent the trust anchors for the community and are installed into the Direct gateways (HISPs and HISP trust stores) of participants. I suggest that we call out three specific communities that need to have policies set for them:
- Direct Federal Community = The community that can exchange with Federal entities. Certificates in this "anchor bundle" must meet the standards ultimately endorsed by the ONC through the HITPC and Tiger Team. Decisions here are ultimately up to ONC.
- Direct Ecosystem Community = The community we have been developing as part of the “Rules of the Road” workgroup that is intended to support broad exchange between a diverse set of participants.
- Direct Citizen Community = The community that chooses to exchange with patients through PHRs or other mechanisms. The anchor bundle for this community will include the HealthVault and Google certs, plus others that want to exchange messages with citizens. We may try to anoint a CA to reduce the number of certificates floating around here.
Other communities can self-form, and choose to clone policy sets from any of the above, or create their own from scratch.
Remember that any provider or organization can participate easily in multiple communities with each user having a single address --- we are not talking about fragmentation that would require providers to juggle a bucket full of addresses in order to do their jobs. Enabling this was a fundamental design principle of the Direct specifications.
Please use the discussion tab on this page to react to this proposal --- later in the weekend and early next week we'll try to create a wiki structure that matches our joint goals.
Thanks!