Clinical element models in the SHARPn consortium.

OBJECTIVE: The objective of the Strategic Health IT Advanced Research Project area four (SHARPn) was to develop open-source tools that could be used for the normalization of electronic health record (EHR) data for secondary use--specifically, for high throughput phenotyping. We describe the role of Intermountain Healthcare's Clinical Element Models ([CEMs] Intermountain Healthcare Health Services, Inc, Salt Lake City, Utah) as normalization "targets" within the project. MATERIALS AND METHODS: Intermountain's CEMs were either repurposed or created for the SHARPn project. A CEM describes "valid" structure and semantics for a particular kind of clinical data. CEMs are expressed in a computable syntax that can be compiled into implementation artifacts. The modeling team and SHARPn colleagues agilely gathered requirements and developed and refined models. RESULTS: Twenty-eight "statement" models (analogous to "classes") and numerous "component" CEMs and their associated terminology were repurposed or developed to satisfy SHARPn high throughput phenotyping requirements. Model (structural) mappings and terminology (semantic) mappings were also created. Source data instances were normalized to CEM-conformant data and stored in CEM instance databases. A model browser and request site were built to facilitate the development. DISCUSSION: The modeling efforts demonstrated the need to address context differences and granularity choices and highlighted the inevitability of iso-semantic models. The need for content expertise and "intelligent" content tooling was also underscored. We discuss scalability and sustainability expectations for a CEM-based approach and describe the place of CEMs relative to other current efforts. CONCLUSIONS: The SHARPn effort demonstrated the normalization and secondary use of EHR data. CEMs proved capable of capturing data originating from a variety of sources within the normalization pipeline and serving as suitable normalization targets.

Standards for detailed clinical models as the basis for medical data exchange and decision support.

INTRODUCTION: Detailed clinical models are necessary to exchange medical data between heterogeneous computer systems and to maintain consistency in a longitudinal electronic medical record system. At Intermountain Health Care (IHC), we have a history of designing detailed clinical models. The purpose of this paper is to share our experience and the lessons we have learned over the last 5 years. DESIGN: IHC's newest model is implemented using eXtensible Markup Language (XML) Schema as the formalism, and conforms to the Health Level Seven (HL7) version 3 data types. The centerpiece of the new strategy is the Clinical Event Model, which is a flexible name-value pair data structure that is tightly linked to a coded terminology. DISCUSSION: We describe IHC's third-generation strategy for representing and implementing detailed clinical models, and discuss the reasons for this design.

Medical data abstractionism: fitting an EMR to radically evolving medical information systems.

Growing and maintaining a simple and flexible EMR (Electronic Medical Record) becomes a complicated task in light of diverse and distributed legacy data representation, advancing technologies, changes in medical practice and procedure, and changes in data regulation. Utilizing several abstraction mechanisms can simplify application development and maintenance, and provide flexibility for data evolution and migration. Newer applications built on these abstractions can be the beneficiary of slower obsolescence and lower maintenance costs.

Integrating detailed clinical models into application development tools.

Several groups are currently working on defining detailed clinical models (also called templates or archetypes) that are refinements of abstract medical models like the HL7 (Health Level Seven) Reference Information Model. At IHC, we have created over 3,000 detailed clinical models in the last five years. These models have become an essential part of the architecture of our electronic medical record (EMR) system. As a result, we have created an increasingly sophisticated set of tools that allow the models to be searched, viewed, and ultimately incorporated into medical applications. These browsers have some commonality with terminology browsers, but are distinct in that the explicit structure of the information models must be accommodated. In this paper we report our experience in making browsers for detailed clinical models that are integrated with application authoring tools.

Lessons learned in detailed clinical modeling at Intermountain Healthcare.

BACKGROUND AND OBJECTIVE: Intermountain Healthcare has a long history of using coded terminology and detailed clinical models (DCMs) to govern storage of clinical data to facilitate decision support and semantic interoperability. The latest iteration of DCMs at Intermountain is called the clinical element model (CEM). We describe the lessons learned from our CEM efforts with regard to subjective decisions a modeler frequently needs to make in creating a CEM. We present insights and guidelines, but also describe situations in which use cases conflict with the guidelines. We propose strategies that can help reconcile the conflicts. The hope is that these lessons will be helpful to others who are developing and maintaining DCMs in order to promote sharing and interoperability. METHODS: We have used the Clinical Element Modeling Language (CEML) to author approximately 5000 CEMs. RESULTS: Based on our experience, we have formulated guidelines to lead our modelers through the subjective decisions they need to make when authoring models. Reported here are guidelines regarding precoordination/postcoordination, dividing content between the model and the terminology, modeling logical attributes, and creating iso-semantic models. We place our lessons in context, exploring the potential benefits of an implementation layer, an iso-semantic modeling framework, and ontologic technologies. CONCLUSIONS: We assert that detailed clinical models can advance interoperability and sharing, and that our guidelines, an implementation layer, and an iso-semantic framework will support our progress toward that goal.