Today, orthodontists should not need to burden their work load with tasks such as figuring out how to send patient information to colleagues or how to share the same patient record across different software programs. In a long-term attempt to lighten these tasks, we are developing a standard for electronic orthodontic patient records to enable a seamless interchange of data between software programs. This article describes a practical proposal that integrates 2 existing standards, HL7 and DICOM, to create a standard for electronic orthodontic patient records.
Over the past decades, personal computers have found their way into almost every field of medicine. The advantages of using a computer in an orthodontic practice are evident for many applications, such as digitizing x-rays, automatically tracing and collecting measurements, modeling patient growth, storing clinical photographs, placing brackets automatically, and much more. The rapid development and spread of computer hardware has enabled the performance of increasingly complex operations, forcing software vendors to quickly meet the public’s demands. At the beginning, it was believed that 1 company could meet all orthodontic requirements. Software engineers were planning their software to be independent, and relationships among software vendors tended to be competitive. After some years, with various high-quality software products sharing the market, the need to interchange electronic patient data gained importance.
At the time of writing, the interchange of orthodontic electronic data among different programs is difficult. This difficulty can be broken down into 2 problems: (1) there is no straightforward way for orthodontists to share selected electronic patients records (EPRs), and (2) there is no mainstream way for 2 or more orthodontic programs to access the same pool of EPRs.
The first problem is exemplified by the following scenario. Carl is a recently graduated orthodontist. Unsure of the treatment of choice for a patient, he seeks the help of a more experienced colleague, Magda, to clarify his clinical doubt. Magda asks Carl to send the patient’s record, so that she can look at them. Although the patient’s electronic record in Carl’s patient management program already includes impressions, x-rays, tracings, and notes, it is not the same patient management program that Magda uses. After various failed attempts, Carl admits he cannot send his information to her in a compatible format. He thus resorts to printing out paper copies of the material to send to her. However, Magda would like to also analyze the impressions, which, even when printed, are not easily analyzed. Although they are already digitized, her software does not allow her to view them, and she must visit Carl in person to solve this problem. Carl and Magda work in the same city and can work around the problem of software incompatibility. But what if they lived in different cities or even different countries?
The next scenario will help us understand the second problem. Recently graduated, Carl wants to build his new practice. Among other choices, he must decide which patient management software program to purchase, and he found a great one that meets his needs. After purchasing and using the program for some time, however, he discovers that its cephalometric analysis part is weak, and that he could improve patient care by using the same cephalometric analysis program that Magda has. He purchases it but soon realizes that these 2 software programs do not communicate with each other. If, for example, a record lists a patient’s birthdate as May 13, 1993, and another erroneously gives May 13, 1983, Carl must modify (add or remove) the patient record twice, once for each system. If he forgets, he might end up with inconsistent patient records; this makes a big difference from an orthodontic perspective. Suppose he decides to add a new image management program or a cone-beam computed-tomography scanner to his institution. Must he modify 3, 4, or 5 EPR databases for each change?
If we accept the assumption that computer programs should improve patient care by making processes more efficient, the above situations are unacceptable. These issues need to be addressed immediately. The use of already developed clinical standards has been limited to observation and prototyping by vendors and experimentation in academia, mainly because the use of proprietary design maintains the vendors’ competitive positions in the marketplace. A standard only gains commercial value when it is widely implemented. This explains why vendors are reluctant to implement a new informatics standard. Presently, we see increasing interest in these standards because of current United States federal government initiatives in health information interoperability, ⁎ following a trend in other regions such as Europe (with heavy government involvement in health care programs). Now is the right time to illustrate a practical way to solve these issues.
Instead of developing the orthodontic electronic patient record (ortho-EPR) standard from scratch, we believe that the answer lies in a standard composed of 2 already existing and well-established informatics standards: Health Level Seven (HL7) for textual data and digital imaging and communication in medicine (DICOM) for image data. Their integration will be coordinated and published by the American Dental Association (ADA) Standards Committee for Dental Informatics (SCDI) to ensure functionality in an orthodontic context. From a technological point of view, the standard would define the processes and interactions involved during everyday clinical and financial orthodontic practice: in short, a computer standard for software vendors and programmers. Among its tasks, the standard will document all fields necessary to fully represent orthodontic patient records as well as their transferability, and be recognized by a large community of orthodontic specialists. In addition, it will include an implementation manual for software vendors to demonstrate its intended operation. Once completed and implemented, the standard will allow seamless and efficient patient information exchange and synchronization.
Here, we discuss the general process of developing an informatics standard and describe our proposal for solving the problems described previously. This requires a brief study of the building blocks of our suggestion: ADA SCDI, HL7, and DICOM.
The development of an Ortho-EPR can be broken down into 7 parts: forming a community, defining the domain, researching existing technologies, defining a technology, building the standards, balloting and releasing, and implementing and testing. These methods of execution are based on the initial proposal of Philippe deSmedt.
The process of developing a standard starts by forming a community of interested persons that eventually develops into a formal body. To achieve this, in May 2004, a working group in the ADA SCDI was formed by Philippe deSmedt (of Align Technology) and Steve Bartingale (of 3M). Called WG 11.6, Integration of Orthodontic Standards, this working group includes representatives of 3M, University of Northern Carolina, University of Illinois at Chicago, University of the Pacific, University of Missouri Kansas City, Case Western Reserve University, University of Pittsburgh, Loma Linda University, Universidade de Brasília, Kodak, Dolphin Imaging, Ortho Computer Systems, Orametrix, and Drake Visual—from academic, commercial (industry), and clinical fields.
Domain is the specific sphere of activity and the working elements of a given project. WG 11.6 decided that the domain for the standard should include all orthodontic data currently used in digital format. This encompasses the entire orthodontic domain, which can be grossly divided into imaging data (photos of patients, x-rays, cone-beam computed-tomography scans) and nonimaging data (patient demographics, clinical information, financial information). The group’s members are refining this definition.
We are now evaluating existing imaging medical, dental, orthodontic, and other data, and data-exchange standards to adopt them when appropriate. We are evaluating the organizations, their internal processes and implementations, and the structure of their standards to find a match for our project. The infrastructure of an existing standard-developing organization can greatly simplify the development process of the ortho-EPR. In the research process, we will collect various proposals from our group members. These documents should include a brief summary of the standard, how it would benefit the project, and the relationship between our group and the above-mentioned organizations.
Based on the documents delivered in the previous phase, the group will meet to decide which proposal to advance. On reaching a consensus on the path to take, the group will deliver a document specifying which standard organizations to adhere to and the details of the relationship between our group and the external organizations. The document will include how to divide the group into subgroups to work toward the final product.
To build the standard, each subgroup will work individually according to the plan established previously. Then their work will be harmonized to create the ortho-EPR standard and to deliver a first draft of it.
The first draft of the standard must be balloted, so that every member of our group and other affiliated groups can review it. This process will cause revisions and reballoting, and eventually result in the first implementable release of the standard.
The first release of the standard must be implemented and tested before it can be considered complete. Subgroups formed primarily by vendors and software developers should take over this task to produce software that can handle orthodontic information stored or transmitted in the newly developed format. If errors are found in this stage, a new cycle of revision, balloting, release, implementation, and testing will take place. Thus, once this stage has been reached, the group might cycle between balloting, releasing, implementing, and testing until a satisfactory version of the product is delivered.
Standards for medical informatics
The 2 most successful medical informatics standards are HL7 for messaging and DICOM for imaging.
The HL7 standard defines how to transfer medical nonimaging information across different computer systems, networks, and programs. HL7 differs from Specification 1000 (see below) in that it specifies how the data should be transferred when they leave a specific computer program, whereas Specification 1000 defines how the data should be stored when they enter a computer program.
Although Specification 1000 is based on a fully balloted and diagrammed clinical process model, HL7 starts its development from storyboards. A storyboard is a short description of a specific medical scenario (also called a use case) but does not use diagrams and is not balloted. The latest HL7 release is version 3, which is based on modern object-oriented modeling and programming techniques.
HL7 is growing rapidly and spreading internationally. Its organization has affiliates in more than 20 countries, and the standard is being used by many well-accredited health institutions. According to its organization, 90% of hospitals in the United States use some form of the HL7 standard (mostly the older version 2). Although no official dental technical committee exists in the United States, the Canadian Dental Association and HL7-Canada already have completed some work with dental insurance claims and have shown interest in joining the ADA to form a dental HL7-USA technical committee.
Making use of HL7 to develop the Ortho-EPR standard would yield several advantages. First, the HL7 community is large and includes international members; thus, quality feedback could be obtained to improve the product. Second, HL7 uses modern technologies, mixing the clinical approach (starting from storyboards) with object-oriented modeling (using version 3) should result in better planning and a more flexible end product. Furthermore, HL7’s widespread use in hospitals could facilitate its appeal to software companies, an important issue since widespread implementation is equivalent to a successful standard and better integration between orthodontic practices and clinics and hospitals. On the other hand, HL7 has no specifications for images, but it does integrate well with DICOM.
DICOM is the only internationally recognized standard for the communication of images and related information in the health domain. It originated in 1983 when the American College of Radiology and the National Electrical Manufacturers Association identified the need for interoperability among imaging equipment from various vendors.
DICOM is extensively used in many countries and medical environments, and is undergoing considerable development to include images from new devices and medical fields. Extensions of the DICOM standard now encompass all aspects of digital and digitized dental radiographs. The ADA endorses DICOM as the standard means for exchanging all digital dental images. However, the DICOM standard extends well beyond the needs of dentistry, making it necessary to select the relevant parts for dentistry. The ADA SCDI has formed a working group called Application of the DICOM Standard to Dentistry (WG 12.1), whose members are part of an equivalent working group in the DICOM Standards Committee. This tight collaboration ensures that DICOM developments satisfy requirements of dental professionals with documents such as “Technical Report No. 1023: Implementation Requirements for DICOM in Dentistry.”
Unlike HL7, DICOM already has a working group for the dental community. This and its widespread use encourage the use of DICOM for orthodontic digital images. DICOM offers standards for most kinds of medical images; refining it for orthodontics should involve relatively little work.
DICOM provides a good framework that could be used for defining the image domain of the ortho-EPR.
ADA and Specification 1000
The ADA is the sponsor and secretariat of the standards program for all areas of dentistry, including dental materials and products (ADA Standards Committee on Dental Products) and dental informatics (ADA Standards Committee on Dental Informatics). The ADA’s standards committees balance the interests of dentists, government, academia, and industry, and develop standards according to rigorous protocols that ensure consensus among them.
Specification 1000 refers to American National Standards Institute (ANSI)/ADA “Specification No. 1000, Standard Clinical Data Architecture for the Structure and Content of an Electronic Health Record,” the only American national standard that defines the fundamental data structures used to build EPRs. Specification 1000 defines the data structure of a generic health record. This means that it defines how to program a database so that it can be used as a virtual health-record file cabinet. This differs greatly from other computer standards (such as HL7 or DICOM) that primarily specify how programs should send information related to health care between computer systems. When implemented, Specification 1000 would ensure that 2 programs could directly access the same health-record data pool at the same time. It does not, however, define how to exchange the data across different medias or networks.
The only ADA SCDI standard that deals with informatics, Specification 1000 was the first standard derived from a balloted clinical process model. This means modeling out all clinical processes first and then defining the informatics standard from the model. Specification 1000 comes with an implementation manual, but, to the best of our knowledge, Specification 1000 has been limited to observation and prototyping by vendors and experimentation in academia. In addition, it contains no dental-specific definitions.
As the largest, most influential dental association in the world, with a well-developed standards committee, the ADA can provide a solid infrastructure for the development of the ortho-EPR standard. The SCDI comprises members from various areas who can contribute their knowledge and resources for the project; whereas orthodontists provide the more technical necessities and contribute their specialized knowledge, industry and government representatives will supply resources for meetings, implementation, and testing. In addition, the committee is specialized in developing and distributing standards and is an ANSI-accredited institution. We recommend developing the ortho-EPR standard by following the clinical model approach used for Specification 1000.
From our analysis, we propose a structure for the ortho-EPR standard: an ADA/ANSI standard that includes the integration of HL7 with DICOM. Using this approach, we can make sure that the data will be most compatible with existing systems and deliver a complete orthodontist-approved ortho-EPR standard. The ADA SCDI would provide the official standard and standard implementation documentation (similar to Specification 1000 and its accompanying Technical Report 1027). This process has 3 main phases: planning, developing, and integration.
These concepts have not been presented to the organizations (ADA, HL7, and DICOM) yet. None of these organizations will be responsible for any of the concepts. Even though it is likely that some parts of this proposal will be implemented, none of the organizations has agreed to complete or execute these ideas, either in whole or in part.
In the planning stage, it is necessary to develop a model of clinical processes. We suggest starting from HL7-like storyboards and then mature the storyboards into a balloted and diagrammed clinical model. This will lay the groundwork for the next 2 stages.
The ortho-EPR developers are divided into imaging and nonimaging groups, based on their interests. These collaborate with the DICOM and the HL7 standard organizations to make sure that their respective standards will include all necessary fields and definitions to accommodate ortho-EPRs. This stage will add missing elements in the ballots for future HL7 and DICOM releases. This process entails the formation of a dental/orthodontic technical committee in HL7 and the inclusion of interested persons in the appropriate DICOM working group (DICOM WG 22 or ADA SCDI WG 12.1).
When the 2 standards are ready, the ADA SCDI will publish a higher-level standard to instruct software developers and others interested in implementing the standard on the joint use of HL7 and DICOM as approved by ADA/ANSI. Once balloted and released, the document will consist of a technical document as the official standard reference and a less technical companion (similar to Technical Report 1023 ) to guide the implementation and use of the standard.