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.

Next year should be interesting.  From Red Flag compliance, federal breach reporting requirements, significantly augmented HIPAA penalties, and HIPAA security standards that are based on NIST guidelines will change the traditional compliance model for Covered Entities and Business Associates.  Hot topics for enforcement next year (based on recent CMS audits of their business partners) will likely be in the areas encryption of portable media devices, remote access by employees to protected health information, and failure to document a rational risk management process.

1. Electronic Health Records and Interoperability.  The American Recovery and Reinvestment Act of 2009 (ARRA) allocated $19 billion over a five-year period to help providers purchase and implement electronic health record systems.  Of more concern to providers, however, are the penalties for failing to adopt (and make meaningful use) of an EHR system before 2015  when providers will face a reduction in their Medicare fee schedule of -1% in 2015, -2% in 2016, and    -3% in 2017 and beyond.  There are many willing health care providers that want to implement EHR systems.  However, whether the EHR systems work as intended and actually meet the government’s meaningful use requirements remains an open question.
2. Federal Breach Reporting Requirements.  Covered entities will be on the spot for ensuring that their business associates report security breaches to them in a timely manner.  Covered entities must then document their risk analysis and their conclusion as to why or why not a security incident should be reported to members.  This analytic process should be incorporated into your security incident policy and procedures as soon as practicable.  Due diligence of some sort may be indicated for those business associates who have heretofore not been meeting their obligations to comply with the requirements of the HIPAA Privacy and Security regulations.  Moreover, some members of Congress are not entirely happy with the harm standard; they favor a strict acquisition based reporting obligation.  If this happens, we can expect to see a lot of security breach reports, many plaintiff class actions, and further federal legislation in reaction to the perceived threat of riskless security breaches.
3. HIPAA Security and Privacy Regulations will begin to look a lot like FISMA.  The Federal Information Security Management Act of 2002 (“FISMA”, 44 U.S.C. § 3541, et seq.) requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.  NIST prepared a series of guidelines to help federal agencies comply with FISMA.  These guidelines address administrative, physical and technical safeguards. We expect HHS to largely remove itself as the source of all knowledge as to what is specifically required to with respect to administrative, physical and technical safeguards and utilize NIST standards as the new guideposts for evaluating the effectiveness of a covered entity’s risk management program and mitigating safeguards.  For example, CMS’s auditing materials used to audit CMS’s business partners are very similar to NIST privacy and security guidance.  Unlike HIPAA, NIST standards are very specific and include well over 20 core publications.  You can get a head start on your spring reading by reviewing SP 800-66 Rev 1, An Introductory Resource Guide for Implementing the Health Insurance Portability and Accountability Act (HIPAA) Security Rule (Oct. 2008).
4. Encryption and Remote Access.  2010 will be the year where many organizations will begin layering encryption controls onto portable media, laptops, and publically accessible workstations.  Whether an encryption product has been certified as FIPS 140-2 should be a key consideration when purchasing a new encryption solution.  You can find out whether a product you are considering has been certified at http://csrc.nist.gov/groups/STM/cmvp/validation.html.  In addition, you can get a sample implementation policy produced by the manufacturer at the time of certification stating how the product should be deployed.  The FIPS 140-2 standard is an information technology security accreditation program for cryptographic modules produced by private sector vendors who seek to have their products certified for use in government departments and regulated industries (such as financial and health care institutions) that collect, store, transfer, share and disseminate “sensitive, but un-classified (SBU)” information.  Proper encryption policies and procedures rely on ensuring that users are properly trained to follow the precise process dictated by the encryption product’s documentation.  The failure to do so will compromise a company’s encryption solution.   The elephant in the room remains remote access to systems containing sensitive information by users from their home computers.  Unfortunately, although remote access is convenient for employer and employee alike, its safeguards are expensive and difficult to implement.  It is not clear what level of control must be exercised over an employee working from home on his/her remote computer.
5. Watch for Further Enforcement Actions.  Enforcement activities by the OIG provides some insight into what is important for avoiding HIPAA Privacy and Security liability.  For example, after the Providence Health System case we know encrypting portable media is a hot topic.  And following the CVS enforcement action, most organizations are making sure that their employees have easy access to shredders and training on how to properly destroy documents.
6. Red Flag Compliance.  The Federal Trade Commission (FTC) has delayed the compliance deadline of the Red Flags Rule yet again — this time until June 1, 2010.  The AMA is pushing the FTC and Congress to republish the rule so that there is sufficient opportunity to formally comment and state AMA’s objections to physician inclusion in the program.  However, I would not count on the Red Flag Rules being delayed again.

          

Key Issues in Privacy and Security for 2010 originally appeared on Law Blog 2.0 on November 17, 2009.

Health Information Exchange

A Health Information Exchange (HIE) is a network of healthcare information systems electronically connected across organizations within a region or a community using a common communication protocol for the transparent exchange of health information.  HIEs provide the capability to move clinical information among disparate health care information systems while maintaining the meaning and context of the data being exchanged.  The goal of an HIE is to facilitate access to and retrieval of clinical data to provide safer, more timely, efficient, effective, equitable, patient-centered care.  HIEs are also useful for public health authorities to assist in analysis of the health of a population.  Federal Health Architecture is intended to deliver free, scalable solution to help organizations to tie health information systems into the NHIN.  Thus far the project has yielded at least one success (outside of the federal government) where data have been successfully transferred between a civilian hospital and the VA.

In February 2009, the CONNECT software gateway was used for the first time in a limited production environment when the SSA began receiving live patient data from MedVirginia through the NHIN.  The agencies built CONNECT using open source components, made it available under an open source license in order to encourage innovation and ease the cost of adoption.

Key issues with testing and/or implementing CONNECT include:
•    Too many manual steps where human typing errors can occur (setting environmental variables incorrectly, typos, setting incorrect directories, etc);
•    Having to manually edit scripts and different files to update with IP address, add XML pieces, etc;
•    Once Gateway is set-up, no way to communicate to another Gateway unless you set-up another Gateway;
•    Log files are confusing; and
•    Need better out of box experience.

The license found at the Connect websites allows the user many rights (including the right to withhold developments done privately from the project as a whole).  Many open source libraries require the community to give back new features/ source code to the project.  Guidance and documentation on how to connect into the NHIN framework is available at http://www.connectopensource.org/display/NHINR21/Guidance+on+Joining+the+NHIN+Using+the+CONNECT+Gateway.  The interface schema for the Connect gateway is available at http://www.connectopensource.org/download/attachments/14450700/CONNECT_+Release_2_1_Integrated_Interface_Description_Document_070709.pdf?version=1.  Currently the software can be compiled and run in a MSFT Windows environment, however, organizations including the open source community and Red Hat are working on a *nix version what will allow the distribution of a VMware image for easy testing and review by organizations that are potentially interested in using the software for resolving internal communication issues in large health systems and also to connect to the NHIN.  The software is available for download at http://www.connectopensource.org/display/NHINR21/Release+2.1+Home.
The success of NHIN thus far was made possible by the Federal Health Architecture and open source software.  The Federal Health Architecture (“FHA”) is an E-Government Line business initiative.  The FHA made software, called CONNECT and supporting documentation available at www.connectopensource.org, available to help health information technology systems communicate to the Nationwide Health Information Network (NHIN), a federal initiative to facilitate the electronic exchange of health information.

The NHIN seeks to achieve these goals by:
•    Developing capabilities for standards-based, secure data exchange nationwide;
•    Improving the coordination of care information among hospitals, laboratories, physicians offices, pharmacies, and other providers;
•    Ensuring appropriate information is available at the time and place of care;
•    Ensuring that consumers’ health information is secure and confidential;
•    Giving consumers new capabilities for managing and controlling their personal health records as well as providing access to their health information from electronic health records (EHRs) and other sources; and
•    Reducing risks from medical errors and supporting the delivery of appropriate, evidence-based medical care.

The FHA is responsible for:
•    Leveraging federal expertise by creating a federal health information sharing environment;
•    Supporting federal efforts to develop and adopt health IT standards and services; and
•    Ensuring that federal agencies can seamlessly exchange health data among themselves, with state, local and tribal governments, and with private-sector healthcare organizations.

Organizations are now emerging at the community, state and federal level to detail/ create the necessary protocols that will allow health information exchange efforts to succeed.  These organizations (often called Regional Health Information Organizations, or RHIOs) are ordinarily geographically-defined entities which develop and manage a set of contractual conventions and terms, arrange for the means of electronic exchange of information, and develop and maintain HIE standards.  The NHIN is a commercial/government effort working to build an electronic infrastructure to allow data to move among different organizations and applications.

To promote a more effective marketplace, greater competition, and increased choice through accessibility to accurate information on healthcare costs, quality, and outcomes, the Office of the National Coordinator (ONC) is advancing the NHIN as a “network of networks” which will connect diverse entities that need to exchange health information, such as state and regional health information exchanges (HIEs), integrated delivery systems, health plans that provide care, personally controlled health records, Federal agencies, and other networks as well as the systems.

From the press release Federal Health Architecture Delivers Free, Scalable Solution Helping Organizations Tie Health IT Systems into the NHIN (dated April 2009)(http://www.connectopensource.org/display/Gateway/2009/04).

“The CONNECT software is the outcome of a 2008 decision by more than 20  federal agencies to connect their health IT systems to the NHIN.  Rather than  individually building software required to make this possible, the federal  agencies, through the Federal Health Architecture, created CONNECT. This shared  software solution can be used by each agency within its own environment. CONNECT  implements the core services defined by the NHIN including standards for  security to protect health information when it is exchanged with other trusted  health organizations.”

          

Open Source Programmers Collaborate To Improve the CONNECT Gateway originally appeared on Law Blog 2.0 on August 31, 2009.

ONC Grants Announced

The Office of the National Coordinator for Health Information Technology (ONC) has recently release more information on two grant programs.  The HITECH Act authorizes two grant programs: (1) a Health Information Technology Extension Program (Extension Program) and (2) the State Health Information Exchange Coopertive Agreement Program (Agreement Program).  This program provides grants for the establishment of Health Information Technology Regional Extension Centers that will offer technical assistance, guidance and information on best practices to support and accelerate health care providers’ efforts to become meaningful users of Electronic Health Records (EHRs). The consistent, nationwide adoption and use of secure EHRs will ultimately enhance the quality and value of health care.  The State Health Information Exchange Cooperative Agreement Program supports states and/or State Designated Entities (SDEs) in establishing health information exchange (HIE) capacity among health care providers and hospitals in their jurisdiction. Such efforts at the state level will establish and implement appropriate governance, policies and network services within the broader national framework to rapidly build capacity for connectivity between and among health care providers. State programs to promote HIE will help to realize the full potential of EHRs to improve the coordination, efficiency and quality of care.  For those interested ONC has made available a “grants primer” (avaliable at http://healthit.hhs.gov/portal/server.pt/gateway/PTARGS_0_10741_877878_0_0_18/Grants_Primer_update.pdf).  The primer will help a state find and apply for grants.

Health Information Technology Extension Program- Regional Centers

Grants are available to Regional Centers that are affiliated with a U.S.-based, nonprofit institution or organization, or an entity thereof, that applies for and is awarded funding under the Extension Program.  “The program anticipates that potential applicants will represent various types of nonprofit organizations and institutions with established support and recognition within the local communities they propose to serve.”

Principally Regional Centers will support health care providers with direct, individualized and on-site technical assistance in:

• Selecting a certified EHR product that offers best value for the providers’ needs;
• Achieving effective implementation of a certified EHR product;
• Enhancing clinical and administrative workflows to optimally leverage an EHR system’s potential to improve quality and value of care, including patient experience as well as outcome of care; and,
• Observing and complying with applicable legal, regulatory, professional and ethical requirements to protect the integrity, privacy and security of patients’ health information.

The Grant Process

“The application review and funding process will be separated into three application cycles, the dates of which are outlined in the table below.  Applicants will be required to submit a preliminary application that will undergo an objective review; successful preliminary applicants will be requested to submit a full application for merit review.  Successful full applications will result in award of four-year cooperative agreements.  Initial award decisions for Regional Centers are anticipated to be made in the first quarter of FY2010.  Additional awards are expected to be made as a result of two subsequent application cycles to be completed in FY2010.”

State Grants to Promote Health Information Technology Planning and Implementation Projects

“The State Cooperative Agreements to Promote Health Information Technology: Planning and Implementation Projects are to advance appropriate and secure health information exchange (HIE) across the health care system. Awards will be made in the form of cooperative agreements to states or qualified State Designated Entities (SDEs). The purpose of this program is to continuously improve and expand HIE services over time to reach all health care providers in an effort to improve the quality and efficiency of health care. Cooperative agreement recipients will evolve and advance the necessary governance, policies, technical services, business operations and financing mechanisms for HIE over a four year performance period. This program will build off of existing efforts to advance regional and state level HIE while moving towards nationwide interoperability.”

Participating states will also be expected to use their authority and resources to:

• Develop and implement up-to-date privacy and security requirements for HIE;Develop directories and technical services to enable interoperability within and across states;
• Coordinate with Medicaid and state public health programs to enable information exchange and support monitoring of provider participation in HIE.
• Remove barriers that may hinder effective HIE, particularly those related to interoperability across laboratories, hospitals, clinician offices, health plans and other health information exchange partners;
• Ensure an effective model for HIE governance and accountability is in place; and
• Convene health care stakeholders to build trust in and support for a statewide approach to HIE.

“Total funding for this initiative is $564,000,000. States (including territories) or their non-profit SDEs may apply, as designated by the state. No more than one award will be made per state. States may choose in enter into multi-state arrangements.”

See http://healthit.hhs.gov/portal/server.pt?open=512&objID=1331&parentname=CommunityPage&parentid=47&mode=2&in_hi_userid=11113&cached=true# for more information.

See also http://healthit.hhs.gov/portal/server.pt?open=512&objID=1333&parentname=CommunityPage&parentid=47&mode=2&in_hi_userid=11113&cached=true#

          

HITECH Grant Opportunities for Regional HIT Centers and HIE Cooperatives originally appeared on Law Blog 2.0 on August 24, 2009.

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.