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".
  • P7 | Markle | Advancing America's Future
    and their participants II Logging and Audit Controls in a National Health Information Network With these HIPAA requirements as a baseline audit and logging practices will differ in important respects among the various actors in a National Health Information Network This section will provide a general analysis of the level of logging and audit controls to be expected among covered entities within each SNO at each SNO itself and for inter SNO sharing The next section will recommend specific logging and audit practices to apply at the SNO and inter SNO levels For covered entities within each SNO the baseline will be the requirements of the HIPAA Security Rule discussed briefly in the prior section The Security Rule contemplates that the level of audit controls required varies with the security environment Throughout HIPAA requirements are scalable which means that large and sophisticated entities are expected to establish more rigorous safeguards than small entities For audit scalability means that small entities often have less thorough safeguards than large entities In setting policy for logging and audit control practices for covered entities within each SNO it is important to recognize the small scale of many covered entities Even for many large covered entities current logging and audit control systems likely do not match the rigor and complexity of the best practices of large institutions Given these current practices it would likely be difficult to insist on heightened logging and audit control standards for each covered entity within SNOs Any attempt to require such standards would quite possibly discourage participation in the overall system and further delay participation Our recommendation at this time is thus not to require heightened logging and audit control standards for each covered entity or other participant within a SNO The analysis shifts however for logging and audit control practices at the level of each SNO in order to best safeguard ePHI Each SNO is expected to be a sophisticated entity operating at a scale that is consistent with rigorous audit and other security practices Compared with individual providers who often depend largely on paper records SNOs are likely to rely more heavily on electronic health records which are typically more suitable than paper records for enhanced and automated logging and audit control approaches In order to promote trust among patients and participating institutions we therefore recommend excellent logging and audit control practices at the SNO level as described in the next section The case for strong logging and audit control standards is even stronger for inter SNO sharing through the RLS As discussed in previous documents of Markle Connecting for Health the RLS will provide a means for locating records of an individual patient that are held by different data providers including in different SNOs It will be crucial to build public confidence in the good data handling practices of the RLS A transparent and effective method for logging and audit controls is one important component of the case that the public deserves to trust the RLS The next section recommends specific practices notably including an independent third party audit on a regular basis In establishing these strict logging and audit practices at the SNO and inter SNO levels it is important to clarify what types of records are likely to move through such information systems As contemplated in the Markle Connecting for Health Common Framework the RLS itself will not contain clinical data Instead the RLS will contain demographic data in order to identify and provide contact information for the actual holders of clinical records Transfer of clinical records will be point to point That is an entity seeking the records of a particular patient may learn about other record holders through the RLS That entity then will directly contact the other record holders in order to receive the clinical records For purposes of logging and audit controls this structure means that the flows of demographic information will be carefully tracked at the RLS level Transfers of clinical records however will not take place through the RLS itself and will thus be subject to the logging and audit practices at the level of each entity As a related point SNOs may operate in a similar way Whatever demographic or other information moves through the SNO would be subject to audit under the strict logging and audit standards contemplated here for SNOs Transfers of clinical records however may take place through paths that do not include a SNO III Specific Logging and Audit Recommendations In preparing this paper on logging and audit practices it has been helpful to review the actual audit documents of some large cutting edge health care organizations The discussion here draws on those documents as well as some publicly available materials 2 A Audit and Accountability Checklist We first put forward a recommended audit and accountability checklist This checklist is intended to apply at least to SNOs and the RLS and it represents good practice for a broader range of covered entities Audit and Accountability Audit is the practice of recording the occurrence of selected system events management uses reports alerts generated from audit records to monitor the appropriateness of activities Accountability results when activities are attributable to individuals Yes No N A 1 The system is required to log users system login and logoff with date and time or if the system does not have the capability to record login logoff activity it may rely on an external security system s access control logging function to record access 2 The system must have the ability to log read create update delete forward and print access initiated by individuals and processes for systems containing confidential and restricted data For data warehouses data marts and operational data stores the system must have the ability to log queries or alternatively the tables read must be logged Row level logging must be available on demand 3 All audit records must be identified by a unique record key or number and include User identifier name of user Time

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


  • P8 | Markle | Advancing America's Future
    addition the SNO must report any breaches to the particular data provider whose data 12 was improperly used This would not be limited to serious breaches but would include all breaches Most SNOs will be a business associate of the Participants who provide patient data to the SNO in which case the SNO is required under HIPAA to report all Security Incidents to the covered entity 13 See relevant sample contract excerpts below 14 Section 8 03 Report of Improper Use or Disclosure The SNO agrees promptly to report to a Participant any use or disclosure of the Participant s PHI not provided for by this Agreement of which the SNO becomes aware and Section 8 14 HIPAA Security Rule Provisions a b The SNO agrees promptly to report to a Participant any Security Incident related to the Participant s ePHI of which the SNO becomes aware Similarly each Participant must agree to inform the SNO of any serious breach of confidentiality It is not necessary for a Participant to inform the SNO of minor breaches of confidentiality unless there is otherwise a legal duty to disclose such breaches to the SNO While it is difficult to define what would rise to the level of a serious breach SNOs and Participants might decide that the breaches of concern would be ones that impact 1 the viability of the network 2 the trust that other Participants have in each other or 3 the legal liability of the SNO In addition SNOs and Participants might decide that repeated minor breaches that demonstrate a pattern of lax internal operations or enforcement may also rise to the level of a serious breach See relevant sample contract excerpt below Section 5 01 Confidentiality The Participants agree that any Information obtained from the Network will be kept confidential pursuant to the Privacy Rule and all other applicable federal state and local laws statutes and regulations as well as each Participant s own rules and regulations governing the confidentiality of patient records and information Participants agree to report promptly to the Management Committee any serious breach of the confidentiality of the Information of which it becomes aware As mentioned above some states have enacted laws that require the notification of individuals whose personal data is compromised 15 Several federal bills have also been introduced that include breach notification which could pre empt state law if and when enacted 16 SNOs must analyze any relevant state laws in this regard and what impact such laws may have on the SNO s operations For example a state law may require that a SNO notify a covered entity Participant of a breach but the burden to notify patients may fall on the covered entity Participant rather than the SNO In any event procedures need to be in place that will address this scenario in advance of an event Communities should be prepared to comply with evolving national norms regarding breach notification and Participants and SNOs should work towards implementing a system that ensures affected patients are notified in the event of a breach Withdrawal from the SNO SNOs may wish to consider including a provision in their Participant agreements allowing for withdrawal from the SNO As noted above the Markle Connecting for Health Model Contract for Health Information Exchange provides a variety of model provisions that could allow Participants to terminate their participation freely at any time require that termination be preceded by a substantial period of advance notice or require that Participants maintain their participation for a certain period of time 17 In general SNOs and Participants are encouraged to consider the particular circumstances of small provider practices in developing relevant terms for withdrawal from SNO provisions in their SNO agreements The Markle Connecting for Health Model Contract for Health Information Exchange also provides a model provision allowing for a Participant to withdraw from a SNO if a serious breach of its patient data has occurred as described here See relevant sample contract excerpt below Section 12 03 Withdrawal of a Participant The following shall constitute adequate cause for the withdrawal from this Agreement a A significant breach of another Participant s duties of confidentiality under ARTICLE V of this Agreement with regard to Information stored on or transmitted over the Network by the withdrawing Participant or a significant breach of the SNO s duties under ARTICLE VII or ARTICLE VIII with regard to Information stored on or transmitted over the Network by the withdrawing Participant provided that the Participant has allowed a reasonable time for the SNO to cure any such significant breach Any claim of a significant breach by a Party shall be submitted to the Management Committee which will determine pursuant to Section 10 02 of this Agreement whether a claimed breach is significant enough to constitute cause under this Agreement This determination shall be an advisory opinion and shall not be binding on any party to this Agreement and shall not act as a waiver or determination of any Party s rights under federal state or local laws In a vote to determine whether a breach is significant the complaining party ies and the alleged breaching party ies shall not participate Whether the SNO should have a mechanism for termination of a Participant for significant breaches of confidentiality could be an item for further discussion among Participants and SNOs This typically would not be a problem in a model where individual users are not Participants but rather are part of a Participant s workforce Thus the Participant s own internal policies would be invoked in the event of a breach of patient data by the individual user The Markle Connecting for Health Model Contract for Health Information Exchange includes several model provisions that could allow for a SNO to terminate a Participant s Registration Agreement including a model provision allowing for termination for cause Indemnification for Breaches of Confidentiality Indemnification provisions may or may not be included in a SNO agreement As noted above the

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

  • P9 | Markle | Advancing America's Future
    as concerns about privacy and security lack of consumer awareness lack of brand lack of a sustainable business model will likely remain in place and limit growth The continuing stream of news reports about privacy breaches of electronic data in several sectors including health care may affect consumer demand for PHRs and even create backlash against EHRs Distribution of technology to the patient and family by 2008 Control over technology and information will remain in the hands of health care organizations Public reporting efforts and information support for health care transparency and quality will be very modest Few incentives will be in place to entice consumers to adopt technology and to take a more active role in their care Reallocation of roles responsibilities and money by 2008 Higher co pays and health savings accounts HSAs have been promoted in part to shift greater responsibility for health care decision making to the consumer Additionally there are government payer and employer initiatives to pay for performance However we predict that these efforts will have little effect on the underlying roles responsibilities and financial flows of the health care system as a whole by 2008 Given the low expectations for EHR penetration and interoperability health care transformation strategies that rely on EHRs and clinician based health data sharing networks are not likely to yield substantial near term impact We recognize the importance of EHRs and the high value of their integration with PHRs We support efforts to increase EHR adoption and interoperability However we contend that it would be a strategic mistake to wait for full fruition of trends 2 and 3 in order to achieve increased consumer participation through trends 4 and 5 Rapid consumer adoption of newly networked services has proven to be possible indeed phenomenal in other sectors Consumers can adapt to technology and culture transformation more rapidly than large health care institutions with long histories of business processes and legacy systems Furthermore even as the majority of clinicians continue to keep consumers data on paper other important personal health information namely claims pharmacy diagnostic images and lab data are available in digital form today We conclude that the immediate effort to catalyze health care transformation must include a strategy to create a networked environment for PHRs and related technologies that takes advantage of these currently available digital data streams Providers can gradually form and join networks as their systems increasingly interoperate In fact networked connections to PHRs could help accelerate the EHR adoption curve as clinicians see advantages to joining the network There are additional strong rationales for involving consumers in a much needed transformation toward greater information access and transparency First the health care consumer has the largest stake in the contents of such information The consumer s life is put at risk when preventable errors occur due to lack of information Second the consumer is the ultimate payer of health care services Consumers are being asked to pay directly for a larger proportion of their care 26 27 Third younger generations expect to use technology in almost all aspects of their lives Fourth as the number and complexity of diagnostic and treatment modalities grows at a rapid pace patients are increasingly required to share the responsibility of decision making with their health care providers Furthermore patients are often in the best position to gather and share information with providers 28 29 For example a physician might know that a medication has been prescribed for a patient But without asking the patient the doctor does not know whether the patient actually took the medication how well it worked what other remedies she is taking or whether she had side effects Empowering health care consumers by placing information directly in their hands has the potential to radically improve health care 30 31 PHRs are still in the early development stages and a great deal of study is needed to measure the benefits and risks of PHRs Consumers patients and their families vary widely in the responsibilities they each wish to maintain in their own health However as noted in Markle Connecting for Health s 2004 report Connecting Americans to Their Health Care preliminary evidence suggests that PHRs have potential to Empower patients and their families 32 33 34 35 36 37 38 39 Improve the patient clinician relationship 40 41 42 43 44 Increase patient safety 45 46 47 48 Improve the quality of care 49 50 51 52 53 Improve efficiency and convenience 54 55 56 57 58 59 Improve privacy safeguards 60 61 Save money 62 63 64 65 66 67 68 Lastly there is general agreement among many stakeholders including those listed below that PHRs should be a key part of health care modernization and reform efforts Government bodies like the National Committee on Vital and Health Statistics 69 and the American Health Information Community 70 Professional societies such as the American Medical Association 71 and the American Health Information Management Association 72 Consumer groups such as AARP and the American Diabetes Association 73 Health insurance plan associations like America s Health Insurance Plans and the Blue Cross Blue Shield Association 74 Bipartisan political leaders 75 Stakeholders do not share a consensus view on how to stimulate PHRs or even what PHRs should ultimately be We do not know what kinds of applications and functions will be most effective in encouraging the transformation we seek The mere presentation of health data to consumers is unlikely to be transformative Applications likely will have to interpret and apply the data in innovative ways that provide specific benefit to specific people and connect them with their health team and caregivers Although the next sections of this paper recommend a framework for enabling networked PHRs we purposely avoid recommendations on what those applications should be or do Development of a sufficiently flexible network will enable the use of a great variety of personal health technology applications including many that we cannot imagine today pagebreak Section 4 Background on the Common Framework Architecture Markle Connecting for Health has created a structure called the Common Framework which is specifically designed to strike an appropriate consensus based balance between the need to share personal health information electronically and the need to protect it from inappropriate access or use Although the Common Framework was originally designed to guide personal health information exchange among health care providers its underlying principles were developed to support consumer access Below we briefly discuss these principles Common Framework Policy Principles The Common Framework has endorsed a set of fair information practices to guide systems that support the exchange of personal health information These principles are fully presented in P1 The Architecture for Privacy in a Networked Health Information Environment 76 Here we summarize them 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 Common Framework Technical Principles The Common Framework also prescribes several technical principles upon which health information exchange networks should be based We summarize them below Make it thin Data exchange networks should impose the minimal requirements for storing and transmitting health data leaving as much processing as possible to applications at the edges of the network No requirement of a national health ID We argue that a national health identifier is neither likely nor necessary Avoid rip and replace The health care industry has already invested heavily in technology The network should take advantage of the technology currently in use not require its replacement Separate applications from the network The roles of the network and of applications should be distinct The purpose of the network is simply to transfer data All other data related functions should reside at the application level This architecture provides for a stable infrastructure upon which application developers may build innovative functions Because this distinction is critical to our recommendations for networked PHRs we discuss it further in Appendix B How Applications Interact with Networks Decentralization Data should remain with the originators of that data e g providers pharmacies etc Consumers already have trusted relationships with these entities Federation A federation of network members based on mutual agreements is necessary given the complexities of a decentralized network Flexibility The network should be designed such that it can scale and adapt over time and allow participation by a wide variety of network members Security and privacy Privacy protection and security should be top priorities that guide the design and development of the network Accuracy There should be a low tolerance for errors with regard to identifying people and their data records There should also be a means to correct data errors that are discovered Markle Connecting for Health put these principles into practice in a three region prototype documented in previous Common Framework technical and policy papers This paper adds to a compendium of policy resources for interoperable electronic health information exchanges Those resources consist of An overarching architecture for privacy based on nine interdependent principles Model privacy policies and procedures Notification and consent policies Policies for correctly matching patients with their records Policies for authentication of system users Patient information access rights summary based on the Health Information Portability and Accountability Act HIPAA Policies for audit logs Policies for breaches of confidential health information The Common Framework as an Architecture for Networked PHRs To date the Markle Connecting for Health policies have been designed to enable interoperable exchange of patient data among clinicians It is a substantial challenge to add consumers to the exchange From the policy standpoint these principles must be translated into an adequate set of information sharing policies to which both consumers and institutional data custodians can agree On the technical side a network architecture must be developed that is consistent with the above principles yet scalable and adaptable to the many combinations of relationships that consumers have with various health care entities These technical and policy challenges must be addressed in tandem Definitions in the Markle Connecting for Health Common Framework Architecture Previously released Common Framework documents described Markle Connecting for Health s vision of a nationwide network for health information exchange The fundamental design elements of that network architecture would not be changed by granting consumers access to the network In fact consumer access has always been a design principle of the work Below we review some of the key architectural concepts described more fully in prior Common Framework reports Nationwide Health Information Network NHIN As its name implies the NHIN is an overarching network that connects exchange networks within the nation Thus it is envisioned as a network of networks Regional Health Information Organization RHIO The current trend in health information exchange is to build provider centric regionalized networks These networks are usually referred to as RHIOs A functioning RHIO would connect multiple provider institutions in a region such as a state or county Sub Network Organization SNO A Sub Network Organization is a business structure comprised of entities that agree to share personal health information in accordance with a minimum set of technical and policy requirements embodied in the Common Framework A SNO may be organized on a geographic basis i e a RHIO or in support of other business relationships that are not determined by location For instance the Veterans Administration VA has a network of hospitals and clinics that exchange health information on a nationwide level Both RHIOs and non regional networks like the VA would be sub networks of the NHIN Thus we prefer the term SNO because it is a more inclusive term than RHIO Record Locator Service RLS As its name implies the RLS is a service that queries the locations of patient records within a SNO Each SNO has its own RLS The purpose of an RLS is best described by an example A physician or other health care professional may wish to retrieve data on a patient from other institutions that the patient has visited The physician would send a query to the RLS which returns a list of record locations but not the data itself Thus the RLS might inform the doctor that her patient has medical records at institutions X Y and Z The contents of those records are not revealed by the RLS Retrieval of data contained in an identified record is a separate process that occurs directly between the requesting physician and the institution that stores the record Inter SNO Bridge ISB A physician might want to search for records outside his SNO Thus he would send a query to the RLS of another SNO The ISB is the conduit through which these queries and responses flow Each SNO would have an ISB which would be its single gateway for channeling all requests and responses from other SNOs In summary the Common Framework architectural vision is a network of networks one NHIN made up of many SNOs Each SNO uses an RLS to locate the consumer s records and an ISB to talk to other 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 Opportunity Analysis in the Current Health Care Landscape 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 The next section discusses how PHRs could become part of this network connecting consumers to their own unique slice of data and enabling them to drive health care transformation pagebreak Section 5 How Consumers Could Be Networked Via the Common Framework 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 77 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 for all of the reasons cited in the Opportunity Analysis in the Current Health Care Landscape section of this paper 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 and patient focused principles discussed in Values and Principles The Common Framework vision of a federated decentralized network of SNOs was created to meet this core requirement Under the Common Framework authorized clinicians are able to query the network e g request an index of the locations of a patient s records on the basis of their organization s membership in a SNO To establish a chain of trust the participating SNOs must have common understandings and expectations such as how to authenticate and authorize clinicians to use the network and how to log their actions Consumers also need a chain of trust to interconnect across networks Yet they represent a greater challenge than clinicians for authentication authorization liability and security There is no commonly accepted set of practices today to provide credentials to consumers for health information exchange across different systems and data repositories It is reasonable to expect that consumer applications could become more easily networked if such a set of common practices existed that is if some type of enforceable arrangement required all participants to operate under a common set of policies and agreements to mitigate risks such as misidentification or identity theft In the Markle Connecting for Health model a network of interconnected SNOs is viewed as the most flexible and practical means to untether applications from data silos as well as to enforce a common set of rules among participants To integrate PHRs into the NHIN we assume that the same model for connecting users a chain of trust brokered by an ISB that can talk to other entities in the system must be available to patients and consumers This paper considers the functions and requirements of an entity that provides consumers with access to the nationwide network of SNOs Consumer Access Services Could Act as Intermediaries We start with three assumptions about how consumers could gain access to their data in the future The first is that there will be services acting on the consumers behalf as aggregators of personal health information Other kinds of networked services with many sources of data from e mail to online bill paying to airline booking sites aggregate data on behalf of the user It may become technically possible for the consumer to access her health data via a personal computer directly from the hospitals labs and other organizations that hold it However even in such a scenario many services will arise to hold and manage the data on the consumer s behalf Issues of backup remote access and economies of scale are in fact already driving the creation of these sorts of services Some models may offer storage services of all of the consumer s data others may emerge simply as gateways for access without actually storing the data Ideally consumers would choose which aggregation model best serves them The second assumption is that there will be services that issue identity and authentication credentials to the consumer and pass those credentials or proof of authentication to other organizations in the NHIN on the consumer s behalf Today we have no generally accepted methods or policies for initially proving the identity of each individual for the issuance of online credentials based on that identification nor for the initial and repeated authentication of that individual s identity in an online environment In a nationwide health information network those who hold personal health data will need to be confident that the person to whom they transmit data is indeed who she claims to be Common reliable policies for initial proofing and repeated verification of identity will be essential functions of these intermediary services Although a complex set of issues surround identity authentication and authorization we will group all of these issues under the label authentication for the rest of this document Given the high cost of the initial consumer identification and the low cost of the subsequent authentications economies of scale will drive the creation and growth of these functions These intermediary services would be contractually obligated to comply with the rules governing participation in the network Likewise they would be expected to enforce those rules in the event of any violation by one of their authorized users and to successfully exclude unauthorized users By the same logic the entities that issue identity credentials to individual consumers must have the organizational standing to enforce nationwide policies within their network Third we assume that the aggregation and authentication functions will be combined While aggregation and authentication could be offered separately the economic logic driving the creation of the services will also drive their combination As a result competing services would act as proxies for many consumers potentially millions at a time holding both their authentication tokens and their data These authentication aggregation service providers would not necessarily be covered entities under HIPAA For the rest of this document we will assume that authentication and aggregation functions will be offered in tandem by entities we will call Consumer Access Services We will also assume that the interaction between Consumer Access Services and other entities in the NHIN will use the service oriented architecture of the Common Framework including both SOAP messages and message brokering by Inter SNO Bridges Following the diagram below such a combined authenticating and aggregating service would perform key NHIN functions including at a minimum authenticating individual users providing an ISB interface to bridge between those users and the rest of the NHIN and aggregating information into PHRs on those users behalf A number of entities may be interested in offering these combined services to enable consumer access to the NHIN including the following examples Provider organizations could strengthen their role as primary care providers and care coordinators by accessing all of a patient s data when authorized and playing the role of interpreter and coach Health insurance plans and government programs e g Medicare Medicaid VA could apply their data analytic and decision support capabilities to the clinically rich patient data available across the network and compete on their ability to deploy beneficial interventions based on that analytic intelligence Pharmacy services i e pharmacy benefit managers retail pharmacies clearinghouses could offer new services to attract consumers Application vendors could benefit from a more efficient marketing and distribution environment by offering their products to a range of Consumer Access Service suppliers with large populations of consumers Affinity and patient advocacy groups could create their own intermediary services to help members select and use appropriate products while using aggregate data as a platform for improving health and advocating for shared concerns Employers could steer employees toward consumer access services that allow secure access to personal health information and other benefits Web portals and other non traditional health care players could enter the health care space both leveraging their brand credibility and gaining appropriate access to data that the consumer wants them to have without negotiating separate access agreements with each trading partner Regional Health Information Organizations RHIOs could offer services to connect consumers Markle Connecting for Health wishes to enable consumers to aggregate and manage their health care data while protecting them against silo ization the difficulty or inability to move their personal data easily from one source to another especially data they may have added to their own records and against the misuse or loss of personal data Two key questions will need to be addressed 1 What qualifications must a Consumer Access Service possess One broad answer could be Only current participants in the health care system would be allowed to offer consumers access to their data This restriction would assure that all those offering consumer access are already covered entities under HIPAA An alternative answer could be Any organization that ensures accurate authentication and accountable handling of consumer data would be allowed to act as a Consumer Access Service One possible middle ground would be to insist contractually that all Consumer Access Services abide by HIPAA regulations regardless of their status as a covered entity 2 What policies contracts and other governing mechanisms should be applied to these services Consumer Access Services must be trusted partners of every other SNO and NHIN participant These organizational partners must be confident that the entity to which they pass personal health information will handle it properly and only share it with the intended and authenticated user What sorts of contracts standards support and other mechanisms of governance would constitute a sufficient chain of trust to enable Consumer Access Services to participate fully in the NHIN One set of issues involves identification and authorization of the patient including but not limited to Minimum standards of original proofing Minimum procedures for authentication Levels of sensitivity authentication methods stronger authentication for more sensitive data and how those levels are established Bonded access to ensure some sort of penalty for misuse by third parties Co issuance of credentials across the network Contracts that specify responsibilities and liabilities Another set of issues is related to access including but not limited to Whether the consumer must be offered a store and forward capability like e mail Whether the consumer must be offered an encrypted cache to secure the data on the server Whether the consumer must be asked for consent for secondary uses of the data and what constitutes consent Whether the consumer must have access to an audit trail that tracks every time her data is viewed or used by someone else Whether the consumer must have the right to get a full copy of her data in an appropriate format These issues should be resolved by a process that maximizes the value of these intermediary services for the consumer while limiting the risk of misuse of that data by other parties including the Consumer Access Services themselves Public policy must make it possible for each person to access personal health information regardless of where it was originally acquired and where it is now maintained In solving a problem like authentication the NHIN needs to make sure that every American has an opportunity to gain the necessary credentials and take advantage of the information channels that exist without being subservient to any particular gatekeeper pagebreak Section 6 Charting a Path Toward Fully Networked PHRs A number of significant projects to deploy PHRs are now underway With this document we have offered a vision of how these multiple approaches to the PHR might coexist and even support each other We began by presenting a set of values and principles that assert the right of the individual to control personal health information and eventually to share that information with a variety of innovative health care services We then outlined a strategy to put those principles into practice by developing a networked PHR The first step toward achieving our goal is to develop policies that will enable consumers to participate in health information exchange Connecting consumers to a health information exchange network raises a number of policy questions How will individual consumers be authenticated How will authorized users of an individual s PHR be authenticated and allowed access How does the consumer know she is communicating with who she thinks she is through the network How does she verify the source and accuracy of data received What consent procedures will be followed before granting consumers access to the network Which secondary uses of the data if any are to be sanctioned How will unauthorized uses of data be handled How will personal health applications be certified to access data sources Will standards for patient sourced data be defined Will patient entered data e g errors changes in medication use etc be propagated back to data suppliers How will the consumer s ability to control the sharing of her data be ensured By what procedures will consumers grant access to other users such as providers and caregivers How will relationships among consumers Consumer Access Services and other NHIN participants be formalized What mechanisms will assure accountability All of the policy issues above cannot be solved at once Therefore we have chosen to focus on a few priority problems in 2006 and 2007 These significant policy issues can be grouped into the following categories Authentication How does a network participant know that a consumer user is really who she says she is The discussion of this issue should include a thorough exploration of private sector and federal sector roles in determining adequate policy Consumer Access Service policy requirements What are the key principles and characteristics of a Consumer Access Service What specific capabilities and liabilities must a Consumer Access Service assume to maintain a chain of trust with the participants of other SNOs Markle Connecting for Health will convene multi stakeholder Working Groups that will formulate policy recommendations for each of these challenges We recognize that each stakeholder has its own set of interests To successfully develop an open market of networked PHRs each stakeholder must make a commitment to enable portability of personal health data with the consumer in control Organizations should make the data that they hold available at the consumer s request to applications offered by other entities as long as those entities comply with a Common Framework of rules and practices for information stewardship This approach would allow consumers to access their information through applications of their choosing as opposed to having access exclusively through the application offered by each entity that captured their data The networked model opens up possibilities for existing entities and new entrants to compete on innovation value and service to consumers This model holds more promise than proprietary silos because no one organization holds all of the data valuable to most consumers We therefore recommend that organizations aim to exploit the power of networks by developing and adopting a Common Framework for networked PHRs A networked PHR environment cannot be achieved without collaborative efforts and consensus agreements among all stakeholders To achieve our national vision of networked PHRs for every American who wants one we need to agree on the characteristics of the network and the means by which personal health information will be shared and managed We must create an environment of trust and confidence Without a Common Framework of policies for information stewardship even a thousand interesting projects and product offerings are not likely to produce a trustworthy interoperable PHR This paper provides a vision of a plurality of organizations that offer opportunities for consumers to connect to networks of personal health information and services An individual could connect via a Consumer Access Service offered by a provider group a RHIO a retail chain a payer an affinity group a web portal a bank etc We seek a free and fair competitive environment in which all players agree to a minimum set of common rules The precise path toward this vision is not completely knowable now However we envision several steps over the next five years Collaboration among multiple stakeholders to recommend policies beginning with the key areas cited above Development of one or more prototype Consumer Access Services with multiple PHR connections Broad dissemination of the prototype findings and requirements Contractual agreements to abide by a Common Framework among a critical mass of health care actors Evaluation of potential methods to validate and enforce rules for Consumer Access Services

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

  • T1 | Markle | Advancing America's Future
    to operate even when handling aggregate data even when such requests are not governed by HIPAA as with required public health reporting Our model for direct aggregation from the source is the Shared Pathology Informatics Network SPIN 11 and modeling of SPIN style interactions in the Common Framework is part of the 2006 effort 5 Subscription Models Any of the above transactions may be modeled as a subscription to a particular source of data as well where an authorized user can request that when a piece of remote content is updated they receive either a notification of the update or receive the updated data itself However this pattern is not yet specified The Common Framework is based on Web Services which enormously lowers the required coordination among network participants both in advance of and during a transaction As a result of this loose coupling subscription models of data transfer e g Notify me when this patient has new lab results can be modeled in two ways The first is scheduled pull scheduled requests from the querier to the RLS or data holder which requests automatically repeat periodically in intervals between seconds and months depending on the nature of the query The other is triggered push where the RLS or data holder watches for updates to data and pushes out any such updates to a list of subscribers or their designated proxies The design and implementation of such models is complex and highly dependant on the technical savvy of the member entities of the SNO A number of variables affect decisions about subscriptions such as who assumes the costs of maintaining the subscription information the querier in the case of scheduled pull and the holder of the data in the case of triggered push As a result like aggregation the design and implementation of subscription models is currently envisioned as a per SNO design choice though with the assumption that observation of the various implementations in 2006 will provide a guide to any nationwide standardization Broad Policy and Technical Requirements The Common Framework provides a list of the minimal set of policies and standards that must be adopted by any participating SNO On the policy and governance side all incorporated members of a SNO 12 must Adopt the policies of the Common Framework See the policy documents contained in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange Agree to any SNO wide policies in place In addition each SNO has three technical services it must offer A SNO wide Record Locator Service to allow authorized entities within the SNO to look for patient data A matching algorithm to match patient demographics contained in incoming requests with the records stored in the Record Locator Service An Inter SNO Bridge ISB to allow authorized outside parties to look for and retrieve patient data The basic rationale behind these governance and technical requirements are discussed below the detailed policy recommendations are contained in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange the detailed technical implementation guides are contained in the Health Information Exchange Architecture Implementation Guide contained in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange A health care entity can belong to more than one SNO this would of course entail the additional expense of listing patient demographics and record location information in more than one place and reconciling contractual requirements where they differ between SNOs There is no conceptual obstacle to multi SNO membership however There is no minimum or maximum size for a SNO a single institution can be a SNO so long as it adheres to the principles and standards of the Common Framework In practice only very large institutions will do this as having a single institution as a SNO creates little of the efficiencies or cost savings that multi entity SNOs can have Software Requirements for RLS Matching Algorithm and ISB One of the key design principles of the Common Framework is that no particular software application is required in the same way that email software from different organizations all read the same email data standards the technical infrastructure of a SNO can be built on any suitably secure hardware and software platform 13 so long as it produces and consumes common data standards 14 The three applications a SNO is required to host 15 are the Record Locator Service a matching algorithm for matching queries for clinical data with patient records and an Inter SNO Bridge for traffic between the SNO and the outside world RLS One of the basic software requirements of a SNO is the operation of a Record Locator Service RLS The institutions with the right to list patient demographics and record locations in the RLS are the members of a SNO by definition Thus the RLS is the practical locus of most SNO wide activity The details of the RLS are covered in the Health Information Exchange Architecture Implementation Guide and the relevant policies in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange but the basic functions are described here The Common Framework makes the following assumptions about the design of the RLS There is one RLS per SNO which holds the universe of records that can be queried using the RLS service within that SNO 16 There is no meta RLS in keeping with the No requirement for national services design The RLS is designed only for patient centered queries Aggregate queries e g Find all admissions in the last 24 hours presenting with shortness of breath must be dispatched to the participating institutions or run against aggregated databases that are collected and kept separately The lack of clinical data at the RLS keeps the RLS from being a target of loss or theft of clinical data and allows interactions to be optimized for a single simple case The RLS participates in two types of transactions the addition modification or deletion of listed patient record locations from the entities that hold data on the patient and requests for information about a particular patient from entities that want those locations All transactions to and from the RLS are logged and audited The RLS must have a valid SSL certificate and may only communicate with requestors who support encrypted web communications https The RLS is designed to take a query from authorized users in the form of demographic details or alternatively a query in the form of a unique provider ID plus a Medical Record Number which would enable them to use the RLS to find other records for the patient whose MRN they know 17 The RLS must support patient data in incoming queries expressed in the HL7 2 4 format described in the Health Information Exchange Architecture Implementation Guide The RLS may support incoming queries expressed in the HL7 3 0 format described in the Health Information Exchange Architecture Implementation Guide The RLS must support both synchronous queries where the data is returned in a single round trip and asynchronous queries where the data is delivered in a new session some time after the original query The querier may request either synchronous or asynchronous queries the RLS may also default to asynchronous return of results if it is unable to complete a given query in a timely fashion The RLS must implement a probabilistic matching algorithm for patient queries so that the chance of incidental disclosure presenting a false match is minimized See the policy document Correctly Matching Patients with Their Records In responding to such queries the RLS will return zero or more matching demographic records each including a locator usually an Institution code and a Medical Records Number to a set of clinical data for that patient The locator contents are used for subsequent queries for clinical data The RLS will return only records which meet or exceed a minimum probability level See the policy document Correctly Matching Patients with Their Records The RLS will not provide a Break the Glass procedure in which a physician or other inquirer can request an emergency exception to allow examination of records below the minimum probability level Besides having a high probability of incidental disclosures and false positive matching there is no logical additional method that the inquirer can use to positively identify the correct record If a user has certainty that a record related to a specific patient exists at a particular entity that user should work directly with that entity to attempt to locate the record The RLS will return as matched data for any data transformations it performed in matching the data e g noting that it matched a name provided as Elizabeth with a patient whose first name is listed as Liz 18 The RLS should not return demographic data in fields not submitted by the querier The RLS may well have demographic details about a patient that a clinician has not submitted these details should not be displayed to avoid incidental disclosure and the risk of authorized users fishing for data The SNO must maintain a logical separation of clinical from demographic identifying data The RLS itself will not hold clinical data or metadata all of that is controlled by the entities that created the data or who hold copies because they provide the patient with care The design of the RLS assumes that the clinical data itself may be served from cached or other copied versions of the live clinical data and it is acceptable to centralize the physical storage of this data in order to control costs and guarantee service levels However wherever it is located the data itself should remain in the control of the providing institution which should be deferred to as the final source of truth on issues of data accuracy and cleanliness At the time or shortly after records are published to the RLS from entities the RLS must report obvious errors back to the publishing entity Such errors include but are not limited to non numeric characters or incorrect number of digits in numeric data such as SSN day month and year designations in Date of Birth dates that are out of range e g February 31 etc The requestor is not required by the Common Framework to act on these reports but the RLS must make them available and the individual SNO may have a policy requiring particular responses to such errors At the time of publishing records to the RLS from an entity the RLS may report possible errors including but not limited to name and gender fields with a high probability of inconsistency e g Sylvia M pairs of records above the matching threshold with different dates of birth patient records above the matching threshold with different local record numbers etc The publishing entity is not required by the Common Framework to act on these reports but the RLS must make them available and the individual SNO may have a policy requiring particular responses to such errors The RLS must be able to provide an audit log indicating all entities that have published records on behalf of an individual patient and all users that have received record locations in response to requests regarding an individual patient Adoption of a Matching Algorithm The RLS stands between authorized queriers either entities within a SNO including possible aggregation services or the ISB and a database of patient demographics and record locations The RLS s job is to take the incoming queries format the contents of the message and make a query to a matching algorithm that determines which records in the database are likely matches Those records and only those records are returned by the matching algorithm to the RLS The policies governing the matching algorithm are covered in Correctly Matching Patients with Their Records There is not any standard matching algorithm that can be adopted nationwide because the work on matching is highly sensitive to local regulations as with regions that forbid the use of Social Security Numbers SSNs for matching and to the relative cleanliness of the underlying data The more accurate the collection and storage practices are the more likely that highly accurate matching will occur with fewer fields See Background Issues on Data Quality in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange for a discussion of this issue Such algorithms are also highly sensitive to local characteristics of the data set being queried A last name of Smith is a better predictor of uniqueness in Wewoka OK than Waltham MA NYSIIS transformed 19 names are better matches for Anglo Saxon names than French names and so on The adoption of a matching algorithm that satisfies the conditions below is a nationwide requirement the nature and tuning of the particular algorithm must be left to the SNO itself The Common Framework makes the following assumptions about the matching algorithm The algorithm itself is not specified each SNO is free to use and tune any algorithm that meets the below criteria Two of our prototype sites have made their matching algorithms available as part of this release Indianapolis and Mendocino County Boston uses a commercially available product as do many existing health care systems Authorized queriers present a set of demographic details and receive in return zero or more matching record locations Only records meeting a minimum level of probability should be returned That minimum level is calculated at each RLS such that the probability of returning a false positive match is very low e g one chance in 100 000 Matches approaching but not reaching that level sometimes called fuzzy matches should not be returned to avoid incidental disclosures Further the querier should not be told which data elements do not match since that could encourage fishing It is legitimate to suggest that the querier provide additional data fields if these were not provided in the initial query The details of how those matches are calculated must be hidden from the querier by the RLS to preserve the ability of SNOs to use different and selectively tuned matching algorithms while maintaining standard interfaces Should the algorithm use transformations of the presented demographic data e g treating Maggie and Margaret or off by one errors in numerical data as approximate matches then the data returned should indicate both the fact of the match and the fact that a transformation was used in the match The details of the display are up to the receiving application but the information is provided to allow the requester possibly in conversation with the patient to add a check step against false positives which are possible even with a high probability match Because delivering too little information is far less dangerous than delivering the wrong information the algorithm must be tuned to minimize false matches even at the expense of increasing the number of failed matches false negatives The algorithm must meet the policy requirements for accuracy currently described in Correctly Matching Patients with Their Records A national health identification number is not required Demographic matching can work at population scale without triggering either the enormous expense or political risk of failure that will attend any work on unique patient IDs Should such an identifier exist however its use would still require the mechanics for matching and record location created by the RLS 20 Social security number although far from perfect as an identifier and other types of identifying numbers can increase the probability of achieving a correct match Individual SNOs may allow or require local IDs to be used as identifiers for the RLS e g a SNO in a region with a primary employer may add employer IDs to the criteria to be matched If there are records in the RLS that are below the matching threshold the querier may not be presented a list to choose from as this would create the very incidental disclosure the algorithm must be designed to avoid This restriction also forbids wild card searching disallowing a search for e g all patients with the last name Smith Instead the querier may be offered the ability to provide additional demographic details The RLS cannot assure that all records that exist for a given patient will be located even in principal because the patient may have received care outside the SNO and because even within the SNO there may be records that refer to the patient but are beneath the matching threshold or that are being kept confidential for reasons of patient preference or legal constraints from the State or local policies set by the SNO or participating entities The SNO may at its discretion require that displays of results returned from the RLS contain a reminder that the data may only be partial ISB The other application a SNO is required to host is the Inter SNO Bridge ISB The ISB is the interface to data held by a SNO but used by institutions outside the SNO It serves as a single point of access for all remote queries to entities inside any given SNO The technical details of the ISB are in the Health Information Exchange Architecture Implementation Guide The relevant policies are contained in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange The Common Framework makes the following assumptions about the design of the ISB There is one ISB per SNO which handles all per patient clinical requests coming from or going to that SNO The ISB is only for patient centered queries Aggregate queries e g Find all admissions in the last 24 hours presenting with shortness of breath should be dispatched to the participating institutions or run against aggregated databases that are collected and kept offline The lack of centralized clinical data keeps the ISB from being a target of loss or theft of clinical data and allows interactions to be optimized for a single simple case All transactions to and from the ISB are logged and audited The ISB must have a valid SSL certificate and may only communicate with requestors who support encrypted web communications https The ISB like the RLS is designed to take a query from authorized users in the form of demographic details or alternatively a query in the form of a unique provider ID plus a Medical Record Number The ISB must support patient data in incoming queries expressed in the HL7 2 4 format described in the Health Information Exchange Architecture Implementation Guide The ISB may support incoming queries expressed in the HL7 3 0 format described in the Health Information Exchange Architecture Implementation Guide The ISB must support two possible patterns of request The one pass pattern has the requestor presenting patient details and receiving back the aggregated records In this case the ISB has acted as the aggregator as described in Step 2 of the section Modeling Interactions above The other pattern that must be supported is a two pass interaction in which the ISB acts like a standard RLS returning locators to the remote querier who then replies with a list of records they would like access to The ISB must support asynchronous delivery of records where the requestor whether a remote ISB or other entity sends a request in and then makes available a server for later delivery of the results of the request Later may only be measured in seconds but the asynchronous pattern is important because there is no guarantee that the ISB can dispatch and resolve all the required transactions local to the SNO quickly enough to support a synchronous return pagebreak Part III External Dependencies and Open Issues Security Identity Authentication and Authorization Trust is the essential glue enabling transfer of medical records and distrust is a key defense against their misuse All the hardware and software in the world will not provide adequate defenses against users who are allowed to have copies of records from your institution if those users fail to protect the records properly or if they actively misuse those records It is thus critical to provide the holder of any given set of records enough information to enable them to answer the question Do I trust the person making this request and the institution they work for In a large network it will be impossible for every possible pair of sender and receiver of a request to know one another in advance Particularly for remote queries some sort of transitive trust will be necessary If I trust Institution A I trust Institution A s employees To make such a judgment the requestor must be able to identify Institution A In addition the recipient of the request may need to review one or more queries after the fact it is essential in this case that the recipient be able to communicate quickly and effectively with the sender of the request Being able to provide the time date entity identifier and person identifier will make such reviews considerably simpler quicker and cheaper than merely having a transaction ID and requiring the counterparty to look it up in order to discover those identifiers on their own The federal HIPAA Privacy and Security Rules and applicable state laws provide the baseline for the Markle Connecting for Health Common Framework although in some cases greater privacy protections and individual rights are recommended by the CFH Policy Subcommittee In no instance does the Common Framework permit less protection of personal health information than those required by federal or state law however participation in an SNO is not a surrogate for determining whether a Participant is a HIPAA Covered Entity or is in compliance with the HIPAA regulations Importantly the Common Framework permits SNO Participants to establish and follow their own more protective data management privacy and security policies and procedures In addition some customization may be necessary at the SNO and Participant level to ensure consistency and compliance with applicable state laws In addition to HIPAA Markle Connecting for Health recommends but does not require use of the use of the Common Criteria ISO 15408 to analyze the security procedures of the SNO and of each participating entity In addition to HIPAA requirements the transitive trust model requires reliable reporting of identity between parties participating in a record exchange which in turn requires the issuing of identifiers for employees and the maintenance of an authentication and authorization systems Identifiers authentication and authorization are all required by HIPAA what the Common Framework specifies are the reporting requirements necessary for transitive trust plus the additional policies related to the transitive trust model as laid out in Authentication of System Users in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange These reporting requirements have three levels Reporting of SNO identity for inter SNO communications Reporting of entity identity the HIPAA mandated identity Reporting of the identity of the individual who authorized the query 21 Reporting of SNO Identity As noted above the Common Framework assumes a thin NHIN the NHIN is a network of networks with no NHIN wide services required other than basic connectivity Both the data and the contextual functions required for inter SNO transfers of data rely on capabilities provided by the aggregate group of SNOs There are no top level service providers required 22 In particular we do not envision a single top level identity service Instead individual health care entities will use the identifiers mandated under HIPAA and the SNOs are required to provide an invariant name expressed as a URI 23 that is unique within the NHIN 24 In practice the URI will also be the URL of the SNO thus using the Domain Name System as the basic guarantor of uniqueness Reporting of Entity Identity In the case of inter SNO communications it is not enough to know which SNO has dispatched a message the source entity e g clinic hospital lab must also be identified In practice this identifier will be the HIPAA mandated National Provider Identifier NPI 25 plus a human readable name of the institution Reporting of Individual Identity In the case of inter SNO communications it is not enough to know which SNO and entity has dispatched a message the requesting individual must also be identified There is no person equivalent of the NPI under HIPAA therefore some form of username or employee ID unique within the domain of a particular NPI must be reported along with the human readable name of the person making the request One possibility we explored but did not require was the additional reporting of the role of the requesting individual e g clerk admitting physician etc The reporting of such roles would be valuable in cases where the institution receiving the request wanted to limit responses to queriers with certain roles However the reporting of roles today is not universally adopted and where it is in use the definitions of the roles themselves are variable between institutions If role based access becomes important to the operation of the NHIN considerable work will need to be done to standardize the expression of such roles As noted above the reporting of these three identifiers SNO entity person serves two separate functions The first is to allow judgment about whether to honor a given request for records based on past expectations The second is to simplify future audits should a particular transaction or set of transactions come under suspicion Based on the transmission of these identifiers there are four conceptual levels of record exchange Within a single entity Between entities in a SNO Between entities in different SNOs Requests from an entity not affiliated with a SNO Within an Entity Because this takes place beneath the level of SNO wide traffic these transactions are governed by the entity alone and raise no SNO wide identity reporting requirements Between Entities in a SNO These transactions are governed by SNO wide policies but in all cases the entity making a request either to the RLS or to other entities must report its NPI and the username and name of the person making the request Because both sender and receiver are part of the same SNO we presume that most of these requests will be routine and will be subjected to a routine level of scrutiny Between Entities in Different SNOs These transactions are not governed by any mutual contractual obligations as entities in a single SNO are Instead they are governed by HIPAA and other national regulations and by the adoption of the Common Framework by each SNO In all cases the entity making the request must report the SNO of which it is a member its NPI and the username and name of the person making the request Because sender and receiver of a query are not part of the same SNO we assume these queries will be relatively rare in comparison to the volume of local traffic and should be subjected to a higher level of scrutiny Requests from an entity not affiliated with a SNO 26 The entity making a request to the SNO must report its NPI and the username and name of the person making the request Because the sender is not part of the any SNO we presume that most of all requests will be regarded as unusual and will be subjected to the highest level of scrutiny Preventive Security Encryption and Certificate Exchange Preventive security encompasses defenses against outside attack insider misuse of data accidental loss or deletion and so on Outside the issues particular to identity authentication and authorization preventive security involves defending against access to data by unauthorized parties misuse of data by authorized parties unauthorized alteration of data and accidental disclosure or deletion of data As noted above the principal governing requirement for security is HIPAA which describes administrative physical and technical safeguards required for securing data In addition to HIPAA requirements and the policy requirements of Identity Authentication and Authorization the Common Framework makes the following two specific security requirements SSL TLS Encryption All traffic within and between SNOs will be encrypted using Secure Socket Layers 3 0 SSL or Transport Layer Security v 1 0 TLS Exchange of SNO Certificates Between Pairs of SNOs Each ISB must have an SSL certificate and any two ISBs planning to exchange data must each have the other s certificate This is implicit in the required asynchronous data exchange pattern between ISBs Note that making each new SNO exchange credentials with all current SNOs will become problematic as the NHIN grows large 27 We believe however that exchange of certificates between pairs of SNOs is the proper model for the NHIN in its early years for two reasons first the number of SNOs and therefore of ISBs needing certificates will be small Second the trust of the participants in the system is a critical predictor of its success a system that is technically feasible but unpalatable to real world institutions will simply fail Taken together we believe that requiring that each new entrant announce itself to the existing members and requiring some formal per pair handshake will not be technically onerous for a network containing even a hundred separate SNOs something that would occur in 2008 at the earliest and would be beneficial in terms of assuring participants that the network contained no unknown actors It will also provide a better environment for actually watching trust develop thus providing experience valuable to the design of any later stage certificate brokering system 28 Two proposed but not currently adopted questions around encryption merit further examination the encryption of data as stored on a disk and the special issues involved in handling SSNs With regards to encryption there is considerable work being done on on disk encryption where the contents of every file are stored in an encrypted format and are only able to be decrypted when running in a trusted environment e g with proper user authentication This means that should hardware containing information on patients be physically stolen as happened frequently in recent years the material contained would not be available to the holders of the physical disk without their also having access to the password or any other required forms of identification Though such systems are not so widely adopted today that we feel comfortable mandating their use as part of the Common Framework the increasing threat of identity theft coupled with the increasingly large aggregated data sets being generated by the health care industry means that continued attention needs to be paid to the possibility of including such a requirement The use of SSNs also creates a special set of problems A patient s SSN can be a valuable tool in improving match accuracy and is in use in many medical record systems However the SSN is also a weak and poorly designed authentication token and a key input to identity theft and other forms of personal intrusion As a result there are good reasons to both use and not use SSN and while there are health information networks in operation today which require its use there are others that forbid it It is clear that the rise in identity theft is going to lead to some regulation of the use of SSNs whether industry by industry state by state or on a national level As a result any SNO implementing an RLS must take special care in deciding whether to use SSN as a match field and if so must take special care in protecting the SSN never returning the SSN when a match is made even if an SSN was submitted for a patient so as to prevent fishing Though use of the last 4 digits of the SSN is on the rise this is simply re creating the original difficulty An attacker who has the last 4 digits of a full SSN but only needs to report those 4 digits to gain access to material has the same advantage as an attacker who has the full SSN when the full SSN is required 29 Reactive Security Auditing and Logging In addition to preventive security procedures need to be in place for detection of security breaches and other misuse of data While detection is an important part of securing any system it is especially vital in the health care system Health is not money and health care is not banking where many industries can tolerate a relatively high degree of inconvenience in their user transactions health care cannot Waiting a couple of days to get a new ATM card is an inconvenience waiting a couple of hours to get data on a patient s allergies can be fatal Because of this there is a presumption towards disclosure in cases where a physician reports a critical need for the data a presumption reflected in for example Break the Glass modes of access In addition to preventive measures against accidental or intentional misuse of data maintaining a good log of the use of the system and periodically auditing that log to look for negative events or patterns is critical While preventative security requires a high degree of standardization so that everyone can for example use the same encryption scheme reactive security requires less standardization Instead the ability to detect and react to events after the fact requires policies that set a minimum level of technical requirements which requirements can be met in ways most compatible with the rest of a particular SNO s technological choices For the first phase of this work we have specified two sets of policies regarding reactive security Logging and Auditing Managing breaches Logging and Auditing It is essential that information about all relevant transactions that touch clinical data be logged so that the system can be periodically audited and so that should there be misuse of data the events leading up to that misuse can be examined and it is essential that these logs be immutable so that once written they cannot be edited or deleted in order to prevent sophisticated attackers from removing traces of their work The other essential constraint is that such logs not contain the full record being transmitted so that the logs themselves do not become an alternate target for attackers looking for clinical information The Common Framework policies regarding logging and auditing are contained in Markle Connecting for Health Auditing Access to and Use of a Health Information Exchange Managing Breaches In addition to preventing breaches of identifying or clinical data where possible every SNO needs a set of policies for reacting to such breaches where they occur and these policies will necessarily differ between cases such as accidental disclosure suffering from a successful external attack or having an authorized employee misuse data The Common Framework policies regarding breaches of information are contained in Breaches of Confidential Health Information in The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange External Standards Though the Markle Connecting for Health prototype is obviously standards based rather than assuming homogeneity of underlying technology we are principally a consumer of standards rather than a producer of them Much of the prototype work was an attempt to avoid setting standards where possible either by designing a system tolerant of multiple standards as with the separation of clinical message contents from their delivery envelope or by taking advantage of existing standards Many of the technical issues requiring standardization were solved by adopting Web Services standards there are two cases where that has not been sufficient 30 Coordinating asynchronous communication between SNOs Making assertions about the individuals responsible for a request In the case of coordinating asynchronous communications the obvious standard to use is WS Addressing 31 In the case of assertions about the identity of requesting individuals the obvious standard to use is

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

  • T2 | Markle | Advancing America's Future
    NHINQuery node One echoes the CLIENT control information and the other contains the query response For example the topmost level of the PatientDataQuery SOAP message BODY might look like soapenv Body xmlns nhin http www nhin gov messaging nhin NHINResponse nhin EvaluationSettings nhin MaxResponseInterval 60 nhin MaxResponseInterval nhin ResponseStyle I nhin ResponseStyle nhin EvaluationSettings nhin Response format HL7 version 2 4 RSP Z01 xmlns urn hl7 org v2xml RSP Z01 nhin Response nhin NHINResponse soapenv Body All NHIN queries are expressed as HL7 2 4 messages and segments Most of the query responses are also standard HL7 messages and are represented in a single Response node However queries that return medication history do so in the NCPDP Scripts 8 1 XML format an XML representation of NCPDP rather than in HL7 To accommodate this and future mixed data representations within a query response multiple Response nodes are permitted Data formats are not mixed within one Response node For example an HL7 response will never be intermixed with an NCPDP Scripts response although they may be wrapped within the same query response message Every EvaluationSettings node has the same schema definition across all messages as documented in Appendix C Values within this node define general query processing settings like the maximum time interval before the querying system expects a response as per the example above We define the following SOAP operations which cover the current use cases Operation Description PatientDataQuery Requests patient health data for a single patient PatientDataQueryResponse Returns the requested patient health data for all registrations found for the specified person 4 1 XML Namespaces NHIN query messages currently use two namespaces for NHIN specific elements and attributes one for the query data and one for the header attributes used to route the asynchronous query responses see next section of this document The header attributes used for response routing are defined in the http www nhin gov addressing namespace which is qualified as nhinWsa in the examples used in this document Note that nhin gov is a URI but not a URL we have adopted it simply to guarantee uniqueness of namespace All other NHIN specific elements and attributes are defined in the http www nhin gov messaging namespace which we qualify with nhin in the examples in this document The SOAP envelope tags for a typical NHIN query might look like soapenv Envelope xmlns soapenv http schemas xmlsoap org soap envelope xmlns xsd http www w3 org 2001 XMLSchema xmlns xsi http www w3 org 2001 XMLSchema instance xmlns nhinWsa http www nhin gov addressing xmlns nhin http www nhin gov messaging soapenv Envelope 4 2 Asynchronous Query and Response Messaging Between ISBs We expect that the WS Addressing 1 0 W3C Recommendation will become a W3C standard within the next year We believe it will enjoy widespread use following standardization and that tools for implementing it will then proliferate Of special interest to the NHIN project are the WS Addressing 1 0 controls in the SOAP header for defining an asynchronous SOAP conversation since all initial NHIN SOAP conversations will be asynchronous However NHIN is not comfortable making WS Addressing 1 0 a requirement for initial NHIN participants WS Addressing is not easily implemented across SOAP server platforms at least in the versions that are currently in wide use Newer implementations as they currently exist would make it difficult to communicate with NHIN servers on their present SOAP server platforms Hence NHIN defines its asynchronous conversations using a subset of the tag names that WS Addressing would use but in NHIN s own XML namespace The NHIN architecture also defines its logically asynchronous query and reply conversation as a pair of physically synchronous SOAP conversations one conversation for the query and one for the response These variances from real WS Addressing enable immediate use of the NHIN message infrastructure but simplify the move to full WS Addressing in the future For now a WS Addressing style value in the SOAP message header defines where the asynchronous query response will be sent by the NHIN server In an asynchronous NHIN query and reply a NHIN client sends a query to an NHIN server in a SOAP message The NHIN server immediately returns a SOAP ACK message see Appendix F to the NHIN client signifying that the query has been received and understood This initial SOAP conversation representing the NHIN query is now complete as far as the SOAP servers are concerned Once the NHIN server has read and formatted the query results it initiates a new SOAP conversation The NHIN server sends the query response to the destination it found in the node of the original SOAP query message Once the NHIN client receives the query response it returns a SOAP ACK to the NHIN server This completes the NHIN response SOAP conversation To summarize the NHIN logical query and respond conversation is implemented as two physical SOAP conversations a query and ACK SOAP conversation followed by a separate respond and ACK SOAP conversation This logically asynchronous conversation can be implemented on virtually all SOAP server platforms Suppose the ISB receives a message whose SOAP message begins with the following soapenv Envelope xmlns soapenv http schemas xmlsoap org soap envelope xmlns xsd http www w3 org 2001 XMLSchema xmlns xsi http www w3 org 2001 XMLSchema instance xmlns nhinWsa http www nhin gov addressing xmlns nhin http www nhin gov messaging soapenv Header nhinWsa MessageId 1234 nhinWsa MessageId nhinWsa ReplyTo nhinWsa Address https 1 2 3 4 8443 myapp services NHINQuery nhinWsa Address nhinWsa ReplyTo soapenv Header The ISB will send the NHINPatientDataResponse query response to the URL http 1 2 3 4 8080 myapp services NHINPatientDataResponse An example of a SOAP header with full NHIN addressing information follows soapenv Envelope xmlns soapenv http schemas xmlsoap org soap envelope xmlns xsd http www w3 org 2001 XMLSchema xmlns xsi http www w3 org 2001 XMLSchema instance xmlns nhinWsa http www nhin gov addressing xmlns nhin http www nhin gov messaging soapenv Header nhinWsa MessageId 1234 nhinWsa MessageId nhinWsa ReplyTo nhinWsa Address https 1 2 3 4 8443 myapp services NHINQuery nhinWsa Address nhinWsa ReplyTo soapenv Header soapenv Body soapenv Body soapenv Envelope 4 3 Identifying the Query User Every query must identify the user who initiated the query as per HIPAA guidelines and log the user identification along with a description of the data that was accessed The Inter SNO Bridge service that receives the NHIN query trusts that the user was properly authenticated by the sending SNO The mechanism for reaching that understanding is beyond the scope of this document We consulted the OASIS SAML specification to find the format in which it represents username information in the SOAP header hoping to use their format However the UsernameToken 1 0 profile does not specify some attributes that we require like the user s full name in any concrete manner Instead then NHIN queries identify the query requesting user in an NHIN specific node within the SOAP header NHIN plans to harmonize its user identification format with the SAML specification in the future Currently though the query user s identity in the node is in the same data format that one would use to retrieve the access log information about that query user That is the query user is defined in the same format that would be found within an HL7 query or response NHIN queries represent the query requesting user in a familiar HL7 2 4 XCN data type An example follows nhin Security nhin QueryRequestor XCN 1 JoeUser CX 1 XCN 2 Smith XCN 2 XCN 3 Joseph XCN 3 XCN 9 HD 1 ST ELSEWHERE HOSPITAL Users HD 1 HD 2 USERID HD 2 HD 3 ST ELSEWHERE HOSPITAL HD 3 XCN 9 XCN 13 EI XCN 13 XCN 14 HD 1 ST ELSEWHERE HOSPITAL HD 1 XCN 14 nhin QueryRequestor nhin Security This is the same manner in which that user would have been represented within any of the HL7 2 4 messages sent across the NHIN 4 4 NHIN Server Error Handling Upon receipt of a request message from a CLIENT system the SERVER acknowledges receipt of the message validates the syntax of the incoming message and asynchronously starts processing the message If an error occurs after the valid message indication the error information must be returned to the CLIENT system in the asynchronous SOAP response If the error occurs before the SERVER validates the query message and responds with the ACK SOAP message a SOAP Fault can be generated Appendix D lists the potential fault codes returned and the information that should be included in the accompanying detail When an error fault occurs after the NHIN server has sent its ACK back to the NHIN client it is impossible or at least very difficult to return a SOAP Fault using a current SOAP server Therefore the error fault must be sent back in the asynchronous query response message In that message the MSA 1 ACKNOWLEDGMENT CODE value is AE Application Error instead of AA A descriptive fault message is also returned in the MSA 3 TEXT MESSAGE The NHIN SERVER can encounter different types of errors once it receives a valid query message An application error may occur within the SERVER itself A SOAP fault may occur when the SERVER tries to send a SOAP message to another node within its SNO when that system is down appropriate security certificates are not in place network communications fail the service rejects the message due a syntax error etc Finally a true application error may occur inside the SNO node that is doing the query resolution on behalf of the NHIN server In the first case the NHIN Server must create its own error code and error message In the second case the server retrieves the SOAP fault code and error message from the SOAP fault In the third case the server recovers the application error information from the response message it gets back from the SNO node In any case the NHIN server ends up with an error code and an error message that are sent back to the CLIENT within the MSA segment of the query response pagebreak 5 HL7 Queries within PatientDataQuery Operation Although there is a single NHIN SOAP operation it may contain a variety of different HL7 queries HL7 2 4 requires a formal Conformance Statement be published for each of these queries The sections that follow document the currently supported NHIN queries for patient data and their Conformance Statements Table 1 below lists all of the currently defined HL7 queries supported within the NHINQuery service HL7 Queries Supported by NHINQuery SOAP Service 5 1 Observation Reporting Query for Patient Results and Reports An Observation Reporting Query requests clinical results and reports for one person Query parameter values may be used to limit the number and type of the returned results and reports The query contains HL7 s MSH QPD and PID and RCP segments in that order The response message is an HL7 response based on the ORU R01 message for laboratory reports and results and or a NCPDP Scripts 8 1 element for medication dispensing history The official HL7 query conformance statement for the query is defined in section below although it does not address the medication dispensing history portion of the returned data Most clinical data are supported by this query response pair Clinical laboratory results pathology reports vital signs nursing notes radiology reports diagnosis lists patient questionnaire results discharge summaries and more are easily represented in the response message Refer to chapter 7 of the HL7 2 4 manual for more details on the ORU R01 message and its great flexibility The HL7 ORU R01 messages are formatted according to the ELINCS 2 0 standard formerly available at http www chcf org topics chronicdisease index cfm The ELINCS specification contains an implementation guide for constructing HL7 ORU R01 messages ELINCS defines LOINC codes to be used for common laboratory tests types of HL7 data expected in each ORU R01 data field and general guidelines for HL7 message construction Laboratory Results Standards part of The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange notes the deviations we make from the ELINCS standard For the most part these deviations are simply the permission to populate HL7 data fields in cases where ELINCS prohibits those data fields from being valued The NCPDP Scripts 8 1 XML in which the medication dispensing history is returned is described in Medication History Standards part of The Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange 5 1 1 Observation Reporting Query Conformance Statement Query Grammar Pattern Response Grammar Pattern QPD Input Parameter Specification QPD Input Parameter Field Description and Commentary RCP Response Control Parameter Field Description and Commentary 5 1 2 Observation Reporting Query HL7 Message Description The QPD segment defines the type of data amount of data and reporting time frame of the data being requested The PID segment defines the patient for whom data is being requested 5 1 3 Observation Reporting Query Response Message This response message is based on the standard HL7 ORU R01 message It contains one RSP Z01 node for each registration for which results and or reports exist Each RSP Z01 node contains exactly one RSP Z01 PATIENT node which contains exactly one PID node Each RSP Z01 node also contains one or more RSP Z01 ORDER OBSERVATION nodes Each RSP Z01 ORDER OBSERVATION node represents a single result battery or text report as per the HL7 Observation Reporting specification The order of the RSP Z01 ORDER OBSERVATION nodes is not guaranteed The following table lists the HL7 segments that one can currently expect in the NHIN query response Note that the HL7 specification defines additional segments for this message type but that NHIN queries do not return those optional segments at this point in time In fact most of those optional segments will never be returned in NHIN query responses Note that the XML format for sending HL7 results requires some additional grouping tags that segregate the registration data from the reports Our sample messages demonstrate this grouping 5 1 4 Complete Example Sample Query QBP Z01 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Query Application Name HD 1 MSH 3 MSH 4 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 4 MSH 5 HD 1 Target ISB HD 1 MSH 5 MSH 6 HD 1 Target SNO Name HD 1 MSH 6 MSH 7 TS 1 200506171410 TS 1 MSH 7 MSH 9 MSG 1 QBP MSG 1 MSG 2 Z01 MSG 2 MSG 3 QBP Z01 MSG 3 MSH 9 MSH 10 123456789 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH QPD QPD 1 CE 1 Z01 CE 1 CE 2 Observation Reporting Query CE 2 CE 3 NHIN Query Code CE 3 QPD 1 QPD 2 Q123456 QPD 2 QPD 3 CE 1 RES CE 1 CE 2 result CE 2 CE 3 0048 CE 3 QPD 3 QPD 5 CE 1 LABORATORY CE 1 CE 2 Laboratory CE 2 CE 3 NHIN 0001 CE 3 QPD 5 QPD 6 TS 1 19980810 TS 1 QPD 6 QPD 8 LATEST QPD 8 QPD PID PID 1 PID 1 PID 2 PID 2 PID 3 PID 3 PID 5 XPN 1 FN 1 THOMPSON FN 1 XPN 1 XPN 2 MARK XPN 2 XPN 3 Q XPN 3 PID 5 PID 5 XPN 1 FN 1 AliasLastName FN 1 XPN 1 XPN 2 AliasFirstName XPN 2 XPN 3 AliasMiddleName XPN 3 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 1 SAD 1 28W 10TH Street SAD 1 XAD 1 XAD 3 Metropolis XAD 3 XAD 4 IN XAD 4 XAD 5 98765 XAD 5 PID 11 PID 11 XAD 1 SAD 1 666 Bleaker Street SAD 1 XAD 1 XAD 3 QUINCY XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID 19 9991112222 PID 19 PID RCP RCP 1 I RCP 1 RCP 2 CQ 1 10 CQ 1 RCP 2 RCP QBP Z01 Sample Response RSP Z01 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Target ISB HD 1 MSH 3 MSH 4 HD 1 Target SNO Name HD 1 MSH 4 MSH 5 HD 1 Query Application Name HD 1 MSH 5 MSH 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 6 MSH 7 TS 1 20051024074506 TS 1 MSH 7 MSH 9 MSG 1 RSP MSG 1 MSG 2 Z01 MSG 2 MSG 3 RSP Z01 MSG 3 MSH 9 MSH 10 432 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH MSA MSA 1 AA MSA 1 MSA 2 123456789 MSA 2 MSA QAK QPD QPD 1 CE 1 Z01 CE 1 CE 2 Observation Reporting Query CE 2 CE 3 NHIN Query Code CE 3 QPD 1 QPD 2 Q123456 QPD 2 QPD 3 CE 1 RES CE 1 CE 2 result CE 2 CE 3 0048 CE 3 QPD 3 QPD 5 CE 1 LABORATORY CE 1 CE 2 Laboratory CE 2 CE 3 NHIN 0001 CE 3 QPD 5 QPD 6 TS 1 19980810 TS 1 QPD 6 QPD 8 LATEST QPD 8 QPD RSP Z01 PATIENT RESULT RSP Z01 PATIENT PID PID 3 CX 1 MADEUP 7 CX 1 CX 4 HD 1 ST ELSEWHERE HOSPITAL Medical Record Numbers HD 1 HD 2 MEDICAL RECORD NUMBER HD 2 HD 3 ST ELSEWHERE HOSPITAL HD 3 CX 4 CX 5 MR CX 5 CX 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 CX 6 PID 3 PID 5 XPN 1 FN 1 THOMSON FN 1 XPN 1 XPN 2 MARK XPN 2 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 3 N QUINCY XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID RSP Z01 PATIENT RSP Z01 ORDER OBSERVATION OBR OBR 3 EI 1 FAKE 14454 EI 1 EI 2 ST ELSEWHERE HOSPITAL EKG System EI 2 EI 3 FILLER ORDER NUMBER EI 3 EI 4 ST ELSEWHERE HOSPITAL EI 4 OBR 3 OBR 4 CE 1 18844 1 CE 1 CE 2 EKG CE 2 CE 3 LN CE 3 OBR 4 OBR 7 TS 1 198905191158 TS 1 OBR 7 OBR RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8626 4 CE 1 CE 2 P Wave Axis CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 75 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8632 2 CE 1 CE 2 QRS Axis CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 106 OBX 5 OBX 8 HH OBX 8 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8638 9 CE 1 CE 2 T Wave Axis CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 9 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 CE OBX 2 OBX 3 CE 1 18844 1 CE 1 CE 2 EKG CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 CE 1 9327 CE 1 CE 2 normal sinus rhythm CE 2 CE 3 Local Concept CE 3 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 CE OBX 2 OBX 3 CE 1 18844 1 CE 1 CE 2 EKG CE 2 CE 3 LN CE 3 OBX 3 OBX 4 1 OBX 4 OBX 5 CE 1 11397 CE 1 CE 2 sinus arrhythmia CE 2 CE 3 Local Concept CE 3 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 CE OBX 2 OBX 3 CE 1 18844 1 CE 1 CE 2 EKG CE 2 CE 3 LN CE 3 OBX 3 OBX 4 2 OBX 4 OBX 5 CE 1 678 CE 1 CE 2 right bundle branch block CE 2 CE 3 Local Concept CE 3 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 CE OBX 2 OBX 3 CE 1 18844 1 CE 1 CE 2 EKG CE 2 CE 3 LN CE 3 OBX 3 OBX 4 3 OBX 4 OBX 5 CE 1 18557 CE 1 CE 2 abnormal ECG CE 2 CE 3 Local Concept CE 3 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8637 1 CE 1 CE 2 RR Interval CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 998 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8634 8 CE 1 CE 2 QT Interval CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 436 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 OBSERVATION OBX OBX 2 NM OBX 2 OBX 3 CE 1 8625 6 CE 1 CE 2 PR Interval CE 2 CE 3 LN CE 3 OBX 3 OBX 4 0 OBX 4 OBX 5 160 OBX 5 OBX 11 F OBX 11 OBX 14 TS 1 198905191158 TS 1 OBX 14 OBX RSP Z01 OBSERVATION RSP Z01 ORDER OBSERVATION RSP Z01 PATIENT RESULT RSP Z01 5 2 Patient Identities Query Message A Patient Identities Query identifies a person of interest person attributes are specified in an HL7 PID segment and requests the NHIN server to find all of the known patient registrations for that person across that SNO The SOAP request message is an HL7 Query By Parameter QBP message with event code Z02 It contains HL7 s MSH QPD PID and RCP segments in that order The response message will contain one PID segment for each registration found in one of the SNO s Master Patient Index tables 5 2 1 Patient Identities Query Conformance Statement Query Grammar Pattern Response Grammar Pattern Only the PID segment is currently valued but other segments might be valued in future releases QPD Input Parameter Specification QPD Input Parameter Field Description and Commentary RCP Response Control Parameter Field Description and Commentary 5 2 2 Patient Identities Query Message Description 5 2 3 Patient Identities Response Message Format This response contains a list of HL7 PID segments one for each patient registration that matches the attributes specified in the query In the case where no matches are found the return message contains no PID segments No matches is not considered an error condition The response is an HL7 ADT Response ADR message with event code A19 It contains only the HL7 MSH MSA and PID segments in that order There is one PID segment per registration match found 5 2 4 Sample Patient Identities Query Message Dialogue Sample Query QBP Z02 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Query Application Name HD 1 MSH 3 MSH 4 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 4 MSH 5 HD 1 Target ISB HD 1 MSH 5 MSH 6 HD 1 Target SNO Name HD 1 MSH 6 MSH 7 TS 1 200506171410 TS 1 MSH 7 MSH 9 MSG 1 QBP MSG 1 MSG 2 Z02 MSG 2 MSG 3 QBP Z02 MSG 3 MSH 9 MSH 10 987654321 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH QPD QPD 1 QPD 1 QPD 2 QPD 2 QPD PID PID 1 PID 1 PID 2 PID 2 PID 3 PID 3 PID 5 XPN 1 FN 1 THOMPSON FN 1 XPN 1 XPN 2 MARK XPN 2 XPN 3 Q XPN 3 PID 5 PID 5 XPN 1 FN 1 AliasLastName FN 1 XPN 1 XPN 2 AliasFirstName XPN 2 XPN 3 AliasMiddleName XPN 3 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 1 SAD 1 28W 10TH Street SAD 1 XAD 1 XAD 3 Metropolis XAD 3 XAD 4 IN XAD 4 XAD 5 98765 XAD 5 PID 11 PID 11 XAD 1 SAD 1 666 Bleaker Street SAD 1 XAD 1 XAD 3 QUINCY XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID 19 9991112222 PID 19 PID RCP QBP Z02 Sample Response RSP Z02 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Target ISB HD 1 MSH 3 MSH 4 HD 1 Target SNO Name HD 1 MSH 4 MSH 5 HD 1 Query Application Name HD 1 MSH 5 MSH 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 6 MSH 7 TS 1 20051024074505 TS 1 MSH 7 MSH 9 MSG 1 QBP MSG 1 MSG 2 Z02 MSG 2 MSG 3 QBP Z02 MSG 3 MSH 9 MSH 10 2 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH MSA MSA 1 AA MSA 1 MSA 2 123456789 MSA 2 MSA QAK QPD QPD 1 QPD 1 QPD 2 QPD 2 QPD RSP Z02 QUERY RESPONSE PID PID 1 PID 2 PID 3 CX 1 MADEUP 7 CX 1 CX 4 HD 1 ST ELSEWHERE HOSPITAL Medical Record Numbers HD 1 HD 2 MEDICAL RECORD NUMBER HD 2 HD 3 ST ELSEWHERE HOSPITAL HD 3 CX 4 CX 5 MR CX 5 CX 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 CX 6 PID 3 PID 5 XPN 1 FN 1 THOMSON FN 1 XPN 1 XPN 2 MARK XPN 2 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 3 N QUINCY XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID RSP Z02 QUERY RESPONSE RSP Z02 QUERY RESPONSE PID PID 1 PID 2 PID 3 CX 1 MADEUP 8 CX 1 CX 4 HD 1 ST ELSEWHERE HOSPITAL Medical Record Numbers HD 1 HD 2 MEDICAL RECORD NUMBER HD 2 HD 3 ST ELSEWHERE HOSPITAL HD 3 CX 4 CX 5 MR CX 5 CX 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 CX 6 PID 3 PID 5 XPN 1 FN 1 THOMSON FN 1 XPN 1 XPN 2 MARCUS XPN 2 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 3 BOSTON XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID RSP Z02 QUERY RESPONSE RSP Z02 5 3 Access History Query Reporting NHIN Accesses Made and Attempted Access History Query requests data from the SNO s log of access attempts This information could be used to obtain data about whose information a particular user has been accessing which users have been accessing a particular person s data or a combination of those conditions HL7 supports this type of query with its QBP RTB pattern query by parameter and tabular response The QPD elements can also be used to limit the returned access log data by time The RCP elements can limit the response data to a maximum number of rows 5 3 1 Access History Query Conformance Statement Query Grammar Pattern Response Grammar Pattern QPD Input Parameter Specification QPD Input Parameter Field Description and Commentary RCP Response Control Parameter Field Description and Commentary Input Output Specification Virtual Table Virtual Table Field Description and Commentary 5 3 2 Access History Query HL7 Message Segments 5 3 3 Access History Query Response Message Format This response contains a list of the virtual rows one per user access returned from the user access log No matches is not considered an error condition No rows are simply returned 5 3 4 Sample Access History Message Dialogue Sample Query QBP Z03 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Query Application Name HD 1 MSH 3 MSH 4 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 4 MSH 5 HD 1 Target ISB HD 1 MSH 5 MSH 6 HD 1 Target SNO Name HD 1 MSH 6 MSH 7 TS 1 200506171410 TS 1 MSH 7 MSH 9 MSG 1 QBP MSG 1 MSG 2 Z03 MSG 2 MSG 3 QBP Z03 MSG 3 MSH 9 MSH 10 987654321 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH QPD QPD 1 CE 1 Z03 CE 1 CE 2 Access History Query CE 2 CE 3 NHIN Query Code CE 3 QPD 1 QPD 2 Q987654321 QPD 2 QPD 4 TS 1 200602241030 TS 1 QPD 4 QPD PID PID 1 PID 1 PID 2 PID 2 PID 3 PID 3 PID 5 XPN 1 FN 1 THOMPSON FN 1 XPN 1 XPN 2 MARK XPN 2 XPN 3 Q XPN 3 PID 5 PID 5 XPN 1 FN 1 AliasLastName FN 1 XPN 1 XPN 2 AliasFirstName XPN 2 XPN 3 AliasMiddleName XPN 3 PID 5 PID 7 TS 1 19090630 TS 1 PID 7 PID 8 M PID 8 PID 11 XAD 1 SAD 1 28W 10TH Street SAD 1 XAD 1 XAD 3 Metropolis XAD 3 XAD 4 IN XAD 4 XAD 5 98765 XAD 5 PID 11 PID 11 XAD 1 SAD 1 666 Bleaker Street SAD 1 XAD 1 XAD 3 QUINCY XAD 3 XAD 4 MA XAD 4 XAD 5 02171 XAD 5 PID 11 PID 19 9991112222 PID 19 PID RCP QBP Z03 Sample Response RTB Z03 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Target ISB HD 1 MSH 3 MSH 4 HD 1 Target SNO Name HD 1 MSH 4 MSH 5 HD 1 Query Application Name HD 1 MSH 5 MSH 6 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 6 MSH 7 TS 1 20051024074505 TS 1 MSH 7 MSH 9 MSG 1 RSP MSG 1 MSG 2 Z03 MSG 2 MSG 3 RSP Z03 MSG 3 MSH 9 MSH 10 2 MSH 10 MSH 11 PT 1 P PT 1 MSH 11 MSH 12 VID 1 2 4 VID 1 MSH 12 MSH MSA MSA 1 AA MSA 1 MSA 2 123456789 MSA 2 MSA QAK QPD QPD 1 CE 1 Z03 CE 1 CE 2 Access History Query CE 2 CE 3 NHIN Query Code CE 3 QPD 1 QPD 2 Q987654321 QPD 2 QPD 4 TS 1 200602241030 TS 1 QPD 4 QPD RTB Z03 ROW DEFINITION RDF RDF 1 8 RDF 1 RDF 2 RCD 1 QueryUser RCD 1 RCD 2 XCN RCD 2 RCD 3 100 RCD 3 RDF 2 RDF 2 RCD 1 QueryURL RCD 1 RCD 2 ST RCD 2 RCD 3 100 RCD 3 RDF 2 RDF 2 RCD 1 QueryTag RCD 1 RCD 2 ST RCD 2 RCD 3 40 RCD 3 RDF 2 RDF 2 RCD 1 QueryBegin RCD 1 RCD 2 DT RCD 2 RCD 3 26 RCD 3 RDF 2 RDF 2 RCD 1 QueryEnd RCD 1 RCD 2 DT RCD 2 RCD 3 26 RCD 3 RDF 2 RDF 2 RCD 1 QueryServiceCode RCD 1 RCD 2 CE RCD 2 RCD 3 200 RCD 3 RDF 2 RDF 2 RCD 1 QueryDepartmentCode RCD 1 RCD 2 CE RCD 2 RCD 3 200 RCD 3 RDF 2 RDF 2 RCD 1 Patient RCD 1 RCD 2 XCN RCD 2 RCD 3 200 RCD 3 RDF 2 RDF RDT RDT 1 XCN 1 JoeUser XCN 1 XCN 2 FN 1 Smith FN 1 XCN 2 XCN 3 Joseph XCN 3 XCN 9 HD 1 ST ELSEWHERE HOSPITAL Users HD 1 HD 2 USERID HD 2 HD 3 ST ELSEWHERE HOSPITAL HD 3 XCN 9 XCN 13 EI XCN 13 XCN 14 HD 1 ST ELSEWHERE HOSPITAL HD 1 XCN 14 RDT 1 RDT 2 https www myisb org RDT 2 RDT 3 Observation Reporting Query RDT 3 RDT 4 TS 1 200602230831 TS 1 RDT 4 RDT 5 TS 1 200602230832 TS 1 RDT 5 RDT 8 XCN 1 123456 7 XCN 1 XCN 2 FN 1 Patient FN 1 XCN 2 XCN 3 Example XCN 3 XCN 9 HD 1 Brigadoon Emergency Care Patients HD 1 HD 2 MR HD 2 HD 3 Brigadoon Emergency Care HD 3 XCN 9 XCN 13 MR XCN 13 XCN 14 HD 1 Brigadoon Emergency Care HD 1 XCN 14 RDT 8 RDT RTB Z03 ROW DEFINITION RTB Z03 pagebreak 6 Using Registration Data from the Patient Identities Query Response in a Subsequent Observation Reporting Query An NHIN query client may choose not to obtain the results reports and or medications from all registrations only from selected ones To support this type of query NHIN queries recognize the IdentifyPatient attribute within the query EvaluationSettings When IdentifyPatient is set to no the query must already contain one or more fully identified patient registrations usually from the response to a previous Patient Identities query Let us define how such a combination of queries and responses might look First the client makes a Patient Identities query just like the one described in the Patient Identities Query Message section of this paper For brevity we do not repeat that sample query here Refer to the Sample Patient Identities Query Message Dialogue section for that example Suppose that the NHIN client now determines that it wants the results and reports stored for the MADEUP 8 medical record number rather than the results and reports stored for all identified medical record numbers The NHIN client constructs the Observation Report Query listed below Note that the PID segment included in this query message is identical to the PID segment returned in the Patient Identities Query response The response to this query is like any other Observation Reporting Query response Sample Query soapEnv Body nhin EvaluationSettings nhin IdentifyPatient no nhin IdentifyPatient nhin EvaluationSettings nhin Query QBP Z01 xmlns urn hl7 org v2xml MSH MSH 1 MSH 2 MSH 3 HD 1 Query Application Name HD 1 MSH 3 MSH 4 HD 1 ST ELSEWHERE HOSPITAL HD 1 MSH 4 MSH 5 HD 1 Target ISB HD 1 MSH 5 MSH 6 HD 1 Target SNO Name HD 1 MSH 6 MSH 7 TS 1 200506171410 TS 1 MSH 7 MSH 9 MSG 1 QBP MSG 1 MSG 2 Z01 MSG 2 MSG 3 QBP Z01 MSG 3 MSH 9 MSH 10 123456789 MSH 10 MSH 11 PT 1 P PT 1 MSH

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

  • T3 | Markle | Advancing America's Future
    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 T3 One of two use cases we tested in the Markle Connecting for Health Common Framework prototype was the exchange of medication history In order to do so we adopted a format for representation in the network that had the best fit with broad adoption and potential standardization The Medication History schema we used was derived from the National Council for Prescription Drug Programs NCPDP 1 SCRIPT specification version 8 1 as described by RxHub 2 We generated a schema for use in the prototype using the ZixCorp 3 XML implementation These Medication History schemae as developed by CSC can be located at https ehr consult csc com cfh There is considerable work on medication history standards and we anticipate that there will be future changes to this standard in the near term Because the Common Framework maintains a separation between data description and transport updates to the medication history standard will not require re engineering the network to accommodate the new standard www ncpdp org http www surescripts com www zixcorp com Markle Connecting for Health thanks the Massachusetts prototype team John Halamka MD Vinod Muralidhar John Calladine and Gail Fournier for their implementation efforts on this standard 2006 2012 Markle Foundation These works were originally published as part of the Markle Connecting for Health Common Framework Resources for Implementing Private and Secure Health Information Exchange They are made available free of charge but subject to the terms of a License You may make copies of these works however by copying or exercising any other rights to the works you accept and agree to be bound by the terms

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

  • T4 | Markle | Advancing America's Future
    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 T4 One of two use cases we tested in the Markle Connecting for Health Common Framework prototype was the exchange of laboratory results In order to do so we adopted a format for representation in the network that had the best fit with broad adoption and potential standardization The Laboratory Results schema we used was derived from the ELINCS v2 0 draft specification created by the California Healthcare Foundation 1 The specification can be found at http elincs chcf org specifications aspx There is considerable work on laboratory results standards and we anticipate that there will be future changes to this standard in the near term Because the Common Framework maintains a separation between data description and transport updates to the lab results standard will not require re engineering the network to accommodate the new standard The ELINCS 2 0 version we used is still in draft form The messages as we formatted them had several deviations from the ELINCS implementation guide in its draft form ELINCS prohibits populating many of the PID fields NHIN permits any or all to be populated in query messages and returns most of those values when responding to a query Our own implementation will return most of the contents of the PID segment in the query response with the exception of SSN which we will blank out The ELINCS draft requires a time zone accompanying all date time values while we do not We believe that that requirement will be relaxed in the balloted standard Only the first component of the OBR 15 SPECIMEN SOURCE is allowed to be valued in the ELINCS draft We routinely get very useful specimen source information in all five components of this HL7 field and have allowed them to be populated The draft ELINCS spec requires all units be expressed as UCUM codes We do not expect to see all units expressed in that coding system HL7 permits OBX 14 DATE TIME OF OBSERVATION when test results for some members of a test battery were preformed at a time different from the other members of the test battery ELINCS forbids this value We support it The ELINCS draft limits the value type in OBX results segments to be of type CE code SN structured numeric ST string TX text or FT formatted text HL7 defines a much longer list of allowed value types Our messages also support the longer list for those value types such as DT date etc The ELINCS draft ignores OBX 4 SUB ID for all but microbiology tests Our messages include

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

  • T5 | Markle | Advancing America's Future
    the totality of features and characteristics of a data set that bear on its ability to satisfy the needs that result from the intended use of the data 13 Data accuracy is one of the foundational features that contribute to data quality 14 along with other attributes such as timeliness relevancy representation and accessibility 15 In addition data quality has two essential components content i e the information must be accurate and form i e the data must be stored and presented in a manner that makes it usable These definitions are important to keep in mind when considering ways to minimize data inaccuracies as they illustrate why the task of fixing dirty data requires more than merely providing right information Equally important when developing a strategy to increase data quality is identification of the underlying causes of dirty data Two broad categories of errors can be distinguished systematic and random Among the sources of systematic errors are programming mistakes bad definitions for data types or models violations of rules established for data collection poorly defined rules and poor training Random errors can be caused by keying errors data transcription problems illegible handwriting hardware failure e g breakdown or corruption and mistakes or deliberately misleading statements on the part of patients or others providing primary data This is obviously not an exhaustive list but a few examples of the types of errors that may occur It is worth noting that according to the Data Warehousing Institute 76 percent of all errors across sectors and setting result from data entry This suggests the critical role played by human error many of the strategies proposed below therefore focus on reducing the likelihood of human error III Strategies to Address Dirty Data Towards a Data Quality Culture To establish data quality within a health care setting and to prevent data quality errors in the system and limit their consequences health care organizations should develop comprehensive strategies to establish a data quality culture Ideally such strategies should be developed from the outset and be embedded in the design of any networked health information exchange system Organizations can use a variety of tools and techniques to increase the cleanliness of data both at the time of collection and during subsequent processing For the purposes of Markle Connecting for Health data cleanliness efforts should be concentrated on those data elements required by the RLS As the US moves towards widespread data standardization 16 data input quality control can improve the usability and quality of data outputs It should be noted that the documentation of a clinician cannot by law be changed retroactively as this constitutes a change to the documented medical record of an individual adding corrected information is allowed For cases in which data cleansing techniques 17 are applicable in health care for example detection not resolution of a single patient with two records these techniques can be automated e g in the form of software packages or involve a human component e g monitoring and training Ultimately a well thought out and comprehensive data quality program should include both automated and human strategies such as Standardize data entry fields and processes for entering data 18 Institute real time quality checking including the use of validation and feedback loops 19 Design data element to avoid errors for example through the use of check digits and checking algorithms on numeric identifiers where human entry is involved and the use of well designed user interfaces 20 Develop and adhere to guidelines for documenting the care that was provided to the patient 21 Review automated billing software Build human capacity including training awareness building and organizational change Each of these strategies will incur certain costs but they are likely to be less expensive than addressing errors resulting from a system designed without data quality features The US health care system has a unique window of opportunity to establish such an internal data quality culture when considering how to adopt health IT systems in the near future These organizational strategies should be complemented by external strategies especially redress mechanisms which encourage identification and correction of errors Redress mechanisms are frequently built into laws and regulations which among other things allow consumers to access and correct errors in personal information In the United States legal systems for redress date back at least to the Fair Credit Reporting Act of 1970 In addition redress is built into the Privacy Act of 1974 and the Health Insurance Portability and Accountability Act of 1996 Common redress strategies include Notice of a possible adverse decision using inaccurate data and the procedure for challenging it Access to the information on which the decision is based which is premised on the ability to trace information to its source for verification Opportunity to correct erroneous information and an obligation to correct or delete information that is erroneous Procedures for ensuring that erroneous information does not re enter the system Obligations on data furnishers to respond to requests for reconsideration of data and to take corrective action when justified and Independent administrative or judicial review and enforcement IV Creating a Data Quality Culture Implementation Issues to Consider Implementing a data quality culture as suggested above poses various challenges Without specifying the operational procedures that may be unique to each network design and RLS implementation the following set of questions will need to be addressed Record Locator Service How do data quality concerns affect the RLS and clinical data exchange What are the particular data quality problems likely to afflict the RLS requiring RLS specific interventions How does the network deal with the integrity of data in the RLS itself Who is responsible for these cleaning functions in the network Network versus Participants What are the expectations or requirements for each Participant vis à vis the Network with regard to sustaining a data quality culture Are patients rights to access their records as they pertain to the RLS provided by the Network centrally or does each Network participant offer

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



  •