4.1 White Box Use Cases
4.1.1 Use Case Description – Register Service
Register Service
Author (s): T. Omen Date: 11/26/10
Version: 1.00
Use Case Name: Register Service Use Case Type Business Requirements: ☐ System Analysis: ☑
Use Case ID: UC_EHR_009
Priority: High
Source: SOA Approach to Electronic Health Records Primary Business
Actor:
Service Provider (SP) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component.
Primary System Actor:
Enterprise Service Bus (ESB)
Other Participating Actors:
None
Other Interested Stakeholders:
None
Description: This use case describes the event of a Service Provider (SP) (e.g. Health care provider software entity) registering itself as a service provider with the Enterprise Service Bus (ESB). All SPs must be
registered with the ESB in order to have service requests properly routed. Upon registration with the ESB, the SP is then considered “live” and available for service requests from a service consumer (e.g.
an Insurance Provider).
Precondition: The SP must have off-the-shelf software that implements the one or more service interfaces.
Trigger: This use case is triggered when a service provider is added to the EHR system for the first time.
Typical Course of Events:
Actor Action System Response
31
4.1.2 Use Case Description – Invoke Service
Step 1: The SP calls the
registration service of the ESB and properly identifies itself as a Healthcare Provider, Insurance Provider, or Pharmacy.
Step 4: The SP processes successful response.
Step 2: The ESB responds by adding the SP to applicable service provider lists. For example, a SP registering as a “Healthcare Provider” will include service interfaces for patient medical history, patient payment, patient personal information, and patient prescription.
Step 3: The ESB responds by returning a Boolean indicating
“True” that the registration was successful.
Alternate Courses: Step 3a: The ESB fails to register the SP and returns a Boolean indicating “False”.
Step 4b: The SP reattempts registration. Go to Step 1.
Conclusion: This use-case concludes when the SP is successfully registered with the ESB.
Postcondition: The SP is registered and available for service requests.
Business Rules: None Implementation
Constraints and Specifications:
None
Assumptions: ● The SP can re-attempt registration if failure occurs.
Open Issues: None
Use Case ID: UC_EHR_010
Priority: High
Source: SOA Approach to Electronic Health Records Primary Business
Actor:
Service Consumer (SC) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component. For this use-case, an insurance provider plays the role of the SC.
Primary System Actor:
Enterprise Service Bus (ESB)
Other Participating Actors:
Service Providers (SP) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component. For this use-case, the service provider roles are played by Healthcare providers.
Other Interested Stakeholders:
None
32
4.1.3 Use Case Description – Data Confidentiality
Description: This use case describes the event of a Service Consumer (SC) (e.g. Insurance Provider requesting payment information) requesting a service be invoked. The SC contacts the Enterprise Service Bus (ESB) with its service request. The ESB iterates through each Service Provider (SP) and requests a service. The ESB then returns each SP response.
Precondition: The SP/SC have been registered with the ESB.
Trigger: This use case is triggered when a service consumer requests any service.
Typical Course of Events:
SC Actor Action System Response SP Actor Action
Step 1: The Insurance provider requests payment information for the patient with social security number 111-11-1111.
Step 6: The SP receives the payment information and processes it accordingly.
Step 2: The ESB responds with a
“True” Boolean indicating it has successfully requested the service.
Step 3: The ESB responds by iterating through each payment service provider and requesting payment information.
Step 5: The ESB forwards the SP response to the SC.
Step 4: The Healthcare Provider returns an asynchronous message indicating the payment information including insurance information, medical services rendered, and the total cost.
Alternate Courses: Step 2a: The ESB has no SP registered for payment information and returns a “False” Boolean since there are no service providers for that given service.
Conclusion: This use-case concludes when the SC has received one or more service responses from the ESB.
Postcondition: The SC has successfully received one or more service responses.
Business Rules: None Implementation
Constraints and Specifications:
None
Assumptions: ● The SP can re-attempt service request if failure occurs.
Open Issues: None
Use Case ID: UC_EHR_011
Priority: High
33 Source: SOA Approach to Electronic Health Records
Primary Business Actor:
Service Consumer (SC) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component. For this use-case, an insurance provider plays the role of the SC.
Primary System Actor:
Enterprise Service Bus (ESB)
Other Participating Actors:
Service Providers (SP) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component. For this use-case, the service provider roles are played by Healthcare providers.
Other Interested Stakeholders:
None
Description: This use case describes the event of a Service Consumer (SC) (e.g. Insurance Provider requesting payment information) requesting a service be invoked. The SC encrypts the contents of its service request (e.g. social security number (SSN)) and then contacts the Enterprise Service Bus (ESB) with its service request. The ESB iterates through each Service Provider (SP) and forwards the service request. The Service Provider receives the message and decrypts its contents. The SP encrypts the contents of its response and sends it to the ESB. The ESB forwards the response to the SC.
Precondition: The SP/SC have been registered with the ESB.
Trigger: This use case is triggered when a service consumer requests any service.
Typical Course of Events:
SC Actor Action System Response SP Actor Action
Step 1: The Insurance provider encrypts the contents of its service request (i.e. encrypts patient SSN).
Step 2: The Insurance provider requests payment information for the patient.
Step 6: The Insurance provider receives the payment information and decrypts the contents.
Step 7: The Insurance provider uses the payment information accordingly.
Step 3: The ESB responds with a
“True” Boolean indicating it has successfully requested the service.
Step 4: The ESB responds by iterating through each payment service provider and requesting payment information.
Step 5: The ESB forwards the healthcare provider response to the insurance provider.
Step 4: The Healthcare Provider decrypts the contents of the message and searches for payment information related to patient with the given SSN.
Step 5: The Healthcare provider encrypts the
response message and returns it to the ESB asynchronously.
Alternate Courses: Step 2a: The ESB has no SP registered for payment information and returns a “False” Boolean since there are no service providers for that given service.
Conclusion: This use-case concludes when the SC has decrypted the contents of one or more service responses.
Postcondition: The SC has successfully decrypted one or more service responses.
Business Rules: None Implementation
Constraints and Specifications:
None
Assumptions: ● The SP can re-attempt service request if failure occurs.
Open Issues: None
34 4.2 STATIC VIEWS
This section describes the service interfaces, message types, and entities. The diagrams read much like a UML class diagram. All method descriptions and attribute descriptions can be found in the appendix.
4.2.1 Service Interface View
The service interface view presents the service contracts discussed in the architecture section in greater detail
*11+. Here we also begin to see the “Message types” which “specify the information [that] is exchanged between service consumers and providers [11]. The services shown below all require a unique identifier in order to properly identify the correct patient. In this case, the social security number of the patient is used. This sensitive value is encrypted with XML-ENC during transport.
Figure 13 Service Interfaces
4.2.2 Healthcare Provider View
soaml Serv ice Interface View
«serviceInterface»
ManagePatientMedicalHistory
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
«messageType»
MedicalHistory
+ examResults: String + allergies: String + diagnoses: String
«serviceInterface»
ManagePatientPayment + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPersonalInformation + providePatientPersonalInfo(patientInfo :PatientInformation) : void
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPrescription + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«messageType»
Prescription
+ drugType: DrugType + doctorID: int + dateIssued: int + drugQuantity: int
DrugType + phoneNumber: String
«messageType»
PaymentInformation
+ insuranceInfo: InsuranceProvider + medicalServices: String + totalCost: double
InsuranceProv ider + name: String + insuranceID: int
35 Figure 14 Healthcare Provider View
The Healthcare Provider entity must implement service interfaces in order to be a provider of its applicable services (e.g. ManagePatientPayment, ManagePatientMedicalHistory, etc). The entity also includes an attribute
“TYPE” which specifies the type of service provider it is. This attribute is used for registration with the ESB.
4.2.3 Insurance Provider View
soaml HealthCareProv ider View
«entity»
HealthCareProv ider - TYPE: ServiceProviderID = HEALTHCARE {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage
+ providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientMedicalHistory(medHistory :MedicalHistory) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + providePatientPrescription(prescription :Prescription) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
+ queryPatientPaymentInfo(socialSecurityNum :int) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientMedicalHistory
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPayment + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPersonalInformation + providePatientPersonalInfo(patientInfo :PatientInformation) : void
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPrescription + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«entity»
Serv iceProv iderID
+ PHARMACY: ServiceProviderID {readOnly}
+ HEALTHCARE: ServiceProviderID {readOnly}
+ INSURANCE: ServiceProviderID {readOnly}
36 Figure 15 Insurance Provider View
The Insurance Provider entity must implement service interfaces in order to be a provider its applicable services (e.g. ManagePatientPayment, ManagePatientMedicalHistory, etc). The entity also includes an attribute “TYPE”
which specifies the type of service provider it is. This attribute is used for registration with the ESB.
4.2.4 Pharmacy View
soaml InsuranceProv ider View
«serviceInterface»
ManagePatientMedicalHistory
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPayment + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPersonalInformation + providePatientPersonalInfo(patientInfo :PatientInformation) : void
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«entity»
InsuranceProv ider - TYPE: ServiceProviderID = INSURANCE {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage + providePatientMedicalHistory(medHistory :MedicalHistory) : void + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
+ queryPatientPaymentInfo(socialSecurityNum :int) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«entity»
Serv iceProv iderID
+ PHARMACY: ServiceProviderID {readOnly}
+ HEALTHCARE: ServiceProviderID {readOnly}
+ INSURANCE: ServiceProviderID {readOnly}
37 Figure 16 Pharmacy View
The pharmacy entity must implement service interfaces in order to be a provider of its applicable services (e.g.
ManagePatientPayment, ManagePatientMedicalHistory, etc). The entity also includes an attribute “TYPE” which specifies the type of service provider it is. This attribute is used for registration with the ESB.
4.2.5 ESBRouter View
soaml Pharmacy View
«serviceInterface»
ManagePatientPayment + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPersonalInformation + providePatientPersonalInfo(patientInfo :PatientInformation) : void
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«entity»
Pharmacy - TYPE: ServiceProviderID = PHARAMCY {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage
+ providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + providePatientPrescription(prescription :Prescription) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
+ queryPatientPersonalInfo(socialSecurityNum :int) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPrescription + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«entity»
Serv iceProv iderID
+ PHARMACY: ServiceProviderID {readOnly}
+ HEALTHCARE: ServiceProviderID {readOnly}
+ INSURANCE: ServiceProviderID {readOnly}
38 Figure 17 ESBRouter View
The ESBRouter implements all service interfaces in order to be able to properly route all service requests.
soaml ESBRouter View
«entity»
ESBRouter - paymentServices: List <ManagePatientPayment>
- medHistoryServices: List <ManagePatientMedicalHistory>
- prescriptionServices: List <ManagePatientPrescription>
- personalInfoServices: List <ManagePatientPersonalInformation>
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void + providePatientPaymentInfo(paymentInfo :PatientInformation) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
+ queryPatientPaymentInfo(socialSecurityNum :int) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean + registerServiceProvider(type :ServiceProviderID) : boolean
- registerMedicalHistoryProvider(provider :ManagePatientMedicalHistory) : void - registerPersonalInfoProvider(provider :ManagePatientPersonalInformation) : void - registerPaymentProvider(provider :ManagePatientPayment) : void
- registerPrescriptionProvider(provider :ManagePatientPrescription) : void
«serviceInterface»
ManagePatientMedicalHistory
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPayment + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPersonalInformation + providePatientPersonalInfo(patientInfo :PatientInformation) : void
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«serviceInterface»
ManagePatientPrescription + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«entity»
Serv iceProv iderID
+ PHARMACY: ServiceProviderID {readOnly}
+ HEALTHCARE: ServiceProviderID {readOnly}
+ INSURANCE: ServiceProviderID {readOnly}
39
4.2.6 Data Confidentiality Pattern
The data confidentiality pattern works by encrypting the contents of the message, in this case via XML-ENC, such that the contents of the message are not decipherable by any intermediary service. Only the intended end service is able to decrypt the message [3].
Figure 18 Data Confidentiality View soaml Data Confidentiality View
«serviceInterface»
Security
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
«messageType»
SecureMessage + secureXML: String
«messageType»
UnsecureMessage + unsecureXML: String
«entity»
InsuranceProvider - TYPE: ServiceProviderID = INSURANCE {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage + providePatientMedicalHistory(medHistory :MedicalHistory) : void + providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
+ queryPatientPaymentInfo(socialSecurityNum :int) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean
«entity»
Pharmacy - TYPE: ServiceProviderID = PHARAMCY {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage
+ providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + providePatientPrescription(prescription :Prescription) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
+ queryPatientPersonalInfo(socialSecurityNum :int) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
«entity»
HealthCareProvider - TYPE: ServiceProviderID = HEALTHCARE {readOnly}
+ encrypt(xmlMsg :UnsecureMessage) : SecureMessage
+ providePatientPaymentInfo(paymentInfo :PaymentInformation) : void + providePatientMedicalHistory(medHistory :MedicalHistory) : void + providePatientPersonalInfo(patientInfo :PatientInformation) : void + providePatientPrescription(prescription :Prescription) : void + decrypt(xmlMsg :SecureMessage) : UnsecureMessage
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + modifyPatientPersonalInfo(socialSecurityNum :int, patientInfo :PatientInformation) : boolean + modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
+ queryPatientPaymentInfo(socialSecurityNum :int) : boolean + queryPatientPersonalInfo(socialSecurityNum :int) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
40 4.3 DYNAMIC VIEWS
4.3.1 Service Registration
All service providing participants register themselves with the ESB and provide a ServiceProviderID. The
ServiceProviderID (e.g. Healthcare, Insurance, or Pharmacy) tells the ESB which services interfaces this participant implements. The ESB keeps a list of each service provider that registers. This allows “the source of a *service+
message” to be “decouple*d+” from “the ultimate destination” *17+.
Figure 19 Service Registration Sequence
4.3.2 Service Request
The sequence diagram below shows an example of a service request. In this example the contents of the message is encrypted by using XML-ENC (e.g. social security number). The diagram below only shows one instance of a service invocation however the process for invoking other services follows a similar sequence.
soaml Serv ice Registration
«entity»
hcp :HealthCareProvider
«entity»
esb :ESBRouter
alt
[if( type == ServiceProviderID.HEALTHCARE)]
Service provider was identified as a HealthCareProvider, thus ESB knows which service interfaces are applicable for registration.
registerServiceProvider(ServiceProviderID.HEALTHCARE) :boolean
registerMedicalHistoryProvider(ManagePatientMedicalHistory)
registerPaymentProvider(ManagePatientPayment)
registerPersonalInfoProvider(ManagePatientPersonalInformation)
registerPrescriptionProvider(ManagePatientPrescription)
41 Figure 20 Service Request
5 DESIGN VERIFICATION
The design has been verified with respect to the architecture by showing the “white-box” use-case scenarios and showing the static and dynamic design related to each scenario.
6 CONCLUSIONS
7 REFERENCES
Please not that all citations are in IEEE format.
1) M. Amataykul, "EHR versus EMR: what's in a name?,” Healthcare Financial Management: Journal of The Healthcare financial Management Association, vol. 63, no. 3, pp.24, 2009.
soaml Serv ice Request
«entity»
ip :InsuranceProvider
«entity»
esb :ESBRouter
«entity»
hcp :HealthCareProvider
«messageTy...
:UnsecureMessa...
«messageTy...
:SecureMessage
«messageType»
:PaymentInformation loop
[for each ManagePatientPayment in paymentProviders]
Responses to each query are sent asynchronously
create()
encrypt(UnsecureMessage) :SecureMessage
create()
queryPatientPaymentInfo(int) :boolean
queryPatientPaymentInfo(int) :boolean
decrypt(SecureMessage) :UnsecureMessage
create()
encrypt(UnsecureMessage) :SecureMessage
providePatientPaymentInfo(PaymentInformation)
providePatientPaymentInfo(PaymentInformation)
decrypt(SecureMessage) :UnsecureMessage
42 2) J. Conn, “Agreement could put EHRs on fast track," Modern Healthcare, vol 37, no. 9, pp. 22, 2007.
3) T. Erl, SOA Design Patterns. Indianapolis, IN: Prentice Hall Professional Technical Reference, 2009.
4) E. Gamma, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addision-Wesley, 1995.
5) D. Nickul. (2007, December). Service Oriented Architecture (SOA) and Specialized Messaging Patterns [Online]. Available:
http://www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_from_Adobe.pdf 6) Health Insurance Portability and Accountability Act (HIPAA), S. 3103, 1996.
7) N. Lewis. (2010, August 31). EHR Revenue To Hit $3 Billion In 2013 [Online]. Available:
http://www.informationweek.com/news/healthcare/EMR/showArticle.jhtml?articleID=227200057&cid=R SSfeed_IWK_News
8) J. Miller. (2009, March 23). DoD Says Electronic Health Record System on Track [Online]. Available:
http://www.federalnewsradio.com/?sid=1631317&nid=35
9) P. McCloskey. (2009, March 9). Military Health System Develops EHR for White House. Available:
http://www.healthcareitnews.com/news/military-health-system-develops-ehr-white-house>
10) H. Hoffmann. “UML 2.0-Based Systems Engineering Using a Model-Driven Development Approach,”
CrossTalk – The Journal of Defense Software Engineering, pp.17-21. November 2005.
11) A. Solberg. “Model-Based Development with SoaML” unpublished. May, 2010.
12) XML Encryption Syntax and Processing, W3C Standard, 2002.
13) SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Standard, 2007.
14) Service Oriented Architecture Modeling Language (SoaML) Specification, OMG Standard, 2009.
15) Object Management Group. (2010, July 12). Availability of Tool Support [Online]. Available: http://
www.omgwiki.org/SoaML/doku.php
16) A. Rodriguez. (2008, November 6). “RESTful Web services: The basics” [Online]. Available:
https://www.ibm.com/developerworks/webservices/library/ws-restful/
17) F. Menge. “Enterprise Service Bus”. Free and Open Source Software Conference 2007. 2007.
18) N. Ali. “Modeling Service Oriented Architectures of Mobile Applications by Extending SoaML with Ambients”. 2009 35th Euromicro Conference on Software Engineering and Advanced Applications”. 2009.
19) Certification Commission for Health Information Technology. (2010, November 26). CCHIT [Online].
Available: http://www.cchit.org/
8 APPENDIX A
The appendix includes the references architectures used to derive the architecture described in this document.
8.1 REFERENCE ARCHITECTURE
43 [11]
[11]
44 [11]
[11]
45 [18]
8.2 DESIGN PATTERN REFERENCES
8.2.1 Enterprise Service Bus
[3]
8.2.2 Data Confidentiality
46 [3]
8.3 CLASS AND INTERFACE DESCRIPTIONS
8.3.1 ManagePatientMedicalHistory
Method Name Description
providePatientMedicalHistory This method has one parameter, the patient’s medical history. This method is invoked in by a service provider in response to a queryPatientMedicalHistory method.
See MedicalHistory class for further details.
modifyPatientMedicalHistory This method has two parameters, the patient’s SSN and their medical history. This method is invoked in by a service consumer in order to modify medical history
soaml Serv ice Interface View
«serviceInterface»
ManagePatientMedicalHistory
+ providePatientMedicalHistory(medHistory :MedicalHistory) : void
+ modifyPatientMedicalHistory(socialSecurityNum :int, medHistory :MedicalHistory) : boolean + queryPatientMedicalHistory(socialSecurityNum :int) : boolean
47 data. See MedicalHistory class for further details. This method returns a “True” Boolean if the modification is successfully or false otherwise.
queryPatientMedicalHistory This method has one parameter, the patient’s SSN. This method is invoked when a service consumer requests the medical history of a patient described by the SSN.
This method returns a “True” Boolean if the query is sent successfully or false otherwise.
8.3.2 MedicalHistory
Attribute Name Description
examResults Lists the patient’s exam results.
allergies Lists the patient’s allergies.
diagnoses Lists the patient’s diagnoses.
8.3.3 ManagePatientPrescription
Method Name Description
providePatientPrescription This method has one parameter, the patient’s
prescription information. This method is invoked in by a service provider in response to a
queryPatientPrecription method. See Prescription class for further details.
modifyPatientPrescription This method has two parameters, the patient’s SSN and their prescription. This method is invoked in by a service
soaml Serv ice Interface View
«messageType»
MedicalHistory
+ examResults: String + allergies: String + diagnoses: String
soaml Serv ice Interface View
«serviceInterface»
ManagePatientPrescription + providePatientPrescription(prescription :Prescription) : void
+ modifyPatientPrescription(socialSecurityNum :int, prescription :Prescription) : boolean + queryPatientPrescription(socialSecurityNum :int) : boolean
48 consumer in order to modify prescription data. See Prescription class for further details. This method returns a “True” Boolean if the modification is successfully or false otherwise.
queryPatientPrescription This method has one parameter, the patient’s SSN. This method is invoked when a service consumer requests the prescription of a patient described by the SSN. This method returns a “True” Boolean if the query is sent successfully or false otherwise.
8.3.4 Prescription
Attribute Name Description
drugType The drug type. See class description for “DrugType” for
more detail.
doctorID A unique identifier assigned to a medical doctor.
dateIssued The date described as the number of milliseconds since
1970 (Epoch time).
drugQuantity The quantity of the drug type.
8.3.5 DrugType
Attribute Name Description
name The drug’s name.
dosage The drug’s dosage amount.
soaml Serv ice Interface View
«messageType»
Prescription
+ drugType: DrugType + doctorID: int + dateIssued: int + drugQuantity: int
soaml Serv ice Interfa...
DrugType
+ name: String + dosage: int
49
8.3.6 ManagePatientPayment
Method Name Description
providePatientPaymentInfo This method has one parameter, the patient’s payment information. This method is invoked in by a service provider in response to a queryPatientPaymentInfo method. See the PaymentInformation class for further details.
modifyPatientPaymentInfo This method has two parameters, the patient’s SSN and their payment information. This method is invoked in by a service consumer in order to modify payment data.
See PaymentInformation class for further details. This method returns a “True” Boolean if the modification is successfully or false otherwise.
queryPatientPaymentInfo This method has one parameter, the patient’s SSN. This method is invoked when a service consumer requests the payment information of a patient described by the SSN. This method returns a “True” Boolean if the query is sent successfully or false otherwise.
8.3.7 PaymentInformation
Attribute Name Description
insuranceInfo The InsuranceProvider information. See
InsuranceProvider class description for more detail.
medicalServices List of medical services the patient received.
totalCost The total cost of the medical services.
soaml Serv ice Interface View
«serviceInterface»
ManagePatientPayment
+ providePatientPaymentInfo(paymentInfo :PaymentInformation) : void
+ modifyPatientPaymentInfo(paymentInfo :PaymentInformation, socialSecurityNum :int) : boolean + queryPatientPaymentInfo(socialSecurityNum :int) : boolean
soaml Serv ice Interface View
«messageType»
PaymentInformation
+ insuranceInfo: InsuranceProvider + medicalServices: String + totalCost: double
50
8.3.8 InsuranceProvider
Attribute Name Description
insuranceProvider The name of the insurance provider.
insuranceID A unique id related to the insurance provider.
8.3.9 ManagePatientPersonalInformation
Method Name Description
providePatientPersonalInfo This method has one parameter, the patient’s personal information. This method is invoked in by a service provider in response to a queryPatientPersonalInfo method. See the PatientInformation class for further details.
modifyPatientPersonalInfo This method has two parameters, the patient’s SSN and their personal information. This method is invoked in by a service consumer in order to modify patient personal data. See PatientInformation class for further details.
This method returns a “True” Boolean if the modification is successfully or false otherwise.
queryPatientPersonalInfo This method has one parameter, the patient’s SSN. This
queryPatientPersonalInfo This method has one parameter, the patient’s SSN. This