Information Exchange Workgroup

1. Information Exchange Workgroup June 6, 2013

2. Agenda • Review areas for IE WG focus • Query exchange discussion • Next steps

3. Review areas for IE WG focus • IE WG had three issues in the HITPC Stage 3 Request for Comment • Query for Patient Record (102 comments) • Provider directory (EHR certification only) (62 comments) • Data portability (EHR certification only) (56 comments) • Are there any market developments or lessons learned that would cause us to amend this list? • The market is VERY dynamic (and exciting!) and the landscape looks different than it did even 7 months ago when the RFC was released • The demand for cross-vendor query exchange appears to have grown with the rapid growth of ACOs, but the capabilities for such exchange have not kept pace with demand • Directed exchange as required for Stage 2 is starting to take shape • The role and function of HISPs is still murky, but lack of standards for provider directories and security certificates appear to be an obstacle to more rapid progress • Industry projections suggest that 25-30% of physicians may change EHR systems in the near future, making data portability an important issue • Demand for patient engagement is growing, and entrepreneurial activity is as well

4. IE WG Proposed Workplan • It appears that the RFC focus areas are still consistent with aspirational goals of Stage 3 and gaps that still remain from Stages 1 and 2: • Query for Patient Record as high priority for Stage 3 • Provider directory to support query as well as directed exchange required for Stage 2 • Data portability to meet growing need for cross-vendor data migration • Plus: Patient engagement – what’s after VDT? • Recommend an IE WG workplan as follows: • Focus on four areas: Query for Patient Record, Provider Directories, Data Portability, Patient engagement • For July 7 HITPC meeting • Recommend these priority areas and parameters of our recommendations • Present preliminary recommendations on Query for Patient Record and Provider Directories • For September HITPC meeting: • Present final recommendations on all four focus areas • We have 2 calls (June 6 and June 21) to prepare for July 7 HITPC • Suggest that we schedule 2 more calls (June 14? and June 28?) but target getting our work done without need for last call • June 6 and June 14?: Query for Patient Record and begin Provider Directories • June 21: Provider Directories • June 28?: Finalize preliminary recommendations (target doing this offline via email)

5. Query for Patient Record • Query for patient record approach in RFC was essentially rejected by HITSC • HITSC and public comments suggest need to simplify and generalize recommendation • Some strawman first principles for query based on this feedback: • Build on Stage 2 approach that allows use of Direct or organized HIE infrastructures • Set goal of having query and response happen in a single set of transactions • Requestor should be able to send encrypted query message with: • Authenticating information of requesting entity and discover security credentials • Patient-identifying information • Representation of patient authorization • Type of information being requested • Data-holding entity should be able to respond to query message by: • Validating credentials and decrypting query message • Matching patient • Verifying authorization for patient information • Responding with secure message containing requested information or reason for not fulfilling request • Don’t over-specify • Does not enable or motivate new workflows • Not flexible to variation or changes in key inputs (consent, type of information, etc) • Build on already approved Privacy and Security Tiger Team recommendations on patient-matching and query (targeted and untargeted)

6. Anatomy of aQuery for a Patient Record Data Requestor Data holder • Discover provider address and security credentials • Send: • Authenticating credentials • Authorization for request • Patient-identifying information • Type of information being requested • Receive: • Validate authentication credentials • Verify authorization for request • Match patient • Check for requested information query • Receive: • Requested information or reason for not fulfilling request • Log transaction • Send: • Requested information or reason for not fulfilling request • Log transaction response

7. What do we need to specify in policy? • Discoverability of provider information • Build on Direct but may need bolstering with PD requirements • Authentication? • Build on Direct? • Authorization? • HITPC already approved PSTT approach of placing responsibility on end-points • Variation in state- and organization-level policies suggests need to leave this open • Patient-matching? • HITPC already approved PSTT recommendations to NOT place requirements on patient-matching approaches • Data-holding entity determines level of assurance needed to establish a match • Type of information? • May want to leave this open to account for absence of standards and very high variation in capabilities of data holding entities to respond to granular requests • If some type of specification is desired, may want to set minimum threshold response as lifetime medical summary aligned with CCDA content requirements (Redacted Blue Button?) • Sensitive conditions probably too difficult to tackle system-wide due to state variation – responsibility of data-holders to assure that such information not contained in automated responses • Use case specific responses (such as care coordination, etc) probably too difficult to tackle system-wide – very large jump from current capabilities

8. Next Steps • Schedule 2 more calls: June 14? June 28? • Continue Query for Patient Record discussion and perhaps begin Provider Directory discussion on June 14?