Service-Oriented Approach to Electronic Health Records Phase 3 November 23, 2010

Transcription

1 Service-Oriented Approach to Electronic Health Records November 23,

2 Table of Contents 1 Introduction Requirements Use Cases Use Case Description - Create EHR Use Case Description Query Patient Information Use Case Description Query Patient Medical History Use Case Description Manage Medical Payment Use Case Description Query Patient Prescription Use Case Description Protect All Patient Privacy Use Case Description Log All Activity Use Case Description Update EHR Architectural Model Static Views Services Architecture View Service Contract View Manage Patient Medical History Service Contract View Manage Patient Payment Service Contract View Manage Patient Personal Information Service Contract View Manage Patient Prescription Participant Architecture Component View Dynamic Views Safeguarding Privacy Web Service Translation Activity Logging EHR Data Redundancy Architecture Verification Design Model White Box Use Cases Use Case Description Register Service Use Case Description Invoke Service Use Case Description Data Confidentiality Static Views Service Interface View Healthcare Provider View Insurance Provider View Pharmacy View ESBRouter View Data Confidentiality Pattern Dynamic Views Service Registration Service Request

3 5 Design Verification Conclusions References Appendix A Reference Architecture Design Pattern References Enterprise Service Bus Data Confidentiality Class and Interface Descriptions ManagePatientMedicalHistory MedicalHistory ManagePatientPrescription Prescription DrugType ManagePatientPayment PaymentInformation InsuranceProvider ManagePatientPersonalInformation PatientInformation Security SecureMessage UnsecureMessage ServiceProviderID HealthCareProvider InsuranceProvider Pharmacy ESBRouter Table of Figures Figure 1 Use Case Diagram... 6 Figure 2 Services Architecture Figure 3 Service Contract Manage Patient Medical History Figure 4 Service Contract Manage Patient Payment Figure 5 Service Contract Manage Patient Personal Information Figure 6 Service Contract - Manage Patient Prescription Figure 7 Participant Architecture Figure 8 Component View Figure 9 Sequence Diagram - Safeguarding Privacy Figure 10 Sequence Diagram - Web Service Messaging Figure 11 Sequence Diagram - Activity Logging Figure 12 Sequence Diagram - EHR Data Redundancy Figure 13 Service Interfaces Figure 14 Healthcare Provider View Figure 15 Insurance Provider View

4 Figure 16 Pharmacy View Figure 17 ESBRouter View Figure 18 Data Confidentiality View Figure 19 Service Registration Sequence Figure 20 Service Request List of Tables Table 1 Table of Requirements INTRODUCTION This document details an architectural approach for implementing a standard Electronic Health Record (EHR) in a Service-Oriented Architecture (SOA). Healthcare stakeholders such as doctors, insurance companies, and pharmacies rely on electronic health records to process information about patients. The problem as it exists today, is that there many different implementations of digitized health records, or Electronic Medical Records (EMR). The healthcare industry is filled with many EMR software vendors. The US Secretary of Health and Human Services has funded groups such as The Certification Commission for Health Information Technology (CCHIT) to help certify EMR software and insure they are in compliance with government standards. At the time of this paper, the CCHIT has awarded 84 Off-the-shelf (OTS) software products that comply with ONC-ATCB EHR certification [19]. The CCHIT has also awarded 176 EMR software products with their own CCHIT Certification not based on the ONC-ATCB EHR standards [19]. The terms EHR and EMR are often used interchangeably but there is a subtle difference. An Electronic medical record is defined as an electronic record of health-related information on an individual that is used within one healthcare organization *1+. An EMR is recognized by a single healthcare organization such as a hospital network, private practice, dental office, etc. Electronic health record is defined as an electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards *1+. Patient medical history can be shared among many stakeholders, such as healthcare providers, insurance companies, pharmacies, etc. Allowing each of these stakeholders the ability to interoperate would require a solution that defines an accepted EHR format. In other words, an EHR represents a national or global cooperation among many different health care stakeholders and an EMR represents the many disjoint local flavors for recording patient medical information. A SOA solution would allow each flavor of EMRs to exist underneath the hood but encourage nationwide EHR compatibility by using a standardized EHR format such as the ones being developed by American Society for Testing and Materials (ASTM) or Health Level 7 (HL7) [2]. While the particular details related to such a format are out of scope of this project, in either case a standardized format would allow for a SOA solution to hit the floor running. Why not get all health care stakeholders to agree on a single data format for external service layer communication (i.e. EHR) and internal communication (i.e. EMR)? Migrating every legacy system to utilize a single standardize formatted version of EMR would be costly and require costly redesign and development of each EMR software system. In essence, this principle is the same as the Gang of Four s famous declaration program to an interface, not an implementation *4+. The idea being that the utilization of an open-standard interface will allow cross 4

5 system communication without the costly rework associated with completely standardizing all EMR vendor implementations. Health care has recently become a major point of discussion in Washington. The recent advances in health care legislation lead to a need for more nationwide health care collaboration. A recent study suggested that EHR is big business with spending estimated to reach $2.6 billion in 2012 [7]. I chose to focus on EHRs specifically, as there is no question that a nationwide health care system could benefit from a service-oriented architecture approach. Recently, using SOA concepts for EHR systems has had success within the Department of Defense [8][9]. Currently, a nationwide EHR is a novel concept but with this project hopes to show an effective engineering solution to the problem. 1.1 REQUIREMENTS Please note that these requirements have been edited since the proposal to remove 2 requirements and add a single requirement. The high availability non-functional requirement was removed because the verification required was too difficult given the time constraints for this project. Another requirement related to loose coupling of services was removed because its description was too vague and thus would also be difficult verify. A requirement about logging activity was included to help debugging the system. All requirements are verified via a use case walkthrough. This section provides a fully dressed use case description for each use cases shown in Figure 1. Table 1 Table of Requirements Requirement Requirement Verification Technique ID 1 The system shall support EHR interoperability between the Use Case Walkthrough [10] following parties: Healthcare Providers, Insurance Providers, and Pharmacies. 2 The system shall safeguard the privacy of electronic health Use Case Walkthrough [10] records 3 The system shall provide a standardized EHR format that is Use Case Walkthrough [10] supportable with any EMR format. 4 The system shall be support the following open web service Use Case Walkthrough [10] messaging standards: SOAP and REST, [13][16]. 5 The system shall provide data redundancy to prevent EHR loss. Use Case Walkthrough [10] 6 The system shall log activities related to EHR creation, EHR requests, and EHR modifications. Use Case Walkthrough [10] 1.2 USE CASES This section breaks down system functionality into a black-box use case diagram along with black-box use case descriptions [10]. Using this approach we are able to clearly see the actor and system interaction for each requirement. However, these use-cases do not show the interactions at a component level. Sections to follow will include white-box sequence diagrams that clearly verify the architecture of the system. 5

6 Figure 1 Use Case Diagram 6

7 1.2.1 Use Case Description - Create EHR Create EHR Author (s): T. Omen Date: 10/29/10 Version: 1.00 Use Case Name: Create EHR Use Case Type Use Case ID: UC_EHR_001 Business Requirements: Priority: High System Analysis: Source: Primary Business Actor: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records Health Care Provider System Insurance Provider Interested in the patient payment information and the medical services rendered. Pharmacy Interested in patient prescription. Patient Interested in accurate information and that privacy is safeguarded. Description: Precondition: Trigger: Other Health Care Provider A Health Care Provider that is not the same as the one described as Primary Business Actor. Interested in patient s medical history and patient s personal information. This use case describes the event of a Health Care Provider (HCP), such as a hospital or private practice, creating an electronic medical record (EMR) for a patient. The HCP creates a record for a new patient using off-the-shelf EMR software. The HCP enters basic patient information, including name, address, phone number, and a reference. The HCP enters the patient s medical history information. The HCP enters the patient s insurance information. The HCP enters the patient s prescription. Upon completion, the HCP saves the data locally to a persistent storage device, such as a database. The system redundantly copies the information for creation of an EHR on its own servers. Please note that the EMR creation is a black-box operation and it is not necessarily related to the SOA. In other words, the creation of an EMR is dependent on the specific off-the-shelf product but it is assumed that at a bare minimum they include the aforementioned information about the patient. The HCP must have off-the-shelf EMR software that abides by the service contract. This use case is triggered when a new patient concludes their medical appointment at a HCP location. 7

8 Typical Course of Events: Actor Action System Response Step 1: The HCP selects to create a new EMR. Step 2: The HCP enters all desired information such as basic patient information, medical history, bill information, insurance information, and prescription. Step 3: The HCP selects to save changes to the EMR. Step 4: The system responds by adding the EHR to the redundancy EHR servers. Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Open Issues: Not Needed for Phase II. This use-case concludes when the EMR is successfully created and a persistent form of it resides in both the off-the-shelf EMR database and the EHR redundancy database. The off-the-shelf EMR database and the EHR redundancy database have been updated with the EHR. No ne The HCP can rerun this use case as many times as they desire. The HCP can cancel creation of the EMR before submitted. 8

9 1.2.2 Use Case Description Query Patient Information Query Patient Information Author (s): T. Omen Date: 10/29/10 Version: 1.00 Use Case Name: Query Patient Information Use Case Type Use Case ID: UC_EHR_002 Business Requirements: Priority: High System Analysis: Source: Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records Insurance Provider Pharmacy Health Care Provider System Patient Insurance Provider Interested in the patient personal information to use for insurance payment for the medical services rendered. Pharmacy Interested in patient personal information to use to fulfill prescription. Health Care Provider Interested in patient personal information to use for local EMR about the patient. Description: Patient Interested in accurate information and that privacy is safeguarded. This use case describes the event of a Health Care Provider, Insurance Provider, or Pharmacy acting as a service consumer. Together these service consumers will henceforth be known as an Electronic Health Record Consumer (EHRC). The EHRC is interested in querying a patient s personal information. This includes information related to the name, gender, race, address, date of birth, age, phone number, and a social security number. [?] Precondition: Trigger: Typical Course of Events: An EHR record has been successfully created for the patient. This use case is triggered when the EHRC needs to query patient information. For example, a pharmacy fulfilling a prescription. Actor Action System Response Step 1: The EHRC requests patient information based off a social security number as a unique identifier. Step 4: The EHRC extracts the patient information. Step 5: The EHRC updates their local EMR database. Step 2: The system responds by querying the EHR redundancy server for the patient information. Step 3: The system sends the patient s information to the EHRC. 9

10 Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Not Needed for Phase II. This use-case concludes when the EHRC has received the required patient information and has updated their EMR database. The local EHRC EMR database has been updated with the patient information. No ne The EHRC can rerun this use case as many times as they desire. Open Issues: Use Case Description Query Patient Medical History Query Patient Medical History Author (s): T. Omen Date: 10/30/10 Version: 1.00 Use Case Name: Query Patient Medical History Use Case Type Use Case ID: UC_EHR_003 Business Requirements: Priority: High System Analysis: Source: Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records Insurance Provider Pharmacy System Health Care Provider Insurance Provider Interested in the patient payment information and the medical services rendered. Pharmacy Interested in patient prescription. Health Care Provider Interested in patient medical history to use for local EMR about the patient. Patient Interested in accurate information and that privacy is safeguarded. 10

11 Description: This use case describes the event of a Health Care Provider, Insurance Provider, or Pharmacy acting as a service consumer. Together both of these service consumers will henceforth be known as an Electronic Health Record Consumer (EHRC). The EHRC is interested in querying a patient s medical history. This includes information related to the family medical history, past prescriptions, allergies, surgeries, and medical exams Precondition: Trigger: Typical Course of Events: An EHR record has been successfully created for the patient. This use case is triggered when the EHRC needs patient medical history. Actor Action Step 1: The EHRC requests patient information based off a social security number as a unique identifier. Step 4: The EHRC extracts the patient medical history. Step 5: The EHRC updates their local EMR database. System Response Step 2: The system responds by querying the EHR redundancy server for the patient medical history. Step 3: The system sends the patient s medical history to the EHRC. Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Not Needed for Phase II. This use-case concludes when the EHRC has received the required patient medical history and has updated their EMR database. The local EHRC EMR database has been updated with the patient medical history. No ne The EHRC can rerun this use case as many times as they desire. Open Issues: Use Case Description Manage Medical Payment Manage Medical Payment Author (s): T. Omen Date: 10/30/10 Version: 1.00 Use Case Name: Manage Medical Payment Use Case Type Use Case ID: UC_EHR_004 Business Requirements: Priority: High System Analysis: Source: SOA Approach to Electronic Health Records 11

12 Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: Insurance Provider System Health Care Provider Insurance Provider Interested in the patient payment information and the medical services rendered. Health Care Provider Interested in receiving correct payment for medical services rendered. Patient Interested in having medical bill paid and that privacy is safeguarded. Description: This use case describes the event of an Insurance Provider (IP) wanting to manage a patient payment or medical payment information (MPI). This includes activities such as paying medical bills, updating bill to request a patient co-payment, providing patient deductible information. Precondition: Trigger: Typical Course of Events: Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: An EHR record has been successfully created for the patient. This use case is triggered when the Insurance Provider needs to access the patient s medical bill. Actor Action Step 1: The IP requests patient information based off a social security number as a unique identifier. Step 4: The IP extracts the MPI. Step 5: The IP modifies the MPI accordingly (e.g. pays bills, updates co-payment). Step 6: The IP updates their local database. Step 7: The IP sends updated MPI to the system. Not Needed for Phase II. System Response Step 2: The system responds by querying the EHR redundancy server for the MPI. Step 3: The system sends the MPI to the IP. Step 8: The system stores the updated MPI to the redundancy server. This use-case concludes when the IP has received the required MPI and has updated EHR redundancy server with the updated medical payment information. The local IP database and the database on the HER redundancy server has been updated with MPI. No ne 12

13 Assumptions: The IP can rerun this use case as many times as they desire. Open Issues: Use Case Description Query Patient Prescription Query Patient Prescription Author (s): T. Omen Date: 10/30/10 Version: 1.00 Use Case Name: Query Patient Medical History Use Case Type Use Case ID: UC_EHR_005 Business Requirements: Priority: High System Analysis: Source: Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records Pharmacy System Health Care Provider Insurance Provider Interested in paying for patient prescription. Pharmacy Interested in fulfilling the patient prescription. Health Care Provider Interested in patient prescription to use for local EMR. Patient Interested receiving an accurate prescription and that privacy is safeguarded. Description: This use case describes the event of a Pharmacy requesting a patient s prescription. The pharmacy is interested in fulfilling a patient s prescription. The pharmacy needs such information as the specified medication and the dosage. Precondition: Trigger: Typical Course of Events: An EHR record has been successfully created for the patient. This use case is triggered when the EHRC needs patient medical history. Actor Action Step 1: The pharmacy requests patient prescription based off a social security number as a unique identifier. Step 4: The pharmacy extracts the patient prescription. Step 5: The pharmacy fulfills the prescription and notifies the system. System Response Step 2: The system responds by querying the EHR redundancy server for the patient s prescription. Step 3: The system sends the patient s prescription to the pharmacy. Step 6: The system updates the patient s EHR noting the prescription has been fulfilled. 13

14 Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Not Needed for Phase II. This use-case concludes when the pharmacy has finished fulfilling the prescription and the patient s EHR has been updated to reflect the fulfillment. The EHR redundancy server has been updated to note that the patient s prescription has been fulfilled. No ne The pharmacy can fulfill a prescription once. Open Issues: Use Case Description Protect All Patient Privacy Author (s): T. Omen Protect All Patient Privacy Use Case Name: Use Case ID: Priority: Source: Protect All Patient Privacy UC_EHR_006 High SOA Approach to Electronic Health Records Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: Health Care Provider (Acting as a service consumer) Insurance Provider (Acting as a service consumer) Pharmacy (Acting as a service consumer) System Health Care Provider (Acting as a service provider) Insurance Provider (Acting as a service provider) Pharmacy (Acting as a service provider) Insurance Provider Interested in secure transactions between itself and the system. Pharmacy Interested in secure transactions between itself and the system. Health Care Provider Interested in secure transactions between itself and the system. Patient Interested in having privacy safeguarded. 14

15 Description: Precondition: Trigger: Typical Course of Events: This use case describes the event of protecting the contents of an EHR from unauthorized sources. This use case occurs for all data transactions between service consumers (SC) and service providers (SP). This includes transactions that include data related to: Patient personal information (e.g. social security, name, address) Patient medical history (e.g. patient medical exams, allergies, diagnoses) Patient payment information(e.g. medical services rendered, bill, insurance information) A service consumer and service provider exist and are able to interact with each other. This use case is triggered when patient related data is transferred from one service provider to a service consumer. SC Action System Response SP Action Step 1: The SC sends the system a service request with encrypted data. Step 6: The SC decrypts the data contents. Step 2: The system forwards the SP the service request. Step 4: The system forwards the SP response to the SC. Step 3: The SP decrypts the service request data. Step 5: The SP encrypts and sends the system the data contents requested by the SC. Alternate Courses: Conclusion: Not Needed for Phase II. This use-case concludes when SC has decrypted the data contents from the SP. Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: No ne Use case must encrypt all patient data. The encryption/decryption scheme is well understood by all services. Open Issues: Use Case Description Log All Activity Log All Activity Author (s): T. Omen Date: 10/31/10 Version: 1.00 Use Case Name: Log All Activity Use Case Type Use Case ID: UC_EHR_007 Business Requirements: Priority: High System Analysis: Source: SOA Approach to Electronic Health Records 15

16 Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: Description: Health Care Provider System Pharmacy Insurance Provider Insurance Provider Interested having service transactions logged. Pharmacy Interested having service transactions logged. Health Care Provider Interested having service transactions logged. This use case describes the event of a Health Care Provider, Pharmacy, or Insurance Provider acting as service consumers (SC). The SC notifies the system that they require a service from a service provider (SP). Precondition: Trigger: Typical Course of Events: An EHR record has been successfully created for the patient. This use case is triggered when any service transaction occurs between a service consumer and service provider. Actor Action System Response Step 1: The SC requests a service (e.g. querying medical history). Step 5: The SC utilizes the provided service as desired. Step 2: The system logs the request with a date and time stamp. Step 3: The system responds by requesting service from the SP Step 4: The system logs the response from the SP with a date and time stamp. Alternate Courses: Conclusion: Not Needed for Phase II. This use-case concludes after all service activity between the SC and SP has ceased. Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: The system log has been updated with the date and time stamps for all service request and service responses. The system logs all activity with a unique log entry. Open Issues: Use Case Description Update EHR 16

17 Update EHR Author (s): T. Omen Date: 10/31/10 Version: 1.00 Use Case Name: Update EHR Use Case Type Use Case ID: UC_EHR_008 Business Requirements: Priority: High System Analysis: Source: Primary Business Actors: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records Health Care Provider System Pharmacy Insurance Provider Insurance Provider Interested having payment information stored safely. Pharmacy Interested having prescription information stored safely. Description: Health Care Provider Interested having payment, medical history, prescription, and personal information stored safely. This use case describes the event of a Health Care Provider, Pharmacy, or Insurance Provider (known as EHR modifier) acting modifying EHR data (e.g. payment info, personal info, medical history). Precondition: Trigger: Typical Course of Events: An EHR record has been successfully created for the patient. This use case is triggered when any service transaction modifies EHR data (e.g. payment info, personal info, medical history). Actor Action System Response Step 1: The EHR modifier requests to modify EHR data. Step 2: The system responds by modifying the EHR data in its EHR redundancy database. Step 3: The system notifies the appropriate service of an EHR modification. 17

18 Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: Not Needed for Phase II. This use-case concludes after the EHR modification has been stored in persistent form on the EHR redundancy database. The system has updated the modified EHR on the EHR redundancy database. The system logs all activity with a unique log entry. Open Issues: 2 ARCHITECTURAL MODEL The architectural modeling used in this paper shall be using standard SoaML as defined by OMG [14]. Enterprise Architect 7.5 was used to model all diagrams due to its integrated support for SoaML modeling [15]. The architectural section is divided into the following sections: Static Views Dynamic Views The static and dynamic architecture used for these models were based off the reference architecture in Model- Based Development with SoaML by Solberg and others *11]. 2.1 STATIC VIEWS Services Architecture View The services architecture is a high level description of how participants work together for a purpose by providing and using services expressed as service contracts *11+. A participant is defined as a general business role which can represent a specific business entity *11]. In the case of the architecture defined below, the participants are 18

19 considered to be off-the-shelf software used for managing EMRs, insurance information, and prescriptions for the healthcare provider, insurance provider, and pharmacy respectively. soaml Overall Service Architecture View «serv icesarchitecture» Electronic Health Records System «serv icecontract» Manage Patient Medical History «serv icecontract» Manage Patient Personal Information «participant» InsuranceProv ider «participant» HealthcareProv ider «participant» Pharmacy «serv icecontract» Manage Patient Payment «serv icecontract» Manage Patient Prescription Figure 2 Services Architecture The services architecture above defines three primary participants: Healthcare Provider Interested in providing (and requesting from other health care providers) EHR data related to a patient including medical history, prescriptions, personal information, and payment information. Insurance Provider Primarily interested in providing and receiving EHR data related to the payment of medical services rendered. Pharmacy Primarily interested in receiving EHR data related to prescription information about a patient. The services architecture above also defines the following first-level service contracts: Manage Patient Medical History Defines services for modifying, querying, and providing patient medical history (e.g. medical exam information, allergies, diagnoses, etc). Manage Patient Payment Defines services for modifying, querying, and providing patient payment information (e.g. insurance information, medical services rendered, medical costs, etc). Manage Patient Personal Information - Defines services for modifying, querying, and providing patient personal information (e.g. name, address, phone number, etc). 19

20 Manage Patient Prescription Defines services for modifying, querying, and providing patient prescription information (e.g. drugs prescribed, dosage, etc). The sections after this further refine each of these first-level service contracts into second-level service contracts Service Contract View Manage Patient Medical History soaml Manage Patient Medical History «serv icecontract» Manage Patient Medical History «serv icecontract» Prov ide Patient Medical History «participant» HealthcareProv ider «serv icecontract» Modify Patient Medical History «participant» InsuranceProv ider «serv icecontract» Query Patient Medical History «participant» Pharmacy Figure 3 Service Contract Manage Patient Medical History Service Contract View Manage Patient Payment 20

21 soaml Manage Patient Payment «serv icecontract» Manage Patient Payment «serv icecontract» Prov ide Patient Payment Info «participant» HealthcareProv ider «serv icecontract» Query Patient Payment Info «serv icecontract» Modify Patient Payment Info «participant» InsuranceProv ider «participant» Pharmacy Figure 4 Service Contract Manage Patient Payment Service Contract View Manage Patient Personal Information 21

22 soaml Manage Patient Personal Information «serv icecontract» Manage Patient Personal Information «serv icecontract» Prov ide Patient Personal Information «participant» HealthcareProv ider «participant» InsuranceProv ider «serv icecontract» Query Patient Personal Information «serv icecontract» Modify Patient Personal Information «participant» Pharmacy Figure 5 Service Contract Manage Patient Personal Information Service Contract View Manage Patient Prescription 22

23 soaml Manage Patient Prescription «serv icecontract» Manage Patient Prescription «serv icecontract» Prov ide Patient Prescription «participant» HealthcareProv ider «serv icecontract» Modify Patient Prescription «serv icecontract» Query Patient Prescription «participant» Pharamacy Figure 6 Service Contract - Manage Patient Prescription Participant Architecture The participant architecture specifies how parts of [a] participant work together to provide the services of the owning participant [15]. This shows all the services each participant is capable of providing and requesting. 23

24 soaml Participant View «participant» HealthcareProv ider «servicepoint» Provide Medical History «servicepoint» Provide Personal Info «servicepoint» Provide Payment Info «servicepoint» Provide Prescription Info «requestpoint» Request Medical History «requestpoint» Request Personal Info «requestpoint» Request Payment Info «requestpoint» Request Prescription Info «participant» EnterpriseServ icebus «servicepoint» Service Request «requestpoint» Request Payment Info «requestpoint» Request Personal Info «requestpoint» Request Prescription Info «requestpoint» Request Medical History «requestpoint» Request «requestpoint» Request Medical History Personal Info «participant» InsuranceProv ider «participant» Pharmacy Figure 7 Participant Architecture The participant architecture adds an Enterprise Service Bus participant to the architecture. The Enterprise Service Bus (ESB) is defined as a standardized collection of standards and protocols to make communications seamless across all connected devices [5]. This will help facilitate communication of the many EMR implementations by routing service traffic through an ESB responsible for message brokering. The ESB will include adapters that allow many web-service messaging specifications such as SOAP and REST to be processed and converted to any given format understood by the many stakeholders. This participant architecture is based on a similar architecture used by Ali [18] Component View The component view drills down each participant and turns it into the component level. These components adhere to the service contracts defined above by defining operation contracts necessary for providing those services. 24

25 soaml Component View «participantarchitecture» Pharmacy «participantarchitecture» HealthcareProv ider «participantarchitecture» InsuranceProv ider «component» Pharmacy + modifypatientprescription() : void + querypatientpersonalinfo() : void + providepatientpersonalinfo() : void + querypatientpayment() : void + providepatientpayment() : void + querypatientprescription() : void + providepatientprescription() : void «component» HealthcareProv ider + modifypatientpersonalinfo() : void + querypatientpersonalinfo() : void + providepatientpersonalinfo() : void + modifypatientpaymentinfo() : void + querypatientpaymentinfo() : void + providepatientpaymentinfo() : void + modifypatientprescription() : void + querypatientprescription() : void + providepatientprescription() : void + modifypatientmedicalhistory() : void + querypatientmedicalhistory() : void + providepatientmedicalhistory() : void «component» InsuranceProv ider + modifypatientpayment() : void + querypatientpayment() : void + providepatientpayment() : void + modifypatientpersonalinfo() : void + querypatientpersonalinfo() : void + providepatientpersonalinfo() : void + querypatientmedicalhistory() : void + providepatientmedicalhistory() : void «component» Security + decryptdata() : void + encryptdata() : void «component» Security + decryptdata() : void + encryptdata() : void «component» Security + decryptdata() : void + encryptdata() : void «participantarchitecture» EnterpriseServ icebus «component» ESBServ icerouter + modifypatientpersonalinfo() : void + querypatientpersonalinfo() : void + providepatientpersonalinfo() : void + modifypatientpaymentinfo() : void + querypatientpaymentinfo() : void + providepatientpaymentinfo() : void + modifypatientprescription() : void + querypatientprescription() : void + providepatientprescription() : void + modifypatientmedicalhistory() : void + querypatientmedicalhistory() : void + providepatientmedicalhistory() : void «component» ESBLogger «component» ESBTranslator «component» ESBDatabase + logactivity() : void + translatewebservice() : void + persistehr() : void Figure 8 Component View 25

26 Each participant has consists of a composite of core components. Please note that the Security component is based off the Data Confidentiality pattern. A security component is essential because patient privacy is required by law when dealing with EMRs/EHRs. In the US, the Health Insurance Portability and Accountability Act (HIPA) govern privacy measures that must be taken when dealing with patient records. [6] Thus the Data Confidentiality pattern, which helps to keeps data from unintended recipients *3], is appropriate for this architecture. The Data Confidentiality pattern encrypts message contents independent of transport layer measures such as SSL or TLS. This ensures that the message, if passed to intermediary services, such as an ESB, is still encrypted until the intended recipient service decrypts the data [3]. This system plans on using XML encryption (XML-ENC) [12] for protecting the data contents related to patient data Pharmacy Components The pharmacy component defines operation contracts for managing patient personal information, patient payment information, and patient prescriptions. The security component defines operations for encrypting and decrypting data Healthcare Provider Components The healthcare provider component defines operation contracts for managing patient medical history, patient personal information, patient payment information, and patient prescriptions. The security component defines operations for encrypting and decrypting data Insurance Provider Components The insurance provider component defines operation contracts for managing patient medical history, patient personal information, and patient payment information. The security component defines operations for encrypting and decrypting data ESB Components The ESBServiceRouter component must define operation contracts for all possible services within the system. This information is necessary in order to correctly route the information to the require service provider or service consumer. The ESBLogger component defines an operation contract used to log service activity. For example, logging who and when a service consumer request patient personal information. The ESBTranslator component defines an operation contract used to convert from one web service format to another. For example, if a insurance provider s off-the-shelf software makes web service calls via SOAP but the health care provider s off-the-shelf software uses REST then the ESBTranslator must convert the calls into a format each participant understands. 26

27 The ESBDatabase component defines an operation contract used store EHR data. This persisting of data is for redundancy purposes as the local off-the-shelf software already stores a copy of the EMR data. This component is invoked anytime EHR related data is modified. 2.2 DYNAMIC VIEWS These dynamic views show the components of the system in a few key areas. The sequence diagrams below show sequencing for privacy protection (data confidentiality pattern), data redundancy, logging, and web service translation. However, these diagrams also implicitly verify requirements related to system interoperability by showing service calls between the different participants of the system Safeguarding Privacy soaml EHR Privacy Safeguarding «component» InsuranceProvider «component» insurancesecurity:security «component» ESBServiceRouter «component» HealthcareProvider «component» healthcaresecurity:security encryptdata() querypatientpaymentinfo() providepatientpaymentinfo() querypatientpaymentinfo() providepatientpaymentinfo() decryptdata() encryptdata() decryptdata() Figure 9 Sequence Diagram - Safeguarding Privacy Web Service Translation 27

28 soaml EHR Web Serv ice Messaging «participant» InsuranceProvider «component» InsuranceProvider «component» ESBServiceRouter «component» ESBTranslator «component» HealthcareProvider «participant» HealthcareProvider querypatientmedicalhistory() The <<participant>> InsuranceProvider uses SOAP for its web service messaging. querypatientmedicalhistory() translatewebservice() querypatientmedicalhistory() providepatientmedicalhistory() Translates SOAP formated message to a REST format. querypatientmedicalhistory() providepatientmedicalhistory() The <<participant>> HealthcareProvider uses REST for its web service messaging providepatientmedicalhistory() translatewebservice() Translates REST formatted message to SOAP format. providepatientmedicalhistory() Figure 10 Sequence Diagram - Web Service Messaging Activity Logging soaml EHR Logging «component» Pharmacy «component» ESBServiceRouter «component» ESBLogger «component» HealthcareProvider querypatientprescription() logactivity() querypatientprescription() providepatientprescription() providepatientprescription() logactivity() Figure 11 Sequence Diagram - Activity Logging 28

29 2.2.4 EHR Data Redundancy soaml EHR Data Redundancy «participant» HealthcareProvider «component» HealthcareProvider «component» ESBServiceRouter «component» ESBDatabase modifycotsmedicalhistory() modifypatientmedicalhistory() modifypatientmedicalhistory() persistehr() storetocotsdatabase() modifycotspaymentinfo() modifypatientpaymentinfo() storetocotsdatabase() modifypatientpaymentinfo() persistehr() modifycotspersonalinfo() modifypatientpersonalinfo() storetocotsdatabase() modifypatientpersonalinfo() persistehr() Redundant because all modifications are stored to both off-the-shelf EMR database and database component resident in ESB. Figure 12 Sequence Diagram - EHR Data Redundancy 3 ARCHITECTURE VERIFICATION This system is verified by a use-case walkthrough approach. The requirements of the system are verified using Dr. Hoffmann s approach [10]. First, the black-box use cases were presented to give a full description of what is necessary to meet the system requirements. These use-cases were further refined in to white-box components shown in the static diagrams. The white-box components were then used to model sequencing between each component. This sequencing helps visually show what the black-box use cases descriptions described. 29

30 4 DESIGN MODEL The scope of the architectural model is too large to cover in detail. The design model presented in this section will cover the Enterprise Service Bus Router and the Service Provider components (e.g. Healthcare Provider, Insurance Provider, and Pharmacy) that were introduced in the architectural component diagram. This section will not cover the following components: ESBLogger, ESBTranslator, and ESBDatabase. All design here of is to be implemented using J2EE Java language. This section begins by first describe the white-box use cases in detail in order to verify consistency with the architecture. 4.1 WHITE BOX USE CASES 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 Use Case ID: UC_EHR_009 Business Requirements: Priority: High System Analysis: Source: Primary Business Actor: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: Description: SOA Approach to Electronic Health Records Service Provider (SP) such as a Healthcare Provider, Insurance Provider, or Pharmacy software component. Enterprise Service Bus (ESB) 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: Trigger: Typical Course of Events: The SP must have off-the-shelf software that implements the one or more service interfaces. This use case is triggered when a service provider is added to the EHR system for the first time. Actor Action System Response 30

31 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: Conclusion: 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. This use-case concludes when the SP is successfully registered with the ESB. Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: The SP is registered and available for service requests. The SP can re-attempt registration if failure occurs. Open Issues: Use Case Description Invoke Service Invoke Service Author (s): T. Omen Date: 11/26/10 Version: 1.00 Use Case Name: Invoke Service Use Case Type Use Case ID: UC_EHR_010 Business Requirements: Priority: High System Analysis: Source: Primary Business Actor: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: SOA Approach to Electronic Health Records 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. Enterprise Service Bus (ESB) 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. 31

32 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: Trigger: Typical Course of Events: The SP/SC have been registered with the ESB. This use case is triggered when a service consumer requests any service. SC Actor Action System Response SP Actor Action Step 1: The Insurance provider requests payment information for the patient with social security number 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: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: 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. This use-case concludes when the SC has received one or more service responses from the ESB. The SC has successfully received one or more service responses. The SP can re-attempt service request if failure occurs. Open Issues: Use Case Description Data Confidentiality Data Confidentiality Author (s): T. Omen Date: 11/26/10 Version: 1.00 Use Case Name: Data Confidentiality Use Case Type Use Case ID: UC_EHR_011 Business Requirements: Priority: High System Analysis: 32

33 Source: Primary Business Actor: Primary System Actor: Other Participating Actors: Other Interested Stakeholders: Description: Precondition: Trigger: Typical Course of Events: Alternate Courses: Conclusion: Postcondition: Business Rules: Implementation Constraints and Specifications: Assumptions: SOA Approach to Electronic Health Records 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. Enterprise Service Bus (ESB) 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. 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. The SP/SC have been registered with the ESB. This use case is triggered when a service consumer requests any service. 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 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. This use-case concludes when the SC has decrypted the contents of one or more service responses. The SC has successfully decrypted one or more service responses. The SP can re-attempt service request if failure occurs. 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. Open Issues: 33

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 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. soaml Service 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» 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 + name: String + dosage: int «serviceinterface» ManagePatientPayment + providepatientpaymentinfo(paymentinfo :PaymentInformation) : void + modifypatientpaymentinfo(paymentinfo :PaymentInformation, socialsecuritynum :int) : boolean + querypatientpaymentinfo(socialsecuritynum :int) : boolean «messagetype» PaymentInformation + insuranceinfo: InsuranceProvider + medicalservices: String + totalcost: double InsuranceProv ider + name: String + insuranceid: int «serviceinterface» ManagePatientPersonalInformation + providepatientpersonalinfo(patientinfo :PatientInformation) : void + modifypatientpersonalinfo(socialsecuritynum :int, patientinfo :PatientInformation) : boolean + querypatientpersonalinfo(socialsecuritynum :int) : boolean «messagetype» PatientInformation + name: String + address: String + phonenumber: String Figure 13 Service Interfaces Healthcare Provider View 34

35 soaml HealthCareProvider View «serviceinterface» ManagePatientPrescription + providepatientprescription(prescription :Prescription) : void + modifypatientprescription(socialsecuritynum :int, prescription :Prescription) : boolean + querypatientprescription(socialsecuritynum :int) : boolean «serviceinterface» ManagePatientMedicalHistory + providepatientmedicalhistory(medhistory :MedicalHistory) : void + modifypatientmedicalhistory(socialsecuritynum :int, medhistory :MedicalHistory) : boolean + querypatientmedicalhistory(socialsecuritynum :int) : boolean «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 «entity» Serv iceprov iderid + PHARMACY: ServiceProviderID {readonly} + HEALTHCARE: ServiceProviderID {readonly} + INSURANCE: ServiceProviderID {readonly} «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 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 Insurance Provider View 35

36 soaml InsuranceProvider View «serviceinterface» ManagePatientPayment + providepatientpaymentinfo(paymentinfo :PaymentInformation) : void + modifypatientpaymentinfo(paymentinfo :PaymentInformation, socialsecuritynum :int) : boolean + querypatientpaymentinfo(socialsecuritynum :int) : boolean «serviceinterface» ManagePatientMedicalHistory + providepatientmedicalhistory(medhistory :MedicalHistory) : void + modifypatientmedicalhistory(socialsecuritynum :int, medhistory :MedicalHistory) : boolean + querypatientmedicalhistory(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 «serviceinterface» ManagePatientPersonalInformation + providepatientpersonalinfo(patientinfo :PatientInformation) : void + modifypatientpersonalinfo(socialsecuritynum :int, patientinfo :PatientInformation) : boolean + querypatientpersonalinfo(socialsecuritynum :int) : boolean «entity» Serv iceprov iderid + PHARMACY: ServiceProviderID {readonly} + HEALTHCARE: ServiceProviderID {readonly} + INSURANCE: ServiceProviderID {readonly} 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 Pharmacy View 36

37 soaml Pharmacy View «serviceinterface» ManagePatientPayment + providepatientpaymentinfo(paymentinfo :PaymentInformation) : void + modifypatientpaymentinfo(paymentinfo :PaymentInformation, socialsecuritynum :int) : boolean + querypatientpaymentinfo(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» Serv iceprov iderid + PHARMACY: ServiceProviderID {readonly} + HEALTHCARE: ServiceProviderID {readonly} + INSURANCE: ServiceProviderID {readonly} «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 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 ESBRouter View 37

38 soaml ESBRouter View «serviceinterface» ManagePatientPayment + providepatientpaymentinfo(paymentinfo :PaymentInformation) : void + modifypatientpaymentinfo(paymentinfo :PaymentInformation, socialsecuritynum :int) : boolean + querypatientpaymentinfo(socialsecuritynum :int) : boolean «serviceinterface» ManagePatientMedicalHistory + providepatientmedicalhistory(medhistory :MedicalHistory) : void + modifypatientmedicalhistory(socialsecuritynum :int, medhistory :MedicalHistory) : boolean + querypatientmedicalhistory(socialsecuritynum :int) : boolean «entity» Serv iceprov iderid + PHARMACY: ServiceProviderID {readonly} + HEALTHCARE: ServiceProviderID {readonly} + INSURANCE: ServiceProviderID {readonly} «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» ManagePatientPrescription + providepatientprescription(prescription :Prescription) : void + modifypatientprescription(socialsecuritynum :int, prescription :Prescription) : boolean + querypatientprescription(socialsecuritynum :int) : boolean «serviceinterface» ManagePatientPersonalInformation + providepatientpersonalinfo(patientinfo :PatientInformation) : void + modifypatientpersonalinfo(socialsecuritynum :int, patientinfo :PatientInformation) : boolean + querypatientpersonalinfo(socialsecuritynum :int) : boolean Figure 17 ESBRouter View The ESBRouter implements all service interfaces in order to be able to properly route all service requests. 38

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]. soaml Data Confidentiality View «messagetype» SecureMessage + securexml: String «serviceinterface» Security + encrypt(xmlmsg :UnsecureMessage) : SecureMessage + decrypt(xmlmsg :SecureMessage) : UnsecureMessage «messagetype» UnsecureMessage + unsecurexml: String «entity» HealthCareProv ider «entity» InsuranceProv 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 - 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 Figure 18 Data Confidentiality View 39

40 4.3 DYNAMIC VIEWS 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+. soaml Service Registration «entity» hcp :HealthCareProvider «entity» esb :ESBRouter registerserviceprovider(serviceproviderid.healthcare) :boolean alt [if( type == ServiceProviderID.HEALTHCARE)] Service provider was identified as a HealthCareProvider, thus ESB knows which service interfaces are applicable for registration. registermedicalhistoryprovider(managepatientmedicalhistory) registerpaymentprovider(managepatientpayment) registerpersonalinfoprovider(managepatientpersonalinformation) registerprescriptionprovider(managepatientprescription) Figure 19 Service Registration Sequence 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. 40

41 soaml Service Request «entity» ip :InsuranceProvider «entity» esb :ESBRouter «entity» hcp :HealthCareProvider create() «messagety... :UnsecureMessa... encrypt(unsecuremessage) :SecureMessage «messagety... create() :SecureMessage querypatientpaymentinfo(int) :boolean loop [for each ManagePatientPayment in paymentproviders] querypatientpaymentinfo(int) :boolean decrypt(securemessage) :UnsecureMessage Responses to each query are sent asynchronously «messagetype» create() :PaymentInformation encrypt(unsecuremessage) :SecureMessage providepatientpaymentinfo(paymentinformation) providepatientpaymentinfo(paymentinformation) decrypt(securemessage) :UnsecureMessage 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,

42 2) J. Conn, Agreement could put EHRs on fast track," Modern Healthcare, vol 37, no. 9, pp. 22, ) T. Erl, SOA Design Patterns. Indianapolis, IN: Prentice Hall Professional Technical Reference, ) E. Gamma, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addision- Wesley, ) D. Nickul. (2007, December). Service Oriented Architecture (SOA) and Specialized Messaging Patterns [Online]. Available: 6) Health Insurance Portability and Accountability Act (HIPAA), S. 3103, ) N. Lewis. (2010, August 31). EHR Revenue To Hit $3 Billion In 2013 [Online]. Available: SSfeed_IWK_News 8) J. Miller. (2009, March 23). DoD Says Electronic Health Record System on Track [Online]. Available: 9) P. McCloskey. (2009, March 9). Military Health System Develops EHR for White House. Available: 10) H. Hoffmann. UML 2.0-Based Systems Engineering Using a Model-Driven Development Approach, CrossTalk The Journal of Defense Software Engineering, pp November ) A. Solberg. Model-Based Development with SoaML unpublished. May, ) XML Encryption Syntax and Processing, W3C Standard, ) SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), W3C Standard, ) Service Oriented Architecture Modeling Language (SoaML) Specification, OMG Standard, ) Object Management Group. (2010, July 12). Availability of Tool Support [Online]. Available: ) A. Rodriguez. (2008, November 6). RESTful Web services: The basics [Online]. Available: 17) F. Menge. Enterprise Service Bus. Free and Open Source Software Conference ) N. Ali. Modeling Service Oriented Architectures of Mobile Applications by Extending SoaML with Ambients th Euromicro Conference on Software Engineering and Advanced Applications ) Certification Commission for Health Information Technology. (2010, November 26). CCHIT [Online]. Available: 8 APPENDIX A The appendix includes the references architectures used to derive the architecture described in this document. 8.1 REFERENCE ARCHITECTURE 42

43 [11] [11] 43

44 [11] [11] 44

45 [18] 8.2 DESIGN PATTERN REFERENCES Enterprise Service Bus [3] Data Confidentiality 45