HealthCare Messaging System: Integrating UML and …opim.wharton.upenn.edu/~sok/sokpapers/1999-0/rotterdam-bled-june... · HealthCare Messaging System: Integrating UML and ... health

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



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: 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


(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))


5: directive(data_update(results(referral(patient#, referral_diagnosis))))

6: assertive(result(referral(patient#, referral_diagnosis)))


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#))


3: declarative(authorization(prescription(patient#, prescription)))

4: assertive(acknowledge(prescription(patient#, prescription)))

5: directive(data_update(prescription(patient#, prescription)))


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



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



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



Ordinary Verb: PayingSpeaker: sAddressee: aTheme: t

owing


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.

Documents

HealthCare Messaging System: Integrating UML and …opim.wharton.upenn.edu/~sok/sokpapers/1999-0/rotterdam-bled-june... · HealthCare Messaging System: Integrating UML and ... health