archive-org.com » ORG » M » MARKLE.ORG

Total: 1237

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • CT2 | Markle | Advancing America's Future
    that serve to tie a person s identity to a location or service such as a U S Mail box or a bank account and requires no face to face encounter This method is one of a subset of Knowledge based Authentication KBA methods in which a consumer is identified by answering a set of questions only she could reasonably be assumed to know Sometimes these questions involve historical information past addresses use of credit cards for certain transactions and sometimes they involve information generated as part of the KBA process itself as with the PayPal technique of generating specific deposits The ideal situation would be to measure effectiveness of proofing by a numerical target such as Wrongful issuance of credentials must be kept to an error rate below one in X where X would be at least a thousand patients This metric would be a 99 9 deflection of false positives in other words In the absence of such precision for either in person or remote proofing see 1D below the decision about when and how to use remote proofing will necessarily be in the hands of the person responsible for the security of patient data to be undertaken with two principles in mind Minimize false positives and don t rely on a single method Our recommendation is that at least two methods or sources be used in remote proofing processes For example the consumer presents authentication credentials issued to him by another institution and successfully responds to an online interrogation about information acquired through his relationship with a separate independent service This is because two methods are likely to have different strengths and weaknesses thus raising the cost of an attack while lowering its chance of success This is true for both defense i e it s less likely that a criminal could fraudulently obtain knowledge or credentials in two places than in one and for sustainability i e if one method becomes compromised the system would still have at least one untainted method still running to which it could add new methods without starting from scratch Approach 1D Begin Federal research on identity proofing quality This is not a recommendation to data holders but to the federal government We recommend that the National Institute of Standards and Technology NIST in collaboration with other interested agencies study current identity proofing practice wherever consumers are given access to their records remotely to provide or create metrics expressing the effectiveness of those various methods Discussion The current administration has made increasing accessibility of electronic health records to providers and citizens a national goal and the lack of well understood and generally agreed to authentication methods for consumers is clearly a hurdle This recommendation is intended to lead to a benchmark for future proposed systems to meet or exceed thus moving us out of the current situation of identity proofing ratified by habit but uninformed by measurement Recommendation 1E Do not use clinical data in the proofing process As a matter of privacy policy we recommend against using clinical data as validation data in a proofing process The reasons for this are articulated in the Connecting for Health paper Linking Health Care Information Proposed Methods for Improving Care and Protecting Privacy 4 Component 2 Recommendations for Issuing Tokens or Identifiers Upon successful completion of identity proofing it is necessary to issue acceptable tokens or identifiers to the consumer Recommendation 2A Bind the consumer s identity in such a way as to facilitate later authentication At the time of initial proofing the capture and retention of copies of the documents allows for re verification if needed at a future time If in person visits are used in identity proofing they present an opportunity to capture a biometric indicator such as photographs or fingerprints Discussion This process of connecting or binding of particular information or attributes to a particular physical person when combined with system monitoring can provide improved ability to discover certain types of fraud attempts in which attributes are used by multiple registrants However it is important to note that improved information collection of any sort also raises the requirements for securing the database where the records are stored Improvements in knowledge based authentication methods generate as an inevitable side effect more stored knowledge about the consumer knowledge that must be held securely to prevent near term defeat of the authentication system itself and to prevent identity theft Although database security is not in the scope of this paper we note that care must be taken to evaluate the security of the data held in aggregate as well as the security of person by person authentication Less reliable although at times more economically practical are password reminders as shared secrets that can be used to support later authentication or password reset requests A common example is for the consumer to be forced to answer questions such as pet names or mother s maiden name Care must be taken that these not be based on common questions that can be easily guessed or snooped Another possible source of shared secrets are questions the service asks of the consumer For example PayPal makes two small deposits in a new user s account then asks that the user report those amounts back to PayPal This removes the risk of trivial guessability though it requires a higher degree of integration with the financial system Interesting work is being done on zero knowledge authentication systems which reduce or eliminate the need for knowledge based secrets to be held by the authenticating party In a zero knowledge system the consumer proves who he is by using a secret that only he knows to perform a task that he could only perform with that secret Imagine that you see someone unlock a door that you know can open with only one key You could conclude that the person has that particular key without you needing to see a copy of the key yourself Zero knowledge based systems have not yet been widely deployed and have significant management issues in their current implementations Still they should be watched closely as they may provide a way to increase authentication security without also increasing the privacy risk to consumers that comes with knowledge being held about them in various authentication databases Recommendation 2B Choose an appropriate token or identifier There are a variety of credentials available PINs cards tokens fobs with RF chips antennas and fingerprints are a few examples of a rapidly growing array of tokens Discussion Many different types of tokens or identifiers can be used to good effect in authentication processes Much depends on the budget and infrastructure of the token issuer and the tolerance of consumers to remember and use the token appropriately Recommendation 2C If using passwords as tokens enforce strong passwords Requiring and enforcing rules to create strong passwords 5 i e passwords that are not easily guessable is one of the first relatively easy steps that will dramatically increase the security of the username and password token Discussion The username and password combination is the most commonly used token Extremely valuable and potentially risky transactions are conducted millions of times each day employing the protection of username and password Many of the tokens and identifiers listed in Recommendation 2B are essentially variations on the concept of username and password incorporating a variety of technologies to improve on the basic concept Used appropriately the username and password combination provides significant protection at very moderate cost and user inconvenience However if unguided by a set of guidelines or password requirements many consumers tend to create easily guessable passwords and otherwise create the opportunities for compromise of their identity Many systems now prevent the use of dictionary terms as passwords or consecutive or repeating strings of numbers or letters or other easily guessable phrases Some require the use of at least one number a letter and another keyboard character Some systems will provide a rating of the strength of the password as it is created by the user The fundamental challenge with strong password requirements is that they not only make it harder for illegitimate users to guess a password they can make it harder for the legitimate user to remember it If strong password requirements are too onerous they may encourage legitimate users to compensate through insecure practices such as writing down a password and leaving it next to an unattended computer It is increasingly common to supplement the username and password combination with monitoring of the requesting machine e g source IP address machine and browser characteristics Such monitoring which we discuss further below requires no additional issuing of tokens to the user Recommendation 2D Limit attempts on passwords Given sufficient time access and attempts any password will eventually succumb to attempts to guess it Limiting the number of consecutive and total attempts to enter a password requiring periodic changes to the password and other relatively low cost relatively low inconvenience requirements for use of passwords make password guessing an unacceptably difficult approach to compromising tokens Recommendation 2E Establish a clear policy on requirements for password changes Although an inconvenience to end users it may be reasonable to require consumers to create new passwords at regular intervals Each system should decide locally whether to enforce a policy requiring that consumers change their passwords over time However if such policies are enforced it s critical that consumers be given clear explanations on the methods and reasons for resetting their passwords Discussion The value of tokens can diminish over time For example many private and government organizations still use Social Security numbers not only as identifiers but also as tokens 6 and it is precisely because of this ubiquity of uses that Social Security numbers have been a boon to identity thieves Similarly if a consumer uses the same password and password reminder at every site visited it is much less secure than if the consumer uses different secret codes at each site s login On the other hand consumers may have trouble coming up with strong passwords that they can remember and the burden of having to do so frequently could drive down utilization The value of forcing consumers to change passwords is hotly debated and our work group did not feel strongly about making a recommendation one way or the other Component 3 Recommendations for Ongoing Monitoring It is important to perform periodic or ongoing processes to continually improve upon the initial proofing and to weed out compromised identities Recommendation 3A Conduct appropriate ongoing monitoring Ongoing monitoring is an essential third component of appropriate authentication because of inherent weaknesses in the first two components i e identity proofing and issuing of tokens Given the widespread compromise of documents used for initial identity proofing and the large and growing incidence of identity crimes the function of authentication should be thought of as an ongoing process rather than a gateway to be passed through one time Once the consumer s identity is proofed and the token is issued systems should establish the behavior patterns of individuals and alert authorized parties when behavior falls out of the established pattern For example credit card companies have algorithms to detect sudden changes in charging behavior triggering a telephone call to the consumer to investigate possible fraud Discussion Identity proofing is often used as a gateway process It is merely a perimeter defense performed once and not revisited Once identity proofing is completed a registrant is an insider of the system And there is often much secondary reliance on this initial proofing such as airport security relying on a state issued driver s license In the Digital Age the outside inside relationships change continually Allowing network access to partners customers users and some unintended participants quickly renders perimeter defenses insufficient Additionally much of the fraud and abuse comes from people accurately identified or from identities that were compromised after the initial proofing process as well as from inside authorized users There is a robust and active population that continually probes and prods for opportunities to compromise systems and almost immediately shares with others any new intelligence gained The risks and threats to systems change continuously The practices and processes to respond to these threats must likewise change The automated ability to monitor individual behavior for fraud varies significantly from organization to organization depending in part on the type of organization what data it captures and what it is permitted to do with the data Valuable techniques include analysis of transaction history and location keystroke patterns and others Detailed recommendations would rapidly become dated and ineffective Decisions about an ongoing monitoring process must be made locally The U S government provides some guidance for ongoing monitoring as an integral part of an authentication process in the NIST Special Publication 800 100 Information Security Handbook A Guide for Managers 7 Behavior pattern monitoring can include information about the method of login e g consumer s usual IP address machine and browser type etc or information about the types of resources or data that the consumer typically accesses Recommendation 3B Enable consumers to view an immutable audit trail Consumers can become powerful allies in detecting identity fraud when they have access to the transaction history of their accounts We recommend that Consumer Access Services and PHR offerers provide authenticated consumers with online access to an immutable audit log displaying all accesses and data transactions involving their account Discussion Consumers now are able to review their own credit reports online providing an important and highly invested check on potential fraud or errors This recommendation is in keeping with Principle No 3 of this document The Connecting for Health Common Framework document Auditing Access to and Use of Health Information Exchange provides some guidance in this area of immutable audit 8 Component 4 Recommendations for External Audit and Enforcement When relying on a third party to perform proofing or issuing of tokens or both some mechanism of audit and redress is essential to establishing a chain of trust Recommendation 4A Ensure that third parties are observable in how and how well they are performing identity proofing token issuing and ongoing monitoring or any related services to authenticate consumers One recommended practice is to have a contractual commitment for the parties to notify each other if either detects system compromise above a certain threshold or fails to comply with agreed procedures Discussion A fundamental premise of the Common Framework for Networked Personal Health Information paper is that Consumer Access Services will emerge to help consumers network their PHRs with connections to multiple sources of health data and services In order to facilitate the consumer s requests for digital copies of his information from Health Data Sources all parties must be assured of the individual s identity and bona fide authorization to share data Simply put such transactions require trust It will be impossible to trust and rely on any third party s authentication if those third parties practices are not observable either directly among contracted parties or via some industry accepted auditing and validation mechanism Recommendation 4B Ensure a mechanism for enforcement and redress for bad actions There needs to be a commonly accepted mechanism agreed upon in advance to redress unacceptable practices and eject bad actors Discussion Audit enforcement and redress are general issues for Consumer Access Services not just with the task of authentication All this is framed against the larger issues of binding Consumer Access Services to policies and accountability generally and against the general fragmentation of the health care industry a fragmentation that may increase as Consumer Access Services enter the picture Recommendation 4C Consider federation and or other contractual means to address Recommendations 4A and 4B If the Health Data Source Has not done its own identity proofing and token issuing for a consumer and Is considering a request from a Consumer Access Service to pass information on the consumer s behalf and Does not have sufficient direct means to monitor or observe the Consumer Access Service s authentication practices per Recommendations 4A and 4B Then we recommend that The Health Data Source should have strong mechanisms in place for identifying the Consumer Access Service itself The Consumer Access Service should be contractually bound to policies or to a group that sets and enforces shared policies e g the E Authentication Federation EAF Electronic Authentication Partnership EAP or similar The Consumer Access Service should use at least EAP Level 2 or equivalent We believe the EAF EAP is a good framework for a discussion on finding an acceptable degree of authentication certainty and policy enforcement Although some organizations might choose to join the EAF or the EAP there is likely no one size fits all answer Different business relationships and different consumer populations will likely require a variety of authentication services for their transactions Some consumers may even demand higher level authentication stringency for certain services Discussion We emphasize that the above scenario is not the only way to approach the problem See Appendix F for a draft architecture discussion Point to point trust is conceptually simplest from the point of view of any given pair of actors but pairwise trust exposes the system as a whole to daunting complexity Similarly a single national actor coordinating trust on behalf of everyone is not feasible at this time both because of the realities of fragmentation and the business context and also because the policing problem for a single actor is acute If these two extremes are in fact impractical this suggests some sort of chain of trust with mutual policing with various actors monitoring one another possibly in contractually arranged groups Conclusion A Path Forward This paper is driven by a desire to allow U S consumers to access and gain value from their own health information Connecting for Health accepts that much of our valuable personal health data is stored and managed by numerous entities The next key challenge is to establish the rules and techniques that establish trust among participants over a network of networks Policy rules will be needed in a number of areas including patient consent secondary use and data management Identity has quickly emerged as a primary problem in network access particularly given the sensitivity of personal health information A well understood and implemented Common Framework for managing health consumers identity is a prerequisite to networked use of personal health records The recommendations in this paper are based on the technologies and practices current at a particular moment and our desire to stimulate national progress in addressing this particular obstacle to consumers electronic access to their health information The problems of identity proofing and authentication are widely felt by all industries handling sensitive data or electronic transactions and as a result there is rapid evolution in the tools available for authentication Any process of authentication for consumer access anywhere in health care must be regularly re evaluated to factor in both new threats and new capabilities Many health care entities have significant interest in some form of networked personal health records The relationships they forge could have significant impact on possible trust scenarios for consumer authentication In addition there is a critical need to expand consumer education about techniques to safeguard identity in the Information Age Consumers should understand first that there are tradeoffs between security and convenience and second what the tradeoffs mean for them These many trends new threats new business relationships emerging technologies and consumer awareness and behavior all warrant close monitoring They certainly will have more impact on future health information sharing environments than the modest recommendations in this paper We do however hope that this paper contributes to a growing consensus that the path forward on consumer authentication requires careful thinking new research and innovative approaches Appendix A Acknowledgements Connecting for Health thanks the following Work Group members for participating in the rich discussion that resulted in this paper Chair Clay Shirky New York University Graduate Interactive Telecommunications Program Work Group Paula Arcioni New Jersey Office of Information Technology Ernie Argetsinger Omnimedix Institute Siddharth Bajaj VeriSign Inc Dan Combs Global Identity Solutions LLC Jeremy Coote InterComponentWare Inc Maureen Costello Ingenix Phillip D Angio VeriSign Inc James Dempsey JD Center for Democracy and Technology Carol Diamond MD MPH Markle Foundation Martin Fisher MedicAlert Foundation International Thomas Foth Pitney Bowes Inc Christopher Gervais Partners Community HealthCare Inc Mark Gingrich MS RxHub LLC Janlori Goldman JD Health Privacy Project Philip Hagen MD Mayo Clinic Jonathan Hare Resilient Elizabeth Holland Centers for Medicare Medicaid Services Mark Johnson Vanderbilt University and Medical Center Jennifer Kerber Information Technology Association of America Kristy LaLonde Office of E Government Information Policy and Technology U S Office of Management and Budget David Lansky PhD Markle Foundation J P Little RxHub LLC Kathleen Mahan MBA SureScripts Georgia Marsh United States General Services Administration E Authentication Initiative former position Phil Marshall MD MPH WebMD Health Daniel Matthews Lockheed Martin Corporation Damon Miller CapMed Corporation A Division of Bio Imaging Technologies Inc Kim Nazi FACHE United States Department of Veterans Affairs Alison Rein AcademyHealth Eric Sachs Google Health Charles Safran MD Harvard Medical School Scott Schumacher PhD Initiate Systems Inc Donald Simborg MD Independent Consultant Michael Simko RPH Walgreens Pharmacy Services Michael Stokes Microsoft Corporation David Temoshok General Services Administration Office of Governmentwide Policy Robert Tennant MA Medical Group Management Association Jeanette Thornton MPA America s Health Insurance Plans Allison Viola American Health Information Management Association David Yakimischak SureScripts Federal and state employees participated in the Work Group but make no endorsement Participated in Work Group but makes no endorsement per employer policy The Connecting for Health Work Group on Consumer Authentication Policies for Networked Personal Health Information wishes to thank Josh Lemieux for his expertise and tireless help preparing this manuscript In addition we thank Clay Shirky for his leadership and work on this manuscript Without his unique ability to parse very complex issues carefully and adeptly we could not have achieved this paper We also thank Dan Combs and Stefaan Verhulst for their help researching and drafting portions of this document Appendix B Scope and Charge of the Work Group T he Work Group on Consumer Authentication and Health Information Exchange was charged with defining a framework to authenticate the identity of individual consumers consistent with Connecting for Health principles This includes identifying a baseline of policies and technologies to assert within acceptable thresholds of accuracy the identity of an individual consumer requesting copies of her personal data in an electronically networked health information environment The recommendations are intended to encourage a fresh approach to foster trust of all network participants and specifically to protect the consumer the health data holders and the Consumer Access Services from the following threats Defense against illegitimate access to health records This is defined in this paper as externally targeted or automated attacks to gain access into an individual s health information The attackers in this scenario could be either known to the consumer as with a relative or colleague looking at material inappropriately a targeted attack by someone not known to the patient as with a private detective trying to access records or an indiscriminate attack someone looking for anyone s health records possibly as a precursor to medical fraud Defense against identity theft The threat here is not to the clinical data per se but to the consumer s identifiers and demographics address date of birth Social Security Number health benefit eligibility number etc Protecting against identity theft is an obvious goal The key complication here is that it is very difficult to protect against family members posing as one another and it is not possible to design a system that covers all state regulations of parental access to their children s data Our Work Group did not focus on proxy access beyond the key principle that the identity of all proxies accessing the system be recorded as well as the identities of people for whom they are proxies so that should a proxy later lose access their authentication tokens can be revoked separately from the main account The following issues fell outside of the scope of this Work Group but we list them here to acknowledge their importance in creating a trusted health information sharing environment for consumers Consumer Issues Consumer Behavior We are not addressing what consumers do with their copies of personal health data We live in an age in which individuals are increasingly self publishing on the Internet intimate details of their personal lives It was outside the scope of this Work Group to attempt to address the complexities of individual behavior and choice Nevertheless these are relevant concepts Consumers own experiences and individual preferences will no doubt shape this emerging area Phishing There is a parallel problem to consumer authentication related to the assurances provided by the entity hosting the consumer s data Mechanisms need to be in place to defend the consumer against phishing attacks where a consumer is directed to log into a seemingly legitimate web site or service but which is really a copy of an existing site with a similar URL The risk of such phishing in medical contexts is high however the defenses against the phishing problem require a different set of strategies than those outlined in this document Data Storage Issues Data Security Methods to encrypt and secure health data repositories are beyond the scope of this paper We focus on defense against unauthorized users defeating authentication systems not attacks on larger data stores For purposes of this paper we accept as a precondition that all actors have good physical security practices The digital signing of records is also outside the scope of this paper Data Policies Also out of scope of this paper are policies for data custodianship and data sharing other than those related to identity proofing and authentication The parallel Connecting for Health Work Group on Consumer Access Policies for Networked Personal Health Information is working on recommendations for privacy policy disclosure and consent secondary use etc For purposes of this paper we accept as a precondition that the consumer has voluntarily initiated a PHR account and authorized all uses and exchanges of personal health data consistent with Connecting for Health principles for privacy 9 Business Issues Business relationships This paper does not address the necessary business relationships that would provide motivations for health data sources and PHR services to share data on the consumer s behalf or for intermediaries to emerge between them In summary this paper focuses on a framework for the authentication process when the individual wants to access or contribute personal health information electronically among health professionals or other health related entities HIPAA covered or not Appendix C Background on Connecting for Health Connecting for Health founded and operated by the Markle Foundation with additional support over the years from the Robert Wood Johnson Foundation is a public private collaborative organization with representatives from more than 100 organizations across the spectrum of health care stakeholders Its purpose is to catalyze the widespread changes necessary to realize the full benefits of health information technology HIT while protecting patient privacy and the security of personal health information Connecting for Health is continuing to tackle the key challenges to creating a networked health information environment that enables secure and private information sharing when and where it s needed to improve health and health care Connecting for Health has produced the following documents that lay the groundwork for this current work product focused on consumer authentication Linking Health Care Information Proposed Methods for Improving Care and Protecting Privacy February 2005 which describes an approach to matching patient records among disparate health care institutions 10 Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange April 2006 which elaborates and defines a set of policy and technical elements necessary to enable secure exchange of health records among providers across the Internet including a set of principles for privacy and fair information practices in a networked environment The Connecting for Health Common Framework is composed of nine policy documents on topics such as privacy notification audit and authentication of non consumer users of the network and six technical documents that elaborate technical specifications of a network approach based on those policies 11 The Architecture for Privacy in a Networked Health Information Environment April 2006 which describes a set of fair information practices that the Common Framework has endorsed to guide systems that support the exchange of personal health information These principles are Openness and transparency Consumers should be able to know what information exists about them the purpose of its use who can access and use it and where it resides They should also be informed about policies and laws designed to ensure transparency on how privacy is assured Purpose specification and minimization The purposes for which personal data are collected should be specified at the time of collection and the subsequent use should be limited to those purposes or others that are specified on each occasion of change of purpose Collection limitation Personal health information should only be collected for specified purposes and should be obtained by lawful and fair means Where possible consumers should have the knowledge of or provide consent for collection of their personal health information Use limitation Personal data should not be disclosed made available or otherwise used for purposes other than those specified Individual participation and control Consumers should be able to control access to their personal information They should know who is storing what information on them and how that information is being used They should also be able to review the way their information is being used or stored Data quality and integrity All personal data collected should be relevant to the purposes for which they are to be used and should be accurate complete and current Security safeguards and controls Personal data should be protected by reasonable safeguards against such risks as loss or unauthorized access destruction use modification or disclosure Accountability and oversight Entities in control of personal health information must be held accountable for implementing these principles Remedies Legal and financial remedies must exist to address any security breaches or privacy violations Connecting Americans to Their Health Care A Common Framework for Networked Personal Health Information December 2006 which envisions a consumer accessible data stream consisting of electronic copies of personal health data that have been captured at various points on a network e g doctor s offices hospital systems pharmacies and pharmacy benefit managers labs diagnostic imaging services etc 12 Appendix D Other Groups Working on Authentication The following paragraphs list several authentication projects that currently exist This list is based on input from Authentication Work Group members and is not comprehensive Electronic Authentication Partnership EAP Building off the work of the E Authentication Federation see below and other authentication federations EAP has developed as a multi industry partnership working on the vital task of enabling interoperability for electronic authentication among public and private sector organizations It is sort of a federation of federations This group is creating a framework for accrediting and compliance testing of participating Credential Service Providers CSPs and Relying Parties RPs EAP also addresses the issue of liability See http eapartnership org See Trust Framework web site http projectliberty org liberty content download 3736 24651 file liberty identity assurance framework v1 0 pdf E Authentication Federation The E Authentication E Government Initiative is one of the President s 24 cross agency E Government Initiatives Its mission is to put in place the necessary infrastructure to support common unified processes and systems for government wide use E Authentication recently launched the E Authentication Federation EAF a public private partnership that enables citizens businesses and government employees to access online government services using log in IDs issued by trusted third parties both within and outside the government Currently 13 different agency web applications are using the service EAF has focused on the creation of policies systems and relationships that reuse existing credentials to meet the needs of mostly federal government relying parties EAF has created a framework by which a variety of Credential Service Providers currently including federal state and private sector organizations issue credentials to be trusted by Relying Parties in the federal government Quotations taken from E Authentication web site http www cio gov eauthentication Privacy http www cio gov eauthentication documents EAprivacy htm E Authentication Guidance for Federal Agencies M 04 04 http www whitehouse gov omb memoranda fy04 m04 04 pdf NIST 800 63 E Authentication Technical Guidelines http csrc nist gov publications nistpubs 800 63 SP800 63V1 0 2 pdf NIST 800 53 Recommended Security Controls for Federal Information Systems http csrc nist gov publications nistpubs 800 53 Rev3 sp800 53 rev3 final updated errata 05 01 2010 pdf Liberty Alliance Project In 2001 a consortium of 30 organizations formed the Liberty Alliance Project The project s stated mission is to establish an open standard for federated network identity through open technical specifications Over the past few years they have published an open framework for deploying and managing a variety of identity enabled Web Services Liberty Alliance is currently working on a framework for deploying and managing interoperable strong authentication Liberty Alliance is a standards group Liberty Alliance is represented on the EAP and involved either directly or through efforts of members and the products and services they provide with the other efforts Quotations taken from Liberty Alliance Project web site http www projectliberty org eC3 eC3 is an alliance of state and local governmental associations Their mission is to advance the use of electronic commerce by governmental organizations As part of this mission they have published several white papers concerning identity management See http www ec3 org index htm SAFE Biopharma Association This identity management organization maintains and enforces the SAFE framework which permits bio pharmaceutical companies to digitally sign business to business and business to regulator transactions SAFE is a successfully operating federation which has solved a number of important cross boundary issues including those of private public sector and international boundaries Based in the health industry it is familiar with health issues and familiar to current industry participants Representatives of SAFE participate in EAP See http www safe biopharma org HSPD 12 FIPS 201 PIV On August 17 2004 President Bush issued Homeland Security Presidential Directive 12 HSPD 12 This directive called for a common identification standard for all federal employees and contractors Given this directive the National Institutes for Standards and Technology developed the Federal Information Processing Standards Publication 201 FIPS 201 entitled Personal Identity Verification of Federal Employees and Contractors PIV This project will provide credentials to 10 to 12 million people at a relatively high level of verification and authentication and could be rolled out to many others through various extensions See http www whitehouse gov news releases 2004 08 20040827 8 html See Personal Identity Verification web site http csrc nist gov piv program index html Real ID Act The Real ID Act was passed in 2005 by Congress The Act is intended to deter terrorism Among other things the law states that after May 11 2008 no Federal agency may accept for official purposes a state driver s license as proof of identity unless that state s driver s license meets certain requirements defined by the Real ID Act There is a debate as to whether the Act creates a national ID The debate aside unless the law is repealed it will likely have a significant impact on how individuals in America manage their identities Real ID requires issuance of a machine readable credential based upon enhanced identity verification as well as improved security practice and technology There will likely be many different ways to use the Real ID credentials as functions are built to extend the systems or use of the credentials and as States and or the Federal Government extend

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct2 (2016-02-10)
    Open archived version from archive

  • CT3 | Markle | Advancing America's Future
    Media Releases Member Commentary President s Letters Videos CT3 Purpose Audit trails are a basic requirement for electronic health information in EHRs and PHRs Consumer Access Services must provide consumers with convenient electronic access to an audit trail as a mechanism to demonstrate compliance with use and disclosure authorization s An audit trail as defined here is an easy to comprehend date time and source stamped historical record of significant activities and transactions that pertain to access of the consumer s account and the use and disclosure of personal data within Of note electronic audit trails have been in wide use in Internet banking a 2004 survey found that almost all banks provide joint account holders with a clear audit trail that details which account holder performed which transaction 1 The audit trail compiled and maintained by a Consumer Access Service should be the same audit trail displayed to the consumer and each audit trail entry should be immutable i e unchanging and unchangeable in content Persistence of the audit trail should be commensurate with the data persistence policies of the Consumer Access Service For example if the Consumer Access Service retains professionally sourced data for seven years then entries in the consumer s audit trail should persist for at least this same period of time Source stamping is particularly important for end users to evaluate the validity of information displayed from a consumer data stream There are cases when a given data element may have more than one source For example consider the case in which a Consumer Access Service is authorized to obtain the previous 90 days of prescription medication history on the consumer s behalf from a retail pharmacy clearinghouse When the information is imported into the consumer s application the clearinghouse is a source of the transaction Upstream of that transaction there were other sources like the doctor who wrote the prescription and the pharmacy that filled it Ideally the audit history should include each relevant upstream and downstream source Consumer sourced entries must be marked as such Recommended Practice Each Consumer Access Service should maintain an easy to comprehend and clearly labeled electronic audit trail containing immutable entries that pertain to the consumer s account information and policy consent Each entry should identify at a minimum who has accessed the consumer s records a date time and source stamp for each such access and the source of each significant transaction The audit trail should be retained at minimum according to the data retention practice of the service We suggest the following as auditable events activities Account Access attempts and outcomes i e successes or failures length of session including those by proxies Logout events including those by proxies Transactions and data Creation e g self reported allergy Modification e g self reported downward adjustment to a medication s dosage frequency View e g access of a problem list Export e g export of data to a PDA or spreadsheet Import e g import of data

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct3 (2016-02-10)
    Open archived version from archive

  • CT4 | Markle | Advancing America's Future
    limits are placed on their doing so HIPAA Regulations 45 C F R 164 514 provide standards for de identification including a list of 18 identifier data elements that must be stripped out in order for a limited data set to qualify as de identified 1 The Privacy Rule also allows a second way to de identify information by having a qualified statistician determine using generally accepted statistical principles and methods that the risk is very small that the information could be used alone or in combination with other reasonably available information by the anticipated recipient to identify the subject of the information The qualified statistician must document the methods and results of the analysis that justify such a determination This HIPAA regulation remains a reasonable industry standard for defining information as de identified in many circumstances today However it may not be fully identity protective in some contexts such as when applied to very small subsets of populations or with the ever increasing amounts of partially identifying information gathered in electronic environments See Appendix A for more on partially identifying information This reality will necessitate frequent monitoring of risk by policymakers in both the public and private sectors Recommended Practice Consumer Access Services should limit disclosures of identifying data to only those data that are necessary to perform the specified function s that the recipient is authorized to perform Care should be taken to limit the release or exposure of information that can be directly or indirectly tied to an individual including electronic identifiers such as IP address cookies and web beacons Any release of such indirectly or directly identifying information should be consistent with all nine Connecting for Health Privacy Principles and all of the Practice Areas of this Common Framework particularly specification of purpose limitation of use to only specified purpose and no unauthorized combining of data to create a more complete profile of individuals Appendix A Partially Identifying Data In today s web environment much of what consumers do is recorded and tracked by the sites they visit Even when consumers are not logged in various pieces of information are collected about them These little bits of data are often not personally identifying at the time and point of collection But in some cases these bits of information can be combined with other bits of information to build a more complete profile of each user When enough information is collected and combined it can be used to identify individuals Hence we call this information partially identifying Examples include cookies web beacons and even search keywords For illustration persistent cookies are little pieces of text deposited in the web browsers of consumers by the web sites they visit In a similar way that a ticket from the dry cleaner lets the proprietor link the customer out front with the right clothes held in the back cookies contain lookup information that lets a web site link a user to other information held about him in a database such

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct4 (2016-02-10)
    Open archived version from archive

  • CT5 | Markle | Advancing America's Future
    Committee Quick Links Blue Button Common Framework Health IT Health Library National Security Page Sections About National Security Post 9 11 Legacy Our Impact Task Force Quick Links National Security Library Reports and Recommendations Sharing and Collaboration The Lawfare Blog Library Quick Links Our Book America s Moment Archive Media Releases Member Commentary President s Letters Videos CT5 Purpose Over time individuals move change jobs change providers develop health conditions require new services etc We envision a competitive market of Consumer Access Services and networked PHRs that meets the needs of many different populations at various stages of their lives For the overall health of the emerging industry consumers should be able to make their personally identifiable information available to any and all applications to best meet their needs We recommend that the industry work on standardized permissions and formats for the exporting of data from one Consumer Access Service to another upon consumer request Export of Data to the Consumer Consumer Access Services should provide mechanisms for the consumer to export information from her account in standard formats The ideal state is that consumers would have a menu of output formats that are both human usable and machine readable As health data subsets become standardized in the EHR and PHR industries Consumer Access Services should support such standards Ideally Consumer Access Services would provide a mechanism for the consumer to export all data in the account in a human intelligible format into standard software such as a spreadsheet or text file Print capability is a reasonable minimum requirement Once the consumer assumes full control of the copies of data e g stores them on his computer hard drive it is the consumer s sole responsibility to protect them Recommended Practice Consumer Access Services should provide an easy to use mechanism for consumers to export information in their accounts for personal use Such mechanisms should Provide information in human readable form Include audit trail information for data entries time date and source stamping of each diagnosis for example See CT3 Immutable Audit Trails Include a printer friendly format Conform to industry standards for health data subsets as they become available and broadly implemented Enable data to be exported into industry standard software such as spreadsheets PDFs or text files Export and Import of Data Among Consumer Access Services and PHRs The ideal future state is for consumers according to their changing needs and wishes to be able to transfer their information from PHR service or application to another PHR service or application Such electronic interoperability is not a market reality today However Consumer Access Services should support interoperable data exchange protocols and data standards as they become available and market tested Recommended Practice Consumer Access Services should support industry standard data sets for exchanging patient health information as they become available and broadly implemented Consumer Access Services should collaborate to create a standard messaging envelope to export and import information upon the consumer s authorization In the absence of full

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct5 (2016-02-10)
    Open archived version from archive

  • CT6 | Markle | Advancing America's Future
    privacy risk to implement 2 Although this practice area notes the need for strong security detailed recommendations are beyond the scope of this paper The HIPAA Security Rule is a good starting point Another valuable reference is the government s recommended security protocols for federal information systems 3 Below we outline a few basic security considerations Data Stores Facilities that house equipment e g servers backup devices etc that store health data must be physically secured and attended at all times Access to such equipment should be limited to individuals who require it for authorized legitimate and documented i e auditable purposes Individuals who access user data may only access the minimum amount of data necessary to fulfill their authorized purpose s Sensitive user data should be encrypted within the equipment that holds the data so as to prevent unauthorized access and disclosure in the case of a physical loss Because most security breaches occur from within an organization whether intentional or not it is important to require that all persons who have access to such data receive regular training and appropriate reminders about system security and the need to follow related protocols to protect the confidentiality of user information In addition policies should be in place and regularly communicated to handle persons who violate stated security protocols Strong system security for Consumer Access Services and networked PHRs also entails regular risk assessments and system audits Transactions When information is presented to a user s web browser from equipment that holds this data i e a data server all reasonable steps should be taken to ensure a secure transmission of the user s data including use of encryption protocols such as Secure Socket Layer SSL technology Consumer Access Services should comply with industry best practices for transmission of health data over the Internet even if they are not subject to information security regulations governing the health care industry The following are other considerations in the emerging PHR industry In addition to data storage and transactional security it is also important to apply security and systems requirements to electronic mobile storage devices such as smart cards memory sticks and mobile devices offered as consumer access platforms and or data portability options Note that security requirements applicable to mobile storage devices that hold personal health data should be in place not only for the benefit of the consumer but also for the benefit of care providers who may wish to connect the device to their own computer and or network in order to access and or update a user s health information Without strong security and systems requirements guaranteeing protection the benefit these devices may offer to care providers may be outweighed by the security threat posed by viruses trojan horses or other malware that may be hiding within 4 Recommended Practice Consumer Access Services should adopt industry best practices for data transaction and storage security Security requires continuous monitoring of industry practices and threats as well as initial and ongoing personnel

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct6 (2016-02-10)
    Open archived version from archive

  • CT7 | Markle | Advancing America's Future
    SNOs Institutions that want to share information across the network must be members of a SNO comply with Common Framework policies maintain an RLS or equivalent service and build an ISB As noted in CT1 Technology Overview many important pieces of the consumer s record are already held in digital format The custodians of this information include Health insurance plans both private and public Pharmacy services and clearinghouses Nationwide laboratory services Self insured employers data warehouse services Large integrated delivery networks And to a lesser extent some small hospitals and smaller practice EHRs How Consumers Could Be Networked Via the Common Framework Most currently available PHRs either rely on existing data silos i e patient portals offering access to non interoperable health records or create new silos i e consumer populated non interoperable records Potential large scale benefits of PHRs are unlikely to materialize if these applications remain dependent on limited data sources 2 For PHRs to become more universally useful to consumers they must provide a convenient and secure means of connecting to personal data and interactive services from multiple sources and they must provide a convenient and secure means of moving the data out of the PHR as well in whole or in part A number of architectural approaches could permit consumers to deliver information from disparate data sources into a PHR and vice versa At one end of the spectrum the PHR could rely entirely on a centralized database of personal health information A master database at the center of the network would aggregate data from other health information systems before the information becomes accessible in the PHR Theoretically the consumer could then have access via one interface to the central data repository with potentially greater efficiencies than could be provided by queries across a distributed network The primary problems with this centralized approach are Data management Copying all personal health data to a single database and keeping it all up to date is impractical at population scale given the vast amounts of data that exist across systems Data quality Sending all data to a central database may magnify data quality problems although such an effort may also reveal data problems The centralized repository model would make error checking and data reconciliation difficult compared to a model that keeps personal health information close to the entity that creates it and knows the patient Organizations closest to the consumer are in the best position to validate adjudicate or update the consumer s data Business case It is implausible that any one entity can emerge to garner the trust of all health care systems and all consumers in the fragmented U S health care environment A single central database would raise questions central to trust such as who controls the data who governs the process what secondary uses and resale of data will be allowed etc A single source of control for the database would risk the shortcomings of monopolies in general low innovation poor customer service and higher prices It also limits the power of the network to grow organically and incrementally Security and privacy While breaches are a concern for all information holders a centralized model poses significant risk to privacy since a single security breach could lead to a catastrophic data leak Centralized systems can provide valuable efficiencies and controls and may be very appropriate at various network nodes which should have flexibility with regard to data storage solutions for the information that they each hold If centralization is the only model by which health information can be shared across disparate entities however there is a high risk that many entities will not participate The polar opposite of the centralized architecture is an entirely peer to peer network Under this model a consumer would have to create and manage separate data streams between her PHR and each system that holds her data The primary problems with the completely decentralized approach are in many ways the mirror image of the problems of absolute centralization Data management If each consumer is expected to aggregate her data she will become both her own registrar and her own system administrator This burden will be too much for the majority of consumers Data quality Clinical data comes in both highly structured and very unstructured forms The consumer would be responsible for managing these disparate forms of data again a task too challenging for most consumers Business case Each person would pay for or choose a sponsorship model for a PHR but the system would be highly fragmented and create few economies of scale Security and privacy The security risk would be multiplied across many servers with varying levels of technical support and policy compliance However the breach of any given source of data would be more limited reducing the potential for catastrophic data disclosures The pure point to point approach would place too much burden on the consumer to establish electronic transaction relationships with all of her health care services It also would be cumbersome and pose high risks for each of the consumer s data sources given the current lack of standards for clinical information or of a trusted mechanism to authenticate each consumer Further providers would be less likely to access and use the consumer s data if they were confronted with a hodgepodge of information aggregated from a series of unstructured point to point transactions How Could Consumers Aggregate Their Data Creation of centralized data repositories should not be an architectural requirement for data sharing however data aggregation at the level of the consumer could be very beneficial How then can the individual aggregate her health data without relying upon a single repository at the center of the network or learning to manage a completely peer to peer model Any practical strategy for networking PHRs must avoid the negative consequences of these two extremes while satisfying the consumer s need to access and control her information The Common Framework vision of a federated decentralized network of SNOs was

    Original URL path: http://www.markle.org/health/markle-common-framework/connecting-consumers/ct7 (2016-02-10)
    Open archived version from archive

  • Technology Guides: Markle Common Framework for Private and Secure Health Information Exchange | Markle | Advancing America's Future
    to Members Member Commentary Personal Stories Rework America Library Health Page Sections About Health Our Impact Steering Group Consumer Work Group HIE Committee Quick Links Blue Button Common Framework Health IT Health Library National Security Page Sections About National Security Post 9 11 Legacy Our Impact Task Force Quick Links National Security Library Reports and Recommendations Sharing and Collaboration The Lawfare Blog Library Quick Links Our Book America s Moment Archive Media Releases Member Commentary President s Letters Videos About Markle Page Sections About Markle A Message from Zoë Baird Our Principles Our Impact Board of Directors Senior Team Our History Quick Links Conference Space Events Markle in the News Media Releases Past Initiatives President s Letters Rework America Page Sections About Rework America A Message from Rework America Opportunity for All Our Impact Initiative Members Expert Advisors Quick Links Rework America Connected Our Book America s Moment Initiative Overview Latest News Letters to Members Member Commentary Personal Stories Rework America Library Health Page Sections About Health Our Impact Steering Group Consumer Work Group HIE Committee Quick Links Blue Button Common Framework Health IT Health Library National Security Page Sections About National Security Post 9 11 Legacy Our Impact Task Force Quick Links National Security Library Reports and Recommendations Sharing and Collaboration The Lawfare Blog Library Quick Links Our Book America s Moment Archive Media Releases Member Commentary President s Letters Videos Technology Guides Markle Common Framework for Private and Secure Health Information Exchange T1 The Common Framework Technical Issues and Requirements for Implementation This document is an overview of the technical philosophy and decisions behind Markle Connecting for Health s Common Framework and to the policy issues related to those technical requirements T2 Health Information Exchange Architecture Implementation Guide This document specifies a technical architecture designed by Markle Connecting

    Original URL path: http://www.markle.org/health/technology-guides-markle-common-framework-private-and-secure-health-information-exchange (2016-02-10)
    Open archived version from archive

  • Resources | Markle | Advancing America's Future
    NHIN Prototype and personal health technology Phase 3 Common Framework During Phase 3 2005 2006 the Markle Connecting for Health Common Framework model the Markle Connecting for Health Common Framework prototype and the Markle Foundation Personal Health Technology Initiative were developed Phase 2 Roadmap During Phase 2 2003 2004 the Markle Connecting for Health collaboration developed The Markle Connecting for Health Roadmap for Achieving Electronic Connectivity from Our Nations Health Care Leaders Phase 1 Standards and Privacy In Phase 1 2002 2003 the Markle Connecting for Health collaborative focused especially on moving the health care field toward the adoption of health care data standards identifying noteworthy practices in privacy and security and elaborating the role of the consumer and the personal health record Phase 6 Health IT Patient Protections In 2012 an additional set of resources the Markle Connecting for Health Common Framework Policies in Practice for Health Information Sharing Policies in Practice was developed as an addendum to the original Markle Common Framework to address a range of critical health information sharing implementation needs identified by experts working in the field Phase 5 Personal Population Health Throughout its history Connecting for Health has focused on connecting Americans to their personal health information and health related services Phase 5 began in 2007 In June 2008 with support from more than 50 organizations Markle released the Common Framework for Networked Personal Health Information a set of policy and technology practices encourage appropriate handling of personal health information as it flows to and from personal health records PHRs and similar applications or services M2 A Model Contract for Health Information Exchange Introduction This document Model is a model for the organization and content of the Terms and Conditions of a sub network organization SNO Background A SNO is to operate as a health information data exchange organization both regional and affinity based that operates as a part of the National Health Information Network NHIN a nationwide environment for the electronic exchange of health information made up of a network of networks Use of Model The Model is based on a number of assumptions which are described in the following discussion The Model is not the answer for all SNOs Instead it is intended to assist in the organization of a SNO by providing a basis upon which to begin drafting that SNO s Terms and Conditions All language provided in the Model is intended for informational and educational purposes only It is not intended nor should it be used as a substitute for legal advice In preparing its own Terms and Conditions or other legal documents used in connection with its participation in the NHIN an organization should consult with legal counsel Each SNO will have to draft its Terms and Conditions based upon its own organization operations system and services regulatory environment and so on Some of the Model s terms will be inapplicable to some SNOs The Model shows where some of the variations might be expected to occur M1

    Original URL path: http://www.markle.org/publications?term_node_tid_depth=15&tid_1=All&date_filter[value]= (2016-02-10)
    Open archived version from archive



  •