In an open-architecture healthcare environment there often exists a set of
common reference files used by one or more application systems. Such files are
called master files. Some common examples of master files in the healthcare
environment include:
a) doctor master file
b) system user (and password) master file
c) location (census and clinic) master file
d) device type and location (e.g., workstations, terminals, printers, etc.)
e) lab test definition file
f) exam code (radiology) definition file
g) charge master file
h) patient status master
i) patient type master
These common reference files need to be synchronized across the various
applications at a given site. The Master Files Notification message provides
a way of maintaining this synchronization by specifying a standard for the
transmission of this data between applications.
In many implementations, one application system will "own" a particular master
file such as the doctor master file. The changes (e.g., adds, deletes,
updates) to this file are made available to various other applications on a
routine basis. The Master Files Notification message supports this common
case, but also supports the situation where an application not "owning" a
particular master file, transmits update information to other systems (usually
to the "owning" system), for review and possible inclusion.
The Master Files Notification message supports the distribution of changes to
various master files between systems in either online or batch modes, and allow
the use of either original or enhanced acknowledgement modes, as well as
providing for a delayed application acknowledgement mode. These messages use
the MSH segment to pass the basic event code (master files notification or
acknowledgement). The MFI (master file identification) segment identifies the
master file being updated as well as the initial and requested dates for "file
level" events (such as "replace file"). For each record being changed, the MFE
(Master File Entry) segment carries the record-level event code (such as add,
update, etc.), the initial and requested dates for the event, and the
record-level key identifying the entry in the master file. The MFA (master
file acknowledgement) segment returns record-specific acknowledgement
information.
Note: The MFE segment is not the master file record, but only specifies its identifier, event, and event dates. The master file record so identified is contained in either Z-segments or HL7-defined segments immediately following the MFE segment. This record may be either a flat record contained in a single segment, or a complex record needing more than a single segment to carry its data and (usually hierarchical) structure. |
The master file segments commonly needed by many HL7 applications will be
defined in balloted appendices to this chapter. Those needed by other
application-specific chapters will be defined in balloted appendices to the
appropriate application-specific chapter.
A given master files message concerns only a single master file. However, the
location of a record-level event code (and requested activation date) on the
MFE and the MFA segments allows a single message to contain several types of
changes (events) to that file.
The Master Files Notification events do not specify whether the receiving
system must support an automated change of the master file in question, nor do
they specify whether the receiving system must create a file in the same form
as that maintained on the sending system.
In general, the way in which the receiving system processes the change
notification message will depend on both the design of the receiving system and
the requirements negotiated at the site. Some systems and/or sites may specify
a manual review of all changes to a particular master file. Some may specify a
totally automated process. Not every system at every site will need all the
fields contained in the master file segment(s) following the MFE segment for a
particular master file entry.
This also means that an application acknowledgement (or a deferred application
acknowledgement) from a receiving system that it changed a particular record in
its version of the master file does not imply that the receiving system now has
an exact copy of the information and state that is on the sending system: it
means only that whatever subset of that master file's data (and state) that has
been negotiated at the site is kept on the receiving system in such a manner
that a new Master Files Notification transaction with the same primary key can
be applied unambiguously (in the manner negotiated at the site) to that subset
of information.
The Master Files Change Notification message can be used for the following
message-level trigger events:
Mnn: A message containing notifications of changes to a single master
file.
nn defines a particular HL7 master file. Currently defined values are (see
Table 0003): M01 - master file not otherwise specified (for backwards
compatibility only); M02 - staff/practitioneer master file; M03 -
test/observation master file; M04-M99 - reserved for future HL7-defined master
files. Site-specific master files should use a code of the form Znn.
An MFN message may contain the following "file-level" events, as specified in
the MFI segment:
REP: Replace current version of this master file with the version contained
in this message.
UPD: Change file records as defined in the record level event codes for each
record that follows.
These are the only file-level events currently defined. REP means that every
MFE segment that follows will use the MAD event code.
The replace option allows the sending system to replace a file without sending
delete record-level events for each record in that file. UPD means that the
events are defined according to the record-level event code contained in each
MFE segment in that message.
An MFN message may contain the following "record-level" events, as specified in
the MFE segments.
MAD: Add record to master file.
MDL: Delete record from master file.
MUP: Update record for master file.
MDC: Deactivate: discontinue using record in master file, but do not delete
from database.
MAC: Reactivate deactivated record.
The MFD transaction is used for the following trigger event:
MFA: Master Files Delayed Application Acknowledgement.
The following messages are defined for master files transactions: MFN, master
files notification; MFK, master files application acknowledgement; MFD, master
files delayed application acknowledgement; and MFQ, master files query.
The MFN transaction is defined as follows:
MFN Master File Notification
Chapter
MSH Message Header
2
MFI Master File Identification
8
{MFE Master File Entry
8
[Z..] } One or more HL7 and/or (varies)
Z-segments carrying the data
for the entry identified
in the MFE segment
MFK Master File Application Acknowledgement
Chapter
MSH Message Header
2
MSA Acknowledgement
2
[ ERR ] Error
2
MFI Master File Identification
8
{ [MFA] } Master file ACK segment
8
The master file record identified by the MFE segment is contained in either
Z-segments and/or HL7-defined segments immediately following the MFE segment,
and is denoted by "Z..." in the MFN abstract message definition given above.
This record may be either a flat record contained in a single segment, or a
complex record needing more than a single segment to carry its data and
(usually hierarchical) structure.
The master file record "[Z..]" identified by the MFE segment is optional
(indicated by square brackets) in the single case where the master file is a
simple one which contains only a key and the text value of that key. For this
case only, both values may be carried in the primary key value CE field of the
MFE segment.
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgement modes. |
The MFA segment carries acknowledgement information for the corresponding MFE
segment (identified by the primary key value).
The MFD transaction is the delayed application acknowledgement. It can be
used to return "deferred" application level acknowledgement statuses at the
MFE level, without reference to the original MFN message. It is defined as
follows:
MFD Master File Delayed Acknowledgement
Chapter
MSH Message Header 2
MFI Master File Identification 8
{ [MFA] } Master file ACK segment 8
MSA General Acknowledgement
Chapter
MSH Message Header 2
MSA Acknowledgement 2
[ ERR ] Error 2
The MFQ transaction allows a system to query for a particular record or group
records (defined by the primary key) in a particular master file.
The Master files query is defined as follows:
QRY Query for Master File Record
Chapter
MSH Message Header 2
QRD Query Definition 2
[QRF] Query Filter 2
[DSC] Continuation 2
MFR Master Files Response
Chapter
MSH Message Header 2
MSA Acknowledgement 2
[ ERR ] Error 2
QRD Query Definition 2
[QRF] Query Filter 2
MFI Master File Name 8
{MFE Master File Entry 8
[Z..] } One or more HL7 and/or (varies)
Z-segments carrying
the data for the entry
identified in the MFE segment.
[DSC] Continuation 2
The value "MFQ" of the "what subject filter" of the QRD segment identifies a
master files query. The "what department data code" of the QRD identifies the
name of the master file in question. The "what data code value qual" of the
QRD identifies the primary key (or keys, or range of keys) defining the master
file MFE segments (and associated master file records, denoted by "Z..") to be
returned with the response. The QRF segment may be used to define time ranges,
particular MFN record-level event codes etc. Unless otherwise specified, the
response returns only active current record(s).
The following segments are defined for the master files messages.
The fields in the MFI segment are defined as follows:
Figure 8-1 MFI attributes
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
CE |
R |
N |
0175 |
00658 |
Master
file identifier |
8.4.1.0 MFI field definitions
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: a CE field that identifies a standard HL7 master file. This
table may be extended by local agreement during implementation to cover
site-specific master files (z-master files).
Value |
Description |
CDM |
Charge
description master file (see Chapter 6, Appendix) |
Definition: optional code of up to 6 characters which (if applicable)
uniquely identifies the application responsible for maintaining this file at a
particular site. A group of intercommunicating applications may use more than
a single instance of a master file of certain type (e.g., charge master or
physician master). The particular instance of the file is identified by this
field. Refer to user-defined table 0176 - master files application
identifier for suggested values.
Definition: defines file-level event code.
Value |
Description |
REP |
Replace
current version of this master file with the version contained in this
message |
Definition: time stamp for file-level event on originating system.
Definition: an optional effective date/time can be included for file-level
action specified. It is the date/time the originating system expects that the
event is to have been completed on the receiving system. If this field is not
present, the action date/time should default to the current date/time (when the
message is received).
Definition: these codes specify the application response level defined for a
given Master File Message at the MFE segment level as defined in table 0179
- response level. Required for MFN message. Specifies additional detail
(beyond MSH-15-accept acknowledgement type and MSH-16-application
acknowledgement type) for application level acknowledgement paradigms for
Master Files transactions. MSH-15 and MSH-16 operate as defined in Chapter
2.
Value |
Description |
NE |
Never.
no application level response needed |
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
3 |
ID |
R |
|
0180 |
00664 |
Record-level
event code |
8.4.2.0 MFE field definitions
Definition: defines record-level event for the master file record identified
by the MFI segment and the primary key field in this segment.
Value |
Description |
MAD |
Add
record to master file |
Definition: a number or other identifier that uniquely identifies this change
to this record from the point of view of the originating system. When returned
to the originating system via the MFA segment, this field allows the target
system to precisely identify which change to this record is being acknowledged.
It is only required if the MFI response level code requires responses at the
record level (any value other than NE). Note that this segment does not contain
a Set ID field. The MFE:2-MFN control ID implements a more general
concept than the Set ID. It takes the place of the SET ID in the MFE segment.
Definition: an optional effective date/time can be included for the
record-level action specified. It is the date/time the originating system
expects that the event is to have been completed on the receiving system. If
this field is not present, the effective date/time should default to the
current date/time (when the message is received).
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: uniquely identifies the record of the master file (identified in
the MFI segment) to be changed (as defined by the record-level event code).
The first component of this CE data field carries an optional subcomponent, the
application ID, that uniquely identifies the application responsible for
creating the primary key value. The application ID subcomponent can be used to
guarantee uniqueness of the primary key across multiple applications.
The repetition of the primary key permits the identification of an individual
component of a complex record as the object of the record-level event code.
This feature allows the Master Files protocol to be used for modifications of
single components of complex records.
The MFA segment contains the following fields:
SEQ |
LEN |
DT |
C |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
3 |
ID |
R |
|
0180 |
00664 |
Record-level
event code |
8.4.3.0 MFA field definitions
Definition: defines record-level event for the master file record identified
by the MFI segment and the primary key in this segment. Refer to HL7 table
0180 - record level event code.
Definition: a number or other identifier that uniquely identifies this change
to this record from the point of view of the originating system. This field
uniquely identifies the particular record (identified by the MFE segment) being
acknowledged by this MFA segment. When returned to the originating system via
the MFA segment, this field allows the target system to precisely identify
which change to this record is being acknowledged. It is only required if the
MFI response level code requires responses at the record level (any value other
than NE).
Definition: may be required or optional depending on the site specifications
for the given master file, master file event, and receiving facility.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: this field reports on the status of the requested update. Site
defined-table, specific to each master file being updated via this
transaction.
All such tables will have at least the following two return code values:
Value |
Description |
S |
Successful
posting of the record defined by the MFE segment |
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: uniquely identifies the record of the master file (identified in
the MFN segment) to be changed (as defined by the record-level event code).
The first component of this CE data field carries an optional subcomponent, the
application ID, that uniquely identifies the application responsible for
creating the primary key value. The application ID subcomponent can be used to
guarantee uniqueness of the primary key across multiple applications.
The repetition of the primary key permits the identification of an individual
component of a complex record as the object of the record-level event code.
This feature allows the Master Files protocol to be used for modifications of
single components of complex records.
This is an example of a proposed generic method of updating a standard HL7
table. This particular example shows two records being added to the HL7
religion table.
Note: A standard HL7 table segment can be constructed by defining two fields: a table entry field (as a CE field) and a display-sort-key field (a numeric field) as follows. |
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
CE |
R |
R |
xxxx |
Xxxxx |
HL7
table entry for table xxxx |
8.5.1.0 ZL7 field definitions
Components: <Hl7 code> ^ <text> ^ HL7 <HL7 table
number>
Definition: HL7 table values for identifier and text encoded as a CE data type.
Definition: used to specify a non-alphabetic ordering for display or print
versions of a standard HL7 table.
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2
MFI|0006^RELIGION^HL7|UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
In this case, the primary key contains all the data needed for this simple
table, so that the HL7 segment could be constructed with ONLY the single field,
"sort-key", rather than repeating the primary key value as we have done in this
example.
MFK, master file application acknowledgement, as original mode acknowledgement
of the HL7 message according to MFI Response Level Code of "AL".
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060546||MFK|MSGID99002|P|2.2
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7|UPD
MFA|MAD|199109051000|19910918060545|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910918060545|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2||AL|AL
MFI|0006^RELIGION^HL7|UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060545||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19911001080504||MFK|MSGID99502|P|2.2||AL|
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7|UPD
MFA|MAD|199109051000|19910918010040|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910918010040|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7ADT|UH|HL7LAB|CH|19911001080507||ACK|MSGID444|P|2.2
MSA|CA|MSGID5002
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2||AL|NE
MFI|0006^RELIGION^HL7|UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060545||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910919060545||MFD|MSGID99002|P|2.2|||AL
MFI|0006^RELIGION^HL7|UPD
MFA|MAD|199109051000|19910919020040|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910919020040|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7ADT|UH|HL7LAB|CH|19910919060546||ACK|MSGID444|P|2.2
MSA|CA|MSGID500
1. We are investigating a proposal for an OBX-like segment (name value pair)
for use by master files transactions.
2. We invite proposals for the specification of other HL7-wide master files
segments.
The staff (STF) and practitioner (PRA) segments can be used to transmit master
files information between systems. The STF segment provides general information
about personnel; the PRA segment provides detailed information for a staff
member who is also a health practitioner. Other segments may be defined to
follow the STF segment to provide additional detail information for a
particular type of staff member: the PRA segment is the first such segment.
When the STF and PRA segments are used in an MFN message, the abstract
definition is as follows:
MFN Master File Notification
Chapter
MSH Message Header
2
MFI Master File Identification 8
{MFE Master File Entry 8
STF Staff Identification 8
[PRA] Practitioner Detail 8
}
MFK Master File Acknowledgement
Chapter
MSH Message Header 2
MSA Acknowledgement 2
MFI Master File Identification 8
{ [MFA] } Master file ACK segment 8
When the STF and PRA segments are used in the MFR message, the part of the
message represented by:
{MFE
[Z..] }
is replaced by:
{MFE
STF
[PRA]
}
The STF segment can identify any personnel referenced by information systems.
These can be providers, staff, system users, and referring agents. In a
network environment, this segment can be used to define personnel to other
applications; for example, order entry clerks, insurance verification clerks,
admission clerks, as well as provider demographics. MFE-4-primary key
value is used to link all the segments pertaining to the same master file
entry. Therefore, in the MFE segment, MFE-4-primary key value must be
filled in. Other segments may follow the STF segment to provide data for a
particular type of staff member. The PRA segment (practitioner) is one such.
It may optionally follow the STF segment in order to add practitioner-specific
data. Other segments may be defined as needed.
The STF segment contains the following fields:
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
60 |
CE |
R |
|
|
00671 |
STF
- primary key value |
8.A.1.0 STF field definitions
Definition: must match MFE-4-primary key value to identify which entry
is being referenced.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: personnel identification code or institution user number, used by
institution to identify this person. Repeating field allows multiple ID codes
per person, with the type of ID code indicated in the third component of the
coded entry data type.
Definition: staff person's name.
Definition: code identifying what type of staff. Refer to user-defined
table 0182 - staff type. Values may include codes for staff,
practitioner (physician, nurse, therapist, etc.), referral agent or agency, etc.
Definition: staff person's sex. Refer to table 0001 - sex for valid
codes.
Defintion: staff member's date of birth.
Defintion: whether person is currently a valid staff member.
Value |
Description |
A |
Active
staff |
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: institution department to which this person reports or belongs.
Refer to user-defined table 0184 - department.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: hospital or ancillary service with which this staff person is
associated. Depends on intitution use.
Definition: This is a repeating field with a component for indicating which
phone number is which. The TN data type includes a last component which can be
used to indicate whether the preceding phone number is home, beeper, office,
FAX, or cellular. This last component can also contain times of day for which
the numbers are best used. The STF segment contains a separate field for
E-mail address (because it's not in TN format). It is recommended that the
last part of the TN, [C any text], start with a code from the table associated
below with STF-16-preferred method of contact, in order to indicate the
type of each phone number in this repeating field.
Office address and home address are represented by this repeating field.
Note that the last component of the AD data type indicates the address category.
Components: <date (TS)> ^ <institution name (CE)>
Definition: date when staff became active for an institution. Repeats. Note
that the CE component of this field uses the subcomponent character for its
delimiter.
Components: <date (TS)> ^ <institution name (CE)>
Definition: date when staff became active for an institution. Repeats. Note
that the CE component of this field uses the subcomponent character for its
delimiter.
The MFE-4-primary key value of the master file entry which corresponds
to the designated backup person for this staff person.
This is a separate field for contacting staff because it is not in the TN
format as the other contact phones are.
A one letter code that indicates which of multiple phone numbers is the
preferred method of contact for this person. Note that all values of this code
refer to this segment's phone field, except for the value "E", which refers to
the Email address field. If more than one phone number of the preferred type
exists in STF-10-phone, this field refers to the first such instance.
Value |
Description |
H |
Home
phone number |
The PRA segment adds detailed medical practitioner information to the
personnel identified by the STF segment. A PRA segment may optionally follow
an STF segment. A PRA segment must always have been preceded by a
corresponding STF segment.
The PRA segment contains the following fields:
SEQ |
LEN |
DT |
R/O |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
20 |
ST |
R |
|
|
00685 |
PRA
- primary key value |
8.A.2.0 PRA field definitions
Defintion: must match MFE-4-primary key value, to identify which entry is
being referenced.
Components: <identifier> ^ <text> ^ <name of coding
system> ^ <alternate identifier> ^ <alternate text> ^ <name
of alternate coding system>
Definition: name and/or code of a group of practitioner to which this
practitioner belongs.
Definition: category of practitioner. User-defined table 0186 -
practitioner category whose values may include codes for staff physician,
courtesy physician, resident, physician assistant, physical therapist,
psychiatrist, psychologist, pharmacist, registered nurse, licensed practical
nurse, licensed vocational nurse, nurse practitioner, etc.
Definition: how provider services are billed.
Value |
Description |
P |
Provider
does own billing |
Components: <specialty name (ST)> ^ <governing board (ST)> ^
<eligible or certified (ID)> ^ <date of certification (DT)>
Definition: repeating field made up of multiple components to record the
practitioner's specialties. The multiple components of each specialty are: (1)
specialty name or abbreviation, identifies provider's specialty, (2) name of
specialty governing board, (3) Eligible/Certified contains "E" or "C", (4)
certified date contains date of certification, if certified.
Components: <ID number (ST)> ^ <type of ID number (ID)> ^
<state/other qualifying info (ST)>
Definition: repeating field which lists this practitioner's license numbers
and other ID numbers. This is a field made up of the following components: (1)
the ID number, and (2) the type of number, and optionally (3) the state in
which it is valid, if relevant, or other qualifying information. It is
recommended that state qualifications use the two character U.S.P.O.
abbreviations. The practitioner ID number type (component 2) is a user-defined
table whose values may include codes for Universal Physician Identification
Number, Drug Enforcement Agency Number, State License Number, Medicare Number,
Medicaid Number, Labor and Industries Number, General Ledger Number, QA Number,
County Number, Training License Number, Tax ID Number, etc.
Components: <privilege (CE)> ^ <privilege class (CE)> ^
<expiration date (DT)> ^ <activation date (DT)>
Definition: institutional priveleges which this provider may exercise.
Depends upon insitutional needs. For example, admit, transfer, discharge,
place orders, verify orders, review results, etc. Can also be used for
privileges other than patient services. This is a repeating field, with each
privilege made up of the following components: (1) privilege; (2) privilege
class; (3) privilege expiration date, if any; and (4) privilege activation
date, if any. Note that the privilege and privilege class components are CE
data types, and thus they are encoded with the subcomponent delimiter (&)
rather than the component delimiter (^).
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2|||AL|NE
MFI|0004^DOCTOR^HL7|UPD|||AL
MFE|MAD|U2246|199110011230|PMF98123789182^^PLW
STF|PMF98123789182^^PLW|U2246^^PLW~111223333^^SSN|KILDARE^RICHARD^J^JR^DR^M.D.|P|M|
... 19511004|A|^ICU|^MED|(206)689-1999X345CO~ (206)283-3334CH~
... (206)689-1345X789CB|214 JOHNSON ST^SUITE 200^SEATTLE^
WA^98199^H~
... 3029 24TH AVE W^^SEATTLE, WA^98198^O |19890125^UMC&University
Medical
... Center&L01||PMF88123453334|74160.2326 @COMPUSERV.COM|B
PRA|PMF98123789182^^PLW|^KILDARE FAMILY PRACTICE|ST|I|OB/GYN^STATE BOARD OF
OBSTETRICS AND
... GYNECOLOGY^C^19790123|1234887609
^UPIN~1234987^CTY^MECOSTA~223987654^
... TAX~1234987757^DEA~
12394433879^MDD^CA|ADMIT&&ADT^MED&&L2^19941231~DISCH&&ADT^MED&&L2^19941231|
Acknowledgement
MFD 8-4
Master Files 8-1
Message
MFN 8-3
MFA 8-9
MFD 8-4
MFE 8-7
MFI 8-5
MFN 8-3
MFQ 8-5
PRA 8-17
Practitioner Master File Segments 8-13
Query
MFQ 8-5
Segments
MFA 8-9
MFE 8-7
MFI 8-5
PRA 8-17
STF 8-13
Staff master file segments 8-13
STF 8-13
Trigger Event
MFN 8-2