AHCCCS - 2007 Medicaid Transformation Grant Final Report

Back to Table of Contents
Back to Section 3.4

3.5 Activities/Deliverables Funded

3.5.1 Project Kick-Off Event

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.

3.5.2 Focus Groups

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.

Table 1: Area of Focus of Participants
Area of Focus
Number of Focus Group Participants
Primary & Acute Care
48
Specialty Care
7
Emergency Departments
24
Behavioral Health
25
Long-term Care
21
Dental
4
Pharmacy
2
Other (IT, Financial & Administrative)
26

Top Ten findings from the AHCCCS HIEHR Provider Focus Groups include:

  1. Health Information Exchange (HIE) in Arizona will be valuable. Nearly all providers expressed a clear understanding of the benefits of sharing patient data through an HIE to support quality, safety, and continuity of care.
  2. HIE should include all payers in the state so that records of all healthcare consumers are available for exchange, not just AHCCCS members.
  3. Multi-stakeholder input is essential to ensure successful adoption of HIeHR use.
  4. Data must be timely, easy to use, and accessible through high-speed Internet connections in all areas of the state.
  5. Providers are concerned about who will bear the costs of adoption, including capital costs, training, implementation, and ongoing technical assistance.
  6. Seamless interoperability is essential. It will be critical for HIeHR to interface with current Electronic Medical Record (EMR) systems, practice management systems, and systems used by hospitals, labs, radiology, and long-term care.
  7. Liability and privacy issues are concerns, and participants were reassured to hear that the Arizona Health Privacy Project is addressing these issues.
  8. Almost two-thirds of respondents to the quantitative survey currently use or are in the process of installing an EMR. Almost half of those without an EMR are undecided about purchasing a system.
  9. The Regional Health Information Organizations (RHIOs) and AHCCCS were seen as trustworthy entities to manage and deploy Electronic Health Records (EHR) and HIE.
  10. The top priority features of an EHR were identified as:
    • e-Prescribing
    • Clinical Encounter Management (includes allergies, problem lists, etc., as well as progress notes)
    • Eligibility Inquiry/Verification

The focus groups were conducted, and the final report provided by Flanagan-Hyde Solutions, LLC and Your Partners in Quality, LLC.

3.5.3 Provider Survey

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.

3.5.4 HIE Technology, Design, Development, Implementation

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.

3.5.4.1 Architecture

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.

3.5.4.2 MPI

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.

3.5.4.3 Patient Merging and Linking

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.

3.5.4.4 Patient Lookup

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:

3.5.4.5 Initiate
Knowing that in the long term a more robust MPI solution will be required, and expecting that AMIE will have a sustainable business model that can support the cost of a commercially available MPI product, the AMIE team investigated the ability to be interoperable with off the shelf products.

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.

3.5.4.6 Data Interfaces

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.

3.5.4.7 Patient Consent

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:

3.5.4.8 XACML Supported

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

3.5.5 HIE Operations Processes, Procedures, Privacy and Security Policies

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:

Patient Notification, Confidentiality and Privacy
Provision of Information to Patients
Privacy and Confidentiality
Patient Requests for HIE Access Reports
Permitted Purpose of Access
Participant Records
Data for Development and Testing
Non-Compliance/Sanctions
Participant Management and Authentication
AMIE Authentication of Participant
Determination of Authorized Users
Training for Authorized Users
Account Management of Authorized Users
Authentication of Authorized Users
Termination of Account or Authorization
Data Submission
Data Accuracy
Amending Data
Minimum Necessary
Limiting Data upon Patient Request
Prohibited Data
Auditing and Compliance
Audit Logging
Other AMIE Logging
Audit Log Custody and Retention
Review of Audit Logs
Incident Reporting
Notification of Breach
Mitigating Effects of Non-Compliance
Complaints/Investigation/ Resolution
Security Requirements
Information Systems Security
Computer Incident Response Team (CIRT)
Security Risk Management
Session Termination

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:

3.5.6 Data sharing agreements, Data use agreements

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&acutes; requirements. Contract documents have been included with this report.

3.5.7 Provider Adoption User Support and Training

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:

Narcotics Seeking and Diversion
"Clearly it the biggest benefit has been with drug diversion and seeking."
Emergency Department Physician

"The patient visited 32 different doctors and had been prescribed narcotics on average every three days before eventually presenting to the ED. I was able to intercept and provide rehab/social services to this patient. This tool has and will make a world of difference in bettering patient care and overall care at the ED level."
Emergency Department Physician

Adverse Drug Reactions
"A patient taking a medicine for seizures thought they had been taken off of it. I was able to clarify that they were indeed still being prescribed that medication."
Emergency Department Physician

"An elderly patient that I had seen for a few years always brought a hand-written list of meds. AMIE showed that she was taking an MAO inhibitor, which was not on her list. This antidepressant medication has many serious medication and food interactions. I had no idea she was taking this medication. I was able to contact all of her consultants and assure that her other prescriptions were safe, and that she is adherent to the dietary restrictions."
Internal Medicine Physician

Unnecessary Admits & Procedures
"Discharge summaries are very helpful. Patients often cannot tell you what hospital they were in and in general are poor about providing medical history."
Pediatrician

"AMIE has proven useful for not ordering an additional CT Scan on a patient who presented shortly after an admit to the hospital."
Gastroenterologist

"After finding a discharge summary on a patient I was able to ascertain that the patient lied about being in the hospital recently. I was able to pull the record within minutes and locate all the patient´s history."
Emergency Department Physician

"I was able to confirm that my patient had a cardiac workup within 90 days and was able to avoid an admission because of it."
Emergency Department Physician

Efficiency and Safety
"I feel triumphant when I find patient information AMIE. No phones calls, faxes or waiting for data to help me with clinical decisions."
Internal Medicine Physician

"The biggest benefit for me has been around patient safety. The more information you know about the patient the better doctor you will be for them."
Surgeon

Looking to the Future
"I think that ultimately this could be probably the most crucial intervention to revolutionize our health care in the state."
Internal Medicine Physician

"Very organized and very well thought out...something that physicians have wanted for a very long time. Disparate hospitals need this. This is a fantastic effort...hope we keep it going forward."
Surgeon

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.

3.5.8 Project Evaluations, Initial Proof Of Concept, Behavioral Health Pilot

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

Respondents:
Believe AMIE has the potential to help increase the quality and safety of health care while decreasing costs. Would like more information (record types, patients, and substance abuse medications) to be included. Need assistance with incorporating AMIE into their workflow to optimize use.

Selected Respondent Quotes
Potential benefits of AMIE
AMIE will "decrease duplication" and "allow us to cut down on medical errors."
"I found it very useful because we actually have to request a lot of records form other agencies and that makes it better for us because we don´t have to make any calls, we can just look it up in the system and everything can just be pulled off of AMIE."
"We´re hoping is to increase patient safety so that we all know what everybody is prescribing a and have that coordination of patient care for safety and for the best care for the patient."
Expectations of AMIE
"I like the way that the information is exchanged."
"It has absolutely fulfilled my expectations for medications. It´s really exceeded it as long as the patient is on AHCCCS."
Impact of AMIE on costs
"... we have an opportunity to have a discussion with them about the side effects and the importance of medication compliance and also patient safety because that´s an opportunity to work with the collaborative relationship with some of the PCP´s and reducing the amount of medications that some of these patients are on."
"This is going to be a costs savings for the state."
"We can identify options that have been fruitless/not tolerated in the past – so I will not prescribe that."
"[There will be] less medication and class duplication. Can talk to patient about safety and quality and reduce the amount of medications the patient is on."
Impact of AMIE on clinical decisions
"I think that it will definitely help to guide how we prescribe as well as it may help in terms of how we direct treatment..."
"[We] found medications we had no idea people were on ..."
"[We] used AMIE to make sure patient was getting their medication filled."
"Well I can think of at least one patient that is on controlled substances and has a borderline personality disorder and has been in and out or urgent care [...] and been released and somebody at some clinic did put her on a controlled substance, and it´s been more difficult to manage her because she has a tendency to overdose and come in with a petition because she´s suicidal, so it´s nice to know that data when we have her come in and out. Also, she´s on insulin and she tends to overdose on the insulin and it´s a lot of attention getting things, but it´s nice to see who´s prescribing what, when and where so we can track her clinically. In addition to her attention-getting threats."
Integration of AMIE into the workflow "...so for us, it´s more of a tool that we have to learn to integrate into our flow."
Impact of AMIE on efficiency
"It´s saving time for us and our clients and also providing a lot more information that a clients will not always disclose to the psychiatrist." "AMIE is available 24/7, so I find it very efficient. I think I´m saving a lot of time."
"We don´t have to be contacting any staff it´s just very efficient"
Would you recommend AMIE?
"Yes, because the more they use it, the more likely it´s going to contain something that is useful for me.
"Yes, it provides a lot of useful information for the doctors ..."
What other information should AMIE include?
"One of the issues that I have is that some of the confidentiality medicines are left off and those are exactly the meds that I am looking for."
What is the best thing about AMIE?
"[The] potential [to] exchange of information and to collaborate with other providers to give the patient the best overall care."
What is the worst thing about AMIE?
"Not enough information."
"Just trying to figure out how to login and everything and the passwords"

Both project evaluations are included with this report.

3.5.9 Project Assessment

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:

Project Success Focus Areas
  • Project Integration
  • Project Scope
  • Project Schedule Compliance
  • Project Budget Management
  • Project Quality Management
Deliverables Focus Areas
  • In-Process Deliverables
  • Completed Deliverables
Business Value Focus Areas
  • Functional and Technical Requirements Definition
  • System Design and Development
  • Business Process Transformation
  • Data Conversion
  • System Validation and User Acceptance Testing
  • Pilot Rollout and Turnover-to-Production

Gartner´s final report is included with this submission.

3.5.10 Statewide Collaboration (AzHeC)

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:

i. Convening working groups, including community based stakeholders, to facilitate the development of standards for HIE components, including standards for:
a. Provider registration data for HIE participation
b. HIE data use, exchange and privacy protection
c. EHR format
d. Master patient index or other record locator services.

ii. Convening working groups to establish recommended standard terms and conditions and related template documents for HIE participation and data use, exchange and privacy protection.
iii. Developing HIE and HIT awareness initiatives and provider and consumer education, in conjunction with AHCCCS and other organizations engaged in HIE and HIT development.
iv. Developing a plan to establish and sustain public and private partnerships to support HIE and EHR development and implementation
v. Facilitating review and comment on the AHCCCS HIE and EHR user and system requirements developed by the AHCCCS HIE project team and sharing technical assistance with the AHCCCS project team.
vi. Collaborating with AHCCCS and other HIE and HIT organizations on grant proposals and business opportunities to foster HIE and HIT expansion.
vii. Communications and Outreach Plan. The development of a written communications and outreach plan(s) that articulates the strategies and approaches AzHeC will implement over the next two years to raise awareness about AzHeC's mission and strategic organizational role in raising wide spread awareness of the Arizona general public, the media, businesses community, health care consumers, and other important stakeholders about the Arizona Roadmap for the deployment of HIE/HIT, the value of HrT/HIE deployment to providers and consumers, and the role that AzHeC is playing in setting standards and encouraging adoptions of HIT/HIE.
The plan(s) will identify strategies for each target audience, set out specific measurable goals, and identify outcomes to be achieved over the next two years. The communication plan will establish the method(s) by which AzHeC will communicate technical standards and guidelines to health care providers and the public.
The plan(s) should be developed by October 2008.
viii. Website Development. The production of an educational website will be developed by May 2, 2008, to be used in conjunction with annual statewide educational Summits and ongoing educational sessions, for use by clinicians, consumers and other stakeholders. The website would cover the following topics:
a. Health Information Exchange
b. Electronic Medical Record Adoption
c. E-prescribing
d. Personal Health Information Technology
e. Privacy and Security
f. Arizona-specific information, to include descriptions and links to the AHCCCS HIeHR project, and other Arizona projects

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.

ix. Educational Literature. Produce educational literature for consumers, clinicians and other stakeholders on topics such as the above, to be produced in coordination with AHCCCS. The educational literature will be produced in a timeframe mutually agreed to by AHCCCS and AzHeC.
x. Security Standards and Policies.
a. Facilitation of Security Standards and Policies for AHCCCS Pilot. AzHeC will work with AHCCCS to facilitate the development of security standards and policies needed for the AHCCCS Transformation Project Phase I launch in fall, 2008. AzHeC will coordinate constituent input for the development of these initial standards and policies to assist AHCCCS in adopting necessary standards and policies. As part of this process, AzHeC's Clinical/Technical Committee will serve as a primary forum for identifying recommended security standards and policies for the AHCCCS Phase I project.

b. Facilitation and Development of Statewide e-Health Information and HIE Security Standards and Policies. As part of the AzHeC mission, AzHeC will work with the e-health community to develop recommended security standards for e-health and health information exchanges. This work will include participation as a leader in Phase III of the Health Information Privacy and Security Collaboration in 2008-2009. AzHeC will work with national and regional efforts to establish recommended security standards and policies that will maximize for local, regional and national interoperability between electronic health information systems.

xi. Reports AzHeC shall provide two progress reports to AHCCCS to be included with the report AHCCCS provides to the Centers for Medicare and Medicaid (CMS) on the expenditure and outcome of the Medicaid Transformation grant.

The AzHeC report on the services delivered through this contract has been included with this report.

3.5.11 National Medicaid Collaboration

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:

Provider Adoption
Electronic Health Records
Legal/Patient Consent
Health Information Exchange
Clinical Decision Support
Data Standards
Evaluation

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:

How would you rate the summit topic of Health Information Technology?
42% Good - 59% Excellent

Do you think the topic was sufficiently covered?
100% Yes

Will you find the topic/information useful in your job?
100% Yes

Overall, how would you rate the summit?
50% Good; 50% Excellent

Will you be likely to attend another summit on Medicaid Health Information Technology in the next year?
92% Yes; 8% No

Will you be more likely to participate in NASMD Multi-State Collaborative activities in the future?
100% Yes

3.5.12 Medicaid Value Model

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 potential benefits of electronic health records and data exchange have been discussed in diverse contexts and varying degrees of detail. Analysis includes a variety of publications, from medical papers to technical IT forums to the presidential campaigns. Virtually every group with an interest in health care is advocating a broadly accessible electronic health record as, at least, a partial solution to medical cost inflation.

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.

3.5.13 Formation of AMIE Non-Profit

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.

To Section 3.6