HISP Rules of the Road Meeting - May 20
Jump to navigation
Jump to search
o Going to ask David McCallie to give an update on Tiger Team/Policy Committee
o McCallie
§ Clarifying question of who would be able to issue certs for NwHIN
§ Putting a number of simple choices together, asking federal partners to choose:
· Must use a FBCA-partner CA
· Commercial best practice CA (WebTrust, etc…)
· Defer to ONC recommendation (likely in NPRM)
§ Standards committee: entity directory service (aka organizational provider directory) took up certificate discovery – IHE HDP - DSE-XML
· Tabled as moving to aggressively, not doing enough work
§ Consensus that DNS is fine for now until a directory service for discovery is landed on
o Kibbe: Hoping that whatever we do will be taken into account by Tiger team
o McCallie: Tiger team will likely issue recommendation as request for comment, will put us in a good position to respond and be taken seriously
· (Peterson) Review the candidate consensus changes made to revisions 8, 9, and 10 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text" and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus. Very little debate occurred on the wiki.
o Kibbe: Seems that this level of assurance for an organization is one of the critical things that we need to get to consensus on
o Peterson: Reviewing Direct RoR Consensus Statement. Search for “Candidate Consensus Statement”
o Consensus Statement Revision 8 #1: Identity Verification (RA) of Healthcare Entities, Organizations, and Healthcare Professionals (non-patients)
§ Links to NIST 800-63 and x.509 Cert policy for FBCA v2.24
§ Should use NIST identity level 3 for individual identity proofing and FBCA Basic assurance
· Level 2 vs. 3 – 3 requires financial verification (both endpoints)
§ Does not standardize certification or auditing processes
o Consensus Statement Revision 8 #2: When a healthcare organization is issued an organizational Direct certificate, then HIPAA best practices should be followed by the healthcare organization in determining the appropriateness of assigning Direct addresses to its members (all of which will use the same Direct organizational certificate for S/MIME signature verification and encryption).
o Consensus Statement Revision 9: A HISP should not use one organizational or individual certificate to represent more than one distinct healthcare organization or individual provider. For example, if a third-party HISP provides service to 20 distinct hospitals (legal entities), each hospital should be associated with a different organizational certificate.
o Consensus Statement Revision 10: Governance and Oversight
§ Minimal change, just changed from red to black to seek out consensus
§ Added EHNAC as a potential auditor
o ROUND
§ David Kibbe (AAFP) co-chair
· Looking good, but I think Level 2 is sufficient. Extra step seems minor, but feel it will be an encumbrance
· “A HISP should not use one organizational or individual certificate to represent more than one distinct healthcare organization or individual provider.” Should be reworded. A little bit confusing since orgs naturally represent more than one individual
§ Brett Peterson (ABILITY) co-chair
· Agree with David that this should not specify Level 3.
· Would prefer not having FBCA at all
· Would prefer Level 2 minus. Possession of valid government id, even if remote should be plenty. Providing an account number is a burden. Can it be like Lexis Nexis where they answer questions that they only answer
· Fine having EHNAC, but also fine punting on specifics for certification. Once we get more adoption, then we can add structure
§ David McCallie (Cerner)
· Looking good.
· Can we make this more human parseable, add a chart that highlights the details we’ve landed on.
· Need to account for difference between identity proofing of an individual who represents an organization, vs those who get accounts.
· Should feel free to follow line of DEA and do Level 2 Minus – just say what we think
· FBCA certification – someone will tell us what to do – remove for now
· EHNAC is a role model, not specific organization
· Need to deal with authentication standards
o Password, password + token, password + challenge
§ Greg Meyer (Cerner)
§ Andy Heeren' (Cerner)
· For individual representing organization, how do you prove they work for that org. W-2s maybe
§ Gary Christensen' (RIQI)
· Individual proofing – planning to look at IDs, nothing else unless we really have to.
· Organizational proofing – want to make sure we handle the case of whos on the hook when providers disclose to someone who was claimed to be a valid organization, but then discloses inappropriately.
§ John Williams' (Health-ISP)
· Pretty much happy
· Can we add language around a third party being able to provide the identity proofing? Even just parts of it like a notary. What about an ACO that wants to do the identity proofing?
· Kibbe: I think we’ve already covered this under the definitions
· : comes down to the certification problem. Anyone can do it. If you trust those that are doing it, you’re okay. Conceptually no problem with 3rd party proofing
§ Arthur Hedge' (Health-ISP)
· Want to reiterate that FBCA rules are not a requirement, may be dangerous to ask
§ Adrian Gropper (HealthURL)
· Little concerned about Governance/Oversight – self attested and certified. Certification lower bound on cost is concerning.
§ Umesh Madan (Microsoft)
· Echo remarks around FBCA, etc…
· Level 2 seems excessive, Level 2 minus is better. Don’t think verification of accounts is going to work.
· Maybe two factor authentication (call, address, etc…) would be more feasible
· How do you expect HISPs to do individual verification within a larger organization?
o Orgs don’t necessarily don’t need to use an org cert. Couldn’t they just use multiple individual certs?
· John Odden – gap between individual best practice at lots of provider identities, and the model we’ve come up with that doesn’t map. How the hospitals do what they do is based on HIPAA compliance, and this might not fit.
· McCallie – issue is with the PKI/Security standards of the federal body under whose auspices this will run
o Even to be an RA for a trusted CA, you need to audited
· Jorgenson – developing a directory so that orgs can proof their employees as a proxy
· Kibbe: really two separate issues:
o Does org want to/already done proofing for all its members
o Can org take its organizational cert from a trustworthy CA, issues additional individual certs from that organizational cert.
§ This likely introduces some complexity that could trigger additional oversight
· McCallie – believe PKI stops at the org level so that individuals don’t necessarily need certs. If you want to be a proxy to issue sub certs, this introduces more examination of your trust chain
· Peterson: will change text to reflect the discussion
· Umesh: Governance and Oversight section needs some more review in the next call
§ Ali _ (Microsoft)
§ Pete Palmer (SureScripts)
· Have a number of comments
· Would like to not references NIST, rather Kantera 2.0 IAF ([1])
· It’s harmonized with 800-63 generally. There are alternatives to financial account numbers (utility bills with address)
· OMB memorandum (M-04-04) ([2]) – guidance document for risk assessments for those using NIST 800-63
§ John Odden' ()
· Worth studying CAQH.org for proofing decision – held within the purview of the CE. This works well. Proofing outsourced completely to a third party doesn’t have many good examples
· Where we refer to “HIPAA Best Practices” – should be pulled out.
§ Mark Stine ()
· Basically agree with general comments around NIST Levels
· Am concerned a little bit about complexity tradeoffs. Want to get wide adoption, but people need to get comfortable with the fact that there will be security contraints
§ Will Ross' (RedwoodMedNet)
· Will pass in interest of time
§ Sri Koka (TechCent)
· Will pass in interest of time
· What are the examples for downside of Level 2 assurance
· Should avoid certification of HISPs at this time
§ Noam Artz (HLN)
§ Greg Chittim (Arcadia / RIQI)
· (Peterson) Review the remaining red areas in the consensus document and determine if they are in scope:
o Certificate Issuance requirements for a HIDP: Is compliance with the FBCA Certificate Policy required? At what level?
o Certificate Profile: If in scope, do we specify section 7 of the FBCA X.509 Certificate Policy plus the requirements from section 1.4 of the Applicability Statement for Secure Health Transport?
o Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) requirements?
Agenda
- (Kibbe) Introduction and updates.
- (Peterson) Review the candidate consensus changes made to revisions 8, 9, and 10 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text" and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus. Very little debate occurred on the wiki.
- (Peterson) Review the remaining red areas in the consensus document and determine if they are in scope:
- Certificate Issuance requirements for a HIDP: Is compliance with the FBCA Certificate Policy required? At what level?
- Certificate Profile: If in scope, do we specify section 7 of the FBCA X.509 Certificate Policy plus the requirements from section 1.4 of the Applicability Statement for Secure Health Transport?
- Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) requirements?
Attendees
· 'David Kibbe (AAFP) co-chair
· Brett Peterson (ABILITY) co-chair
· Greg Meyer (Cerner)
· David McCallie (Cerner)
· Andy Heeren' (Cerner)
· Gary Christensen' (RIQI)
· John Williams' (Health-ISP)
· Arthur Hedge' (Health-ISP)
· Adrian Gropper (HealthURL)
· Umesh Madan (Microsoft)
· Ali _ (Microsoft)Sri Koka' (TechCent)
· Don Jorgenson (Inpriva)
· Pete Palmer (SureScripts)
· John Odden' ()
· Mark Stine
· Will Ross' (RedwoodMedNet)
· Sri Koka
· Noam Artz (HLN)
· Greg Chittim (Arcadia / RIQI)
Absent:
· Brian Ahier
· Pat Pyette (Inpriva)
· Dan Kazzaz (Secure Exchange Solutions)
· Boris Shur (Secure Exchange Solutions)
· Sean Nolan
· Mark Gingrich
· Steven Waldren (AAFP)
NOTES
(Kibbe) Introduction and updates.o Going to ask David McCallie to give an update on Tiger Team/Policy Committee
o McCallie
§ Clarifying question of who would be able to issue certs for NwHIN
§ Putting a number of simple choices together, asking federal partners to choose:
· Must use a FBCA-partner CA
· Commercial best practice CA (WebTrust, etc…)
· Defer to ONC recommendation (likely in NPRM)
§ Standards committee: entity directory service (aka organizational provider directory) took up certificate discovery – IHE HDP - DSE-XML
· Tabled as moving to aggressively, not doing enough work
§ Consensus that DNS is fine for now until a directory service for discovery is landed on
o Kibbe: Hoping that whatever we do will be taken into account by Tiger team
o McCallie: Tiger team will likely issue recommendation as request for comment, will put us in a good position to respond and be taken seriously
· (Peterson) Review the candidate consensus changes made to revisions 8, 9, and 10 of the Consensus Statement based on wiki discussions. The changes are wrapped by text of the form "Candidate Consensus Text" and are summarized on this discussion thread. Do a round and decide whether the changes can be accepted as rough consensus. Very little debate occurred on the wiki.
o Kibbe: Seems that this level of assurance for an organization is one of the critical things that we need to get to consensus on
o Peterson: Reviewing Direct RoR Consensus Statement. Search for “Candidate Consensus Statement”
o Consensus Statement Revision 8 #1: Identity Verification (RA) of Healthcare Entities, Organizations, and Healthcare Professionals (non-patients)
§ Links to NIST 800-63 and x.509 Cert policy for FBCA v2.24
§ Should use NIST identity level 3 for individual identity proofing and FBCA Basic assurance
· Level 2 vs. 3 – 3 requires financial verification (both endpoints)
§ Does not standardize certification or auditing processes
o Consensus Statement Revision 8 #2: When a healthcare organization is issued an organizational Direct certificate, then HIPAA best practices should be followed by the healthcare organization in determining the appropriateness of assigning Direct addresses to its members (all of which will use the same Direct organizational certificate for S/MIME signature verification and encryption).
o Consensus Statement Revision 9: A HISP should not use one organizational or individual certificate to represent more than one distinct healthcare organization or individual provider. For example, if a third-party HISP provides service to 20 distinct hospitals (legal entities), each hospital should be associated with a different organizational certificate.
o Consensus Statement Revision 10: Governance and Oversight
§ Minimal change, just changed from red to black to seek out consensus
§ Added EHNAC as a potential auditor
o ROUND
§ David Kibbe (AAFP) co-chair
· Looking good, but I think Level 2 is sufficient. Extra step seems minor, but feel it will be an encumbrance
· “A HISP should not use one organizational or individual certificate to represent more than one distinct healthcare organization or individual provider.” Should be reworded. A little bit confusing since orgs naturally represent more than one individual
§ Brett Peterson (ABILITY) co-chair
· Agree with David that this should not specify Level 3.
· Would prefer not having FBCA at all
· Would prefer Level 2 minus. Possession of valid government id, even if remote should be plenty. Providing an account number is a burden. Can it be like Lexis Nexis where they answer questions that they only answer
· Fine having EHNAC, but also fine punting on specifics for certification. Once we get more adoption, then we can add structure
§ David McCallie (Cerner)
· Looking good.
· Can we make this more human parseable, add a chart that highlights the details we’ve landed on.
· Need to account for difference between identity proofing of an individual who represents an organization, vs those who get accounts.
· Should feel free to follow line of DEA and do Level 2 Minus – just say what we think
· FBCA certification – someone will tell us what to do – remove for now
· EHNAC is a role model, not specific organization
· Need to deal with authentication standards
o Password, password + token, password + challenge
§ Greg Meyer (Cerner)
§ Andy Heeren' (Cerner)
· For individual representing organization, how do you prove they work for that org. W-2s maybe
§ Gary Christensen' (RIQI)
· Individual proofing – planning to look at IDs, nothing else unless we really have to.
· Organizational proofing – want to make sure we handle the case of whos on the hook when providers disclose to someone who was claimed to be a valid organization, but then discloses inappropriately.
§ John Williams' (Health-ISP)
· Pretty much happy
· Can we add language around a third party being able to provide the identity proofing? Even just parts of it like a notary. What about an ACO that wants to do the identity proofing?
· Kibbe: I think we’ve already covered this under the definitions
· : comes down to the certification problem. Anyone can do it. If you trust those that are doing it, you’re okay. Conceptually no problem with 3rd party proofing
§ Arthur Hedge' (Health-ISP)
· Want to reiterate that FBCA rules are not a requirement, may be dangerous to ask
§ Adrian Gropper (HealthURL)
· Little concerned about Governance/Oversight – self attested and certified. Certification lower bound on cost is concerning.
§ Umesh Madan (Microsoft)
· Echo remarks around FBCA, etc…
· Level 2 seems excessive, Level 2 minus is better. Don’t think verification of accounts is going to work.
· Maybe two factor authentication (call, address, etc…) would be more feasible
· How do you expect HISPs to do individual verification within a larger organization?
o Orgs don’t necessarily don’t need to use an org cert. Couldn’t they just use multiple individual certs?
· John Odden – gap between individual best practice at lots of provider identities, and the model we’ve come up with that doesn’t map. How the hospitals do what they do is based on HIPAA compliance, and this might not fit.
· McCallie – issue is with the PKI/Security standards of the federal body under whose auspices this will run
o Even to be an RA for a trusted CA, you need to audited
· Jorgenson – developing a directory so that orgs can proof their employees as a proxy
· Kibbe: really two separate issues:
o Does org want to/already done proofing for all its members
o Can org take its organizational cert from a trustworthy CA, issues additional individual certs from that organizational cert.
§ This likely introduces some complexity that could trigger additional oversight
· McCallie – believe PKI stops at the org level so that individuals don’t necessarily need certs. If you want to be a proxy to issue sub certs, this introduces more examination of your trust chain
· Peterson: will change text to reflect the discussion
· Umesh: Governance and Oversight section needs some more review in the next call
§ Ali _ (Microsoft)
§ Pete Palmer (SureScripts)
· Have a number of comments
· Would like to not references NIST, rather Kantera 2.0 IAF ([1])
· It’s harmonized with 800-63 generally. There are alternatives to financial account numbers (utility bills with address)
· OMB memorandum (M-04-04) ([2]) – guidance document for risk assessments for those using NIST 800-63
§ John Odden' ()
· Worth studying CAQH.org for proofing decision – held within the purview of the CE. This works well. Proofing outsourced completely to a third party doesn’t have many good examples
· Where we refer to “HIPAA Best Practices” – should be pulled out.
§ Mark Stine ()
· Basically agree with general comments around NIST Levels
· Am concerned a little bit about complexity tradeoffs. Want to get wide adoption, but people need to get comfortable with the fact that there will be security contraints
§ Will Ross' (RedwoodMedNet)
· Will pass in interest of time
§ Sri Koka (TechCent)
· Will pass in interest of time
· What are the examples for downside of Level 2 assurance
· Should avoid certification of HISPs at this time
§ Noam Artz (HLN)
§ Greg Chittim (Arcadia / RIQI)
· (Peterson) Review the remaining red areas in the consensus document and determine if they are in scope:
o Certificate Issuance requirements for a HIDP: Is compliance with the FBCA Certificate Policy required? At what level?
o Certificate Profile: If in scope, do we specify section 7 of the FBCA X.509 Certificate Policy plus the requirements from section 1.4 of the Applicability Statement for Secure Health Transport?
o Certificate Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP) requirements?