Here is a sample XML file that might be generated by another application: Sample XML
The format of the XML file is roughly based on HL7, the standard format for passing data between medical applications. 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.
General Guidelines
For now, the process is not
entirely automated. The sending application should create create the XML which
the user then pastes into a box in Pract-Eze Dental. The user hits the import button,
and the patient, guarantor, subscriber, insplan are either created or updated.
The logic used is fairly intelligent and it will not overwrite or destroy any
exising 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.
If a field is empty, you can either include it, but with no value, or you can eliminate it completely from the file. You might 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.
Guidelines on how to use the obvious fields are not shown below. See the XML example file to see all the possible fields. If you are not sure if a particular value is allowed in a field, you can just attempt an import on a test database and 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
As you can see, 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.
Pract-EzeDentalVersion- Strongly recommended. Any future
version of OD 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 OD. 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.