xDT

from Wikipedia, the free encyclopedia

xDT (also KVDT) is a group of data exchange formats that are used in the German healthcare system in the area of ​​resident doctors. They were created on behalf of the National Association of Statutory Health Insurance Physicians. The formats have a common, text-oriented syntax , in which each field is written as a line in the file, and a common field directory. You define different message classes for which the mandatory and optional fields from the field directory are specified.

Billing data transfer (ADT)

This first xDT interface was published in 1987 under the name "Abrechnungsdatträger" - it was intended for use with floppy disks . The billing data transfer is used to transmit relevant to the cash accounting data to the Ambulatory Health Association on the basis of the German § 296 SGB V . Transmission content: health insurance certificates, coded diagnoses and fee numbers. The ADT is created by the practice software at the end of each quarter and can be sent to the clearing house online or on a data carrier (a simple disk is sufficient for the practice) by post.

Treatment data transfer (BDT)

The BDT was developed at the beginning of the 1990s by the ZI (the Central Institute for Statutory Health Insurance) to enable the exchange of complete data sets between practice programs from different manufacturers. System changes are also made easier because, in addition to billing data, other content, such as B. the entire file card of the patient with anamnesis , examination results and progress information can be transferred. Software providers can integrate this interface to exchange treatment data. However, this is not always the case - often subject to a charge - and since the record description contains many "can" fields, the result of a data exchange is often surprising. Even the definition of the “must” fields is often interpreted differently. As a rule, information that is helpful but not necessarily medically relevant for everyday work in practice can usually not be transferred via the BDT export and import. Examples of this are doctor addresses, e-mail addresses, text modules, practice's own billing numbers, as well as scanned or stored doctor's letters and the like. Ä.

Furthermore, the export and import do not contain any reusable data such as B. the patient's own drug lists ("repeat prescription ") or the option to display old form content in the new practice program (e.g. old prescriptions for medicinal products with full text). Such information must be interpreted accordingly by the target system. The large number of variants of word processing (in-house or commercial products such as MS Word ) make it difficult to take over written letters and other documents.

In practice, additional programming work is almost always required at the data interface when data is to be exchanged between programs from different manufacturers. The software providers also make it more difficult, partly consciously and partly unconsciously, a one hundred percent perfect data transfer. Does the target system offer e.g. If, for example, certain program functions are not activated, it cannot display some legacy data (e.g. percentiles , growth curves , to-do lists).

Treatment data carrier for ophthalmology (BDT-A)

At the beginning of the 1990s, in cooperation with the professional association of ophthalmologists in Germany, an extension of the BDT for the interests of ophthalmology , the BDT-A, was developed. This interface allowed the exchange of structured data, such as those that regularly arise when collecting ophthalmological findings, for example visual acuity , intraocular pressure , glasses and refraction values or squint angles . The structures of the values ​​determined were mapped down to the last detail, i.e. numbers, decimal places, text values, field lengths, etc.

The aim was to offer ophthalmologists the opportunity to exchange data in the same form between different systems and, if necessary, to enable a system change. The concept ultimately failed because there was only a very small number of systems on the market that offered such a complex documentation structure at all, and therefore the KBV or ZI interface could not be checked. The exchange of data is therefore still usually limited to the information contained in the BDT without taking the ophthalmological extensions into account.

Device data transfer (GDT)

The GDT interface is intended for system-independent data transmission between medical measuring devices or external programs and the practice software. These specifications are approved by the quality ring for medical software . The data transfer takes place via files , the serial interface or direct program-program communication.

Typically, the requesting system (practice program) writes a GDT-IN file that is stored in specified fields, e.g. B. contains the patient master data. The target program (e.g. ECG software) reads this file and makes the transferred data available for further processing. Thus, z. B. re-entering the patient master data and thereby avoiding incorrect entries ("Meier or Maier"). After the display or processing has taken place, the system writes a GDT-OUT file, which is usually read in automatically by the requesting system. Usually the note that external data is available now appears in the patient file.

With this technique z. B. "paperless" medical practices from the practice program directly display examination data from external programs ( ECG , scans, lung function , long-term blood pressure , etc.) on the screen. The usual paper printout is no longer necessary.

With the help of an HL7-GDT converter, measuring devices with a GDT interface can also be integrated into hospital information systems that use the HL7 standard.

Laboratory data transfer (LDT)

The LDT is used to request laboratory tests and to transmit the results of these tests.

Further development

The SCIPHOX project created a bridge to the HL7 standard by transforming the content of some xDT specifications into the Clinical Document Architecture .

Since November 15, 2011, the quality ring Medical Software eV (QMS) has been operating the further development of some standards of the xDT family (GDT, BDT) in the role of a standards development organization. The current status of the work can be followed in a QMS wiki.

Web links

Individual evidence

  1. ↑ An essential feature of the ADT is that each field basically represents its own sentence. This means that it contains the elements length, field identifier, field content and field end. . Retrieved June 9, 2011.
  2. ↑ QMS Quality Ring Medical Software e. V .: BDT 3.0 record description
  3. ↑ The BDT interface is provided by the Central Institute for Statutory Health Insurance (ZI), IT Department, Ottostr. 1, 50859 Cologne, standardized and serves the exchange of treatment data between practice computer systems . Retrieved June 9, 2011.
  4. ↑ So that there is no undue dependence on the manufacturer, the National Association of Statutory Health Insurance Physicians defined the so-called BDT interface (treatment data carrier interface) years ago . Retrieved June 9, 2011.
  5. ↑ The computer guide for doctors and IT decision-makers in health care. Verlag Antares Computer, 2002. ISBN 978-3932971051
  6. ↑ Friedrich Lichtner, Jürgen Sembritzki: BDT sentence description - Appendix A. Published by the Central Institute for Statutory Health Insurance in the Federal Republic of Germany ( Memento from March 4, 2016 in the Internet Archive )
  7. ↑ QMS Wiki for the further development of the GDT and BDT standards ( Memento from April 15, 2013 in the web archive archive.today )