XML Import for Patient Data 

The XML import tool can be used to import patient data from another medical application into EZ2000 Plus Dental.  Typically the sending application creates the .xml file, or a programmer does. The .xml file must be in the correct format for the import to work correctly.  See XML Format below for guidelines.

How to Import
In the Main Menu, click Tools, Misc Tools, Import Patient XML.

The box will be blank at first.  Select the XML, then click in the box and press Ctrl V to paste it.  Click Import to import the data into EZ2000 Plus  Dental.  If formatted correctly, the patient, guarantor, subscriber, and insplan are either created or updated in EZ2000 Plus Dental.

The logic used is fairly intelligent and it will not overwrite or destroy any existing data. Also, nearly all fields can be missing without generating any error. A warning will be displayed if any field is invalid or if the field name is not recognized. All warnings will come up at one time and the user may simply click OK to continue. Because of this, as more fields are added, a programmer creating the XML files can safely include the new fields with minimal impact on the user. In fact, we may add a check box to let users turn off all warnings, allowing smoother automation.

XML Format
The .xml format is roughly based on HL7, the standard format for passing data between medical applications. Use the Sample XML file as a guide, and to see all possible fields.  If a field is empty, you can either include it, but with no value, or you can eliminate it completely from the file.  You will notice that the order of similar fields is not the same in each group. This is intentional. The order we used follows the order used in HL7 files. But you can rearrange the order any way you want.

Unfortunately, HL7 does not have an XML format available yet. But we were able to locate the Version 2.3 Implementation Guide in PDF which can be found at http://www.hl7.org/library/. There is enough information in that free guide for our purposes, mostly in appendix A and B.

Guidelines on how to use the obvious fields in the sample xml file are not explained below. If you are not sure if a particular value is allowed in a field, attempt an import on a test database to see if it gives any errors.

• Dates: Dates can be any typical format.
• Phone numbers: It will try to reformat numbers, so there are many allowed formats. The length of phone fields varies. The limit is 30 for patients, and 255 for insurance carriers. Notes are allowed to be tacked on to the end of telephone numbers for purposes such as extension or contact name. Notes are preserved and do not get reformatted in any way upon import.
• Notes: None of these would be allowed with HL7, but they are indispensible. They map to nearly identical fields in OD which have unlimited length. Totally freeform.

Message: The entire message is surrounded by a <Message> tag. Multiple messages are not yet allowed in a single file. Each group within the message is referred to as a segment, in keeping with the HL7 guidelines.

MessageHeader: Required

• DateTimeOfMessage - Optional.
• MessageType - Required. Only allowed value is AdmitPatient because this roughly corresponds to an A01-Admit Patient HL7 message.
• OpenDentalVersion - Strongly recommended. Any future version of EZ will be able to handle older versions. The version number just helps it figure out how.

PatientIdentification: Required. 

• NameLast - Required. If there is already a patient in the database with the same NameLast, NameFirst, and DateOfBirth, then a new patient will not be added.
• NameFirst - Required.
• DateOfBirth - Required to uniquely identify patient.
• Sex - Must start with m, f, or u (unknown). If missing, u is assumed. Can also be upper case.
• AliasFirst - Maps to the Preferred field.
• AddressOtherDesignation - Maps to Address2.
• AddressStateOrProvince - In the US, should be two letters capitalized.
• MaritalStatus - Maps to Position. Must start with m, s, or w(widowed). Divorced is not supported. Use s. Upper or lower case. The child position is handled in the guarantor relationship field.
• SSN - Dashes are optional. But a warning will be generated if not exactly 9 digits and user is in the US.
• NotePhoneAddress - Any notes relating to the telephone or address fields, such as when to call, secondary address, custom data.
• NoteMedicalComplete - This is a very large box in OD. It's designed to hold _everything_ from the medical history form. The doctor reads it, adds more notes, and distills the important data out into the Medical summary and the MedUrgNote.

Guarantor: Optional. If missing, guarantor is assumed to be the same as the patient. But if the patient already exists, then guarantor can be omitted, and the original guarantor will not be changed. Even if they are the same, you might include the guarantor segment it if you want the employer name. If guarantor is not the same as the patient, then you must include NameLast, NameFirst, and DateOfBirth of guarantor in order to uniquely identify the guarantor.

• GuarantorRelationship - Self, Parent, or Other. Not case sensitive. If self, then only one patient is created. If parent, then the patient gets a Position of child. Other covers any other situation including spouse. If none specified, then assumed self, and patient fields take precedence over guarantor fields.
• EmployerName - Only stored with patient. If you want the employer to show on the ins plan, then also include it in the Insurance segment in InsuredGroupEmpName.

Insurance: Optional. If used, then CompanyName is required, and PolicyNumber is strongly recommended. Only one loop is currently permitted, although more will be allowed later.

• CompanyName - Required. The name of the insurance carrier. If missing, a warning is generated and NO insurance information gets imported.
• InsuredGroupEmpName - The employer name.
• PlanExpirationDate - Usually leave blank or eliminate because plan is still active.
• Insureds NameLast,NameFirst, and DateOfBirth - Required if not patient. If relation is not self, and any of these is missing, then a warning results, and NO insurance information gets imported. This is because the user would not be able to change the subscriber of an existing plan. In this case, the patient will still get imported.
• InsuredsRelationToPat - Self, Parent, Spouse, or Guardian. Not case sensitive. Reverse of the way it's stored in EZ. So maps to Self, Child, Spouse, or Dependent. If none specified, then assumed self, and patient fields take precedence over insureds fields. If not self, then you must include InsuredsNameLast, InsuredsNameFirst, and InsuredsDateOfBirth in order to uniquely identify the insured. The insured will be added to db if necessary.
• AssignmentOfBenefits - Y or N. Not case sensitive. If missing or blank, Y is assumed.
• ReleaseInformationCode - Y or N. Not case sensitive. If missing or blank, Y is assumed.
• PolicyNumber- Strongly recommended. Subscriber ID. Typically no dashes. However it shows on the card. No validation or alteration will be done. If missing, a warning will result, but all other info will still be imported.
• PolicyDeductible - Dollar amount. 0 if none. Blank if unknown. Pennies not saved.
• PolicyLimitAmount - Annual max dollar amount. Blank if unknown. Pennies not saved.
• NotePlan - Any notes about the plan. Can hold any extra fields, percentages, frequencies, etc.