NHIN Workgroup


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

NHIN Workgroup

  1. 1. HIT Policy Committee NHIN Workgroup Call Discussion Framework DRAFT - V 3-1 March 16, 2010 David Lansky, Chair Danny Weitzner, Co-Chair
  2. 2. Discussion Topics <ul><li>1. Update regarding Level of Assurance analysis for identity proofing and authentication </li></ul><ul><li>2. HIE Trust Framework and Role of Trust Enabling Organizations </li></ul><ul><ul><li>Vet overall structure and components of the Trust Framework. </li></ul></ul><ul><ul><ul><li>Is this a good starting point? How can we improve it? </li></ul></ul></ul><ul><ul><li>What are the most important roles for TEOs? </li></ul></ul><ul><ul><ul><li>Are all of these appropriate for a Certification program? </li></ul></ul></ul><ul><li>3. Implications of NHIN Direct for State role and existing State HIE grantees </li></ul>
  3. 3. UPDATE: LEVEL OF ASSURANCE <ul><li>Topic #1 </li></ul>
  4. 4. Phase 1 (Jan. 2010): Recommendation #4 - Authentication <ul><li>Build upon existing federal standards, policies and practices for authentication and identity proofing. </li></ul><ul><li>Determine the level of confidence appropriate for different exchange scenarios . </li></ul><ul><ul><li>Finding: Assurance requires both identity proofing (carbon-based life form) and authentication (same entity); both are best done as close to the provider as possible. </li></ul></ul><ul><li>Permit innovation and local autonomy in the method of authentication. </li></ul><ul><li>If intermediaries are involved in the exchange, make sure that certification (independent verification) of those intermediaries is done for authentication and identity proofing. </li></ul><ul><li>Include oversight mechanisms and redress. </li></ul>
  5. 5. Update Regarding Level of Assurance Analysis <ul><li>Follow up from February call which recommended </li></ul><ul><li>Level of Assurance analysis related to: </li></ul><ul><ul><li>Identity proofing </li></ul></ul><ul><ul><li>Authentication </li></ul></ul><ul><li>Preliminary framing discussions with NIST </li></ul><ul><li>Additional legwork needed to frame this analysis before bringing to NHIN WG for consideration and input </li></ul><ul><li>How realistic are expectations for certification? </li></ul><ul><li>What are the pressing needs for those who want to initiate exchange? </li></ul>
  7. 7. Phase 2 - Recommendation #4: Role of Government <ul><li>Establish and maintain a framework of trust, including ensuring adequate privacy and security protections to enable electronic health information exchange. </li></ul><ul><li>Create structures/incentives to enable information exchange where trust or necessary standards / services do not exist. </li></ul><ul><li>Limit intervention where information exchange with providers currently exists – to the extent possible. </li></ul><ul><li>Create incentives to improve interoperability, privacy and security of information exchange. </li></ul><ul><li>Support real-world testing and validation of the services and specifications to verify scalability on a nationwide basis. </li></ul>
  8. 8. HIE Trust Framework <ul><li>Components for trust should be consistent nationwide </li></ul><ul><li>Framework must be able to accommodate various HIE models, technologies and information </li></ul><ul><li>Working draft presented for NHIN Workgroup consideration and input are based upon lessons learned from existing HIE activities </li></ul><ul><li>Workgroup input need to validate framework and components </li></ul>
  9. 9. HIE Trust Framework: Essential Components for Trust (proposed) <ul><li>Appreciation of the value of information exchange activities </li></ul><ul><li>Validation of information exchange partners </li></ul><ul><li>Minimum technical requirements for information exchange </li></ul><ul><li>Code of conduct for participants in the information exchange </li></ul><ul><li>Oversight of information exchange activity </li></ul><ul><li>Answerability for information exchange activities </li></ul>
  10. 10. 1. Appreciation of the long-term value <ul><li>Knowing that one's exchange partners share a desire to remain trusted entities provides some degree of assurance that these partners will have an incentive to behave appropriately. </li></ul><ul><li>To continue participating, they will have to continue operating in a way that supports the trust fabric. </li></ul><ul><li>Activity must have acknowledged and appreciated value for participants to have incentive to engage and comply with expectations (because exchange is voluntary).  </li></ul>
  11. 11. 2. Validation of information exchange partners <ul><li>Parties will not exchange information with just anyone. Each party has to be confident they are exchanging information with whom they intend to exchange information and that their counter-party is trustworthy. </li></ul><ul><li>Each exchange partner will therefore have to validate (and maintain an audit log of) the identity of those with whom it exchanges information </li></ul><ul><li>Validation can occur in a number of ways (e.g., using identity proofing and digital credentials to validate authorized members of a network) </li></ul>
  12. 12. 3. Minimum technical requirements <ul><li>Each exchange partner must know that those with whom it is exchanging health information meet certain minimum technical requirements for secure routing. In all exchanges, partners will have to follow some technical standards to allow for the secure, electronic exchange of health information. </li></ul><ul><li>Non-compliance with the technical requirements will prevent an exchange from occurring making non-compliance readily apparent. </li></ul>
  13. 13. 4. Code of conduct <ul><li>Agreed upon and mutually understood set of expectations, obligations, policies and rules around how partners will conduct their business generally and their exchange-related activities specifically. </li></ul><ul><ul><li>Assumes participants will obey applicable law </li></ul></ul><ul><ul><li>Beyond that, assumes that they will act in a way that protects the privacy and security of the information exchanged. </li></ul></ul><ul><ul><li>Varies depending upon the type of exchange, the parties involved (including relationship of partners), the purposes for which data are exchanged (including secondary and future use) and other factors. </li></ul></ul><ul><li>Confirming, detecting and enforcing compliance with code of conduct may be hard for exchange partners to enforce on their own. Various methods available (e.g. self-certification, self-attestation, third party intermediary, etc.) </li></ul>
  14. 14. 5. Oversight <ul><li>“ Oversight” is intended to mean management, maintenance, supervision, and monitoring of the trust relationship and exchange activities. </li></ul><ul><li>The nature of oversight and mechanisms used will depend upon exchange characteristics, model and needs identified by exchange partners, including oversight by: </li></ul><ul><ul><li>Parties to the exchange (e.g. lab-provider, through disclosure requirements, such as breach notification) </li></ul></ul><ul><ul><li>Individual subject(s) of the exchanged information </li></ul></ul><ul><ul><li>Centralized oversight (e.g. large, network model) </li></ul></ul><ul><ul><li>Third party to confirm compliance </li></ul></ul><ul><ul><li>Governmental oversight to help ensure compliance </li></ul></ul>
  15. 15. 6. Answerability <ul><li>Each exchange partner must accept responsibility for its exchange activities and answer for adverse consequences. </li></ul><ul><li>Answerability includes penalties for failing to uphold commitments to conduct their activities as a trusted exchange partner and, if appropriate, redress for those harmed by such failure. </li></ul><ul><li>Partners may answer to the other participants in the exchange, individual subjects of the exchanged information, a governmental entity, or some other third party. </li></ul><ul><li>Common desire to avoid these consequences gives each exchange partner some comfort that all other exchange partners will uphold their commitments. </li></ul>
  16. 16. Trust Framework: Applied Scenarios <ul><li>Provider-to-provider electronic push of information (local, regional, statewide, interstate) </li></ul><ul><ul><li>Without a trust enabling organization (TEO) </li></ul></ul><ul><ul><li>With a trust enabling organization (TEO) </li></ul></ul><ul><li>Trust Enabling Organization </li></ul><ul><ul><li>Organizations will play a role in enabling trust – both within and across the network. </li></ul></ul><ul><ul><li>There needs to be some process to oversee/certify/accredit these entities to assure that they are using appropriate mechanisms so that they themselves can be trusted. </li></ul></ul>
  17. 17. Trust Framework: Point-to-Point Push, no Trust-Enabling Organization (TEO) – Examples not exhaustive Validation of Exchange Partners Technical Req’ts Code of Conduct Oversight Answerability Trust Agreement <ul><li>Exchange partners know where to send information </li></ul><ul><li>Past history </li></ul><ul><li>Patient-provided info </li></ul><ul><li>Contact intended recipient </li></ul><ul><li>- Each partner must know: </li></ul><ul><li>Transport </li></ul><ul><li>Format </li></ul><ul><li>Preferences </li></ul><ul><li>Data elements </li></ul><ul><li>Technical specs </li></ul><ul><li>- Known thru past history or a process that identifies compliance with technical requirements (e.g. certification, etc.) </li></ul><ul><li>Info exchanged for limited authorized purposes ( e.g. TPO) </li></ul><ul><li>Protect privacy and security </li></ul><ul><li>Follow applicable law, (e.g. consent) </li></ul><ul><li>Recipient incorporates info into records and protects it </li></ul><ul><li>Recipient has mechanisms to comply </li></ul>- Exchange partners primarily responsible - Monitoring receipt of information - Patient may confirm info receipt - Gov’t oversight -privacy & security , certification criteria and process <ul><li>- Among exchange partners, to the patient and gov’t agencies that enforce privacy and security laws </li></ul><ul><li>Discontinue information exchange </li></ul><ul><li>Patient needs not met; damage to patient relationship </li></ul>Informal agreement between parties
  18. 18. Trust Framework: Transmission Using Trust Enabling Organization (TEO) – Examples not exhaustive Validation Technical Req’ts Code of Conduct Oversight Answerability Trust Agreement TEO validates identities of exchange partners and/or users Other participants rely upon this <ul><li>TEO satisfies, validates, and/or communicates technical req’ts, which could include: </li></ul><ul><li>Transport </li></ul><ul><li>Routing </li></ul><ul><li>Format </li></ul><ul><li>Preferences </li></ul><ul><li>Data elements </li></ul><ul><li>Technical specs </li></ul><ul><li>Authentication </li></ul><ul><li>Provider directories </li></ul><ul><li>* Functions may vary depending upon exchange partner needs </li></ul><ul><li>- Code of conduct re: exchange partners extends to TEO </li></ul><ul><li>- TEO role depends upon functions agreed to by participants </li></ul><ul><li>Other expectations may apply to TEO (e.g. consents, service level expectations, etc.) </li></ul><ul><li>TEO may establish additional expectations of exchange partners </li></ul><ul><li>TEO manages and oversees exchange and can facilitate monitoring </li></ul><ul><li>Exchange partners may retain some oversight responsibilities </li></ul><ul><li>TEO may take on other obligations depending upon expectations established with exchange participants. </li></ul><ul><li>State/federal Gov’t oversight / certification / accreditation of TEO? </li></ul><ul><li>- For exchange partners –exclusion from exchange with other parties, from use of TEO, or liability. </li></ul><ul><li>Non-compliance by TEO could result in loss of cert/accred status, loss of business, other liability, etc. </li></ul><ul><li>TEO process could address other types of consequences / redress </li></ul><ul><li>Formal agreements: </li></ul><ul><li>Between TEO and participants </li></ul><ul><li>Between TEO and end users </li></ul><ul><li>And/or </li></ul><ul><li>Between participants and end users </li></ul><ul><li>Agreement gov’t if TEO accepts quasi-gov’tl status? </li></ul>
  19. 19. Potential Roles for Trust Enabling Organizations (TEO) Validation Technical Requirements Code of Conduct Oversight Answerability Trust agreement <ul><li>- Establish a “trusted” directory </li></ul><ul><li>- Validate information in a directory to assure accuracy (e.g. provider contact information, electronic address, etc.) </li></ul><ul><li>Facilitate identity proofing and authentication </li></ul><ul><li>- Facilitate communications re: minimum technical requirements </li></ul><ul><li>- Provide solutions, services and/or or support to enable partners to meet minimal technical requirements. </li></ul><ul><li>Comply with requirements recognized by government </li></ul>- Identify set of expectations that participating exchange partners will meet - Confirm that exchange partners agree on the expectations in the code of conduct. - Implement and maintain measures to assure TEO complies with code of conduct <ul><li>- Manage and oversee exchange activities and compliance with the minimum technical requirements and code of conduct </li></ul><ul><li>Monitor and audit exchange activities </li></ul><ul><li>TEOs certify exchange partner compliance </li></ul><ul><li>- Potential gov’t oversight of the TEO? </li></ul><ul><li>Help to implement measures that promote answerability among exchange partners </li></ul><ul><li>If paid for services, potential for loss of business </li></ul><ul><li>Loss of quasi-govt’l status </li></ul><ul><li>Authority will vary depending upon role and agreement of participants </li></ul>-Formal trust agreements between TEO and each exchange partners - Quasi-gov’tl status may reduce need for TEO-exchange partner agreements
  21. 21. Potential Role of States in Enabling Secure Routing Through NHIN Direct <ul><li>Clarifying any state-level privacy and security requirements for secure routing of patient information for treatment purposes </li></ul><ul><li>Providing authoritative directory services (provider, plan, pharmacy) </li></ul><ul><li>Participating in NHIN Direct (Medicaid, Public Health) </li></ul><ul><li>Promoting NHIN Direct-mediated information exchange at the state level </li></ul><ul><li>Enabling organization providing identity management and authentication services </li></ul><ul><li>As Accreditation or Certification body for enabling organizations </li></ul>
  22. 22. Implications of NHIN Direct for State HIE grants <ul><li>Many states are planning more comprehensive interoperability solutions </li></ul><ul><ul><li>Governance and Business Agreements </li></ul></ul><ul><ul><li>Translation and transformation services </li></ul></ul><ul><ul><li>Patient and document discovery </li></ul></ul><ul><ul><li>Aggregation of information </li></ul></ul><ul><ul><li>Quality measurement </li></ul></ul><ul><ul><li>Public health reporting </li></ul></ul><ul><li>AND Secure routing </li></ul><ul><li>Can NHIN Direct support comprehensive state-level interoperability? </li></ul><ul><li>Will commoditization of secure routing through NHIN Direct threaten existence/ business case of comprehensive state HIE efforts? </li></ul>