80 likes | 237 Views
Information Exchange Workgroup. June 6, 2013. Agenda. Review areas for IE WG focus Query exchange discussion Next steps. 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)
E N D
Information Exchange Workgroup June 6, 2013
Agenda • Review areas for IE WG focus • Query exchange discussion • Next steps
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
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)
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)
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
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
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?