The typical use case of an HIE under a federated exchange model transaction involves:

• Initiation of a request to the HIE service to determine if a person has relevant medical information within the HIE;
• A response is returned to the requesting organization, which would request to receive the relevant data.
• The HIE service would verify that the requesting organization is authorized, authenticated, and has access privileges to the information and that the person has provided consent for transmission of the given information;
• The approval along with supporting metadata is transmitted to the supplying organization who has the relevant information; and
• The disclosing organization would supply the information as required by the underlying data sharing or HIE participation agreements.

Both HIEs and networks of HIE (basically the NHIN) must be able establishing a baseline of trust among participants, typically, this trust includes–

• Processes to ensure the integrity of patient data;
• Verifiability of data after transforming, storing and/or sending (e.g. checksum, error checking, etc.);
• Verification that the data source and data content are true; and
• Organization the HIE or the NHIN can define standardized data values and a protocol format for sharing medical data.

Implementation usually requires:

• A data sharing agreements and policies to enable information sharing and make system usable;
• An enterprise master patient index (eMPI) which serves as a record locator; and
• A balancing of data standardization (normalization) and physician freedom to have clinical control of the medical record while being efficient in their treatment of patients.[ii]

I have excerpted privacy and security related covenants from a document entitled Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009, which provides a summary of key features of a comprehensive agreement that governs the exchange of health data across a diverse set of public and private entities.  This agreement – the Data Use and Reciprocal Support Agreement (“DURSA”) requires that:

• To the extent that each Participant has existing privacy and security obligations under applicable law (e.g. HIPAA or other state or federal privacy and security statutes and regulations), the Participant is required to continue complying with these obligations.  Participants, which are neither HIPAA covered entities, HIPAA business associates nor governmental agencies, are obligated to comply with specified HIPAA Privacy and Security Rules as a contractual standard of performance.
• It is the responsibility of the responding Participant – the one disclosing the data – to make sure that it has met all legal requirements before disclosing the data, including, but not limited to, obtaining any consent or authorization that is required by law applicable to the responding Participant. This policy is essential for nationwide health information exchange given the number of different state laws, Federal statutes and local policies related to consent or authorization to exchange data for treatment purposes. To effectively enable the exchange of health information in a manner that protects the privacy, confidentiality and security of the data, the DURSA adopts the HIPAA Privacy and Security Rules as minimum requirements.
• Participants are required to promptly notify the NHIN Coordinating Committee and other impacted Participants of breaches which involve the unauthorized disclosure of data through the NHIN, take steps to mitigate the breach and implement corrective action plans to prevent such breaches from occurring in the future. Suspected breaches must be reported within one (1) hour of discovering information that leads the Participant to believe that a breach may have occurred.  As soon as reasonably practicable, but no later than twenty-four (24) hours, Participants must notify affected Participants and the NHIN Coordinating Committee This process is not intended to address any obligations for notifying consumers of breaches, but simply establishes an obligation for Participants to notify each other when breaches occur to facilitate an appropriate response.

(See Overview: Data Use and Reciprocal Support (DURSA) Provisions Overview, dated November 20, 2009)

HIE services typically includes:

• Patient identification and registry services within a directory structure;
• Consent management and enforcement of a user’s consent when collecting, storing, accessing, processing, and disclosing personal health information; and
• Information for the patient about the HIE at the point of care and a business process to obtain consent that will be used  for future exchange of data until changed by the individual.

The CONNECT framework is designed to offer similar services for the NHIN.  CONNECT is designed to implement privacy and security controls defined in the NHIN services, and when implemented and combined with the NHIN operating procedures and the DURSA, it allows organizations to participate in the “web of trust” that enables the secure exchange of interoperable health information among the participants of the NHIN.

Privacy and security laws do not directly cover NHIN in the sense NHIN is really a collaboration of many organizations who elect to participate in the network.  Several different types of entities participate in the NHIN. There are HIPAA “covered entities”, such as providers, there are the HIPAA-defined “business associates” of those covered entities, and there are non-covered entities which are not currently required to comply with HIPAA rules.

The NHIN is more like the Internet than a traditional health information system found within a hospital.  NHIN while not a covered entity, NHIN has a similar threat profile.  Similar to an HIE, the Data Use and Reciprocal Support Agreements (DURSA) permit network participants to contract the specific terms under which they will exchange information, including addressing privacy and security needs of each NHIE amongst themselves.  The responsibility for security, including compliance with state and federal laws, including HIPAA, rests with the member organizations or the network nodes a hospital, physician’s office, etc.  Examples of common DURSA contracts/agreements are listed in the table below.

The typical Connect implementation involves the use of a server based PKI and the NHIN NHIE service registry which define and secure the NHIN core backbone.  Connect services include-

• The messaging platform and authorization framework to implement security and privacy controls to address the known threats for Web services implementations of service-oriented-architectures;
• The audit log query service is designed to meet the requirements for HIPAA disclosure accounting;
• The consumer preferences profile allowomg consumers to express their preferences for whether or not to share their information on the NHIN and for more granular control over access to their private information. The CONNECT policy engine enforces those preferences in the runtime environment to insure that the access policies of the organization and the preferences of the consumer are honored in the decision to release health information in response to a request from the NHIN

In a separate draft publication ONC has detailed use cases on how to obtain, modify, and detail a patient’s consent to access his/her medical record.

If this all seems to daunting, a less ambitious project was recently announced by ONC called NHIN Direct.  The NHIN Direct project is focused on smaller providers who are unable to implement the Connect solution, and/or put in place an appropriate DURSA.  According to ONC- “NHIN Direct is intended to solve simple direct secure electronic transport supporting health information exchange currently being handled via paper or portal communication following existing trust models.”

Transactions that would fall within the scope of NHIN Direct would be those transactions involving the communication of pre-existing information typically transferred via fax, courier, mail or clipboard, or in some cases, via a patient/physician portal.  The transactions must be “push transactions” where patient identity is known and consent and legal authorization exists for the information transfer. (See http://nhindirect.org/User+Stories).[iii]

Additional Information – Data Sharing Agreements

Sample DURSA Business Associate Addendum

Sample Health Information Exchange Agreement

AMENDED AND RESTATED CLINICAL OUTCOMES ASSESSMENT PROGRAM HEALTH CARE PROVIDER INFORMATION SHARING AGREEMENT

ONC NHIN Draft Policies

2010 NHIN Final Production Specifications
The following specifications have been provisionally approved by the NHIN Technical Committee. This approval is subject to the validation of the NHIN reference implementation.

• Access Consent Policies Production Specification – v1.0 [PDF - 176 KB]
  
• Authorization Framework Production Specification v2.0 [PDF - 256 KB]
  
• Query for Documents Production Specification v2.0 [PDF - 212 KB]
  
• Retrieve Documents Production Specification v2.0 [PDF - 178 KB]
  
• Health Information Event Messaging Production Specification v2.0 [PDF - 152 KB]
  
• Messaging Platform Production Specification v2.0 [PDF - 248 KB]
  
• Patient Discovery Production Specification v1.0 [PDF - 214 KB]
  
• Web Services Registry Production Specification v2.0 [PDF - 378 KB]
  

Additional Information Available at the Following Sites:

• American Health Information Community (AHIC) http://www.hhs.gov/healthit/ahic.html
• American Health Information Management Association (AHIMA) http://www.ahima.org/
• Certification Commission for Healthcare Information Technology (CCHIT) http://www.cchit.org
• Commission on Systemic Interoperability http://endingthedocumentgame.gov
• Healthcare Information and Management Systems Society (HIMSS) http://himss.org/ASP/index.asp
• HL7 United States http://www.hl7.org/
• International Health Terminology Standards Development Organization (IHTSDO) and SNOMED International http://www.ihtsdo.org/
• Office of the National Coordinator of Health Information Technology (ONCHIT) http://www.hhs.gov/healthit/

[ii] CONNECT has three primary components:

1. The Core Services Gateway implements the core NHIN services enabling such functions as locating patients at other health organizations within the NHIN, requesting and receiving documents associated with the patient, and recording these transactions for subsequent auditing by patients and others. Other features include authenticating network participants, formulating and evaluating authorizations for the release of medical information, and honoring consumer preferences for sharing their information.
2. The Enterprise Service Component (ESC) provides default implementations of many critical enterprise components required to support electronic health information exchange, including a Master Patient Index (MPI), Document Registry and Repository, Authorization Policy Engine, Consumer Preferences Manager, HIPAA-compliant Audit Log.
3. The Universal Client Framework contains a set of applications that can be adapted to create an edge system, and be used as a reference system, and/or can be used as a test and demonstration system for the gateway solution.

[iii] The project has highlighted the following use cases for the NHIN project:
1. Primary care provider refers patient to specialist including summary care record
2. Primary care provider refers patient to hospital including summary care record
3. Specialist sends summary care information back to referring provider
4. Hospital sends discharge information to referring provider
5. Laboratory sends lab results to ordering provider
6. Providers without a fully certified EHR send and receive data
7. Primary care provider sends patient immunization data to public health
8. Pharmacist sends medication therapy management consult to primary care provider
9. Provider sends patient health information to the patient
10. Provider sends a clinical summary of an office visit to the patient
11. Hospital sends a clinical summary at discharge to the patient
12. Provider or hospital reports quality measures to CMS
13. Provider or hospital reports quality measures to State
14. Laboratory reports test results for some specific conditions to public health
15. State public health agency reports public health data to Centers for Disease Control
16. Provider reports to the State
17. Hospitals reporting to the State

Related Blogs

• Great Visualizers: Stefanie Posavec | Information Is Beautiful
• The anatomy of HIPAA.: An article from: Arkansas Business
• ‘This is a patient’s bill of rights on steroids’ | RedState
• Patient input in their treatment should be valued by doctors | KevinMD.com

          

HIE and NHIN Implementation Issues: (a) Data Sharing Agreements, (b) the Master Patient Index, (c) Data Standardization, (d) Consent Requirements, and (e) Duties of Network Participants originally appeared on Law Blog 2.0 on March 25, 2010.

Meaningful Use

One example from the “Meaningful Use Matrix” requires that a provider – “Ensure adequate privacy and security protections for personal health information.”  This requires compliance with HIPAA Privacy and Security Rules.  Unfortunately the HIPAA Privacy and Security Rules are currently in a state of flux.  Assuming regulations are promptly promulgated the best case scenario requires a massive implementation effort of an EHR solution in less than a year.  The meaningful use matrix specifically requires a “security risk assessment”.  An entity “under investigation” cannot receive stimulus payments until the issue is resolved.  Length of investigation could also potentially include a missed payment (even if found “not guilty”).  The intent of this requirement was to disallow participation in HIT incentives if confirmed HIPAA violation goes unresolved.  The revised wording recommends – “that CMS withhold meaningful use payment for any entity until any confirmed HIPAA privacy or security violation has resolved.”

Potential issues arising from the tortured definition of meaningful use include:

1. Whether a company complies with the meaningful use requirements for 2011 will the company have to comply with the meaningful use requirements for EHRs adopted in 2013;
2. Whether a “confirmed HIPAA violation” is limited to situations where HHS has determined that a covered entity is not compliant and the covered entity was notified of said infraction potentially including a corrective action plan, or will a complaint be sufficient to meet the definition of a confirmed HIPAA privacy and/or security violation;
3. Whether requirements for interoperability and use cases for the EHRs can be implemented quickly (if not otherwise available in the EHR system);
4. Whether there will be a substantive change to the US Healthcare system.  A radical change could alter the playing field; and
5. Whether there will be sufficient data to support computerized provider order entries tied to electronic medication administration records and targeted order sets for chronic diseases including smoking, diabetes and hypertensive patients by 2011.

The lack of certainty and the resources needed to meet the EHR system meaningful use requirements will likely discourage hospitals and other providers from risking limited resources on an early EHR solution.  Given the absence of specificity it would seem that some may conclude that a wait and see approach is the most reasonable strategy.  Here the program requirements have been designed by politicians opposed to software engineers – can we expect that a hospital with limited resources would risk the investment to implement a system that may not work and may not meet some yet to be published future requirements.  Can we expect that EHR vendors will invest the resources necessary to meet system requirements developed by politicians?  The failure to build meaningful use upon previous ground work is concerning.

          

Are ONC’s Meaningful Use Requirements Workable? originally appeared on Law Blog 2.0 on July 30, 2009.

Open Source EMR

On April 23rd Senator John Rockefeller IV introduced the Health Information Technology Public Utility Act of 2009to to build upon open the source electronic health record (eleconic medical record) solution developed by the Department of Veterans Affairs (called VistA)  and other open source software (e.g. OpenEMR).  Unlike proprietary “closed source” software solutions, open source software allows unrestricted access to the source code and does not prohibit the use or re-distribution of software.

Open Source

Currently there are few EMR solutions avaliable in market.  However one vendor attempting to offer an open source solution is called clear-health (http://www.clear-health.com/).  According to ClearHealth’s website: “ClearHealth has taken the powerful VistA EMR system which powers the Veterans Administration health network and modernized it. With added, seamless, scheduling and billing WebVista offers the only fully comprehensive VistA based system in a cost-effective, Web 2.0.”  (http://www.clear-health.com/content/view/41/51/).

Open source is defined by three key characteristics:

• The right to make copies of the program, and distribute those copies;
• The right to have access to the software’s source code;
• The right to make improvements to the program.

(Bruce Perens, The Open Source Definition, 1st Edition Oreilly (January 1999)).

“Open source software is a cost-effective, proven way to advance health information technology – particularly among small, rural providers. This legislation does not replace commercial software; instead, it complements the private industry in this field – by making health information technology a realistic option for all providers.” (Senator Rockefeller)

Summary of Act

Health Information Technology Public Utility Act of 2009:

• Create a new federal Public Utility Board within the Office of the National Coordinator for Health IT to direct and oversee formation of this HIT Public Utility Model, its implementation, and its ongoing operation;
• Implement and administer a new 21st Century Health IT Grant program for safety-net providers to cover the full cost of open source software implementation and maintenance for up to five years, with the possibility of renewal for up to five years if required benchmarks are met;
• Facilitate ongoing communication with open source user groups to incorporate improvements and innovations from them into the core programs;
• Ensure interoperability between these programs, including as innovations are incorporated, and develop mechanisms to integrate open source software with Medicaid and CHIP billing;
• Create a child-specific Electronic Health Record (EHR) to be used in Medicaid, CHIP, and other federal children’s health programs; and
• Develop and integrate quality and performance measurement into open source software modules.

CCHIT Certification and the Open Source Community

CCHIT is the only certification body for electronic medical record systems (EMRs) to date there has been some disagreement around the relevance of the CCHIT standards with respect to open source solutions.  VistA is the U.S. Department of Veterans Affairs National Scale Healthcare Information Systems, which happens to be available for downloaded at no cost from http://www1.va.gov/cprsdemo/.  The open source community and CCHIT requirements are seen to be at odds by some.

One example, noted by a commentator,  SC 03.10 — requires that passwords shall support case-sensitive passwords that contain typeable alpha-numeric characters in support of ISO-646/ECMA-6 (US ASCII).

The commentator noted:

The problem, VistA supports three user ids, one that is equivalent to a username, and two that are similar to passwords. Without getting over my head on the details, there are two possible password types so that you can have one that your admin user can know and reset for you, and one that no one knows but you. There are all kind of administrator abuse scenarios that this addresses, but the VistA username/password/password system is not certifiable out of the box because it does not support case sensitivity. Which, as you can see, is a requirement. Most people are only aware of the CPRS client for VA VistA but in reality there are several clients, all of which support the username/password/password mechanism.  So when any VistA-based EHR goes and gets CCHIT certified it has to make the password system -act- dumber (in compliance with SC 03.09), and add case sensitivity.

(Fred Trotter, CCHIT Feature bucket)

Another critique and a response by CCHIT is avaliable at http://www.emrandhipaa.com/emr-and-hipaa/2009/02/24/cchit-being-thrown-under-the-bus/.  Some commentators argue that a commercial relationship is inconsistent with the definition of open source is required for CCHIT certification.

Bill Status

          

Health Information Technology Public Utility Act of 2009 Would Facilitate the Adoption of Open Source EMR Solutions originally appeared on Law Blog 2.0 on April 26, 2009.