IHE eyecare demystified: Why data standards matter

Page 1

IHE EyeCare Demystified: Why Data Standards Matter What’s happening behind the scenes to keep your equipment connected. B Y A L A N P. G O L O T A

A

ll ophthalmology clinics, large and small, have the same basic patient examination flow. The patient arrives, registers and — based upon the patients’ profile —certain refractive pre-tests or images are ordered. The tests are scheduled and a manual paper list of the procedures is created. The list is then monitored for the status of the procedures performed and the location of where printed testing data and images are stored. Finally, these images are then retrieved, reviewed and evaluated by the ophthalmologist and a decision is rendered — frequently involving an order for additional tests, starting the cycle over. When done manually, this process is inefficient — printing is expensive and mistakes may occur at each step, not to mention the issues with billing. Integrating the Healthcare Enterprise (IHE) is a worldwide, non-profit entity with over 350 registered member organizations and 2,000 individual volunteers who contribute development and deployment resources to 11 clinical and operational domains. Since 2006, the IHE EyeCare domain has applied industry standards to develop electronic interoperability protocol to solve ophthalmology-specific medical record keeping’s greatest clinical challenges and issues. Under the sponsorship of the American Academy of Ophthalmology and more recently the American Society of Cataract and Refractive Surgeons, IHE EyeCare has rapidly gained momentum in allowing the exchange of data and 38

S E P T E M B E R 2 0 1 1 • O P H T H A L M O LO GY M A N A G E M E N T

images from different devices through a standard for medical images known as Digital Imaging and Communications in Medicine (DICOM).

Advantages of Following Protocol Systems that adhere to IHE EyeCare Protocol are meant to create a streamlined, reliable exam experience. When a patient registers, a set of generic or specific physician orders is created based on the patient’s diagnostic profile. These are then automatically scheduled and the patient’s information is sent to each testing and imaging device. The exact detail of when, how and why every test was performed can be electronically monitored, every procedure result or image can be instantly reviewed on your computer monitor and reports can immediately be created and linked to each test and image. Past history can also be reviewed for every exam and image, since all information is securely stored for later follow up. Additionally, procedure and billing information is gathered electronically and automatically charge posted for every test or image performed, including exam and review charges. As patients approach the discharge desk, a detailed invoice of charges is ready for them. All transactions and data are in vendor-neutral, industry standard formats.

Data Compliance Categories The goal of IHE EyeCare is to create for ophthalmology the CONTINUED ON PAGE 40


OM

DICOM DEMYSTIFIED: WHY DATA STANDARDS MATTER

same kind of data-sharing capabilities already developed for radiology. These have served as building blocks for making IHE EyeCare more useful to ophthalmologists by allowing the exchange and display of images from different devices through a standard for medical images known as DICOM; the interchange and reporting of numbers from various devices through a standard for structured reports within DICOM and record visual acuity and refractive discrete elements in accordance with DICOM Supplement 130. When managing non-imaging data, Health Level Seven (HL7) is a methodology that was created to define, integrate and manage protocols so that independent systems can exchange clinical and business electronic health data, such as patient registration and billing data. The AAO has also adopted Systematized Nomenclature on Medicine. SNOMED categorizes medical terms in a hierarchy of meaning that incorporates multiple synonymous terms for the same clinical concept, and categorizes concepts under broader clinical descriptions. SNOMED makes it possible to perform global searches or research on actual patient records. By using numbers to represent medical concepts, SNOMED provides a standard by which medical conditions can be referred, eliminating the confusion that may result from the use of regional terms. This numerical reference system facilitates the exchange of clinical information among disparate healthcare providers and electronic healthcare records.

Achieving IHE Compliance Officially founded in 1997 by the Health Information and Management Systems Society and the Radiology Society of North America (RSNA), the IHE can trace its roots to the early 1990s. Back then it was a loosely interwoven group of software engineers and techies who got together once a year in the RSNA parking lot. In the spirit of cooperation, they would test, compare and show off their latest software developments. Now, the IHE National Deployment Committees (IHE Europe, IHE Asia-Oceania and IHE North America) sponsor regimented formal testing events called “Connectathons.” The Connectathon process provides an independent, monitored, vendor-neutral setting for ‘face-to-face’ system interoperability testing for vendors of health IT systems that wish to prove their IHE integration capabilities. IHE maintains a database of results of each Connectathon for public review, which is accessible at: www.connectathon results.ihe-europe.net. IHE EyeCare is one of the 11 clinical and operational domains, each organized into two committees: technical and planning. The planning committee annually selects the domain-specific ‘use cases,’ or real-world clinical applications, while the technical committee researches 40

S E P T E M B E R 2 0 1 1 • O P H T H A L M O LO GY M A N A G E M E N T

hen reviewing a vendor IHE Integration Statement, be

W

sure to note:

a) Appropriate vendor name b) The product name, as used in the commercial context, to which the IHE Integration Statement applies. c) The product version of the one that you are purchasing, to which the IHE Integration Statement applies. d) Publication date e) The following IHE-required statement: “This product is intended to implement all transactions required in the IHE Technical Framework to support the IHE Integration Profiles, Actors and Options listed below.” f) A list of IHE Integration Profiles supported by the product. g) For each IHE Integration Profile, check for: A list of supported IHE Actors, a list of options as defined in the IHE technical framework and the version number of the technical framework referenced.

and profiles the use of standards to address each use case, documenting them in domain-specific technical framework documents and their supplements. After a public review process, testing and trial implementation, the IHE technical framework is published in the public domain for implementation. The IHE ‘profiles’ created by the technical committees provide a standards-based framework for sharing information within care sites and across networks by addressing critical interoperability issues related to information access for care providers and patients, clinical workflow, security, administration and information infrastructure, and defines the transactions and information content required to address the clinical use case by referencing appropriate international standards — DICOM, HL7, SNOMED, etc. The IHE Profiles are then complied into domain-specific IHE Technical Frameworks; detailed technical formal documents, that serve as implementation guides for developers, vendors, health care facilities, health IT consultants, etc. and are available at www.ihe.net/technical_framework.

Under the Hood of IHE: Integration Profiles What exactly is an IHE profile? Think of a New York Broadway play. The name of the play would be the name of the IHE Domain, so in our example let’s call the ‘play’ EyeCare. The play will have a story line usually composed of four acts, or profiles: (1) Workflow, (2) Charge post, (3) Evidence documents and (4) Displayable reports. Each act will have various ‘actors’ or functions that have a specific script to perform. Some actors will only be in act one and two while other actors are throughout the entire play. All the actors have to work


together and follow a specific script with specific dialogue in order to be successful, so that the audience will understand and enjoy it. For example, the actors ADT, Department System Scheduler/Order Filler, Acquisition Modality and Image Display all have specific transactions or script between them so that they create a profile (act). The profile’s workflow (act 1) and charge post (act 2) each have actors in common that may have a different transaction (script) to perform; however, it is all part of the EyeCare Domain (story line of the play). There are currently four established integration profiles of IHE EyeCare domain that are broken down to perform the following: 1. EyeCare Workflow (A-EYECARE): ADT or patient registration, order placer, department system scheduler and order filler, acquisition modality importer, evidence creator, image manger and archive, performed procedure step manager, image display. 2. EyeCare Charge Posting (EC-CHG): ADT or patient registration, department system scheduler and order filler, performed procedure step manager, acquisition modality, charge processor. 3. EyeCare Evidence Documents (ECED): Image manager and archive, acquisition modality, evidence creator, image display. 4. EyeCare Displayable Report (ECDR): Report creator, repository and reader. Profiles recently completed and available for Connectathon testing this year are Eye Care Appointment Scheduling (ECAS) and Basic Eye Care Workflow (B-EYECARE). The IHE EyeCare technical committee is also developing the Routine Eye Exam Content Profile (REE), which will begin the framework for an eyecare-specific Continuity of Care Document (CCD) based upon exam specifications outlined by the AAO Preferred Practice Patterns’ “Comprehensive Adult Medical Eye Evaluation.”

practical. Another consideration is your existing investment in your digital imaging instrumentation. IHE EyeCare technical and planning committees developed protocols for converting non-DICOM instruments’ data output to a DICOM-conformant data structure for interoperability with the Acquisition Modality Importer (AMI). Be warned that many vendors falsely claim to meet IHE Interoperability standards by describing a product as “DICOM-compatible.” It is very important that you consider a vendor’s level of compliance to the specific standard’s specifications as a major decision point when acquiring instruments and systems for your practice. Vendors need to be required to provide at least two documents to assist you in evaluating their systems for purchase. In the case of the subspecialty of ophthalmology, these are: 1. An IHE EyeCare Integration (Compliance) Statement 2. A DICOM Conformance Statement These documents are technically complex and vendor claims can and will be confusing to the uninformed. Do not be misled by informal claims a vendor or manufacturer may make regarding IHE and/or DICOM-compliance. IHE and DICOM standards require vendors to provide such statements in a formal pre-defined format. These statements are typically posted on vendor Web pages. However, always follow through with confirmation research on the IHE Product Registry, available at http://product-registry. ihe.net/PR/home.seam and IHE EyeCare Connectathon results. Be aware that each vendor is responsible for the completeness and correctness of their IHE Integration Statements. Be sure to incorporate the vendor’s IHE Integration Statement into your system purchase or acquisition contract. By reference, the claims made by that vendor are contractually binding on that acquisition.

How to Choose Devices?

Conclusion

To benefit from the IHE Interoperability strategy, it is important that you determine what level of profile integration is suitable for your practice. While not every clinical environment may require all profiles, each specific profile is modular in design and can be implemented in various combinations thanks to vendor-neutral interoperability and data migration. Data migration occurs when one system replaces another — for example, when integrating into an existing practice management system. Many times an existing system may provide patient demographic data that could be migrated to and substituted for an ADT/Patient Registration actor. Although it would be ideal to design and develop your electronic health record system from scratch, using only IHE-compliant systems, it is not always

Physicians can look forward to improvements in medical decision-making, patient care and cost through the use of interoperable data exchange, facilitated by strict adherence to international standards. The days of medical instrument manufacturers’ proprietary, instrument-specific, ‘data silos’ of patients’ medical information have come to an end. The use and widespread acceptance of DICOM, HL7 and more specifically, IHE Interoperability Protocol will be a great achievement for medicine, research and clinical trials. OM Alan P. Golota is the CEO of Ophthalmic Tools, an IHE and DICOM interoperability consulting company, as well as an IHE EyeCare planning and technical committee member.

O P H T H A L M O LO GY M A N A G E M E N T • S E P T E M B E R 2 0 1 1

41


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.