Tuesday, May 25, 2010

Architecting the Health Enterprise with TOGAF 9

Several factors are currently driving the increased complexity of health information technology (HIT). These factors include: a new regulatory framework, innovations in the practice of healthcare delivery, standardization, cross-enterprise integration, usability, mobility, security, privacy, and the imperative to improve care quality and reduce costs.

A methodology and governance framework is needed for creating a coherent and consistent enterprise architecture (EA). The latter should not be driven by vendors and their offerings. Instead, health enterprises should develop an EA that is aligned with their unique overarching business context, drivers, and vision. Developing an architecture capability that is based on a proven framework should be a top priority for health IT leaders.

TOGAF 9 is an Open Group standard that defines a methodology, standardized semantics, and processes that can be used by Enterprise Architects to align IT with the strategic goals of their organization. TOGAF 9 covers the following four architecture domains:

  • Business Architecture
  • Data Architecture
  • Application Architecture
  • Technology Architecture.

The diagram below from the TOGAF 9 documentation provides an overview (click on the image to enlarge).

The Architecture Development Method (ADM) is the core of TOGAF and describes a method for developing an enterprise architecture. TOGAF 9 includes specific guidance on how the ADM can be applied to service-oriented architecture (SOA) and enterprise security (two areas of interest in health IT). The different phases of the ADM are depicted on the following diagram (click on the image to enlarge).

The Architecture Capability Framework provides guidelines and resources for establishing an architecture capability within the enterprise. This capability operates the ADM. The Content Framework specifies the artifacts and deliverables for each Architecture Building Block (ABB). These artifacts are stored in a repository and classified according to the Enterprise Continuum.

The Open Group has been working on the adoption of an open EA modeling standard called ArchiMate. ArchiMate provides a higher level view of EA when compared to modeling standards such as BPMN and UML. It can be used to depict different layers of EA including business processes, applications, and technology in a way that can be consumed by non-technical business stakeholders. A sample of an ArchiMate enterprise view of a hospital can be found here.

HL7 has published the Services-Aware Interoperability Framework (SAIF), an architectural framework for facilitating interoperability between healthcare systems. SAIF includes the following four components: the Enterprise Conformance and Compliance Framework (ECCF), the Governance Framework (GF), the Behavioral Framework (BF), and the Information Framework (IF).

For guidance on using SOA in healthcare, the Healthcare Services Specification Project (HSSP) has published the Practical Guide for SOA in Healthcare based on the TOGAF Architecture Development Method (ADM) and the SAIF ECCF. The Practical Guide for SOA in Healthcare contains a sample Reference Enterprise Architecture. The Practical Guide for SOA in Healthcare Volume II describes an immunization case study.

Also noteworthy is the HL7 EHR System Functional Model (EHR-S FM) and the HSSP Electronic Health Record (EHR) System Design Reference Model (EHR SD RM).

Saturday, May 22, 2010

Clinical Decision Support: Crossing The Chasm

Clinical Decision Support (CDS) is certainly a "meaningful use" of electronic health records (EHRs). Despite its potential to improve the quality of care, CDS is not widely used in health care delivery today. In tech marketing parlance, CDS has not crossed the chasm. There are several issues that need to be addressed including: physicians buy-in into the concept of automated execution of evidence-based clinical guidelines, seamless integration into clinical workflows, usability, standardization, and CDS software architecture and design.

When I first started to explore CDS systems, I was quite overwhelmed by the number of different competing formalisms, standards, and academic projects in the field. To move us past the current gridlock in CDS adoption, I propose an agile approach to the development of CDS software with an emphasis on:

  • Working CDS software that delivers results for providers and their patients
  • Close daily collaboration between clinicians and software developers during the development process
  • The use of agile techniques such as automated acceptance testing to facilitate the involvement of clinicians in CDS software quality assurance.

Working CDS Software

Different formalisms, methodologies, and architectures have been proposed for representing the medical knowledge in clinical guidelines for their automated execution. Examples include, but are not limited to the following:

  • The Arden Syntax
  • GLIF (Guideline Interchange Format)
  • GELLO (Guideline Expression Language Object-Oriented)
  • GEM (Guidelines Element Model)
  • PROforma
  • EON
  • Asbru
  • SAGE
  • The HL7 Decision Support Service (DSS) Functional Model Specification.

Many academic papers have been written to explain and compare these different approaches. Each of these projects represents an important contribution to the CDS field and will inform the design of future CDS software. However, it is quite easy to fall into analysis paralysis when reviewing and debating which formalism or standard is better. At the end of the day, what really matters to the pragmatic developer is tested and working CDS software that delivers results for clinicians and their patients.

Using business rule engines is not the only way to develop CDS software. However, I believe that because they are written in languages and frameworks that are accessible to mainstream software developers, business rule engines can accelerate the development, deployment, and availability of CDS software. Furthermore, many viable open source business rule engines are available today and can be leveraged.

Getting CDS Done with a Business Rule Engine

ARRA interim certification criteria for electronic health record (EHR) technology include the following CDS-related requirements:

  1. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) according to speciality or clinical priorities that use demographic data, specific patient diagnoses, conditions, diagnostic test results and/or patient medication list.
  2. Automatically and electronically generate and indicate (e.g., pop-up message or sound) in real time, alerts and care suggestions based upon clinical decision support rules and evidence grade.
  3. Automatically and electronically track, record, and generate reports on the number of alerts responded to by a user.

These requirements can be satisfied with simple conditional statements in any programming language. However, it is recognized that clinical decision support rules (like other complex types of business rules) are better implemented with a business rule engine. This allows the developer to externalize the medical knowledge in the clinical guideline in the form of declarative rules as opposed to embedding that knowledge in procedural code. This approach has many benefits notably resilience to change, ease of maintenance, and enabling collaboration with business users (in this case clinicians).

Collaboration between Clinicians and Software Developers

One of the most challenging aspects of CDS has been the translation of the medical knowledge in clinical guidelines into executable code. There are not that many people who are expert in the both the medical and software development fields. The Agile prescription to this problem is close and daily collaboration between clinicians and software developers.

Business Rules engines like JBoss Drools provide features such as Excel-based decision tables or the ability to write rules in a DSL (domain specific language) to allow clinicians to actively participate in the development and maintenance of decision support rules.

Automated Acceptance Testing

The quality of CDS software is of paramount importance for care safety reasons. The Agile prescription here is test-driven development (TDD), particularly the automated integration and acceptance testing of the proper execution of clinical decision support rules. "FIT for Rules" is an example of an automated acceptance framework for rule engines like ILog and Drools. Such frameworks allow both the developer and the clinician to participate in the acceptance testing process.

Service-Oriented CDS

The complexity and cost of developing CDS software strongly argue in favor of a service-oriented approach whereby CDS software capabilities are exposed as a set of services that can be consumed by other client health IT systems such as EHR and Computerized Physician Order Entry (CPOE) systems. To reduce costs, these CDS software services can be shared by several health care providers.

In this regard, the HL7 Decision Support Service (DSS) Functional Model Specification represents one of the most important specifications for CDS implementers today.

Interchange Standard

The complexity and cost inherent in capturing the medical knowledge in clinical guidelines and translating that knowledge into executable code remains an impediment to the widespread adoption of CDS software. Therefore, there is still a need for a standard for the sharing and interchange of executable clinical guidelines. Several formalisms and standards have been proposed such as the Arden Syntax, GLIF, GELLO, and GEM. However, none of these standards has been widely adopted. Although there is a lot that can be learned from these standards, I believe that they are not widely used because they are complex and specific to the healthcare domain, and therefore not accessible to mainstream developers. There is also a lack of open source and even commercial implementations of some of these standards.

If business rule engines are the pragmatic path to CDS adoption, then I would argue that the Rule Interchange Format (RIF) specification might be a solution to the interchange problem. The RIF Production Rule Dialect (PRD) is designed as a common XML serialization for multiple rule languages to enable rule interchange between different business rule management systems (BRMS). RIF is currently a W3C candidate recommendation and is backed by several BRMS vendors.

UPDATE: The following is the Final Meaningful Use criteria for Clinical Decision Support (CDS):

  1. Implement rules. Implement automated, electronic clinical decision support rules (in addition to drug-drug and drug-allergy contraindication checking) based on the data elements included in: problem list; medication list; demographics; and laboratory test results.

  2. Notifications. Automatically and electronically generate and indicate in real-time, notifications and care suggestions based upon clinical decision support rules.

And here are the draft stage 2 requirements:

Use CDS to improve performance on high- priority health conditions.

Establish CDS attributes for purposes of certification:

  1. Authenticated (source cited);
  2. Credible, evidence-based;
  3. Patient-context sensitive;
  4. Invokes relevant knowledge;
  5. Timely;
  6. Efficient workflow;
  7. Integrated with EHR;
  8. Presented to the appropriate party who can take action

Tuesday, May 11, 2010

How Health Plans Can Help Jumpstart EHR Adoption

ARRA incentives will help physicians and hospitals adopt computerized medical records software in the next four years. The next big challenge will be how to obtain patients' electronic health records (EHRs) in order to make a "Meaningful Use" of these investments in health information technology (HIT). Most patients don't currently have an EHR. The goal is to ensure that within four years, all patients in the US have an EHR.

It will take some time before physicians and hospitals have comprehensive medical records for their patients in their newly acquired Electronic Medical Record (EMR) software. EMR systems that are already deployed by providers don't typically contain clinical data about the care delivered by other providers. In contrast to EMRs, EHRs contain a longitudinal view of a patient's medical history across providers and can be populated from other sources including lab companies, at-home medical devices, health plans, and patient self-reported data (for example, data about over-the-counter drug that could potentially generate an adverse drug reaction).

Discussions on Meaningful Use don't usually mention health plans since the incentives are only directed at eligible professionals and hospitals. However, health plans can play a very important role in jumpstarting EHR adoption by extracting health records from the vast amount of clinical data in claim transaction repositories and by making that data available to members and providers as well.

Quality and Care Coordination with Claim-Based Health Records

The following examples demonstrate how health records extracted from claim data, when made available to providers, can significantly improve the quality and coordination of care :

  • Pharmacy claim data can enable medication reconciliation during transitions of care.
  • Lab and radiology claim data help avoid redundant and potentially costly orders.
  • Diagnosis codes in medical claims can provide a view of a patient's problem list for care coordination purposes.

When delivered in standard compliant data format, these claim-based data can be fed into clinical decision support systems for the automated execution of clinical guidelines and for generating alerts and reminders.

Data Integration and the Importance of Data Standards

Maintaining an up-to-date and truly longitudinal view of a patient's medical history requires merging and reconciling data from heterogeneous sources including providers' EMR systems, lab companies, medical devices, and payers' claim transaction repositories. This data integration will only be possible if all stakeholders adhere to common data exchange standards such as the ASTM Continuity of Care Records (CCR) and the HL7 Continuity of Care Documents (CCD) standards.

Both the CCR and the CCD specify an XML Schema for constraining and validating EHR data. Therefore XML tools based on XSLT or XQuery/XQuery Update can be used to automate the merging of data from multiple sources.

To ensure data portability when members switch jobs or health plans, the HL7 standard development organization published a Plan-to-Plan Personal Health Records Implementation Guide of the CCD specification with active participation by America's Health Insurance Plans (AHIP) and the Blue Cross and Blue Shield Association (BCBSA).

Health Plans and HIEs

Collaboration between all stakeholders in the healthcare industry requires an IT infrastructure to ensure effective data exchange orchestration and security. This infrastructure can take the form of a Health Information Exchange (HIE) network at the regional, state, or even federal level. A HIE provides capabilities such as a document registry and repository, an authorization policy engine, a consumer preferences manager, a HIPAA-compliant audit log, and a master patient index (MPI) to reliably aggregate patient's data across payers, providers, and other data sources. Such exchange networks can be built with open source software such as NHIN Connect and the emerging NHIN Direct.

The Value of Claim-Based Health Records for Health Plans

Claim-based health records can help providers meet health plans' pay-for-performance incentives and quality measures initiatives. Electronic Health records will also be an important component of health plans' Population Health Management programs.

Some Accountable Care Organizations (ACOs) will be led by health plans. Data integration will be essential to the success of those ACOs.

Health Plans vs. Google Health and Microsoft Health Vault

Health Plans have a huge competitive advantage compared to online personal health records (PHRs) services such as Google Health and Microsoft Health Vault: they can pre-populate the PHRs of their members with health records extracted from claim transactions and those PHRs are likely to be more useful and reliable to providers than patient self-reported data.

A Roadmap for Health Plans

Health plans can position themselves for their new role as enablers of EHR adoption by doing the following:

  • Create an EHR view of the health records in claim transaction repositories
  • Map the data to industry exchange standards such as the ASTM CCR or the HL7 CCD
  • Make the data available to their members (through a web portal for example) and partners (subject to patient's consent)
  • Get ready to contribute data to HIEs by adopting other necessary standards such as Integrating the Health Enterprise (IHE) profiles for cross-enterprise document exchange (XDS.b), security, and patient consent
  • Embrace and participate in open source projects such as NwHIN Connect and Direct
  • Actively participate in the health IT standards development process
  • Prepare their infrastructure to send and receive health records from providers.