Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007.

Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007

2 Revised Work Product Health Information Protection Taskforce Work Product (accepted by the Taskforce on February 23, 2007; accepted by the State Alliance on March 30, 2007) (1)Conduct an analysis that: a)examines the rationale behind the major state health privacy protection laws that affect the sharing of health information across entities (whether paper- based or electronic); b)discusses the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment; and c)provides recommendations for addressing issues arising from such protections.

Privacy and Security Solutions for Interoperable Health Information Exchange Presented by Dr. Linda L. Dimitropoulos RTI International Presented at Monthly Meeting of the Health Information Protection Task Force State Alliance for eHealth April 25, 2007 RTI International is a trade name of Research Triangle Institute 230 W. Monroe ■ Suite 2100 ■ Chicago, IL 60606 Phone 312-456-5246 E-mail lld@rti.org Fax 312-456-5250

5 Background Variation in privacy and security business practices and policies creates a barrier to electronic clinical health information exchange The existing paradigm for privacy and security protections does not fully accommodate active consumer participation in health information exchange Consumers, organizations, and state and federal entities share concerns related to maintaining the privacy and security of health information

6 Assumptions Decisions about how to protect the privacy and security of health information should be made at the local community level Discussions need to take place to develop an understanding of the current landscape and the variation that exists between organizations within each state, and ultimately across nation Stakeholders at the state and community levels, including patients and consumers, must be involved in identifying the challenges and developing solutions to achieve broad- based acceptance

7 Project Tasks Identify the variation in organization-level business practices, policies, and state laws that creates barriers to eHIE Identify practices and policies that serve as “checkpoints” Document the rationale or “driver” behind the practice or policy Develop solutions Incorporate the “good” practices and policies into proposed solutions Work with stakeholders toward consensus-based solutions to harmonize the variation and create appropriate protections Develop a plan to implement the solutions

8 Project Outcomes Preserve privacy and security protections in a manner consistent with interoperable electronic health information exchange Incorporate state and community interests, and promote stakeholder identification of practical solutions and implementation strategies through an open and transparent consensus-building process Leave behind in states and communities a knowledge base about privacy and security issues in electronic health information exchange that endures to inform future HIE activities

9 Sources of Variation Variation Related to Misunderstandings and Differing Applications of Federal Laws and Regulations HIPAA Privacy Rule  Patient Authorization/Consent  Variation in Determining “Minimum Necessary” HIPAA Security Rule  Confusion regarding the different types of security required  Misunderstandings regarding what was currently technically available and scalable CFR 42 part 2  Variation in the treatment facilities’, physicians’, and integrated delivery systems’ understanding of 42 CFR pt. 2, its relation to HIPAA, and the application of each regulation

10 Sources of Variation (continued) Variation Related to State Privacy Laws Scattered throughout many chapters of law When found, it is often conflicting Antiquated—written for a paper-based system Trust in Security Organizations Consumers/patients Cultural and Business Issues Concern about liability for incidental or inappropriate disclosures General resistance to change

11 Sources of Variation (continued) Variability in the use and implementation of patient consent or authorization across organizations Lack of understanding about when federal and state laws require patient consent Lack of a standardized requirement for when to use patient consent Lack of a standard form to be used in connection with patient consent and authorization

12 Sources of Variation (continued) Variability in the interpretation and application of the “Minimum Necessary” standard Widespread belief that it applies to disclosures to providers for treatment purposes Lack of models and best practices for applying “Minimum Necessary” in all other non-treatment-related disclosures Increases the time required for the exchange and affects the ability to receive comprehensive records

13 Sources of Variation (continued) Lack of a standard, reliable way of accurately matching records to patients Lack of standard authentication and authorization protocols Inability to appropriately segregate data poses a challenge to appropriate role-based access Current lack of auditing capability because of technical inadequacies and nonexistent or poor audit programs

14 Moving Forward Proposed Solutions Fall into 5 Categories Leadership and Governance Practice and Policy Legal and Regulatory Technology and Data Standards Education and Outreach

15 Implementing Solutions Within each project team Clarify Assumptions and Define Core Principles Identify Measurable Goals and Outcomes Define “critical path” activities Define Milestones and Action Steps Across teams Create communication channels and coordinate work to prevent duplication of effort

16 Timelines Final Reports due to AHRQ and ONC May 15 Assessment of Variation and Analysis of Solutions Implementation Plan June 30 Nationwide Summary

17 Thank You http://Healthit.ahrq.gov/privacyandsecurity www.rti.org\hispc

Is HIPAA Preemption a Legal Barrier to Health Information Transparency and Interoperability? Professor Phyllis C. Borzi, J.D., M.A. The George Washington University School of Public Health and Health Services Department of Health Policy

20 Background for Study Concern was expressed to and by policymakers that the HIPAA preemption rule allowing application of more strict state laws was a legal barrier to creation of interoperable health information systems and reporting of transparent data We were asked to undertake a judicial review of current cases to examine this question

21 Why Focus on Judicial Opinions? –One source of evidence as to the existence of a problem –Evidence as to how the health care system understands the sources of power and legal constraints within which it operates

22 Methodology Systematic review of all reported federal and state cases decided between 1996 and 2006 in which HIPAA was mentioned (479 cases; after elimination of duplicate cases involving appeals, 446 cases) Each case was initially examined and categorized based on: –Parties and nature of underlying dispute –Whether the dispute involved HIPAA preemption If so, whether the court was required to determine if state law was “contrary to” or “more stringent than” HIPAA to decide the case Analysis then focused on latter group of cases in which there was an allegation of conflict between HIPAA and state law (113 cases) Tabulation of results in these 113 cases by case domain, underlying claim, type of information sought, types of entities involved, result (e.g., HIPAA governed; state law governed; both governed because no conflict)

23 Key Findings To date, no HIPAA cases involve state law barriers to access to PHI for treatment, payment, patient safety or quality Underlying conflicts generally involve the disclosure of PHI as part of the legal process, rather than use of the information to improve, reduce disparities or create transparency No evidence in the cases that HIPAA preemption poses a barrier to HIT interoperability

24 Overwhelming Number of HIPAA Preemption Cases Involve State Legal Process Disputes

25 Context of Disputes The cases typically involve state laws that govern what information can be used in a pre-trial or trial proceeding The legal question involves access to PHI in –court-supervised discovery in lawsuits between private litigants –government or insurance investigations Courts have concluded that HIPAA is procedural in nature and does not create new substantive federal rights (e.g., new physician/patient privilege) –HIPAA establishes procedural steps that covered entities must follow in order to use/disclose PHI or, more typically, to justify withholding PHI from requester Cases illustrate the flexibility that covered entities have to determine whether and under what circumstances they will disclose No instances in which a more stringent state law blocks provider disclosure for patient care purposes

26 Types of Entities Involved in Dispute Over PHI Total Number of Cases = 113 GW HIPAA Case Law Database, 11/21/06

27 Types of Underlying Claims

28 Types of Claims, cont. The most common scenario involves a health care provider attempting to either shield PHI from disclosure to a patient or third party or obtain it for defensive purposes in a liability action –Depending on the facts and the nature of the dispute, the same type of entity might attempt to seek or deter disclosure –HIPAA is used as both a sword and a shield

29 Nature of PHI Dispute Total Number of Cases = 113 GW HIPAA Case Law Database, 11/21/06

30 Role of Covered Entities Although they may not always be litigants, covered entities are always involved in the dispute, since typically they are the holders of PHI at issue Three basic questions confront the covered entity: –Must the PHI be disclosed? –May the PHI be disclosed? –Is the disclosure prohibited?

31 What are the Courts Doing to Resolve Potential Disputes over PHI? Clear trend in cases: reconciliation of state and federal law to avoid the type of conflicts that would unduly burden data exchange Courts nearly always find a way to allow the covered entity to comply with both HIPAA and state law Court decisions frequently focus not on whether disclosure can be made, but on terms and conditions of disclosure, permissible purposes and uses, and extent of disclosure required –Few cases in which disclosure barred per se.

32 Resolution of Disputes, cont. How do the courts avoid conflicts between HIPAA and state law? –Pathway to reconciliation: discretionary power of covered entities to disclose information under HIPAA so no HIPAA bar to complying with state laws Many disclosures are “permitted” under HIPAA; very few are required or prohibited Most confusing category of permitted disclosures: those that are required under state law (36/113 cases) Covered entity is “permitted” to comply with requirements of state laws

33 Conclusions No evidence in case law that HIPAA or state privacy laws are barriers to disclosure of PHI for: – treatment –creation of transparent interoperable HIT systems, or –using aggregated and/or de-identified PHI for patient safety, improving quality or reducing disparities Vast majority of cases focus on use of PHI in legal process itself

34 Conclusions, cont. Clear desire of courts to reconcile state disclosure laws with HIPAA and to avoid conflicts –Generally disclosure sought is permitted by HIPAA –Therefore covered entities can comply with state law if they want to Covered entities can minimize problems by adopting clear and detailed privacy policies thus substituting their uniform policies for varying state laws Courts have concluded that HIPAA creates no new substantive rights but rather establishes a process for managing and disclosing PHI

35 Policy Implications If Congress were to expand HIPAA preemption and substitute uniform federal standards for more stringent state laws, the most serious and potentially disruptive impact would be on state legal process It is unclear that creating a federal ceiling as well as floor through HIPAA would improve legal certainty and reduce litigation –Traditional “field preemption” still ambiguous “relate to” health information privacy/health information systems “in connection with” privacy, confidentiality, security of PHI Perhaps the bigger challenge is reconciling HIPAA with other federal laws (e.g., Medicaid, Medicare, privacy standards for federally funded alcohol and substance abuse treatment programs)

Health Information Protection Taskforce Activities to Date

38 Our Charge Support the State Alliance for e-Health on issues regarding the protection of consumer health information that ensures appropriate interoperable, electronic health information exchange (HIE) within states and across states; and develop and advance actionable policy statements, resolutions, and recommendations for referral to the State Alliance on these issues.

39 Revised Work Product Health Information Protection Taskforce Work Product (accepted by the Taskforce on February 23, 2007; accepted by the State Alliance on March 30, 2007) (1)Conduct an analysis that: a)examines the rationale behind the major state health privacy protection laws that affect the sharing of health information across entities (whether paper- based or electronic); b)discusses the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment; and c)provides recommendations for addressing issues arising from such protections.

40 Approach to Work Product Pre-work product activities (March/April 2007): 1.Determine categories of major state health privacy protection laws to be considered (completed) 2.Develop privacy principles to use as a metric in conducting analysis  Gain an understanding of the benefits to an individual’s health from electronic exchange of health information  Gain an understanding of privacy benefits and risks/gaps in the electronic exchange of health information 3.Identify examples from 3-4 states of representative laws in each of the identified categories

41 Approach to Work Product Phase I: Examine rationale behind major state health privacy protection laws (May 2007) 1.Identify rationale behind each of the representative laws or categories of laws (gather state perspectives, both historical and current)

42 Approach to Work Product Phase II: Determine the applicability of each kind of protection, with an emphasis on an individual’s health in an electronic HIE environment (June 2007) 1.Determine if the rationale behind each category of state health privacy laws is still relevant today and relevant to the electronic exchange of health information, with an emphasis on an individual’s health

43 In Determining Applicability… Develop or adopt a set of privacy principles to use as a metric to assess the applicability of the major state health privacy laws specific to the exchange of specially protected health information for the purposes of treatment in an electronic HIE environment. Build on existing privacy principles.

44 Approach to Work Product Phase III: Provide recommendations to the State Alliance (July 2007) 1.Determine which categories of laws are still relevant in an electronic environment and frame recommendations to states (through the State Alliance) on how they can evaluate existing state law protections in the context of an electronic environment

45 Approach to Work Product Post-work product activities: (August-September 2007) 1.Create resources for states to support implementation of each recommendation. Resources could include: a. Example situations (e.g., vignettes) b. Model laws c. Tool kits

46 Identified Categories of Major Health Privacy Protection Laws Types of Information Mental health and substance use HIV and other communicable diseases Genetic information Disability Uses of Information Treatment Payment Health care operations Public health Clinical research First response to emergencies Access by Whom to Information Individual’s access to information about them Provider (physicians and hospitals) access to patient information Personal representatives access to patient information (i.e., minors and incapacitated adults)

47 Focus Area Considerations Under existing state privacy laws: What does the law say about …  Who has the permission to access?  How is access authorized? What was the underlying rationale for the legal requirement? Is the rationale applicable in electronic exchange environment? If it is and the legal requirement is also applicable, are there technical solutions that can facilitate exchange while ensuring protections are in place? If the rationale is no longer applicable, should (and can) the legal requirement be modified? If so, what are the steps to modify the law? (i.e., model law) If the legal requirement cannot be modified, what other kinds of tools and resources can the Taskforce provide to help the states?

48 Parking Lot Issues Provider liability Enforcement Choice of law

49 Possible Taskforce Outcomes Work product report  Recommendations on how states can address privacy and security challenges to electronic health information exchange Privacy framework/principles Tool kit Model law Vignettes

April 25, 2007 HITSP Security and Privacy Johnathan Coleman, CISM, CISSP Principal, Security Risk Solutions, Inc. HITSP Security and Privacy Technical Committee Facilitator

52 Evaluation of Standards Harmonization Process for HIT Agenda 1.Relationship between HITSP, HISPC and CCHIT 2.HITSP Charter and Goals 3.Harmonization Process 4.Current Status of HITSP Security and Privacy Activities 5.HITSP Security and Privacy Constructs under Consideration 6.HITSP Contact Information

53 Evaluation of Standards Harmonization Process for HIT A public-private “Community” was then established to serve as the focal point for America’s health information concerns and drive opportunities for increasing interoperability Healthcare Information Technology Standards Panel (HITSP) Nationwide Health Information Network Architecture Projects (NHIN) The Health Information Security and Privacy Collaboration (HISPC) The Certification Commission for Healthcare Information Technology (CCHIT) American Health Information Community The Community is a federally-chartered commission and will provide input and recommendations to HHS on how to make health records digital and interoperable, and assure that the privacy and security of those records are protected, in a smooth, market- led way. HITSP includes 348 different member organizations and is administered by a Board of Directors 24 SDOs (7%) 247 Non-SDOs (71%) 30 Govt. bodies (9%) 12 Consumer groups (3%) 36 Project Team and Undeclared (10%) HITSP includes 348 different member organizations and is administered by a Board of Directors 24 SDOs (7%) 247 Non-SDOs (71%) 30 Govt. bodies (9%) 12 Consumer groups (3%) 36 Project Team and Undeclared (10%)

54 Evaluation of Standards Harmonization Process for HIT The HITSP team is charged with completing eleven different tasks, with current efforts focused on the harmonization process The Community HHS Secretary Mike Leavitt, Chair Project Management Team Executive in Charge, F. Schrotter, ANSI Program Manager, L. Jones GSI Deputy PM, J Corley, ATI Project Manager, Julie Pooley, Booz Allen Project Management Team Executive in Charge, F. Schrotter, ANSI Program Manager, L. Jones GSI Deputy PM, J Corley, ATI Project Manager, Julie Pooley, Booz Allen Harmonization Process Delivery Technical Manager Joyce Sensmeier, HIMSS Harmonization Process Delivery Technical Manager Joyce Sensmeier, HIMSS Harmonization Process Definition Technical Manager Michelle Deane, ANSI Harmonization Process Definition Technical Manager Michelle Deane, ANSI HHS ONCHIT1 PO, Dr. John Loonsk HHS ONCHIT1 PO, Dr. John Loonsk HITSP Dr. John Halamka, Chair Member populated Technical Committees Eleven Tasks are included in this contract: 1.Comprehensive Work Plan 2.Conduct a Project Start Up Meeting 3.Deliver Recommended Use-Cases 4.Participate in related meetings and activities, including the AHIC Meetings 5.Develop a Gap Analysis 6.Standards Selection, Evaluations and Testing 7.Define a Harmonization Approach 8.Develop Interoperability Specifications 9.Develop and Evaluate a Business Plan for the self-sustaining processes 10.Submit Monthly Reports – ongoing efforts 11.Assist with communications – ongoing efforts

55 Evaluation of Standards Harmonization Process for HIT HITSP formed Technical Committees to focus on AHIC breakthrough areas - Initial focus is on 3 use cases  Biosurveillance -- Transmit essential ambulatory care and emergency department visit, utilization, and lab result data from electronically enabled health care delivery and public health systems in standardized and anonymized format to authorized public health agencies with less than one day lag time.  Consumer Empowerment -- Deploy to targeted populations a pre-populated, consumer-directed and secure electronic registration summary. Deploy a widely available pre-populated medication history linked to the registration summary.  Electronic Health Records -- Deploy standardized, widely available, secure solutions for accessing laboratory results and interpretations in a patient-centric manner for clinical care by authorized parties.  Security and Privacy – Initially a formed as a Work Group to address Security and Privacy (S & P) requirements of the first three Use Cases. Now a Technical Committee charged with addressing S & P requirements for all Use Cases provided to HITSP.

56 Evaluation of Standards Harmonization Process for HIT HITSP Coordinating Committees and Leadership  Foundations Committee –Steve Wagner –Bob Dolin  HITSP Process Review Committee –Lynne Gilbertson –Erik Pupo  HITSP-CCHIT Joint Work Group –Jamie Ferguson, Kaiser Permanente  Harmonization Readiness Committee –Lynne Gilbertson  Business Plan Committee –Steve Lieber  International Landscape Committee –Bill Braithwaite  Governance Committee – Michael Aisenberg  HITSP Technical Committee - Care Delivery –James Ferguson, Kaiser Permanente –Steve Hufnagel, DoD –Steve Wagner, Department of Veterans Affairs  HITSP Technical Committee - Consumer Empowerment –Elaine Blechman, PhD, University of Colorado, Boulder –Charles Parisot, GE Healthcare –Scott Robertson, Kaiser Permanente  HITSP Technical Committee- Population Health –Floyd Eisenberg, MD, MPH, Siemens Medical Solutions –Peter Elkin, MD, Mayo Clinic College of Medicine –Shaun Grannis, Department of Family Medicine, Indiana University School of Medicine  HITSP Technical Committee- Security and Privacy –Cochair nominations in progress HITSP Technical Committees and Leadership

57 Evaluation of Standards Harmonization Process for HIT I Harmonization Request Harmonization Process Steps II Requirements Analysis III Identification of Candidate Standards IV Gaps, Duplications and Overlaps Resolution V Standards Selection VI Construction of Interoperability Specification VII Inspection Test VIII Interoperability Specification Release and Dissemination IX Program Management Begin Support Receive Request The actual harmonization process is a series of steps taken by industry stakeholders within the context of HITSP

58 Evaluation of Standards Harmonization Process for HIT HITSP Security and Privacy Goals/Charter  Harmonize HITSP standards for EHR-Lab reporting, Population Health and Consumer Empowerment with relevant Security and Privacy standards.  Convene regular meetings with adequate representation from each TC to review current Interoperability Specifications and identify areas of Security and Privacy that were previously deferred. –This will be expanded to include Security and Privacy requirements from the ER- EHR Use Case and other new Use Cases provided to HITSP  Begin work on identifying security standards, approaches, and identifying unresolved issues. Leverage activities of other Security and Privacy related workgroups. –The purpose of the HITSP SPWG/TC is to ensure that technical standards to address privacy and security needs are identified and harmonized. We will rely on both the HISPC project and the State Alliance for e-Health to inform our work surrounding policy and regulatory considerations.

59 Evaluation of Standards Harmonization Process for HIT Current Status of HITSP Security and Privacy Activities  Review Use Cases and identify Security and Privacy Requirements. This will serve to populate the Requirements sections of the Requirements, Design and Standards Selection (RDSS) document. Completed  Identify candidate standards (from our Inventory of Standards and other sources), and sort them into buckets which correspond to the security and privacy requirements (potential HITSP constructs). Completed  Develop Requirements, Design, Standards Selection (RDSS) document Completed –Technical Actors, Business Actors & mappings from use cases –UML diagrams (initially a high level relationship roadmap) –Identify Security and Privacy Requirements and map to use cases –Public Comment Period: 05/16 – 06/14  Apply Tier 2 criteria to select from the existing standards for each of our potential constructs. Current Activity  Develop HITSP Security and Privacy Constructs which will frame implementation of the selected standards to achieve the requirements as identified in the Use Cases. Current Activity  Inspection Test and Public Comment: 07/20 – 08/16  Comment Resolution and Panel Approval:08/17 – 10/15

60 Evaluation of Standards Harmonization Process for HIT JANFEBMARAPRMAYJUNJULAUGSEPOCTNOVDEC HITSP 2007 Timeline 02/05/07 HITSP Board 04/23/07 HITSP Board 07/09/07 HITSP Board 10/09/07 HITSP Board 03/19/07 HITSP Panel 05/11/07 HITSP Panel 09/07/07 HITSP Panel 03/06 – 03/08 TC Face to Face Chicago IL 5/08 – 5/10 TC Face to Face Arlington VA 6/18 – 6/20 TC Face to Face San Diego CA 09/04 – 09/06 TC Face to Face Arlington VA Public Comment Inspect Test and Public Comment Implementation Support and Testing (with annual updates as required) Comment Resolution and Panel Approval 02/15 – 05/16 04/13 – 05/16 IS Construct Development 05/17 – 07/19 07/20 – 08/1608/17 – 10/15 Implementation Support and Testing (includes minor document updates) EHR, CE and BIO v 2.0 Activity 1 – Version 2.0 of Existing EHR, CE, BIO ISs Activity 2 – Security and Privacy for All Use Cases Activity 3 – New Emergency Responder EHR Use Case On-going Support 10/15/07 HITSP Panel 07/16/07 HITSP Panel 02/12/07 HITSP Panel Activity 4 –New Use Cases from AHIC Detail Schedule to be Established Upon Review of the Use Cases Work Plan and Schedule Overview S&P and EHR-ER v 1.0 Requirements, Design, Standards Selection Public Input on S&P 05/17 – 06/14

61 Evaluation of Standards Harmonization Process for HIT HITSP Security and Privacy Constructs under Consideration 1. Secured Communication Channel (includes mutual node authentication, integrity and confidentiality of transmission contents) 2. Collect and Communicate Security Audit Trail 3. Privacy Consents 4. Verify Privacy Consents 5. Manage Entity Identity Credentials 6. Document Integrity 7. Authenticate User 8. Manage and Control Data Access 9. Non Repudiation 10. Fail-Safe/Emergency access (now rolled into #4 and #8) 11. Consistent Time

62 Evaluation of Standards Harmonization Process for HIT HITSP Security and Privacy Constructs under Consideration

63 Evaluation of Standards Harmonization Process for HIT Questions  For General Technical Committee related questions please contact: Joyce Sensmeier MS, RN-BC, CPHIMS, FHIMSS Vice President, Informatics HIMSS 230 East Ohio, Suite 500 Chicago, IL 60611-3269 Phone: 312-915-9281 email: jsensmeier@himss.orgjsensmeier@himss.org Or Jessica Kant Coordinator, Standards Harmonization Healthcare Information & Management Systems Society 230 E. Ohio St., Suite 500 Chicago, IL 60611 Phone: 312-915-9283 Fax: 312-915-9511 email: jkant@himss.orgjkant@himss.org  For HITSP Security and Privacy related questions please contact: Johnathan Coleman Principal, Security Risk Solutions, Inc. 690 Libbys Pt. Mt. Pleasant, SC 29464 Tel: 843-442-9104 email: jc@securityrisksolutions.com

64 Evaluation of Standards Harmonization Process for HIT Supplementary Slides  The following slides to be used during discussions if necessary

65 Evaluation of Standards Harmonization Process for HIT HITSP Definition of a Standard  A standard specifies a well-defined approach that supports a business process and: (1) has been agreed upon by a group of experts; (2) has been publicly vetted; (3) provides rules, guidelines, or characteristics; (4) helps to ensure that materials, products, processes, and services are fit for their intended purpose; (5) is available in an accessible format; and (6) is subject to an ongoing review and revision process.

66 Evaluation of Standards Harmonization Process for HIT Tier 2 Standards Readiness Criteria  Suitability –The standard is named at a proper level of specificity and meets technical and business criteria of use case  Compatibility –The standard shares common context, information exchange structures, content or data elements, security and processes with other HITSP harmonized standards or adopted frameworks as appropriate  Preferred Standards Characteristics –Approved standards, widely used, readily available, technology neutral, supporting uniformity, demonstrating flexibility and international usage are preferred  Standards Development Organization and Process –Meet selected criteria including balance, transparency, developer due process, stewardship and others.  Total Costs and Ease of Implementation –Deferred to future work

67 Evaluation of Standards Harmonization Process for HIT HITSP Technical Committees Terms of Reference  Perform high level Requirements Analysis and Design of HITSP Interoperability Specifications, transaction packages, transactions, components, constructs including requirements analysis, and minimum data set.  Identify, analyze and document gaps and duplications within the standards industry as they are related to each specific Use Case.  Review and scope statements of work for each new use case.  Provide a listing of all standards that satisfy the requirements imposed by the relevant use cases as well as readiness criteria that shall be used to evaluate the standard.  Select and evaluate recommended standards to meet the relevant Use Case.  Develop, review and evaluate ‘interoperability specifications’ for the selected standards.  Submit recommendations to HITSP for review, approval and resolution.  Ensure timely response and disposition of comments.  Ensure on-going process for addressing corrections/change requests and resolutions.

68 Evaluation of Standards Harmonization Process for HIT HITSP Framework Basis for Interoperability Specification Template  HITSP receives Use Cases and Harmonization Requests from external sources, such as AHIC and ONC.  The Use Case or Request defines scenarios, business actors, and business and functional/interoperability requirements.  HITSP decomposes the Use Case requirements into scenario(s) and then into transactions providing context: technical actors, actions and content. It may create or reuse a transaction or a grouping of transactions (transaction package) based on commonality at this level.  Transactions are logical groupings of actions that are decomposed into components, which are groupings of base standards that work together, such as message and terminology.  Each HITSP construct, i.e., transaction package, transaction or component, may constrain the construct or standard below it. Constraints follow a strict hierarchy and are only imposed by the next higher construct.  Transaction packages, transactions and components all are potential candidates for reuse if a new set of requirements and context are successfully fulfilled by the existing construct.  While reuse is a HITSP goal, it is established in the context of a Use Case and its functional/interoperability requirements.  HITSP constructs are version controlled and, if reused, will be uniquely identified.

69 Evaluation of Standards Harmonization Process for HIT LevelDefinitionExampleRules Use Case or Harmonization Request  Defines business/functional requirements  Sets Context  ONC Harmonized EHR Use Case Interoperability Specification  Models business/ functional/ interoperability requirements  Identifies technical/system requirements to meet use-case  Identifies how to use one or more HITSP constructs to meet use-case requirements  HITSP EHR Interoperability Specification  Based on UML diagram to identify technical actors and actions  Sets context  Testable functional requirements  Ids transactions or transaction packages Transaction Package  Defines how two or more transactions are used to support a stand-alone information interchange within a defined context between two or more systems  Record Locator Service  Entity Identification Service  Thin context and interoperability requirements  Testable  Based on analysis of like technical actors, context and content harmonized across transactions  May be fulfilled by one or more transactions or composite standard  Expresses constraints on the transactions or composite standard Transaction  Logical grouping of actions, including necessary content and context, that must all succeed or fail as a group.  Query lab result  Send lab result  Fulfills all actions between two or more systems needed to meet one or more interoperability requirements  Testable  May be fulfilled by components or composite standard  Expresses constraints on components or composite standard Definitions and Rules

70 Evaluation of Standards Harmonization Process for HIT Definitions and Rules (cont.) LevelDefinitionExampleRules Component  An atomic construct used to support an information interchange or to meet an infrastructure requirement (e.g., security, logging/audit)  Lab result message  Lab result context  Typically will use one “primary” standard and may have other “secondary” standards  Expresses constraints on base or composite standards Base Standard  A standard capable of fulfilling a discrete function within a single category produced and maintained by a single standards organization.  Messaging standard  Security standard  Code set. Per HITSP definition the term “standard” refers, but is not limited to,: –Specifications –Implementation Guides –Code Sets –Terminologies –Integration Profiles Composite Standard  Grouping of coordinated base standards, often from multiple standards organizations, maintained by a single organization. In HITSP, it can serve as a component, transaction or transaction package functional requirements..  Integration profiles  Implementation guides  Health transaction services Per Definition above

72 Elements of Privacy Principles

74 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Analysis of Privacy Principles: An Operational Study John Lindquist President EWA IIT Board Member and Treasurer International Security Trust and Privacy Alliance (ISTPA)

75 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved What is the ISTPA? The International Security, Trust, and Privacy Alliance (ISTPA), founded in 1999, is a global alliance of companies, institutions and technology providers working together to clarify and resolve existing and evolving issues related to security, trust, and privacy ISTPA’s focus is on the protection of personal information (PI). ISTPA

76 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved ISTPA’s Perspective on Privacy Operational - Solution Focus  …“making Privacy Operational”  Recognizing this is a hard problem Privacy Framework Supporting Full PI Lifecycle Basis for Convergence  Shared Privacy Vocabulary  Personal Information Taxonomy  Standardized Set of Industry Specific Use Cases  Platform for Multidisciplinary Collaboration  Policy, Law, Regulatory, Business, Consumer, Security, Technology  Migrate to Privacy Engineering Discipline ISTPA

77 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved ISTPA Framework Submitted as ISO Publicly Available Specification Submitted by ISSEA (International Systems Security Engineering Association) in October 2003 resubmitted after technical changes June 4, 2004 Balloting was to close December 11, 2004 Caused significant discussion, including Privacy Technology Study Group under ISO JTC-1 Withdrawal requested November 22, 2004 Initiated work to address comments of the commissioners

78 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Four ISTPA Companion Projects Analysis of Privacy Requirements - Assessing data protection regulations, the Analysis proposes a common basis for understanding core components of privacy ISTPA-ISSEA Project: Map Security Safeguards to ISTPA Privacy Framework - Using the International Systems Security Engineering Association (ISSEA) Maturity Model for Information Security, security will be mapped to the Framework Master Tool Set for Privacy - Given any set of privacy principles or practices (input requirements), the ISTPA Tool Set will enable mapping into detailed actions under each Privacy Framework Service Framework revision

79 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Analysis- Laws and Directives Included The Privacy Act of 1974 (U.S.) OECD Privacy Guidelines UN Guidelines Concerning Personalized Computer Files EU Data Protection Directive 95/46/EC Canadian Standards Association Model Code (incorporated in the Personal Health Insurance Portability and Accountability Act (HIPAA) Privacy Regulations) US FTC statement of Fair Information Practice Principles US-EU Safe Harbor Privacy Principles Australian Privacy Act – National Privacy Principles Japan Personal Information Protection Act APEC (Asia-Pacific Economic Cooperation) Privacy Framework

80 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Analysis Methodology Select representative international privacy laws and directives Analyze disparate language, definitions and expressed requirements Parse expressed requirements into working set of privacy categories and terms Cross-map common and unique requirements Establish basis for a revised operational privacy framework to ensure ISTPA Framework Services supports full suite of requirements  Note: For purposes of this discussion, we use the term “principles” generically to describe privacy actions and more abstract principles defined in the laws and directives.

81 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Comparative Analysis-Sample OECD Guidelines – 1980  Collection Limitation  Data Quality  Purpose Specification  Use Limitation  Security Safeguards  Openness  Individual Participation  Accountability Australian Privacy Principles – 2001  Collection  Use and Disclosure  Data Quality  Data Security  Openness  Access and Correction  Identifiers  Anonymity  Transborder Data Flows  Sensitive Information

82 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Derive Common Privacy Requirements Accountability Notice Consent Collection Limitation Use Limitation Disclosure Access & Correction Security/Safeguards Data Quality Enforcement Openness Less common: Anonymity Data Flow Sensitivity

83 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved ‘Special Requirements’ Anonymity: a state in which data is rendered anonymous so that the data subject is no longer identifiable (Reference Source Used: EU Data Directive) Data Flow: the communication of personal data across jurisdictions by private or public entities involved in governmental, economic or social activities Sensitivity: specified data or information, as defined by law, regulation or policy that requires stronger security controls or special processing

84 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Analysis Study Observations Common Terminology Four Examples Illustrating More Granular Privacy Requirements

85 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Notice Information regarding an entity’s privacy policies and practices including: 1. definition of the personal information collected 2. its use (purpose specification) 3. its disclosure to parties within or external to the entity 4. practices associated with the maintenance and protection of the information 5. options available to the data subject regarding the collector’s privacy practices 6. changes made to policies or practices 7. information provided to data subject at designated times and under designated circumstances

86 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Consent The capability provided to data subjects to allow 1. the collection and/or specific uses of some or all of their personal data 2. either through an affirmative process (opt-in) 3. or implied (not choosing to opt-out when this option is provided) 4. including support for  Sensitive Information  Informed Consent  Change of Use Consent  and Consequences of Consent Denial

87 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Access and Correction Capability allowing individuals having adequate proof of identity 1. to find out from an entity, or find out and/or to correct 2. their personal information 3. at reasonable cost 4. within reasonable time constraints 5. with notice of denial of access 6. and options for challenging denial

88 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Data Quality Ensures that information collected and used is 1. adequate for purpose 2. relevant for purpose 3. not excessive in relation to the purposes for which it is collected and/or further processed 4. accurate at time of use and 5. where necessary, kept up to date, rectified or destroyed

89 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Next Steps: Path to Framework 2.0 Complete Final version of Analysis in May Use Analysis study to evaluate existing Framework Complete expansion of Framework functions, including function labeling Continue collaboration with ISSEA on security mapping Continue development of Master Toolset project to make Framework more accessible and usable Expected draft v 2.0: December 2007 or early 2008

92 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Accountability Reporting - made by the business process and technical systems which implement privacy policies- 1. to the individual or entity accountable for ensuring compliance with those policies 2. with optional linkages to sanctions

93 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Collection Limitation Constraints exercised by the data collector and user to limit the information collected to 1. the minimum necessary to achieve a stated purpose 2. and when required demonstrably collected by fair and lawful means

94 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Use Limitation Controls exercised by the data collector or data user to ensure that 1. personal information will not be used for purposes other than those specified and accepted by the data subject or provided by law 2. and not maintained longer than necessary for the stated purposes

95 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Disclosure The release, transfer, provision of access to, use for new purposes, or divulging in any other manner 1. of information by the entity holding the information 2. only with notice and consent of the data subject 3. the data collectors policies must be made known to and observed by third parties receiving the information 4. and sensitive health information disclosures must be managed

96 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Security/Safeguards Policies, practices and controls 1. that ensure the confidentiality, availability and integrity of personal information collected, used, maintained, and destroyed 2. and ensure that personal information will be destroyed or de-identified as required

97 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Enforcement Mechanisms to ensure 1. compliance with privacy policies, agreements and legal requirements 2. and give data subjects a means of filing complaints of compliance violations 3. and having them addressed 4. including recourse for violations of law, agreements and policies

98 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Openness Availability to individuals 1. of the data collector's or data user's policies and practices relating to their management of personal information 2. and for establishing the existence of, nature and purpose of use of personal information held about them

99 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Anonymity A state in which information or data 1. are rendered anonymous 2. so that the data subject is not identifiable

100 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Data Flow 1. The communication of personal data across geo- political jurisdictions by private or public entities involved in governmental, economic or social activities

101 Copyright © 1999-2007 International Security, Trust & Privacy Alliance -All Rights Reserved Sensitivity Specified data or information, as defined by law, regulation or policy 1. which requires specific security controls 2. or special processing

103 Elements of Privacy Principles

Certification Commission for Healthcare Information Technology Technology Considerations for Health Information Privacy: Role of Health IT Certification Alisa Ray Executive Director, Certification Commission for Healthcare Information Technology (CCHIT) State Alliance for e-Health Health Information Taskforce Meeting April 25, 2007

Certification Commission for Healthcare Information Technology Background in Brief

© 2007 | Slide 107 | Who Is CCHIT? CCHIT is an independent, nonprofit organization with the mission of accelerating the adoption of robust, interoperable health IT by creating an efficient, credible certification process

© 2007 | Slide 108 | CCHIT’s Role within the Health IT Strategy Standards Harmonization (HITSP) CCHIT: Compliance Certification Contractor Health Info Security & Privacy Collaboration (HISPC) Office of the National Coordinator American Health Information Community NHIN Projects Harmonized Standards Network Architecture Privacy Policies Governance and Consensus Process Engaging Public and Private Sector Stakeholders Certification of EHRs and Networks Strategic Direction + Breakthrough Use Cases Accelerated adoption of robust, interoperable, privacy-enhancing health IT Certification is a voluntary, market-based mechanism to accelerate the adoption of standards and interoperability

© 2007 | Slide 109 | Four Goals of Certification Reduce the risks of investing in health IT Facilitate interoperability of EHRs and emerging networks Enhance availability of adoption incentives and regulatory relief Ensure that the privacy of personal health information is protected

© 2007 | Slide 110 | Scope and Timing of Certification May 2006: Ambulatory (office-based) EHR certification launched May 2007: Development expanded to address 3 specialized areas (child health, emergency department, cardiology); more to follow August 2007: Inpatient (hospital) EHR certification to be launched July 2008: Network (RHIO / health information exchange) certification to be launched

© 2007 | Slide 111 | Evidence of Broad Acceptance of Certification Approximately 80 Ambulatory EHR products certified in first year Endorsement by physician professional societies: –American Academy of Family Physicians –American Academy of Pediatrics –American College of Physicians –American College of Emergency Physicians –Association of Emergency Physicians –Medical Group Management Association –Physicians’ Foundations for Health Systems Excellence Federal recognition under Stark/AKA safe harbor rules Payer IT incentive programs State and regional health information networks

Certification Commission for Healthcare Information Technology Current Certification Requirements in Security and Privacy

© 2007 | Slide 115 | Summary of 2007 EHR Security-Related Criteria User-, role-, and context-based access control (S1-S4) Audit trail of all information accesses (S5-S9) Authentication, session control, and password control (S12-S21) Protection and encryption of transmitted information (S24-S30) Backup and recovery of data (R1-R3) System integrity and reliability (R4-R17)

© 2007 | Slide 116 | Summary of 2007 EHR Privacy-Related Criteria Authorship and integrity of clinical documents (F54-F61) Patient annotation/correction (F71) Capture and manage patient consents (F147-F151) Maintain provider directories for purpose of user- and role-based access authorization (F210-F214) De-identification of data for export (F259) Maintain directory of provider-patient relationships and roles for access purposes (F240-F243) Enforce jurisdiction-specific privacy rules (F247-F251 – some items on roadmap for 2008 or 2009)

Certification Commission for Healthcare Information Technology Privacy Laws and Policies in a Networked Health Information Environment

© 2007 | Slide 118 | Needed: A Uniform Framework for Privacy Laws and Policies Parameters within the framework: –Common definitions for categories of health information Examples: demographics; prescriptions; HIV-related diagnoses; chemical-dependency-related treatment; etc. –Common definitions of parties sending and receiving information Examples: primary care physician; hospital; emergency room physician; home care nurse; etc. –Common definitions of contexts for information requests Examples: payment; treatment; emergency treatment; etc. –Common definitions of patient consent options Examples: opt-in; opt-out; partial opt-out; time-limited opt-in; allow emergency override; etc

© 2007 | Slide 119 | Needed: A Uniform Framework for Privacy Laws and Policies For health information exchange to function: –Rules covering disclosure can vary from state-to- state, but they must all be expressed within the uniform framework –Rules must be capable of being automated – health information networks will not function if human intervention is required for most disclosure decisions Recommended reading: Pritt J, Connor K, “The Implementation of eConsent Mechanisms in Three Countries: Canada, England and the Netherlands”, prepared under contract to SAMHSA, Feb 2007, http://hpi.georgetown.edu/pdfs/prittse-consent.pdf

Thank you! Q & A For more information: www.cchit.org

NYS’ Approach to Electronically Exchanging HIV Data for Treatment Jean Orzech Quarrier Associate Counsel April 26, 2007 _________________________________ Health Information Protection Task Force Meeting

123 Goals Discuss NYS laws re: release of HIV data for treatment Discuss NYS’ approach to electronic exchange of HIV data Comment on challenges/issues Address possible future directions for NYS and national assistance

124 NYS Laws on Release of HIV data for treatment Note: NYS has laws limiting release of any type of medical information for treatment General rule – Release of information gained in a professional capacity is prohibited without consent or when not authorized/required by law found in NYS laws governing lic. providers (EdL), lic. facilities (PHL) and in laws re: special categories of information (e.g. HIV, MH, genetic testing, etc.)

125 Specifically…. NYS HIV law (PHL Art.27-F; 1986) requires written special consent for disclosures unless an exception applies Can release to the patient without written special consent. The patient can redisclose at will Can release without written special consent if “necessary to provide appropriate care or treatment” Protection follows information/each redisclosure needs to be justified Notice restricting redisclosure is required (similar to 42 CFR Part 42)

126 NYS’ Approach to HIV Electronic Exchange Short term: Draft consolidated consent for use when loading or accessing the exchange (general info, HIV, mental health, etc.) Discuss need for HIV information with clinical experts Educate the public Long term: Continue investigating IT applications to feasibly and reliably redact sensitive data and assess the willingness of providers to participate in a fragmented system Consider legislation to allow up-loading and accessing of all data for treatment, with audit and enforcement safeguards Educate the public

127 Issues & Challenges Will patients and providers embrace the HIE? Patient issues: May perceive extraordinary protections of HIV data as minimized by the exchange “All or nothing” approach may drive the patients, who stand to benefit most, away from the exchange Many may favor a clear, simple choice which holds a potential for improved, coordinated care

128 Provider issues: Providers overwhelmingly favor access to all information for enhanced decision-making, complete evaluation and coordination of care Impossible to assess the need for information for evaluation and diagnosis without first seeing the information Categorization of data and redaction is burdensome & costly

129 Provider issues continued Varying redaction standards create unreliable records where completeness is unpredictable Liability risks to providers increase if redaction is not complete

130 Future Directions Need increased interstate collaborations Facilitate expedited standardization of data elements/data sets Look to national leadership for models on how to address special categories of data E.g. Federal position on loading and accessing alcohol and substance abuse data in HIEs Is an “all or nothing” consent approach acceptable to federal authorities? Issuance of a model form would help guide states in handling similar sensitive information situations E.g. favorable opinion on the acceptability of disclosing medicare/medicaid claims data for treatment purposes

131 Summary Including HIV data as part of a clinical data exchange promises to improve the quality of care for those infected Many compelling positions must be considered in decision-making regarding inclusion of such sensitive data into the exchanges National leadership will be helpful to states as they review how sensitive information can be integrated into exchanges Most of all, patient education is essential

132 Good luck to everyone as you deliberate on the way forward Thank you

134 State of California Department of Health Services, Office of AIDS Barbara Bailey, RDH, MS Acting Chief California’s Statutes and Practices Regarding Exchange of HIV Data for Treatment

135 Background  Health and Safety Code (HSC) 100119 designates the California Department of Health Services, Office of AIDS (OA) as the lead agency responsible for coordinating state programs, services and activities related to HIV/AIDS.  OA is comprised of: HIV/AIDS Epidemiology Branch HIV Education & Prevention Services Branch HIV Care Branch AIDS Drug Assistance Program

136 California Confidentiality Statutes  HSC 120980 - Requires that persons responsible for providing medical care obtain written permission before disclosing the results of an HIV test to a third party in any manner that identifies the individual who took the test.  HSC 121025 - Requires that state and local agencies maintain the confidentiality of HIV/AIDS-related public health records that contain any personally identifying information. Except for public health purposes, disclosure of such information must be authorized in writing by the individual named in the record or his/her guardian or conservator.

137 Penalties for HSC 120980 &121025  Each negligent disclosure is subject to a civil penalty of up to $2,500 plus court costs and actual damages.  Each willful or malicious disclosure carries a civil penalty of $5,000-$10,000 plus court costs and actual damages.  Each willful, malicious, or negligent disclosure resulting in economic, physical, or psychological harm to an individual who takes an HIV test is a misdemeanor punishable by imprisonment for up to one year and/or a fine of up to $25,000 plus court costs.

138  HSC 121022 requires that OA and local health department staff and contractors sign a formal Confidentiality Agreement before being allowed access to any confidential HIV-related public health records –Staff and contractors must sign at the time of employment and renew it every twelve months thereafter. California Confidentiality Statutes

139 California Confidentiality Statutes  HSC 123148 permits certain laboratory test results to be posted on the Internet or other electronic method if requested by the patient and deemed appropriate by the health care provider who ordered the test. –Consent of the patient is required –The electronic delivery of any HIV-related test result is specifically prohibited.

140 California Confidentiality Statutes  HSC 121010 allows disclosure of an individual’s HIV test result without prior authorization to: –The health care provider, but not to a health care service plan –An agent or employee of the subject’s health care provider who provides direct care and treatment –The subject of the test or the legal guardian or representative

141 Confidentiality Protections  OA staff: –All staff sign an annual confidentiality agreement (whether they work directly on client issues or not) –All staff have a legal & ethical obligation to protect client confidentiality –Staff working with confidential client information are physically located in a secure environment with restricted access –HIV/AIDS case reports (surveillance cases) are kept in a secure environment in a stand-alone system that is not connected to the Internet  All patients have a right to privacy and to expect that their confidential information: Will be handled with the utmost confidentiality Will be used only for public health purposes Will not be divulged without authorization to persons in a manner that identifies the individual named in the record, either directly or indirectly

142 Office of AIDS Treatment Programs  AIDS Drug Assistance Program (ADAP)  CARE/Health Insurance Premium Payment Program  HIV Care Branch –Home and Community-Based Care –AIDS Medi-Cal Waiver –AIDS Case Management –Therapeutic Monitoring –Early Intervention –Care Services –Housing Opportunities for Persons with AIDS –Residential AIDS Licensed Facilities Program

143 Transfer of HIV client information  Most OA care and treatment programs are HIPAA entities or work with protected health information and must follow federal and state laws regarding the confidentiality of client information.  HIPAA compliance is the responsibility of the local health care sites; however, OA ensures that our programs have appropriate consent forms for the release of confidential information.  OA staff with access to the Medical Electronic Data System, which holds confidential information about California’s Medicare clients, must annually sign an Oath of Confidentiality.  Clients of our publicly funded care and treatment programs must sign a release form before their confidential information is shared with/transferred to other providers.

144 AIDS Drug Assistance Program  Provides life-saving medications to clients who have no other means of paying for their HIV/AIDS drugs.  All ADAP clients: –Receive an ADAP Notice of Privacy Practices –Sign a consent to release confidential personal and medical information –Nearly all pharmacy transactions are electronic, utilizing the National Council for Prescription Drug Programs standard –Information shared electronically with pharmacy benefits manager and Public Health Service Bureau

145 AIDS Drug Assistance Program  ADAP Medicare Part D clients: –Clients sign a disclosure statement which allows OA to share confidential information with Medicare Part D plans –Files are encrypted using software installed on both the sending and receiving computer –Confidential password required to access information –Decryption instructions and encrypted files are sent via separate emails

146 ARIES: Web-based HIV/AIDS client case management system  Care services providers coordinate care for shared clients  Ensures provision of appropriate services  Avoids duplicate services  Service providers enter client demographic, program, medical and service data  Web-based with extensive security features  Client written permission is required for sharing data between care service providers

147 Phasing Out Older Systems  Several care-based data collection systems that function on stand-alone databases  Providers must download client data from personal computers and sent data on a diskette through the mail to OA  All programs using this system utilize client consent forms  Data collection by paper or data files creates chances for confidentiality breaches

148 Challenges – Considerations  A national data base of HIV client information: –May increase the risk of confidentiality breaches, due to the number of users accessing the data –May cause confusion by conflicting with the variety of state statutes regarding security and confidentiality –Would have a significant fiscal impact due to the education, outreach and training that would be required to implement a national program –May create concern among clients and advocates regarding trust of an electronic system of transferring confidential information –May result in unintended consequences.

149 Contact Information  Barbara Bailey, RDH, MS  Acting Chief  Office of AIDS  CA Department of Health Services  1616 Capitol Avenue, Suite 616  P.O. Box 997426 MS 7700  Sacramento, California  95899-7426  (916) 449-5905  bbailey@dhs.ca.gov bbailey@dhs.ca.gov  Website: www.dhs.ca.gov/AIDS

Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007.

Similar presentations

Presentation on theme: "Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007.

Similar presentations

Presentation on theme: "Health Information Protection Taskforce of the State Alliance for e-Health Monthly Conference Meeting April 25-26, 2007."— Presentation transcript:

Similar presentations

About project

Feedback