healthcare messaging system: integrating uml and...
TRANSCRIPT
HealthCare Messaging System:
Integrating UML and Speech Act Theory
Maggie [email protected]
University of PennsylvaniaDepartment of Systems Engineering
Varsha [email protected]
University of PennsylvaniaDepartment of Computer and Information Science
Annapurna [email protected] of Pennsylvania
Department of Operations and Information Management
May 24, 1999
File: OPIM950paper24.doc
HealthCare Messaging System1. Introduction
The 21st century is the century marked by computers and technology. There are
numerous advantages to the computerization of age-old techniques. One of the
mainstream applications is the computerization of the exchange of information between
businesses. An industry that can greatly reap benefits from this type of communication is
healthcare.
Hundreds of documents exchange hands between hospitals, patients, and insurance
companies every single day. These documents support transactions such as patient lab
work, referrals, and bill payment. This method of conducting transactions is extremely
inefficient because humans process the documents. In this paper, we offer a messaging
system to automate these transactions and, thus, speed up and increase the efficiency of
the process of providing health care and coverage to patients. We propose a messaging
scheme that can be interpreted by the computing facilities in hospitals, insurance
companies, pharmacies, clinics, and banks, that will achieve our goal of a paperless, yet,
extremely efficient market. To this end, we have incorporated the widely accepted Unified
Modeling Language and borrowed concepts from Speech Act Theory to develop a
HealthCare Messaging System.
Today, patients bear a disproportionate amount of the burden of ensuring that
completion and transmittal of forms. Thus, a system that is automated will reduce human
error, as well as relieve the burden that patients endure.
Presently, if a patient needs medical services, he goes to the hospital or clinic. At
the hospital, the patient has to fill out forms with the necessary details about his insurance
provider. If lab tests need to be conducted, he is given a slip for the required lab tests. He
must present this slip to the technician in the lab to take the tests. After the tests are
conducted, the laboratory results are handed back to the patient so that he can present it
to the doctor who is caring for him.
Sometimes, a doctor may refer the patient to another doctor, or perhaps, a
specialist. In this case, the primary care provider gives the patient documentation that
describes and authorizes a visit to a specialist. The patient delivers this documentation to
the specialist. In addition, he has to take a copy of his medical records to the specialist.
After his visit to the specialist he must return to the primary physician with the diagnosis
of the specialist. If any medicines need to be taken by a patient, the doctor (physician or
the specialist) provides him with yet another slip of paper, which he has to present at the
pharmacy in order to obtain the needed prescription.
Finally, to file a claim the patient has to collect documents from the hospital, the
clinic, and the pharmacy in order to get reimbursed by the insurance company. If even one
of the documents is missing or some information is missing from any document, the claim
patient. The figure above lists the many tasks that the patient engages in when he
participates in the health care system. Our goal is to improve the process of providing
health care by automating the document exchange process and eliminating the patient’s
role as a document carrier. Since everyone at some point in his or her life participates in
the health care industry, it will be a great accomplishment if we can achieve our goal.
In this paper, we propose a paperless messaging system that incorporates the
Unified Modeling Language and borrows concepts from Speech Act Theory. We
incorporate the class diagram, use case and sequence diagrams from UML to describe the
process of sending messages. We borrow four of the Speech Act Theory message types,
the assertive, the declarative, the directive and the requestive. We refer to a requestive as
a request in this paper. We first describe our message classification and the types of
Insurance Provider
Clinic
Pharmacy
• Delivers Prescriptions
#?!
• Files Claims
Hospital
• Gets Authorization Slip
• Gets Preliminary Diagnosis
• Delivers Lab Results
• Gets Prescriptions
• Pay sfor Care
• Gets Proof of Care
•Gets Proof of Care
•Gets Prescriptions
•Delivers Lab Results
•Delivers PreliminaryDiagnosis
•Updates Diagnosis
• DeliversAuthorization Slip
• Gets Results SlipLab
Retrieves, Transports,and Stores Authorizations
and FormsThe Patient
We believe our message system makes a key contribution to messaging because we
have incorporated two widely used theories, UML and SAT. Furthermore, as we will
demonstrate, our messaging system spans the set of possible messages and is structured to
facilitate code reuse and, therefore, it provides a basis for optimally creating new message
types. In addition, our message classification which we will detail in the next section,
provides a framework for easily expanding our message system.
2. Message Classification.
We draw on concepts from Speech Act Theory to design our message structure
because we believe that it is best suited to a flexible and compact messaging system. The
messages that we propose span the possible messages needed to support the typical
transactions that we describe in this paper. In addition, we believe that our structure is
expandable should new messages need to be developed. We chose Speech Act Theory in
favor of replicating an EDI-type system because EDI is by no means compact. In practice,
EDI has proved to be inflexible and inefficient. Moreover, an important feature of our
messaging system is that we will be able to accommodate new message needs easily. We
do not believe EDI would provide us with that flexibility.
Therefore, we propose to use four message types from Speech Act Theory (SAT)
and reduce the number of message types by categorizing them according to the
illocutionary forces developed by SAT. The four illocutionary forces we use are
The messages are shown in a tree-like structure to demonstrate that all of the
messages that we need are of the four proposed types. A directive is telling another
principal agent to do something. A Declarative, when stated by a recognized authority,
becomes a true statement. In contrast, an Assertive is a statement of purported fact. A
request is asking another principal agent to provide something.
Each leaf of the structure represents a message. The meaning of these messages
will become clear when they are detailed in the message section of this paper. For now, it
is important to note that the structure provides us with a means of categorizing messages.
PaymentMedicalRecord
Directive Request
Authorization
DataUpdate
Test
Lab
Prescription
Results
Referral
Invoice
Notification
Payment
Acknowledge
LabTestReferral
Result
Prescrip-tion
AssertiveDeclarative
Message
different messages. The four messages are two assertives, one declarative and one
directive. The directive referral message is a member of the results subclass which is in
turn a subclass of the data update. The two assertives are each members of the subclasses;
result, and acknowledge. The declarative is an authorization.
3. System Design using UML.
The Unified Modeling Language(UML) provides us with a means of
demonstrating that our messaging system spans the set of possible messages for our
Health Care Messaging system. We use the Rational Rose version of this language with
some slight modifications to develop and explain our system. We begin with the class
diagram and the use case diagram to depict the entire system and to discuss relationships
and transaction types. Then we provide examples of each use case through sequence
diagrams. Finally, we show details of how the messages are related to the sequence
diagrams. Along the way, we note that our system can be expanded easily due to the
structure of UML and our message design.
Class Diagram.
The class diagram depicted was not created in Rational Rose but is similar to one created
in UML. The diagram is useful because it shows all of the principal agents in our system
and with whom they communicate. Should a new agent be necessary in our system, say an
HMO which might differ significantly from a clinic, the new agent could be added with
appropriate linkages.
The agents inside the box are those that are part of the hospital for whom the
messaging system was created. The system relies heavily on a shared database and so the
database is included as a part of the diagram to emphasize its presence in the system. The
agents external to the system are representative of the agents which will communicate
HealthCare MessagingSystem
The Patient
Hospital
Lab
Physician
Clinic
Billing
Insurance Provider
Bank
Data Base
Pharmacy
based upon the information in the database for a particular patient. This design feature is
significant because it means that our system is open to all clinics, pharmacies, banks and
insurance providers. The database will also include the patient’s medical record. The
patient’s profile in the database will include his medical record, insurance provider,
pharmacy, and bank billing information. A unique patient ID number is the key to a
patient’s record.
Use Case Diagram.
The use case diagram enumerates the types of transactions that the principal agents
will engage in. Each circle in the diagram represents a transaction type. The four
transaction types that we modeled are a referral, a lab test, a prescription, and a bill
compilation. These are four representative transactions that a hospital routinely engages
in. Our system could easily be modified to include more transaction types by the addition
lab
bank
insurance provider
referral
lab test
bil l compilation
physician
pharmacy
prescription
clinic
the patient is referred. A lab test will involve a lab, of course. But either a physician or a
clinic may initiate the lab test. Similarly, a prescription may be prescribed by either a clinic
or a physician and will be filled by a pharmacy. The bill compilation involves the most
number of agents. This is because a clinic, a physician, or a pharmacy may initiate a bill.
Moreover, the payment of a bill may or may not be fully covered by an insurance provider.
Thus, the billing center must determine whether or not a bank must also be contacted to
pay the balance of a particular bill. We point out that our system only models the
messaging aspects of these processes. Therefore, the patient is not included. We assume
that the billing center has operations and compilation systems that determine how much
should be billed and to whom.
Sequence Diagram and Corresponding Messages
Sequence diagrams show the order in which messages are sent. We develop four
basic sequence diagrams for our healthcare system and show the corresponding messages
to complete a process. Each of these messages may be mapped to our message
classification figure discussed earlier. The basic sequence diagrams are payment, lab test,
referral, and prescription. Note that these may be reused with different principal agents.
For example, a clinic or a physician may authorize a prescription, but we only show the
sequence diagram for the physician. The class diagram may be used to interpret that these
sequence diagrams would be identical except for the initiator.
Payment.
We simplified our UML representation of our system by developing a separate
sequence diagram for the billing process which is shown in the figure. A physician, a
clinic or a pharmacy may initiate the process. Each of the three other sequence diagrams
Message: RequestIllocutionary Verb: Request-PaymentS: Billing CenterA: Insurance Provider/BankTheme: PaymentSake: Service IDOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit: USDQuantity: float
Message: AssertiveIllocutionary Verb: Assert-Notification-PaymentS: Insurance Provider/BankA: Billing CenterTheme: PaymentSake: request-paymentOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit:USDQuantity: float
Message: RequestIllocutionary Verb: Request-PaymentS: Billing CenterA: Insurance Provider/BankTheme: PaymentSake: Service IDOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit: USDQuantity: float
Message: AssertiveIllocutionary Verb: Assert-Notification-PaymentS: Insurance Provider/BankA: Billing CenterTheme: PaymentSake: request-paymentOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit:USDQuantity: float
billing center insurance provider
bank
1: request(payment(serviceID))
2: assertive(notification(payment(serviceID)))
3: request(payment(serviceID))
4: assertive(notfication(payment(serviceID)))
The fields in parenthesis are the data that must be transferred for the insurance provider to
process the message. We assume that a database which is keyed by the patient ID#
contains standard information for a particular patient that the provider can access to
process the payment request. This information would include such things as the patient’s
type of plan, what is covered, or not covered, etc. We also assume that the insurance
company has an internal process for processing claims. These are not detailed in our
diagrams because our intent is only to model external messaging.
Next the insurance company sends back a notification of a payment in the form of
an assertive to the billing center. Because this may or may not be for the full amount, the
billing center sends a request to the patient’s bank to request the balance of the amount
due. Again, we assume that the billing center has an internal operation that calculates the
balance due and has a database that tells it where to address the request for balance. The
bank sends an assertive notifying the billing center that the balance is paid and our process
is complete.
The messages to the left of our sequence diagram are the messages that
correspond to each arrow in the diagram. They are presented in the same order as the
messages are depicted in the sequence diagram. We show them here to illustrate this one-
to-one correspondence. The details of the messages are discussed in the section titled,
“Message Structure.”
Lab Test.
We include the typical messaging that supports both a visit to the primary care
physician and a lab test in one use case because lab tests are frequently required for
routine visits. In our system, the physician request’s the patient’s medical record prior to
evaluating the patient. The database provides the medical record to the physician as an
assertive. That is the patient’s medical history is a statement of fact. The physician may
request the lab to perform tests. He includes the patient# and type of test as part of his
request. Types of tests are included in Appendix A. The lab acknowledges the request
Message: RequestIllocutionary Verb: Request-Medical RecordS: Clinic/PhysicianA: DatabaseTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: AssertiveIllocutionary Verb: Assert-Medical RecordS: DatabaseA: Clinic/PhysicianTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: DirectiveIllocutionary Verb: Direct-TestS: Clinic/PhysicianA: LabTheme: AdministeringOrdinary Verb: AdministerTheme: Lab TestType: Appendix ASake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-AcknowledgeS: LabA: Clinic/PhysicianTheme: AdministerOrdinary Verb: AdministerTheme: Lab TestType: Appendix ASake: Patient ID
(Messages continued)
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: LabA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: Appendix ASake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Results-Lab_ResultsS: LabA: Clinic/PhysicianTheme: ReportOrdinary Verb: ReportingTheme: Test ResultsType: Appendix ASake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Notification-BillingS: Physician/Clinic/PharmacyA: Billing CenterTheme: OweSake: Service IDOrdinary Verb: OwingTheme: MoneyUnit: USDQuantity: floatSake: Patient ID
physician lab database billing center
1: request(medical_record(patient#))
2: assertive(medical_record(patient#, patient_profile))
3: directive(test(lab_test(patient#, test)))
4: assertive(acknowledge(lab_test(lab_test#)))
5: directive(data_update(results(lab_result(patient#, test, lab_test#, lab_diagnosis))))
6: assertive(result(lab_result(patient#, test, lab_test#, lab_diagnosis)))
7: assertive(notification(billing(patient#, serviceID)))
directive to the database is an order to update the patient’s record. It is telling the
database to do something. The assertive to the physician is conveying facts, the results of
the tests. Finally, the physician notifies the billing center of services rendered to the
patient in the form of an assertive.
Referral.
The physician declares that the patient is authorized to visit a clinic because we
assume that the insurance provider requires authorization from a primary care physician to
reimburse the patient. The referral_id is selected by the physician and indicates which
Message: DeclarativeIllocutionary Verb: Declarative-Authorize-ReferralS: PhysicianA: ClinicTheme: ExaminingSake: Patient IDOrdinary Verb: ExamineTheme: ReferralType: Appendix BSake: Declarative-Authorize-Referral
Message: AssertiveIllocutionary Verb: Assert-Acknowledge-ReferralS: ClinicA: PhysicianTheme: ExaminingSake: Declarative-Authorize-ReferralOrdinary Verb: ExamineTheme: ReferralType: Appendix BSake: Patient ID
Message: RequestIllocutionary Verb: Request-Medical RecordS: Clinic/PhysicianA: DatabaseTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: AssertiveIllocutionary Verb: Assert-Medical RecordS: DatabaseA: Clinic/PhysicianTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: ClinicA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: Appendix BSake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Results-Referral_ResultsS: ClinicA: PhysicianTheme: ReportOrdinary Verb: ReportingTheme: Referral ResultsType: Appendix BSake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Notification-BillingS: Physician/Clinic/PharmacyA: Billing CenterTheme: OweSake: Service IDOrdinary Verb: OwingTheme: MoneyUnit: USDQuantity: floatSake: Patient ID
(messages continued)
physician database clinic billing center
1: declarative(authorization(referral(patient#, referral_id)))
2: assertive(acknowledge(referral(patient#, referral_id)))
3: request(medical_record(patient#, patient_profile))
4: assertive(medical_record(patient#, patient_profile))
5: directive(data_update(results(referral(patient#, referral_diagnosis))))
6: assertive(result(referral(patient#, referral_diagnosis)))
7: assertive(notification(billing(patient#, serviceID)))
results of the referral. Subsequently, the clinic notifies the billing center of the patient’s
charges in the form of an assertive.
Prescription.
Prescriptions are also a routine transaction as a consequence of a visit to a
primary care physician or a specialist. We show the diagram for the physician and note
that the clinic may also initiate a prescription. Before prescribing a medication, the
Message: RequestIllocutionary Verb: Request-Medical RecordS: Clinic/PhysicianA: DatabaseTheme: DeliverySake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordMode: (Delivery, Electronic)Sake: Request-Medical Record
Message: AssertiveIllocutionary Verb: Assert-Medical RecordS: DatabaseA: Clinic/PhysicianTheme: DeliverySake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordMode: (Delivery, Electronic)Sake: Request-Medical Record
Message: DeclarativeIllocutionary Verb: Declarative-Authorize-PrescriptionS: Clinic/PhysicianA: PharmacyTheme: FillingSake: Patient IDOrdinary Verb: FillTheme: PrescriptionDrug: Medicine IDSake: Declarative-Authorize-Prescription
Message: AssertiveIllocutionary Verb: Assert-Acknowledge-PrescriptionS: PharmacyA: Clinic/PhysicianTheme: FillingOrdinary Verb: FillTheme: PrescriptionDrug: Medicine IDSake: Patient ID
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: PharmacyA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: DrugSake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Notification-BillingS: Physician/Clinic/PharmacyA: Billing CenterTheme: OweSake: PrescriptionOrdinary Verb: OwingTheme: MoneyUnit: USDQuantity: floatSake: Patient ID
(messages continued)
physician database pharmacy billing center
1: request(medical_record(patient#))
2: assertive(medical_record(patient#, patient_profile))
3: declarative(authorization(prescription(patient#, prescription)))
4: assertive(acknowledge(prescription(patient#, prescription)))
5: directive(data_update(prescription(patient#, prescription)))
6: assertive(notification(billing(patient#, serviceID)))
4. Message Structure.
As mentioned earlier, we have used four illocutionary forces of Speech Act Theory
in our message structure. The four being: directives which order a principal agent to do
something, assertives which present the world as it is, declaratives which when stated by
an appropriate authority makes the statement true and requests which ask a principal agent
to do something.
The messages are divided into classes and sub-classes. Each of the illocutionary
forces is a main class with a number of sub-classes attached to it. Each leaf node is a
message. In our implementation of this system each sub-class will be processed in a similar
way as its siblings. In other words, the other sub-classes that share a common parent will
also share some amount of generic code that can be replicated, thus leading to an efficient
and manageable health-care system.
The diagram at the top of the next page shows how a generic message in a
sequence diagram translates to the actual representation of a message. The base of the
arrow on the sequence diagram(figure at right) indicates the speaker and it points to the
addressee. The formula for the message is on the arrow. The formula is translated to the
message (figure at left).
some amount of generic code that can be replicated, thus leading to an efficient and
manageable health-care system.
The diagram below shows a generic message.
The first line of the message corresponds to one of our four illocutionary forces.
The illocutionary verb of the message is based on the message classification scheme
presented earlier. Next the principal agents involved in the message are the speaker and
the addressee. The speaker of the message is the initiator of the speech act. The agent is
the initiator of the action. The ordinary verb is the act associated with the illocutionary
force. It is necessary to have the theme in both the blocks of the message because the
theme in the first block is related to the ordinary verb or the act associated with the
message, whereas the theme in the second block is the direct object of the ordinary verb.
The theme is followed by the sake of the message which is defined as “Event x is done for
Message: Illocutionary ForceIllocutionary Verb:S: SpeakerA: AddresseeTheme:Ordinary Verb:Theme:Sake:Qualifier1:Qualifier:
qualifiers such as Unit, and Quantity to make the message more specific for better
comprehension.
The table below summarizes all the components of Speech Act Theory and their
standard roles that we have incorporated in our messaging system. We have divided them
into two dimensions. The first dimension is the degree of specificity. We place the role
under generic if it is applicable over a wide range of message systems. If it is more specific
to our system, we place it in the specific column. The second dimension is categorized
into: Nouns, Illocutionary Verbs, Ordinary Verbs, Thematic roles, and Other. Nouns are
mainly specific to our system such as the name of the patient. The Illocutionary verbs can
either be generic or specific. And we have classified each specific illocutionary verb into
Generic SpecificNouns Patient ID
Lab Test IDService IDAppendix A (lab test types)Appendix B (referral)
Illocutionary Verbs Assertive
Declarative
Directive
Request
NotificationResultsAcknowledgementDeliver Medical RecordAuthorization
Data UpdateAdminister Test
PaymentDeliver Medical Record
Ordinary Verbs OwingPayingDeliveringExaminingAdministeringUpdatingReportingFilling
Thematic Roles SpeakerThemeAddresseeAgentBeneficiary
Other SakeQuantityTypeUnit
USDfloat
are in some way related to the message. The other category contains all the qualifiers
needed to elaborate on the message.
5. Code reusability and expansion.
We organize our messages based upon their ordinary verb, to demonstrate the
main principles of code-reuse and expansion for our system. Each ordinary verb forms a
parent class with a number of sub-classes, irrespective of which illocutionary force the
sub-class message falls under. The diagrams for each ordinary verb are included in
Appendix C. We show the diagram for the ordinary verb deliver below.
The ordinary verb deliver is a theme for both a request for a delivery andfor an assertion that a delivery is complete. Example 2. on the next pagediscusses how a Directive might be added.
Our message system can be expanded in three important ways. First, the messages
Message: RequestIllocutionary Verb: Request-Medical RecordS: Clinic/PhysicianA: DatabaseTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: AssertiveIllocutionary Verb: Assert-Medical RecordS: DatabaseA: Clinic/PhysicianTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Ordinary Verb: DeliverSpeaker: sAddressee: aTheme: t
amount of code. The third way we can accommodate changes in our message system is by
expanding the possible qualifiers in our messages.
Below we discuss a few specific examples in which code could be re-used to expand
our message system:
1. Currently, our message system includes two types of messages for the ordinary verb,
Deliver, an assertive and a request. If the physician wants to have a patient’s medical
records delivered to another physician for an evaluation, we may need to add a
directive under Deliver. This new message would direct the database to deliver the
medical record to the second physician. Once this new message is classified under the
parent class Deliver, our system will know how to process it because a large chunk of
the code is similar across the sub-classes because the common theme of the messages
is deliver. Only small pieces of the code will differ across the sub-classes depending on
the type of illocutionary force. And to update this part of the code will be pretty
simple.
2. We are already re-using code in yet another way in our system. The message
pertaining to the billing center requesting payment from the insurance provider is the
same as the message in which the billing center requests a payment from the bank.
Instead of creating two messages, we detected the similarity between the two
messages and created only one message. The only difference is the addressee of the
would have to create many more new message types for this new type of transaction.
But with our implementation, we can reuse messages already created. All the messages
that the physician uses to communicate with the clinic can be used by the first clinic to
communicate with a second clinic. We only need to replace the physician as the
speaker and the addressee by the first clinic.
Next, we discuss how we could accommodate changes in our message system by
expanding the set of possible qualifiers. In our message system, we have included lab tests
and referral types as potential entries in our messages. Incorporating a new lab test or
referral type is as easy as adding them to the list of possible entries in appendices A and B.
This is representative of the third important way we can accommodate changes to our
messaging system.
6. Conclusions.
We have presented a message system that incorporates the structure of UML and
concepts from Speech Act theory. The system is compact and spans the possible
messages that might be sent for the four typical transactions that we have discussed. We
believe that the system can be expanded easily in several important ways. The modeling
structure of UML allows us to modify the structure of our system. Specifically, new
We believe the use of UML and Speech Act Theory together in a messaging
system for business to business communication is significant. Our system is superior to
current practices using EDI because it is compact, flexible and expandable. Furthermore,
the integration of UML and Speech Act Theory is ideal because both UML and Speech
Act Theory are widely used, accepted and understood. Therefore, we believe that the
system we have described can be built and that users could easily understand and use it.
Moreover, our concept of code reuse will enable users to update and change their system
cheaply.
Appendix A
Lab Test Entries
The following lab test entries were transcribed from a lab test form from the Hospital of
the University of Pennsylvania.
Lab testsNA () SodiumP () PotasiumCL () ChlorideCO2 () CO2 contentGLU () Glu/FAsting/RandomN () Bld Urea NitrogenCRE () CreatinineCA () CalciumPHO () PhosphateURA () Uric AcidALB () AlbuminP () Total ProteinALT () ALT/SGPTAST () AST/SGDTGT () Gamma GTALK () ALkaline PhosTBIL () Total BilirubinDBIL () DIrect BilirubinCHOL () CholestoralTRIG () TriglyceridesHDL () HDL CholesterolFE () IronTRNSFRN () TransferrinAMY () AmylaseHBA1C () Hemoglobin AICFERR () FerritinANA () Anti Nuclear AbT3 () T3T4 () T4 T3U FTITSH () TSHRUB () RubellaMEAS-IGG () Rubeola Titer/IGGMUMPS () Mumps IgG Immune StatusRPR () RPRLYME () Lyme EIA Titer
HCB () Quantitative HCBCPT () Protime/INR, Coudamin y/n Heparin y/nCPTT () APTT Coumadin y/n
Heparin y/nUADIP () Urine dip dispaly onlyUA () Urinalysis/Diff
Appendix B
Referral Entries
The following referral form entries were transcribed from a referral form from the Hospital
of the University of Pennsylvania.
Problems
(01) Abdominal pain 789.0(02) Allergic Rhinitis 477.9(03) Allergy (to include alergy injection) 995.3(04) Anxiety 300.0(05) Arthritis 716.9(06) Asthma 493.9(07) Bronchitis, acute 466.0(08) Bursitis, Tenosynovitis, Tendonitis 727.3(09) Chest pain 786.5(10) Conjunctivitis 372.3(11) Contact Dermatitis 692.9(12) Coronary Arthery Disease 414.9(13) Depression 311.0(14) Diabetes 250.0(15) Fatigue/Tiredness/Malaise 780.7(16) Gastroenteritis 558.9(17) Headache 784.0(18) Hyperlipidemia 272.4(19) Hypertension(NOS) 401.9(20) Lower back pain 724.2(21) Medical exam no disease detected V70.9(22) Obesity 278.0(23) Otitis media 382.9(24) Pharyngitis 462.0(25) Pneumonia 486.0(26) Pregnancy V22.2(27) Refractive errors 367.9(28) Sinusitis, acute & chronic 473.9(29) Tonsilitis 463.0(30) Upper Respiratory Infection 465.9(31) Urinary Tract Infection 599.0(32) Vaginitis 616.1(33) Viral Syndrome 079.9(34) Contusion 924.9 of: ___________________(35) Laceration 998.2 of: _____________________(36) Strain 848.9 of: __________________
Stress Test:(04) Regular(05) Thallium
(06) Holter MonitorEchocardiogram:(07) 2-D(08) M Mode[Peds Only]
ENT(09) Audiogram(10) Tympanometry(11) Insert P E tubes(12) Laryngoscopy
EYECARE(13) Routine exam(14) Visual fields
GI(15) Gastroscopy(16) Colonoscopy(17) Sigmoidoscopy
GU(18) Cystoscopy
MENTAL HEALTH(19) Ongoing care
NEUROLOGY(20) EEG(21) Emg/Nerve conduct.
OB/GYN(22) Pregnancy(23) Colposcopy(24) Infertility
ORTHOPEDICS(25) Fracture care(26) Arthroscopy
PULMONARY(27) Spirometry/PFT
Appendix C.
Ordinary Verb Diagrams
deliver
Message: RequestIllocutionary Verb: Request-Medical RecordS: Clinic/PhysicianA: DatabaseTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Message: AssertiveIllocutionary Verb: Assert-Medical RecordS: DatabaseA: Clinic/PhysicianTheme: DeliveryMode: (Delivery, Electronic)Sake: Patient IDOrdinary Verb: DeliverTheme: Medical RecordSake: Request-Medical Record
Ordinary Verb: DeliverSpeaker: sAddressee: aTheme: t
examine
Message: DeclarativeIllocutionary Verb: Declarative-Authorize-ReferralS: PhysicianA: ClinicTheme: ExaminingSake: Patient IDOrdinary Verb: ExamineTheme: ReferralType: Appendix BSake: Declarative-Authorize-Referral
Message: AssertiveIllocutionary Verb: Assert-Acknowledge-ReferralS: ClinicA: PhysicianTheme: ExaminingSake: Declarative-Authorize-ReferralOrdinary Verb: ExamineTheme: ReferralType: Appendix BSake: Patient ID
Ordinary Verb: ExamineSpeaker: sAddressee: aTheme: t
Filling
Message: DeclarativeIllocutionary Verb: Declarative-Authorize-PrescriptionS: Clinic/PhysicianA: PharmacyTheme: FillingSake: Patient IDOrdinary Verb: FillTheme: PrescriptionDrug: Medicine IDSake: Declarative-Authorize-Prescription
Message: AssertiveIllocutionary Verb: Assert-Acknowledge-PrescriptionS: PharmacyA: Clinic/PhysicianTheme: FillingOrdinary Verb: FillTheme: PrescriptionDrug: Medicine IDSake: Patient ID
Ordinary Verb: FillingSpeaker: sAddressee: aTheme: t
Ordinary Verb: AdministerSpeaker: sAddressee: aTheme: t
Paying
Message: RequestIllocutionary Verb: Request-PaymentS: Billing CenterA: Insurance Provider/BankTheme: PaymentSake: Service IDOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit: USDQuantity: float
Message: AssertiveIllocutionary Verb: Assert-Notification-PaymentS: Insurance Provider/BankA: Billing CenterTheme: PaymentSake: request-paymentOrdinary Verb: PayingAgent: Insurance Provider/BankBeneficiary: Billing CenterTheme: MoneyUnit:USDQuantity: float
Ordinary Verb: PayingSpeaker: sAddressee: aTheme: t
owing
Message: AssertiveIllocutionary Verb: Assert-Notification-BillingS: Physician/Clinic/PharmacyA: Billing CenterTheme: OweSake: Service IDOrdinary Verb: OwingTheme: MoneyUnit: USDQuantity: floatSake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Notification-BillingS: Physician/Clinic/PharmacyA: Billing CenterTheme: OweSake: PrescriptionOrdinary Verb: OwingTheme: MoneyUnit: USDQuantity: floatSake: Patient ID
Ordinary Verb: OwingSpeaker: sAddressee: aTheme: t
Reporting
Message: AssertiveIllocutionary Verb: Assert-Results-Lab_ResultsS: LabA: Clinic/PhysicianTheme: ReportOrdinary Verb: ReportingTheme: Test ResultsType: Appendix ASake: Patient ID
Message: AssertiveIllocutionary Verb: Assert-Results-Referral_ResultsS: ClinicA: PhysicianTheme: ReportOrdinary Verb: ReportingTheme: Referral ResultsType: Appendix BSake: Patient ID
Ordinary Verb: ReportingSpeaker: sAddressee: aTheme: t
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: LabA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: Appendix ASake: Patient ID
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: PharmacyA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: DrugSake: Patient ID
Message: DirectiveIllocutionary Verb: Direct-Data_UpdateS: ClinicA: DatabaseTheme: UpdateOrdinary Verb: UpdatingTheme: Medical RecordType: Appendix BSake: Patient ID
Ordinary Verb: UpdatingSpeaker: sAddressee: aTheme: t
References
S.O. Kimbrough, Formal Language for Business Communication(FLBC): Sketch of aBasic Theory, Manuscript, September 30,1998.
S.O. Kimbrough and S.A. Moore, “On the Spanning Hypothesis for EDI Semantics,”September 30, 1998.
S.A. Moore, “Categorizing automated messages”, Decision Support Systems,forthcoming.
J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language ReferenceManual, Addison-Wesley, Berkley, California.