The problems which were detected and which this study is attempting to solve are the following:

1. Novel medical processes that are based on the application of new technologies contain unique characteristics and, as a result, cannot use existing computer control applications [3 Crichton C, Davies J, Gibbons J, Harris S, Tsui A, Brenton J. Metadata-driven software for clinical trials Proceedings of the 2009 ICSE Workshop on Software Engineering in Health Care Los Alamitos: IEEE 2009; pp: 1-11.]. When attempted, it causes problems for the functionality of medical procedures.
2. The time required to develop and refine a specialized computer application capable of bridging the characteristics of a medical procedure with international medical standards for exploiting such information is disproportionately large to the initial development of the medical procedure itself [4 Kuhn K, Lenz R, Elstner T, Siegele H, Moll R. Experiences with a generator tool for building clinical application modules Methods Inf Med 2003; 42: 37-44.]. The result is the accumulation of a very large volume of medical information at medical organizations which either remains in primary electronic format or in handwritten documents.
3. Each medical incident is unique for the attending physician, depending on the uniqueness of the patient, though digitization requires the “adaptation and placement” of incidents into groups with common elements and terms, aiming to exploit information stemming from the final result [5 Hillestad R, et al. Can electronic medical record systems transform health care? Potential health benefits, savings, and costs Health Aff 2005; 24: 1103.].
4. In the case of surgery, the effort to digitize and record an incident with a computer application based on medical models may influence the medical development of an incident itself, eventually causing delays and dysfunctions that decrease the final reliability of the undertaking [6 Li Z, Xuan-Dong Y, Kai-Yang L. Digitization and DICOM standardization of X-ray image signal Wuhan Univ J Nat Sci 2004; 9: 463-7.].
5. The usual strategy that is followed in the application of medical models while coding medical information is to use the medical standards entirely as well as independently to then bind medical terms [7 Young A. The creation of medical knowledge: some problems in interpretation Soc Sci Med Med Anthropol 1981; 15: 379-86.] with the incident’s data. However, this strategy is inferior in speed and functionality, since there are time-consuming intermediary calculations during this process of binding and the final user is not exempted from the requirement to have a full awareness of the function and structure of the entire model.

The present study describes the methods used in the creation of a computer application to manage a hysteroscopy surgery based on the SNOMED medical model. Processes were defined and executed to transcribe the existing handwritten medical information of the surgery into a form that can be input into a database, thereby allowing it to be fully exploited. This practice is considered to be a research priority according to the resolutions of the European parliament [8Available at www.Hl7.org ].

During this effort, we attempted to construct and propose a process of coding hysteroscopy incidents. Up to now, hysteroscopy has not been interoperable with the SNOMED medical model [9Available at: www.cda.org ]. Also, the Clinical Document Architecture (CDA) [9Available at: www.cda.org ] has not yet adopted a relative architecture of harmonizing hysteroscopy to the medical model.

This work advanced in two stages. The first stage was to create the environment of the hysteroscopy medical process based on the established practice that is followed by doctors of this specialty. In the second stage, a mapping of the application fields to the elements of the SNOMED model was carried out using a mechanism for mapping XML schemas-SNOMED to object-relational database systems.

In an effort to arrive at an accommodating solution it was decided to follow the medical procedure as it is defined by medical practice [12 Hamou JE. Hysteroscopy and micropolhysteroscopy: text and atlas. Norwalk CT: Appleton & Lange 1994.] (Fig. 1). Though in the backstage and with methods that will be described below, the model was satisfied completely; only in exceptional cases (Fig. 2) was any direct input made to the existing data. The steps followed are shown in Fig. (1).

Fig. (1) Cross-correlation of handwritten registration fields with a computerized environment

Fig. (2) Data input according to the rules of the standard.

Fig. (3) Flow chart illustrating how handwritten forms were transferred into computerized format.

Fig. (4) Depiction of relational tables of the database in the Entity-Relation-Diagram (ERD).

Fig. (5) Examples of data with selected elements of the model.

Fig. (6) Data transfer flowchart.

Fig. (7) Example of the “double field” use.

Fig. (8) Example of handwritten registration form.

Fig. (9) Input of patient's personal information into the database.

Fig. (10) Database Medical Document creation process.

The proposed process includes six stages, which are schematically represented in Fig. (3):

1. The data used in the process were analyzed (Table 1). The fields and the order of data input were researched before the corresponding terms were located in the medical model. Wherever it was judged necessary for fields that had not been forecasted in advance, it was planned for them to be added into the application given default values without user intervention.
2. The model's tables and the relationships and properties of the medical terms used were analyzed in order to ascertain to which point they coincided with the handwritten procedures.
3. When the model required particular term properties that were not present on the handwritten form, this was to be completed by a mechanism independent to the data entry procedures.
4. The possible values for every field were located, connecting them to the input values from the handwritten forms with even more terms from the model's dictionary. Thus, special lists in table form were created, from which values could be selected by the user. The latter was rendered possible after almost all values from handwritten forms were input and partially revised according to an appropriate regrouping of handwritten forms containing “relative” data. The value being input was to be selected from a user-defined list, and not from one containing the exact term given by the model, although the value that was being input into the table was the standard model value (Fig. 3).
5. Techniques for storing and sharing multimedia files were incorporated in such a way that there would be no need for the operator to have specialized materials or knowledge (Fig. 3).
6. Finally, the input environment was changed to the form used in handwritten documents, with only minor modifications made in cases where it was obviously difficult to apply the model (Fig. 3). Natural language data entry techniques were used with parallel binding to the model's terminology.

We first studied and analyzed the model and final export to the database tables of the application of all data and relationships connected to hysteroscopy (see Appendix). Because the model did not determine the process that ought to be followed [11 Elkin PL. Evaluation of the content coverage of SNOMED CT: ability of SNOMED clinical terms to represent clinical problem lists Mayo Clin Proc 2006; 81: 741-8.], this design was based on established medical practices [13 Neis KJ, Brandner P, Hepp H. Hysteroscopy: textbook and atlas. NY: G. Thieme Verlag 1994.]. Three stages were included in the outline. In Stage A, the incident data were recorded (Personal Data, Medical data, Gynaecological Data and Ultrasonic Examination Results) upon which the "Cause" of the examination was justified. In Stage B, the examination data were recorded (Examination Data, Photos, Video, Sketch and Findings). Finally, in Stage C, the final diagnosis and decision (Future Actions) were recorded. These stages are presented in the Entity-Relation-Diagram (ERD) shown in Fig. (4).

This stage offered both the usability sought by the physician [13 Neis KJ, Brandner P, Hepp H. Hysteroscopy: textbook and atlas. NY: G. Thieme Verlag 1994.] as well as the flexibility that was provided by the reduced encoding of the model and its data (Fig. 4). The creation of independent tables with elements from the model was judged essential because the application required only components of the model's elements and not the complete tables. Thus, the choice of components from the model’s basic tables that were related to hysteroscopy, and their incorporation into the application's files, added speed and accuracy to the processing of information (Fig. 5).

Study and analysis of the currently used handwritten hysteroscopy form and adaptation of its elements were made not from the form itself but were accomplished according to the SNOMED coding. In order to achieve this, the binding of each tab field to those of the model's was studied, and a connection between them was achieved. Strictly following the model, these were added where necessary in the application’s background, not in the foreground, so as not to influence the existing data input process (Table 1). Wherever possible, this was achieved with the use of predetermined values from the model given to fields (e.g., sex) that needed to be created and were customizable.

Table 1

Examples of Field Binding

Table 2

Example of the Unification of Different Field Values into One Normalized Value

Next, the problem of regrouping and coding the already registered values in existing fields was studied and analyzed (Fig. 6). The main problems were found in fields such as "Indication for examination" ("Hysteroscopy cause”) or “Pathology intra-uterine” (“Endometrial pathology”), as the values of these fields could not be standardized. To manage this problem, two fields (Fig. 7) were created: one for the doctor's past description and another which is a list from the model and which will be completed in the future.

The possibility of exporting and importing medical documents in the CDA format based on the SNOMED model was investigated and materialized. To protect personal data a special scheme was created as a subset of the described elements of the method to succinctly describe a hysteroscopy medical incident (Document Type Definition).

This study is based on the development of medical management software that describes a medical incident using an automatically derived SNOMED medical standard. In contrast, many browsers [15Available at: http://www.nlm.nih.gov/research/umls/Snomed/snomed_browsers.html ] (e.g., CliniClue, Federation Health Browser, MedTalk, Minnow, Mycroft, NCI Terminology Browser, OpenKnoME 5.4d, ClaW Workbench, SNOB, SnoFlake, Snow Owl, Virginia Tech Browser, etc.) of that standard have been developed using an inverse philosophy. In other words, these browsers describe the medical incident via hierarchically sequenced SNOMED terminology.

It is known that the measure of SNOMED’s complexity is linked to the amount of steps needed in order to complete a medical incident description. The measure of this complexity can be described by the simplicity ratio SX=EXPX , where X is the total number of steps, E(X) is the number of the concepts of X, and P(X) are partial-areas of X [16 Wei D, Wang Y, Perl Y, Xu J, Halper M, Spackman KA. Complexity measures to track the evolution of a SNOMED hierarchy AMIA Annu Symp Proc 2008; 2008: 778-82.]. The quantitative comparison between these techniques (i.e., the one proposed in this study and those of browsers) is calculated as follows:

For the proposed study, E(X) = 1 because in this method the concept is referred with medical incident uniquely, thus S1X=||1PX , while for browsers S2X=||EXPX. Taking into account that E(X) ≥ 1 and that P(X) is the same for both techniques we can conclude that S₁(X) ≤ S₂(X). Therefore, our technique is superior to browsers in terms of quantitative complexity in this specific application.