HISP Rules of the Road - Meeting 1

From Direct Project
Jump to navigation Jump to search

HISP Rules of the Road - Meeting #1


  • Review group objectives, timelines, and deliverables
  • Co-chair (with David Kibbe)
  • Identify issues for work:
    • Closed issues - write down and codify
    • Minor open issues - assign individuals to propose solution for consensus in meeting #2
    • Major open issues - assign small groups to develop options
  • Schedule follow-up meetings
  • Review next steps

Meeting Action Items

Set up next meeting – likely repeating Fridays at 3pm
Compile existing language around charter items 1,4,5 into a single wiki page

Session Notes

· David Kibbe (AAFP) co-chair
· Steven Waldren (AAFP)
· David McCallie (Cerner)
· Andy Heeren (Cerner)
· Dan Kazzaz (Secure Exchange Solutions)
· Boris Shur (Secure Exchange Solutions)
· Brian Ahier
· John Odden
· Brett Peterson (ABILITY) co-chair
· Don Jorgenson (Inpriva)
· Pat Pyette (Inpriva)
· Sean Nolan (Microsoft)
· John Hall (Krysora)
· Mark Gingrich (Surescripts)
· Gary Christensen (RIQI)
· Greg Chittim (RIQI)

· Kibbe: have spoken personally to many in prep for Direct Boot Camp. The 5% that is not in best practices/documentation not only exists, but is important. Problems if we don’t have clarity around what needs to happen for HISP to HISP trust. Trying to get to consensus on the outs
· Introductions
o David Kibbe – AAFP, IT consulting
o David McCallie – Standards Committee, Tiger Team
o Andy Heeren – involved from beginning, technical focus
o Dan Kazzaz – implementing point to point product, secure communication before Direct existed
o Boris Shur – works with Dan at SES. Architecting and Design
o Brian Ahier – Health IT Evangelist, contracting with ONC on Direct Boot Camp. Avid champion of Direct. We just completed our debrief of Direct with ONC staff and Arien – they are both excited and nervous about our work
o John Odden – consulting often with technology slant. Direct HISP, serving rural and underserved providers.
o Brett Peterson – chief architect at Ability. Involved with Direct from early on. Working on commercialization now
o Don Jorgenson – Inpriva CEO. Heavily involved in RI pilot. Very active in HL7 standards, security, privacy
o Pat Pyette – Inpriva CTO. Contribute to reference implementations. Working on commercial
o Steve Waldren – AAFP – Director of HIT. Involved with beginning. Now partnering with SureScripts
o Sean Nolan – Microsoft Health Solutions – engaged with Direct for a while. Working on HealthVault a lot now. Looking to take protocols from HealthVault to enterprise lines soon
o Mark Gingrich – SureScripts CIO. Commercializing solution with AAFP
o Gary Christensen – RIQI COO/CIO
· Rhode Island Context
o Use case that really needs the work of this group
o Realized early on Direct was an answer to many of the issues we’re facing with REC, HIE, and Beacon. Early on adopted Direct as the interoperability standard.
o Developing set of services for REC and Beacon. Want to offer assistance on setting up and using Direct both for point to point and as underlying transport (with CCD as content) for collecting clinical data from heterogeneous EHR environment to the state HIE currentcare
o May 6 launch date for statewide rollout of point-to-point direct. Have a vendor marketplace model to match up pre-vetted vendors with providers, facilitate adoption, provide support.
o Application to Participate for HISP Vendor Marketpalce is out there. Received back 7 responses. Currently scoring now. Everyone who is above the line in the scoring will be invited to join the marketplace. Providers can select the HISP that best meets their needs.
o From the beginning, we will be a multi-HISP environment. Interoperability between HISPs matters to us NOW.
o HISPs will need to agree to specs that are a superset of the Best Practices from the Direct work group. We plan to include any low level items from this group in that specification.
· Sean Nolan: Are you intending that HISPs will issue certs?
o Gary Christensen: No. Unlike HISPs, don’t think there’s a lot of differentiation (from providers perspective) in CAs. So minimal value if giving lots of choice. RIQI will be issuing and RFP for CA to issue certs for the Rhode Island Trust Community (signed by RIQI). As part of setting up HISP mailbox, can say that you trust anyone who has a cert signed by RIQI.
o Gary Christensen: Nothing should/can be RI specific.
· Sean Nolan: Glad to hear there is a differentiation between the trust and the tech
· David Kibbe: Let’s agree on rules of the road
o Try to bite off reasonable chunks, and then come to consenus.
o First item is what’s our charter? What are we actually trying to do?
o Focus on two main use cases:
§ http://wiki.directproject.org/HISP+Rules+of+the+Road
o Don’t want to revisit the Applicability Statement for Secure Health Transport
o RIQI is immediate audience, but also critical for other states
· ROUND: commentary on charter
o Steven Waldren (AAFP) – assume this is about determining trust, not establishment of trust?
§ David Kibbe – do want some rules of the road to establish trust in the first place.
§ Steven Waldren - Is it to determine if someone uses two factor authtication, or to determine *if* you should be using two factor authentication
§ David Kibbe – both are fair game
o David McCallie (Cerner) – have lots of thoughts
§ Outcome/measure of success – many of providers are connected because HISPs trust each other, both because of the NPRM and because of technical interoperability. This is the conditions under which HISPs would agree to exchange their root certificates with each other.
o Andy Heeren (Cerner) – as we look for these governance structures/principles, make sure we keep in mind the potential longer term goals/requirements. Cross certified with the Federal Bridge, etc… to give us hints
o Dan Kazzaz (Secure Exchange Solutions)
§ Appears that we’re going to want to think about a federated directory mode.
§ Where does federation get published? Discovery and synchronization.
o Boris Shur (Secure Exchange Solutions)
§ Specification is not always definitive enough – “you can use DNS, or you need to provide another mechanism” elsewhere it says “if you use DNS, you’re fully compliant, else conditionally compliant”
§ Caused some issues with exchanging info with HealthVault
§ How does scaling/wide distribution work? Even HealthVault only has one cert (for direct.healthvault.com)
§ David Kibbe - want to table detailed issues until we all agree on charter
§ Do you even need to trust at this level? If you have entity that binds identity to cert to signature, can you just trust the entity
o Brian Ahier
§ Want to make sure we can scale trust
§ Keep in mind the additional rule making that will occur. Make sure we stay focused and stay aligned
o John Odden
§ 4 quick things about me
· Was effot a decade ago to do MEdiPass to give doctors their own digital IDs. Can we bring lessons learned
· Have range of concerns around shadow editor for Identity and Cross Credentialing Sytems
· Most people in HIT get HIPAA wrong. CEs serving 150M patients feel very different.
· Practice out of own Direct HISP. Focus on white space, ideally where providers can just add the minimum to an Exchange/Outlook solution
§ Want an artifact for how the small folks can come out and play in this environment
§ David Kibbe: How do we make this as easy as possible for round trip communication
o Brett Peterson (ABILITY) co-chair
§ Think items 1,4,5 in charter have already been addressed in Direct. Probably just need to consolidate. David McCallie’s presentation from the Boot Camp covers much of this.
§ Much to cover in 2 and 3 (cert discovery and trustworthiness of HISPs)
o Don Jorgenson (Inpriva)
§ Simple decision tree on who to trust
o Pat Pyette (Inpriva)
§ HISP governance policies to ensure we’re providing secure and trusted service for customers and their counterparts
§ Certs – what they mean, how do discover them.
§ Are two items above conflated too much? Do we need to broaden the cert discussion to others, and focus this group on governance/policy and implementation
§ David Kibbe: want to confirm what you’re saying. If we pulled out paragraph 1 and points 1,4,5 then RIQI could decide which HISPs to trust. Bulk of work that needs to be done is in points 2,3.
§ Correct, but there is value in creating concrete policies around 1,4,5 that can be reused easily.
o Sean Nolan (Microsoft)
§ Want to ensure we decouple operation of HISP and certificates, from both technology and policy perspective.
§ Must is a scary word. Come out of this with a framework that others can follow, but don’t try to prohibit others from doing things if they don’t agree with us. Other trust circles are okay.
o Mark Gingrich (Surescripts)
§ Agree with Pat and Sean
§ Concerns are around policy side. If we come up with criteria, how do we confirm everyone has implemented a set of policies?
o Gary Christensen (RIQI)
§ We need to be able to promise to our providers that HISPs/CAs are doing what they’re supposed to and we’re auditing/paying attention to them.
§ Add to charter – use case 0: operationalizing this. Act of setting up an account. Anything we’re implying around HISP-HISP trust
o Greg Chittim (RIQI)

· Next week planning:
o Kibbe: Can we agree that 1,4,5 is just a matter of assembling the best language available? Brett will take this on – compiling things on the wiki
o Kibbe: What is RIQI doing wrto certificates? Are we issuing them?
§ Gary:
· No. We’re going to contract with a CA
· Point providers to that CA.
· We will do identity checking, etc…
· Help doctors get their certs
· Will sign certificates
§ Kibbe: How do you deal with previously generated certs?
· Gary: Assumption is that you can have multiple certs
§ Gary: Question is what we as RIQI can assert about CAs/HISPs
Just because you have a Direct address, doesn’t mean your identity has been validated. Act of issuing certs is very different than just being a HIS