3.5 Activities/Deliverables Funded
On June 22, 2007, a kick-off meeting was held, attended by the project steering committee, key stakeholders, and community agencies. The Project Team was introduced the Steering Committee role, project scope, budget, timeline, organization and project assignments were shared with over 150 attendees.
To inform the design and development priorities of the AHCCCS Medicaid Transformation Grant Health Information Exchange (HIE) & Electronic Health Record (EHR) (HIeHR) Utility Project, qualitative, professionally-moderated focus group research was conducted from October through December 2007. One-hundred fifty-seven participants in 10 Arizona counties provided feedback during 28 focus groups. Participating providers and administrators also completed a quantitative Health Information Technology (HIT) Provider Survey during the focus group sessions. To ensure that all participants shared a common understanding of HIT and HIE, each focus group discussion was preceded by a standard slide presentation covering basic terminology, the Arizona HIT environment, and HIeHR project overview. Moderators followed a discussion guide developed in coordination with the HIeER team and captured responses to formal questions as well as the abundant spontaneous comments.
Forty percent of focus group participants were physicians and 60 percent were other types of health professionals. Participant areas of focus are summarized in Table 1.
|
|
|
|
Primary & Acute Care |
|
Specialty Care |
|
Emergency Departments |
|
Behavioral Health |
|
Long-term Care |
|
Dental |
|
Pharmacy |
|
Other (IT, Financial & Administrative) |
|
Top Ten findings from the AHCCCS HIEHR Provider Focus Groups include:
The focus groups were conducted, and the final report provided by Flanagan-Hyde Solutions, LLC and Your Partners in Quality, LLC.
The survey was developed and implemented by the Center for Health Information & Research (CHIR), an interdisciplinary research group at Arizona State University, on July 17, 2007 with the Arizona Medical Board (AMB) for allopathic physicians and the Arizona Board of Osteopathic Examiners (ABOE) on November 1, 2007 for osteopathic physicians. The data in this report represent two years of the allopathic physicians´ renewal cycle. All osteopathic renewals for the current cycle are included. The survey questions for both groups were included with physicians´ applications for license renewal. During the period from July 2007 through July 2009, the allopathic data were collected from paper survey forms which were transmitted for coding and data entry. The osteopathic information was collected electronically. Both licensing boards also supplied the data from the licensing applications in electronic form. The survey data was merged with the licensing data creating records for each physician. Data were collected for the allopathic physicians using the questions focused on EMRs until project closure in July 2009.
Some of the conclusions from this survey are:
The full report is included with this submission.
Hardware, software, use cases, design specifications, software development, and implementation of the HIE were all funded through the grant. Every aspect of the HIE was specified through a well defined methodology of requirements gathering and development through use cases, then detailed specifications. A thorough development and release cycle methodology was implemented based on the Agile software development lifecycle model. A stringently adhered to quality assurance process was implemented. Approximately $300k was used for the hardware and software needed to build, implement, and operate the exchange. Only a subset of the documentation of the use cases, design specifications and software is included in this report due to its volume. Additional documentation is available as requested.
The AMIE uses a combination of open source software applications, internally developed software and off the shelf products. The AMIE is designed to meet standards established by the Office of the National Coordinator for Health Information Technology (ONCHIT), the Medicaid Information Technology Architecture (MITA), the Arizona statewide technology standards, AHCCCS standards, as well as industry standards for data exchange (such as HL7, SNOMED, NCPDP, LOINC), and technical standards common to web technologies and internet connectivity. We had intended to be able to meet the certification by the Certification Commission for Healthcare Information Technology (CCHIT). The base technology for the Utility is Microsoft Windows, .NET and C#.
Services Oriented Architecture (SOA) is the architectural style for creating business processes as loosely-coupled units that communicate via a common protocol such as SOAP. The units can be distributed over a variety of platforms on a network and communicate with each other by passing data from one web service to another. The AMIE project defined a technology interface based upon SOA for the exchange of health information. The interface is secured by encryption and other approved security technology and techniques to maintain privacy and integrity of the information. Standard messaging formats are used for interacting with Data Providers. This messaging is based upon the Clinical Document Architecture (CDA). An overview of the technology, standards, and tradeoffs that contributed to the architectural design of AMIE is included in a PowerPoint presentation with this report. The business requirements for the HIE are also documented in an attached spreadsheet. In addition we have included with this report, our technical specification for the Record Locator Service (RLS), and messaging specifications. These documents can be found here.
The MPI research lead us to the conclusion that although commercial products with advanced algorithms are available, their cost was prohibitive, and that an in-house developed MPI would suffice until the HIE revenue model could support the acquisition of a more robust solution. Wes Rishel from Gartner gave a presentation to the project steering committee which looked at the differences between a deterministic algorithm for matching patient demographics and a probabilistic algorithm. This presentation informed us that neither were a complete solution to this problem, and each has its pros and cons.
There are two aspects to be considered when managing patient identify information:
One is how information is stored in the MPI, for this we adopted the concepts of merging patient identities when we can be sure they are the same patient, the second is linking them when they are close but not certain.
The second is when searching for or looking up, a patient. Which fields are needed to search, and which fields matching constitutes a valid match.
Both of these topics were researched, and solutions for AMIE were determined. The documents in which the analysis is shared are attached with this report. Below is a brief overview of these topics.
The purpose of the Patient Index´s patient merging algorithm is to consolidate demographic data for a single patient into a single patient entry. Furthermore, the Patient Index´s patient linking algorithm is to link two patient entries where they have a very high probability of being the same patient. Since the Record Locator Service (RLS) has to store routing information for each patient record, RLS will contain one entry per patient per data provider source system. This could potentially lead to a single patient having hundreds of entries in the RLS system. As a result, searching the RLS for a patient could return too many results for an end-user to process in a timely manner.
To address this issue, the Patient Index was designed to create one entry per patient. This one entry would be linked back to multiple RLS records for easy retrieval once the correct patient is identified. In order to create a single entry that relates to all of the RLS entries, a set of rules are in place to determine how to merge the RLS demographics into a single patient index entry. Furthermore, an additional set of rules is in place to determine a high probability that two patient index entries are the same, in which case these two entries are linked.
Patient Merging
Patient Merging is combining a single RLS patient demographic entry with an
existing Patient Index entry based on a predefined set of rules. The patient
index stores the accumulated patient demographics from each of the RLS entries.
All of the accumulated patient demographics will be related by a single patient
identifier.
Patient Linking
Patient linking is linking two Patient Index records based on a predefined set
of rules. Patient linking is done when two records do not match enough to be
merged, but there is a high probability that the two patients are the same
person. As a result, when one patient is found during a search, the linked
patient information will be presented as an additional likely match and
displayed as two separate patients.
The approaches to Patient Search mechanisms implemented by healthcare organizations, vendors, and health information exchanges across the country represent a delicate balance of what often appear to be competing interests:
As a result, a variety of lookup strategies have been deployed, ranging from a single unique identifier (e.g., AHCCCS) to combining four (4) or more criteria in order to increase accuracy and efficiency of the lookup function (e.g., Connecting for Health or Initiate Systems). Commercial software vendors typically offer a configurable solution that will support a variety of local Privacy and Security practices. All solutions reviewed offer more criteria for data entry than are actually required. This is related to the fact that depending on the clinical situation, the known or available data will vary.
For the AHCCCS Viewer, the Team recommended two approaches to the Patient Search function depending on whether the User has the AHCCCS ID (the unique identifier for the Medicaid population in Arizona) available:
Initiate is recognized as one of the leaders in MPI solutions. In discussing potential opportunities to work with Initiate, they agreed to execute a pilot project which would:
Over a span of about three months, with approximately 5 hours per week of effort, we were able to achieve the ability through configuration settings, to switch seamlessly between Initiate and the native in-house developed AMIE MPI engines.
The Initiate AMIE Integration Technical Specification documents what was accomplished.
In the ideal world, all health information technology (HIT), would be interoperable in a standardized manner. Unfortunately, this is not the case, and each data source although using standards like HL7 and being somewhat similar, is still unique. In order to accommodate the variations in the data sources, and to support the emerging standard Clinical Document Architecture, we developed the concept and design for an edge like server we named the Emulator. The Emulator is able to accept a number of different types of data sources, and convert them to the CDA standard.
The Emulator is an application component built on Microsoft BizTalk Server and Microsoft BizTalk HL7 Accelerator. The Emulator processes the data received from the Data Provider systems. It will transform data delivered into a CDA format and persist it in the emulator database. Furthermore, it will publish all transformed and persisted records to the AMIE. Also, it will provide the records to the AMIE upon request either in CDA format or in the same format as it was received.
The Emulator is architected to support the needs of a Data provider that does not have the ability to integrate with the AMIE natively. This solution can be deployed either at the data provider location or at the AHCCCS data center. The Emulator can support many different methods of transferring the data from the Data provider, and will connect to the HIE using Web Services over HTTPS.
The Emulator is configured to accept large "bundles" of, or individual records over MLLP, FTP, and Web Services. It processes the records and publishes the availability of these records in the record locator service (RLS). When one of the records is requested, the emulator will process that request and return the record through the HIE to the requesting application.
In addition to using the AMIE developed Emulator, Cisco Systems provided a prototype product that was used with one of our data providers, and was able to serve as the Emulator for that data source.
The Emulator design specifications and data partner infrastructure requirements are included with this report.
One of the fundamental challenges all HIEs face is that of establishing policies around consumer consent directives and developing the technology to support those directives. Some policy decisions are too difficult or expensive to implement. Additionally, many states differ in their regulations for managing consent directives.
In order to make informed decisions regarding the adoption of a patient consent policy and model, the AMIE team conducted research on the following:
Kristen Rosati, in "Consumer Consent for Health Information Exchange: An Exploration of Options for Arizona´s HIEs", a white paper for AzHEC describes Arizona Law regarding consent. Among the requirements she lists are the following:
In particular, she mentions that the only restrictions that apply to exchanging data involve the following scenarios:
Based on this research, the AMIE team recommended that they should initially adopt an opt-out consent model since it would meet current requirements for exchanging data in Arizona. It is expected that this model would evolve over time as new regulations are put into place and health information technology standards for consent are adopted by vendors. The AMIE Manage Consent Directive Use Case was used to define the requirements and business processes to support managing patient consent. The AMIE team also developed a consumer/patient information pamphlet to be made available at participating providers´ offices to educate about health information exchange, privacy and security, and AMIE´s; consent policy and how to opt-out.
On the technical level, AMIE implemented patient consent following the IHE XDS.b and XACML standards, using the patient search (PDQ), Query Clinical Documents, retrieve Clinical Documents, Submit Consent Directive (XACML), Request Decision (XACML), Request Policies (XACML), Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Information Point (PIP) constructs
Operating an HIE necessitates having privacy, security, processes and procedures defined to ensure compliance with HIPAA and other regulations. Regular auditing and follow up activities were defined and executed. The documents in which the AMIE policies and procedures are defined have been included with this report.
The following responsibilities were addressed through these policies and procedures:
Not to be overlooked, the ability to audit and report on user activity, knowing what records are being accessed is required by HIPAA, and is an invaluable capability to the data partners and those responsible for privacy compliance. The requirements for information to be maintained in the audit logs, and the report specifications are included with this report. At a high level, the auditing capabilities included:
For each source of data, and for all of those accessing data, contracts needed to be put in place to specify requirements and responsibilities of all those involved, including the obligations of the health information exchange. One contract was created to cover whether the participant was sharing data, accessing data, or both. This agreement was based on the Markle Foundation for Connecting for Health, and work performed by the Arizona Health-e Connection Legal Workgroup, and then further refined by the AMIE project team to specifically support AMIE´s; requirements. Contract documents have been included with this report.
The early focus groups and surveys informed us that there were few EHRs being used by our target clinician community, and even fewer EHRs that were HIE ready. In order to realize value from the HIE, a decision was made to also build and implement a simple web browser based viewer, through which, once authenticated with a provisioned account, the clinicians could access the information available through AMIE.
A strategy for provider adoption was developed. Flexibility to accommodate different workflows in the practice setting was required. Working with the clinicians to understand their work habits and engineer how the AMIE Viewer fit into their processes was paramount to provider acceptance. Once having access to the information, the providers quickly found how valuable having a HIE can be. Some of the anecdotal feedback received was:
Having a user facing application required the management of users, user accounts, and training of the users. The application was simple to use, but more importantly was the education and enforcement of the privacy policies of the HIE. User training material was developed, and is included with this report. Also on-line training tutorials were created to support a more aggressive expansion of users.
24/7 support for the users is an absolute must for clinical applications, especially when being used in emergency settings. A support line was set up; with call tracking, and round the clock direct human contact. The highest volume of support calls were for password reset. In response to this need, an on-line capability for password reset was implemented and training material was created to walk users through this process. The training material has been included with this report.
AMIE Initial Proof of Concept Evaluation
The University of Arizona, College of Pharmacy was contracted to perform the
evaluation of the initial AMIE three month ´Proof Of Concept´ (POC),
which included 29 Phoenix-based providers affiliated with three major hospital
systems who practiced in emergency departments, outpatient clinics, and private
offices. Through AMIE, the inaugural cohort was equipped with web-based access
to medication history, recent laboratory test results, and hospital discharge
summaries across the systems. AMIE POC users were required to commit time to
participate in training and feedback meetings. Both focus groups and survey
research methods were used.
Summary of Results:
At the end of the POC:
AMIE Behavioral Health Pilot Evaluation
The University of Arizona was contracted to perform the evaluation of the AMIE
Behavioral Health Pilot. Authorized behavioral health (BH) clinician users were
granted access to AMIE´s secure web-based application in March 2009. This
pilot included 26 AHCCCS BH providers affiliated with four regional behavioral
health authorities (RBHAs) who practiced in outpatient clinics and private
offices. Through AMIE, the BH cohort was equipped with web-based access to
medication history, recent laboratory test results, and hospital discharge
summaries across the systems.
Conclusions
Gartner, Inc., the world's leading information technology research and advisory company, was contracted to provide project assessments and guidance to minimize risk and assure project success. Through quarterly interviews of project staff, steering committee members and stakeholders, and review of project documentation, Gartner provided quarterly reports with their assessments and recommendations. This resulted in guiding the project team early in the project initiation process towards a smooth functioning organization leading to a high level of success.
Gartner´s guidance was focused on the following areas:
Established in January 2007, Arizona Health-e Connection (AzHeC) is a statewide non-profit organization whose mission is to lead Arizona´s establishment of health information infrastructure (HII), which includes support of health information exchange (HIE) and adoption of health information technology (HIT), such as clinician office electronic health records. Arizona Health-e Connection is neither a regional health information organization (RHIO) nor an information exchange, but instead provides strategic direction for the establishment of successful health information infrastructure in Arizona through:
History
Arizona Health-e Connection grew out of an August 2005 gubernatorial executive
order and the subsequent work of hundreds of Arizona individuals and
institutions. Within six months of the executive order, a steering committee,
working with eHealth Initiative (eHI) of Washington D.C., and Arizona
volunteers, delivered a five-year plan - known as "The Roadmap" - for
establishing the state´s e-health infrastructure. The Roadmap called for
development of infrastructure on a regional basis, with provision of shared
infrastructure components as necessary by a statewide non-profit organization.
This statewide entity would also provide leadership for educating Arizonans on
e-health, developing statewide policies and agreements, and promoting
clinicians´ adoption of electronic medical records, e-prescribing, and
other health information technology. Arizona Health-e Connection was founded in
January 2007 to provide this leadership.
AHCCCS established an agreement with AzHeC to provide services that will support the AHCCCS HIE initiative, including the development of connectivity and linkages to other HIE and HIT resources, and to further AzHeC´s mission to foster statewide HIE and HIT development and implementation, collectively referred to as Support Services. The Medicaid Transformation Grant provided $800,000 to AzHeC in return for these Support Services.
Support Services focus on facilitating the development and implementation of
public and private HIE and HIT initiatives and include:
Arizona Health-e Connection must produce the majority of the website design and content and launch the website in conjunction the AzHeC Summit scheduled for May 2 and 3, 2008.
The AzHeC report on the services delivered through this contract has been included with this report.
In May of 2007, Director Rodgers of the Arizona Health Care Cost Containment System, who was responsible for the Medication Transformation Grant awarded to Arizona, through the National Associated of State Medicaid Directors (NASMD), initiated the Multi State Collaboration for the Planning and Development of State Medicaid Electronic Health Record and Health Information Exchange Initiatives. The charter of this collaborative is to advance the successful development, implementation, and deployment of Electronic Health Records and Health Information Exchange technology and to achieve the goals of Medicaid System Transformation and Value-Driven Health Care Initiatives.
There were 13 states in the initial collaborative and it has grown to include the majority of the states in the country. Through this collaborative, the states have been able to share their experiences from their initiatives, and identify key topics and issues, that they are then able to research and formulate methods to address. The charter document for the collaborative is included with this report.
During 2008, 7 workgroups were formed, and focused on specific topic areas:
In January of 2009, the Medicaid Multi-State Collaboration on Health System Transformation First Annual Summit was held. The Agenda for the meeting is included with this report. Over 210 people attended the summit, from all over the country and a great deal of positive feedback was received.
Summary of survey results with respect to value of the summit:
Dr. Thomas Walsh from FOX Systems, with 30 years experience in Health and Human Services Programs and Program Management, having served at the executive level in Illinois State government for eleven years and as the Medicaid Administrator for the State from 1984 to 1986, was contracted to help develop a methodology for assessing the value of a health information exchange to the AHCCCS Medicaid program. The full report and the modeling spreadsheet are included with this report. Following is an excerpt from the document created by Dr. Walsh to help introduce what was developed.
The benefits often discussed tend to encompass estimates of global savings, including all possible benefits that might be realized. Yet, when the success stories are examined, we find that they have consistently followed an incremental strategy. Successful Regional Health Information Organizations (RHIOs) have developed and perfected specific solutions with a limited, well-defined scope. After successful implementation of one product, they have moved to their next project. Successful delivery and adoption of electronic health records does not begin and end in a single effort that realizes all potential benefits. More often, it is an ongoing effort that follows a strategic plan of demonstrating the usefulness of initial products, leveraging successes, and incorporating early successes into additional products.
Development of a successful strategic plan requires a framework for analyzing alternative product strategies and their value to stakeholders. The HIE Value Model provides a mechanism to compare and evaluate the costs and benefits of alternative electronic health products that can be provided through the HIE.
The approach taken in developing the Value Model for the AHCCCS Transformation Grants is an iterative approach to planning for its HIE products. The first set of products is limited to the scope of the HIE project funded by CMS Transformation Grant 1. We recognize that a much broader range of products is both desired and possible, and will be added over time. It is recommended that the value each candidate product for development be simulated using this model, including estimation of its costs and potential benefits. However, our initial model will focus on the three circumscribed products selected by Arizona providers and that are associated with high benefits and limited risks.
By dividing the program into a series of iterative cycles, the HIE Value Model provides a variety of benefits and opportunities for risk mitigation to the overall HIE program, including:
Early-cycle Deliverable Benefits
The benefits of features delivered early in the program begin to materialize
before other components are complete, possibly before others are even defined.
This creates opportunity for refinements, and improves the value of any
multi-year cost benefit analysis
(CBA).
With this in mind, program leadership may decide to lead with development cycles that show the clearest opportunity for success. They might also create cycles that combine high-value features with infrastructure development in order to manage expense and revenue flow.
Decreased Program/Delivery Risk
Smaller projects with narrowly targeted user groups begin with a focused scope
that is reinforced by the user group selected for its uniform needs. This makes
the Value Model´s iterative cycles more likely to satisfy time and budget
constraints than a single large-development
effort
Improved Service
Provider Adoption of New Tools and Services
A focused value proposition offered to users with a similar set of needs will
have higher acceptance rates than more complex or broadly targeted products.
Particularly when adoption requires changes to one or more existing business
practices, a more focused approach allows AHCCCS to provide better
communication and education, and lessens the burden on potential
users.
Flexibility to Support Developing Strategic
Initiatives
Gaps between release cycles allow for the revision of subsequent projects based
on changes in 1) industry trends, 2) observed trends with the local community,
3) governmental or departmental strategy, 4) feedback from the current user
base, and 5) variance from revenue or expense forecasts. The opportunity to
respond to these sources of input will help ensure the HIE Product´s
ongoing sustainability as well as increasing
relevance.
Flexible Release
Strategy
The life-cycle of some products will be associated with more technical and
behavioral barriers than others. By formulating a focused product release
schedule, those products that are more easily developed will not be forced into
a release schedule that is slowed by the more complex
products.
With the positive acceptance of the AMIE by the practitioners and the data partners, a non-profit organization was established, to which the AMIE would be transferred from the AHCCCS. The non-profit called AMIE, includes all of the data partners, AHCCCS and a commercial payer on its board. The board has undertaken the task of working with other initiatives in the state to form a state-wide governance and technology infrastructure for health information exchange in Arizona.