An Interoperability Architecture for the Health Information Exchange in Rwanda
|
|
- Jean Gordon
- 8 years ago
- Views:
Transcription
1 An Interoperability Architecture for the Health Information Exchange in Rwanda Ryan Crichton 12, Deshendran Moodley 1, Anban Pillay 1, and Christopher J. Seebregts Health Architecture Laboratory, Centre for Articial Intelligence Research, University of KwaZulu-Natal and Council for Scientic and Industrial Research, Durban, South Africa 2 Jembi Health Systems, Cape Town and Durban, South Africa, 3 Medical Research Council, Cape Town, South Africa Abstract. Rwanda, one of the smallest and most densely populated countries in Africa, has made rapid and substantial progress towards designing and deploying a national health information system. One of the challenging aspects of the system is the design of an architecture to support: interoperability between existing health information systems already in use in the country; incremental extension into a fully integrated national health information system without substantial reengineering; and scaling, from a single district in the initial phase, to national level without requiring a fundamental change in technology or design paradigm. This paper describes the key requirements and the design of the current architecture using ISO/IEC/IEEE standard architecture descriptions. The architecture is based on the Enterprise Service Bus architectural model. We also describe a partial implementation of the architecture, and give a preliminary analysis based on our experiences. Keywords: interoperability; national health information system architecture; enterprise service bus 1 Introduction The current landscape of health information systems, especially in the developing world, is mostly characterized by fragmented, piecemeal applications deployed by multiple organizations or contractors[1,4]. Applications are mostly custom built around specic outcomes, using dierent architectures and technologies, with interoperability low on the list of priorities. While these systems may be useful in a specic domain, their integration into a coherent national health information system (NHIS) poses serious challenges, limiting the usefulness and sustainability of these applications. One potential solution to this problem is to implement a national Health Information Exchange (HIE) and interoperability architecture to facilitate the integration of such applications into the NHIS. In our previous work[16] we identied general challenges and requirements for designing and developing NHIS architectures in developing African countries.
2 In this paper we identify specic interoperability challenges and requirements for the Rwandan NHIS and describe the design and implementation of an interoperability architecture that has been adopted in Rwanda for use in its NHIS. In section 2 we describe the background to the Rwandan NHIS. Section 3 provides the key requirements and challenges for interoperability. The HIE interoperability architecture is presented in section 4 and section 5 gives an analysis of this architecture. We draw our conclusions in section 6. 2 Background: A national health information system for Rwanda The Rwanda Ministry of Health (MoH) has already made signicant progress in developing their NHIS, including community health systems, health management information systems and the national rollout of an electronic medical record application[15]. The Rwanda Health Enterprise Architecture (RHEA) project, led by the Rwanda MoH and supported by a consortium of partners and donors has developed an architecture to contribute to the development of the NHIS. One of the main deliverables is the architecture for a HIE to support the Rwandan NHIS in order to facilitate interoperability between individual health information systems and applications. Implementation of the Rwandan HIE will be achieved in several phases. The rst phase will implement foundational services and improve interoperability between two point of care information systems supporting maternal health in the Rwamagana district in Rwanda, including 13 health centers. The two supporting systems are OpenMRS[14,2,21], an Electronic Medial Records (EMR) system which is being implemented and maintained by the Rwandan MoH and RapidSMS, an SMS based data collection tool that is currently being used by community health workers in Rwanda. RapidSMS allows community health workers (CHWs) in Rwanda to submit maternal and child health information to a central server using SMS based messages from mobile phones. There are many CHWs within Rwanda and this information plays an important role in monitoring the progress of pregnant women and the health of children where frequent visits to clinics are not possible. An important feature of the HIE interoperability architecture is that it will serve as the foundation for the HIE in Rwanda and enable other systems currently implemented in the country to connect and inter-operate more easily. The HIE plans to promote data re-use between the connected systems and to facilitate information sharing. It also aims to provide patients with a continuity of care record[9] to enable access to a patient's clinical information from dierent health facilities, improve the tracking of patients and reduce patients lost-to-follow-up. The rst phase involves deploying the HIE interoperability architecture combined with a set of foundational infrastructure services, providing services to point of care applications, initially, OpenMRS and RapidSMS. The HIE will allow them to share clinical information and ensure that shared information
3 uniquely identies the patient, provider and facility within the information exchange (Figure 1). The foundational infrastructure services are: Shared Health Record This system persists and responds to queries for an appropriate subset of the patient's longitudinal, patient-centric medical record. Client Registry This system persists and responds to queries for a patient's demographic and identifying information used to uniquely identify patients. Facility Registry This system persists and responds to queries for data of the facilities participating in the information exchange. This is primarily used to maintain current and valid facility codes required in transactions. Professional Registry This system persists and responds to queries for information about health care professionals who work at participating health care facilities in the information exchange. This is primarily used to uniquely identify health care professionals within the HIE. Terminology Service This system stores all the clinical code systems (eg. LOINC, ICD10 and country specic code systems) that will be used within the HIE and facilitates verication and mapping between codes. It exposes endpoints that allow codes to be veried against the stored code systems. Fig. 1. The architecture of the Rwandan Health Information Exchange
4 3 Interoperability: challenges and requirements The HIE interoperability layer, shown in gure 1, is the cornerstone of the Rwandan HIE architecture and its design has signicant impact on the eectiveness, scalability, sustainability and adaptability of the system. Its design was informed by the following requirements and challenges: Facilitate interoperability between disparate and heterogeneous systems, both existing and future. In the context of the Rwandan NHIS, the HIE initially allows the OpenMRS and RapidSMS systems to inter-operate with the infrastructure services (client registry, provider registry, facility registry and the shared health record) in order to share information. Each system embodies a dierent technology and architecture and the interoperability layer enables these systems to interact eectively. The Interoperability Layer must provide mechanisms to allow existing disparate and heterogeneous systems to be incorporated into a HIE with minimal changes to the systems and still allow for local autonomy. The systems need to be able to grow and develop independently of the overall HIE and the other systems participating in the HIE. The architecture must be technology agnostic, with minimal restrictions on the technologies used within participating systems. Challenges include syntactic, semantic and process or pragmatic heterogeneity [17,11]. Adapt and scale within a changing environment The focus of the current project is to enable the sharing of maternal health information between point of service applications in a single district. However, this architecture will need to adapt to new requirements and grow as the project progresses. It has to be designed to expand such that the services may be readily expanded to other districts in Rwanda, to incorporate additional domains of health care (for example, HIV/TB programmes) and allow other systems to be incorporated as part of the growth of the HIE. The architecture must support incremental development and evolution of the HIE and also must be able to grow as the country's needs expand over time. This is especially true in low-resource environments where many organizations implement disparate information systems for a variety of purposes[3]. An essential feature of a HIE is its ability to cope with change. The architecture must be exible enough to deal with changing and evolving NHIS requirements. The system must also be able to scale, in terms of transaction volume, geographical locations and increased functionality. Local changes should not propagate through the system In Rwanda, development teams in dierent organizations design and maintain participating systems such as OpenMRS, RapidSMS and the infrastructure services. There are currently 14 partners working on the Rwandan HIE with 7
5 dierent development teams working on the various systems. Participating systems must be able to develop independently without aecting other systems. Participating systems will need to balance local requirements and NHIS requirements, but from a practical perspective development teams will often prioritise local requirements. Changes to participating systems should have minimal effect on other systems and systems must also be protected as much as possible from changes to infrastructure services. All systems must still maintain a large degree of local autonomy, especially since these systems are implemented and maintained by a variety of disparate organizations. Provide a low barrier to entry to connect new and legacy systems Implementing partners have development teams distributed around the world with varying degrees of expertise and technical skills. Inter-operating with the infrastructure services must be simple and require minimal eort both for current as well as new technical teams. A number of existing health information systems including the OpenMRS implementations and the RapidSMS implementation existed before the HIE was conceived. The HIE should reduce the burden of connecting new and legacy systems participating in the HIE. The approach toward integration of legacy systems should be to `embrace and extend' and not to `rip and replace'. The architecture must provide a minimal barrier to entry to incorporate a system into the HIE and reduce the overhead required to modify a particular system to participate in the HIE. This feature will maximize the existing investment in legacy applications and help prevent useful and functioning legacy applications from being abandoned unnecessarily. 4 The architecture of the Health Information Mediator This section describes the design of the Health Information Mediator shown in gure 1. The descriptions provided are based on the ISO architecture descriptions [13,8]. ISO/IEC FDIS provides a formal language and a metamodel for creating, analysing and sustaining architecture descriptions. An architecture can be described by a number of architectural viewpoints with each viewpoint framing a number of concerns (including requirements) of dierent groups of stakeholders with an interest in the system. Together, these views make up the architecture description. Based on the requirements identied in section 3, three major viewpoints and their associated concerns are described below. 4.1 Logical Viewpoint This viewpoint describes the overall functionality of the system. The model kinds include custom diagrams showing how transactions ow through the architecture. This view frames the following concerns:
6 The architecture must facilitate interoperability between heterogeneous systems The architecture must provide a low barrier to entry to connect both new and legacy systems Changes should be kept local and not propagate through the system Based on the above requirements, we have designed a middleware system, the Health Information Mediator (HIM) to enable interoperability between participating systems and infrastructure services. The HIM is based on the Enterprise Service Bus architectural model. An Enterprise Service Bus (ESB)[5,20] is a middleware system that facilitates interoperability by providing a central bus that manages all communications between systems. Since the components within an ESB are loosely coupled and can run completely independently of each other, each component can still function independently when other components fail. ESB is a well established architectural model for meeting the requirements associated with interoperability between distributed and disparate systems that has previously been applied to the problem of interoperability between disparate health information systems[19,12]. All participating systems in the HIE are represented as services. Systems that provide services to other systems are termed service providers, while systems that make requests of other systems are termed service requesters. All service requests are made via the HIM. The HIM thus provides mediation and orchestration functions within the system. Our approach contains three major components described by the following 3-tuple: HIM = {I, P, M} where HIM is the Health Information Mediator, I is the Interface component, P is the Persistence component and M is the Mediation component. Figure 2 shows the order in which transactions ow through each of the components. Each of these components are described below: I - Interface Component All interactions are carried out via the HIM. The interface component exposes an API that allows systems or applications to make service requests through the HIE. It is responsible for dening and handling all incoming service requests. Service requests are received using a standard protocol (e.g. HTTP) and translated into a common internal format that is accessible by the other components in the layer (e.g. Java Object). The request is then passed to the persistence component for further processing. This component not only provides a single and consistent entry point for all service requests, but also enforces security and access policies for the HIE.
7 Fig. 2. Overview of components in the HIM architecture A single point of access simplies interactions with the HIE as the systems can make service requests without needing to know the location or security requirements of the service providers. The API currently uses web services which aords the HIM greater exibility when connecting systems using varying platforms and technologies. The functions provided by the API are dened according to the requirements of the HIE implementation. In the Rwandan use case this includes functions to save and query a patient's clinical record within the shared health record and to query and update records in the client, provider and facility registries. This component also provides a central place for dening and applying advanced security policies. In this component, access to the API and access to specic functions of the API should be strictly controlled. The component also allows data-level security policies to be applied, if needed. In this paper, we have not addressed the complexities of dening how these security policies could be applied. P - Persistence Component This component receives authorised service requests from the interface component and starts and monitors a transaction required to fulll the request to completion. It stores a copy of each transaction received by the HIM and maintains a persistent data store for the request data, the response data and metadata for each transaction. This data is stored for logging and audit purposes and can also be used to identify and handle exception conditions. This allows the administrators of the system to identify and solve recurring problems or failures. In this paper, we acknowledge that audit trails and exception handling are important issues to consider within a HIE however we do not explore these issues further, at this stage. The metadata stored around transactions allow administrators of the system to monitor transactions and gauge the health of the system. This is useful for discovering bottlenecks and performance problems.
8 M - Mediation Component The mediation component executes transactions. Its main functions are orchestration and message translation. The mediation component is made up of a number of transaction channels. A channel is provided for each transaction type, e.g. a transaction type to save a patient's encounter. It contains the necessary logic to normalise, orchestrate and de-normalise that transaction. Each function exposed by the API in the interface component maps to a transaction type and therefore to a transaction channel. Below we describe the process that occurs within a single transaction channel contained within the mediation component. Fig. 3. The workow of a transaction channel within the transaction mediation component Figure 3 shows the inner workings of the transaction mediation component described earlier. Each transaction type has its own transaction channel. The diagram represents the workow within a single transaction channel. A transaction channel always begins with a normalisation sub-component. This sub-component transforms the request message contained within a transaction to a normalised state. After this process the transaction data must be in a consistent and predictable format to allow components following this to process it in a predictable fashion, no matter what format it arrived in. This process consists of 2 operations. Firstly, an on-ramp transformation is applied. This ensures syntactic interoperability for the transaction. For example, if the transaction arrives from a legacy application that only supported exporting data in a custom XML format, this process would ensure that the XML is transformed into a form that the rest of the exchange can understand, e.g. an HL7v2 4 message. 4 HL7 is a standard messaging format for data within the health domain.
9 Secondly, a translation operation is invoked. This operation is responsible for ensuring the codes and code systems used within the transaction are translated to a standard set of vocabulary or clinical terms that have a common interpretation by other components of the HIM. This involves a call to the terminology service to translate and verify that the codes used within the transaction are in or are translated to an internal standard vocabulary. The terminology server is responsible for maintaining a standard vocabulary and mappings to other vocabularies used by participating systems. In this way semantic interoperability between service requesters and providers is achieved. Following this, the transaction is sent to the orchestration sub-component. This sub-component is responsible for performing implementation-specic orchestration for the current transaction. The process of orchestration is described in Peltz et al[18]. The aim of the orchestration component is to execute the received transaction and perform any consequent action(s) required for this transaction. This could include 0 or more calls to external services. This component also compiles the response for the executed transaction and returns this to the persistence component which forwards the response to the service requester via the interface component. A de-normalisation sub-component is provided for each external service. This sub-component is responsible for transforming (or constructing) a service request into a format that is understandable to the service provider. This operates in a similar way to the normalisation component except the operations occur in reverse order. This approach serves to decouple service providers from the orchestration component, which allows for service providers to be easily modied or replaced with minimal impact on the mediation component. 4.2 Scalability view This view serves to show how the architecture can scale. This viewpoint frames the following concern: The architecture must scale in terms of the number and volume of transactions Figure 4 show the scalability of the architecture. In the architecture there are 3 major components; the interface API, the persistence component and the mediation component. Each of these components are loosely coupled to allow them to be deployed accross dierent servers. This is shown in `Conguration 2' in gure 4. The 3 components are responsible for separate units of work. This loose coupling allows the components to be spread over dierent hardware as long as they can communicate over a network. The ESB architectural model used for this architecture ensures that the components are loosely coupled and can be deployed distributedly. It is also feasible to further separate the persistence component and the transaction mediation component through clustering. The persistence component performs the static function of persisting any transaction that passes through it. As
10 Fig. 4. Scalability congurations of the HIM architecture this function is not dynamic it could easily be replicated over multiple servers with the provision that the data store is kept in sync. This component could also be invoked in an asynchronous fashion as the mediation component subsequent to it does not require this process to complete in order to continue. The transaction mediation component can be scaled horizontally. The transaction mediation component holds a set of channels, one for each transaction type that is supported by the implementation. Each of these channels encapsulates information about how each transaction should be transformed and orchestrated. Each transaction channel runs independently which allows for deployment of the channels across dierent servers. This is shown in conguration 3 in gure Adaptability view This view shows the architecture's ability to grow with a country's NHIS and how new services can be easily added or changed within the architecture. This view frames the following concern: The architecture must be adaptable in a changing environment Adaptability is an important consideration for this architecture. Figure 5 shows how additional services could be added to the architecture. As can be seen, to add additional services the interface component's API needs to be extended to add new API endpoints for each new function that needs to be supported. The persistence component is generic enough that it does not require any change to process new types of service requests. The transaction mediation component is where most of the changes are required. This component is designed to encapsulate transaction mediation logic for each transaction type. A new transaction
11 Fig. 5. Adapability of the HIM architecture channel can easily be added to support a new type of service request. The channel will encapsulate all the logic for normalising the transaction, executing the necessary orchestration steps and to de-normalise the transaction when an external service orchestration call is made. This encapsulation simplies the addition of new service request types as functionality increases and the HIE expands. 5 Analysis In this section the HIM architecture is analysed against the requirements set out in section 3. This HIM architecture is currently being used to drive the development of the Rwandan HIE. This implementation and deployment of the rst phase of the HIE is currently underway and the architecture is already showing benet during this process. The discussion below is based on our experiences of implementing this architecture. One of the core requirements of the HIE is to allow disparate systems to connect to each other easily. These could be legacy or new systems built by various international organizations. The architecture accomplishes this by enforcing a single interface API to connect to the HIE. This API hides the complexity of the HIE as well as the underlying system(s) that are invoked to fulll service requests. This architecture also protects the application requesting services from changes that will inevitably occur to service providers, their API's or migration to a dierent location. This enables and supports local autonomy of the participating systems. As new services are being developed and deployed for the Rwandan NHIS the Rwandan HIM implementation is being used to quickly and easily switch between mock service providers and the actual service provider implementations. This demonstrates one of the most critical features of the architecture; the ability to adapt. We are able to easily swap-out systems providing services as the environment changes. This will inevitably be a very important feature when the system goes live within Rwanda due to the ever changing nature of HISs in low resource environments.
12 The proposed architecture proves to be highly adaptive. This can be seen in the adaptability view of the architecture. Adding additional transaction types to the HIM is simplied by minimising the points at which changes are needed and by encapsulating transaction type specic logic into channels dedicated to specic transactions. This allows the architecture to adapt eectively as the HIE environment and functionality grows. One of the major benets of this architecture is that is does not prescribe the use of a particular data exchange format. There are many messaging standards available in the health domain for syntactic interoperability, each with dierent structures for representing data. Standards exist for various types of messaging needs. For example, sending clinical information (HL7 v2, HL7 v3, OpenEHR Archetypes[6,10,7]) or aggregate health information for reporting (SDMX-HD[3]). A defacto standard for health care messaging has yet to emerge[7]. New standards will emerge over time and current standards will fall away. Given these facts we can see that no single standard will ever be sucient for all messaging needs. Therefore, the architecture must support current and future standards for syntactic interoperability. In the proposed architecture any data can be exchanged as long as we have normalisation and de-normalisation transforms dened to allow the data format to be transformed into and out of a form that the mediation component can understand and orchestrate. This aords the architecture greater exibility in the types of data that can ow through it and allows the architecture to cater for multiple domains of health care even if the standard data exchange formats used within those domains are very dierent. This approach also future proofs the architecture against the inevitable change and evolution that will occur in the syntactic interoperability domain in health care. A criticism of the architecture presented here is that it does not draw a clear line between parts of the system that are implementation specic and parts that can be part of a more general interoperability framework. Within the interface component and the mediation component there are parts that need to be dened depending on the API and business processes that are being implemented. These parts are implementation specic. The interface component denes an API that will be heavily driven by implementation needs and the mediation component denes orchestrations that are dened by the implementation as well as onramp steps and o-ramp steps that would depend on the data representations used within that implementation. It would be benecial to identify the implementation specic aspects of this architecture so that a general interoperability framework can be extracted and implementation specic conguration can be plugged-in as needed. The current architecture does not account for this. This can be explored in future work. The security architecture is also not expanded upon greatly in this architecture. It is identied that having a common entry point into the interoperability layer is benecial in this regard as there is only a single endpoint to secure, however there are much greater considerations that need to be identied. Two main examples are: restricting transactions that specic applications can execute
13 within the interoperability layer and providing data level security on the clinical information that passes through the system. Overall, the architecture fullls the key requirements needed to implement a HIE interoperability architecture for a NHIS in Rwanda. This has been proven to work in a lab environment as the implementation for the Rwandan HIE is being developed. Many of these requirements are not specic to Rwanda and can be applied to other low-resource settings where a HIE is needed. Therefore, the authors believe this architecture is highly applicable for use in other countries. 6 Conclusion In this paper we have identied the need for an interoperability architecture to solve the problem of interoperability between many disparate Health Information Systems. The Rwandan HIE use case was used to drive the identication of the requirements for this middleware layer, however, these requirements are largely applicable to other contexts. We introduce the HIM architecture that attempts to solve all the problems identied by the requirements. ISO is utilised to describe this architecture so that we can ensure all of the concerns are satised by utilising 3 dierent views of the architecture. The HIM architecture description presents a proposed solution for interoperability architectures for use in low-resource countries like Rwanda and attempts to formalise the description of such an architecture so that it can be reused in other settings. The architecture is analysed using experience in implementing the architecture for use in the Rwandan HIE. It is identied that the architecture solves the problems identied by the requirements, however, it fails to provide a clear separation between the implementation specic conguration and the framework for a more general architecture. Overall, the architecture provides a solution to the major problems faced when attempting to facilitate interoperability between many disparate health information systems and it has proven in practice to be an appropriate, adaptable and scalable solution. Acknowledgements The authors wish to acknowledge the support of the Rwanda Ministry of Health and, in particular, the National ehealth coordinator, Dr Richard Gakuba, and advisers, Elizabeth Peloso and Randy Wilson. Other inputs were received from the Rwanda Health Enterprise Architecture (RHEA) project team, including Mead Walker, Beatriz de Faria Leao, Paul Biondich, Wayne Naidoo and Eduardo Jezierski. Additional support was obtained from ez-vida in Brazil and, in particular, Dr Lincoln Moura. The RHEA project is funded by grants from the IDRC (Open Architectures, Standards and Information Systems (OASIS II) Developing Capacity, Sharing Knowledge and Good Principles Across ehealth in Africa. Grant Number: ), the Rockefeller Foundation (Open ehealth Enterprise Architecture Framework and Strategy Development for the Global
14 South; Grant Number: 2009 THS 328) and the Health Informatics Public Private Partnership Project funded by the United States President's Emergency Plan for AIDS Relief (PEPFAR). The HEAL project is funded by grants from the Rockefeller Foundation (Establishing a Health Enterprise Architecture Lab, a research laboratory focused on the application of enterprise architecture and health informatics to low-resource settings, Grant Number: 2010 THS 347) and the IDRC (Health Enterprise Architecture Laboratory (HEAL), Grant Number: ). References 1. Carla AbouZahr and Ties Boerma. Health information systems: the foundations of public health. Bulletin of the World Health Organization, 83(8):578583, August Christian Allen, Darius Jazayeri, Justin Miranda, Paul G. Biondich, Burke W. Mamlin, Ben A. Wolfe, Chris Seebregts, Neal Lesh, William M. Tierney, and Hamish S. Fraser. Experience in implementing the OpenMRS medical record system to support HIV treatment in Rwanda. Studies in health technology and informatics, 129(Pt 1):382386, Jørn Braa, Andrew S. Kanter, Neal Lesh, Ryan Crichton, Bob Jollie, Johan Sæbø, Edem Kossi, and Christopher J. Seebregts. Comprehensive yet scalable health information systems for low resource settings: a collaborative eort in Sierra Leone. AMIA... Annual Symposium proceedings / AMIA Symposium. AMIA Symposium, 2010:372376, Jorn Braa and Humberto Muquinge. Building collaborative networks in Africa on health information systems and open source software development - Experience from the HISP/BEANISH network David Chappell. Enterprise Service Bus: Theory in Practice. O'Reilly Media, July Rong Chen. Towards interoperable and knowledge-based electronic health records using archetype methodology. PhD thesis, Marco Eichelberg, Thomas Aden, Jörg Riesmeier, Asuman Dogac, and Gokce B. Laleci. A survey and analysis of Electronic Healthcare Record standards. ACM Comput. Surv., 37(4):277315, December David Emery and Rich Hilliard. Updating IEEE 1471: Architecture Frameworks and Other Topics. In Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008), pages , Washington, DC, USA, February IEEE. 9. J. M. Ferranti, R. C. Musser, K. Kawamoto, and W. E. Hammond. The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis. Journal of the American Medical Informatics Association, 13(3):245252, May Sebastian Garde, Rong Chen, Heather Leslie, Thomas Beale, Ian McNicoll, and Sam Heard. Archetype-Based Knowledge Management for Semantic Interoperability of Electronic Health Records, pages IOS Press, Patricia Gibbons, Noam Arzt, Susie Burke-Beebe, Chris Chute, Gary Dickinson, Tim Flewelling, Thomas Jepsen, Don Kamens, Joanne Larson, John Ritter, Michael Rozen, Sherry Selover, and Jean Stanford. Coming to Terms: Scoping Interoperability for Health Care. Technical report, February 2007.
15 12. Ibm. IBM Enterprise Service Bus for Healthcare. Technical report, Iso. ISO/IEC FDIS IEEE P42010/D9. Systems and software engineering - Architecture description. Technical report, March Burke W. Mamlin, Paul G. Biondich, Ben A. Wolfe, Hamish Fraser, Darius Jazayeri, Christian Allen, Justin Miranda, and William M. Tierney. Cooking up an open source EMR for developing countries: OpenMRS - a recipe for successful collaboration. AMIA Symposium, pages , Moh. Health Sector Strategic Plan. July June 2012, July Deshendran Moodley, Anban Pillay, and Christopher J. Seebregts. Position Paper: Researching and Developing Open Architectures for National Health Information Systems in Developing African Countries. In International Symposium on Foundations of Health Information Engineering and Systems, volume 1234, August A. M. Ouksel and A. Sheth. Semantic interoperability in global information systems. SIGMOD Rec., 28(1):512, March C. Peltz. Web services orchestration and choreography. Computer, 36(10):4652, October Amanda Ryan and Peter Eklund. The Health Service Bus: an architecture and case study in achieving interoperability in healthcare. Studies in health technology and informatics, 160(Pt 2):922926, M. T. Schmidt, B. Hutchison, P. Lambros, and R. Phippen. The Enterprise Service Bus: Making service-oriented architecture real. IBM Systems Journal, 44(4): , Christopher J. Seebregts, Burke W. Mamlin, Paul G. Biondich, Hamish S. F. Fraser, Benjamin A. Wolfe, Darius Jazayeri, Christian Allen, Justin Miranda, Elaine Baker, Nicholas Musinguzi, Daniel Kayiwa, Carl Fourie, Neal Lesh, Andrew Kanter, Constantin T. Yiannoutsos, and Christopher Bailey. The OpenMRS Implementers Network. International Journal of Medical Informatics, 78(11): , November 2009.
University of KwaZulu-Natal and Council for Scientific and Industrial Research, Durban, South Africa
An Architecture and Reference Implementation of an Open Health Information Mediator: Enabling Interoperability in the Rwandan Health Information Exchange Ryan Crichton 1,2, Deshendran Moodley 1, Anban
More informationHealth IT - the African Approach
Health IT - the African Approach Chris Seebregts, PhD Executive Director, Jembi Health Systems SOUTH AFRICA HIMSS Asia-Pacific, Sep 2012 Outline Challenges and opportunities associated with low resource
More informationPhilippines Architecture Experience Sharing Workshop. Chris Seebregts, PhD Executive Director, Jembi Health Systems SOUTH AFRICA
Philippines Architecture Experience Sharing Workshop Chris Seebregts, PhD Executive Director, Jembi Health Systems SOUTH AFRICA Current Implementation Blog Carl Fourie, Jembi Health Systems, 18 September
More informationIntroduction to OpenHIE and interoperability for national health information systems
Introduction to OpenHIE and interoperability for national health information systems Chris Seebregts CEO Jembi Health Systems NPC - Hon Assoc Prof, Discipline of Computer Science, UKZN Carl Fourie, Ryan
More informationAdvancing public health through information technology. A developing African country perspective
Advancing public health through information technology A developing African country perspective Deshen Moodley UKZN/CSIR-Meraka Centre for Artificial Intelligence Research Health Enterprise Architecture
More informationSemantic interoperability of dual-model EHR clinical standards
Semantic interoperability of dual-model EHR clinical standards Catalina Martínez-Costa Departamento de Informática y Sistemas, Facultad de Informática Universidad de Murcia, CP 30100, Murcia cmartinezcosta@um.es
More informationHow service-oriented architecture (SOA) impacts your IT infrastructure
IBM Global Technology Services January 2008 How service-oriented architecture (SOA) impacts your IT infrastructure Satisfying the demands of dynamic business processes Page No.2 Contents 2 Introduction
More informationOntology-based Archetype Interoperability and Management
Ontology-based Archetype Interoperability and Management Catalina Martínez-Costa, Marcos Menárguez-Tortosa, J. T. Fernández-Breis Departamento de Informática y Sistemas, Facultad de Informática Universidad
More informationEHR Standards Landscape
EHR Standards Landscape Dr Dipak Kalra Centre for Health Informatics and Multiprofessional Education (CHIME) University College London d.kalra@chime.ucl.ac.uk A trans-national ehealth Infostructure Wellness
More informationTechniques for ensuring interoperability in an Electronic health Record
Techniques for ensuring interoperability in an Electronic health Record Author: Ovidiu Petru STAN 1. INTRODUCTION Electronic Health Records (EHRs) have a tremendous potential to improve health outcomes
More informationPlatform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture
Platform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture 1 B. Kamala 2 B. Priya 3 J. M. Nandhini 1 2 3 ABSTRACT The global economic recession and the shrinking budget
More informationService Oriented Architecture 1 COMPILED BY BJ
Service Oriented Architecture 1 COMPILED BY BJ CHAPTER 9 Service Oriented architecture(soa) Defining SOA. Business value of SOA SOA characteristics. Concept of a service, Enterprise Service Bus (ESB) SOA
More informationIntroduction to Service Oriented Architectures (SOA)
Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction
More informationEAI OVERVIEW OF ENTERPRISE APPLICATION INTEGRATION CONCEPTS AND ARCHITECTURES. Enterprise Application Integration. Peter R. Egli INDIGOO.
EAI OVERVIEW OF ENTERPRISE APPLICATION INTEGRATION CONCEPTS AND ARCHITECTURES Peter R. Egli INDIGOO.COM 1/16 Contents 1. EAI versus SOA versus ESB 2. EAI 3. SOA 4. ESB 5. N-tier enterprise architecture
More informationStandards and their role in Healthcare ICT Strategy. 10th Annual Public Sector IT Conference
Standards and their role in Healthcare ICT Strategy 10th Annual Public Sector IT Conference Peter Connolly Oct 2014 What is the Direction of Travel? 1 Understanding the Why- The Data Context 2 Stakeholder
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7 No. 7, September-October 2008 Applications At Your Service Mahesh H. Dodani, IBM,
More informationArchetype-Based Knowledge Management for Semantic Interoperability of Electronic Health Records
Medical Informatics in a United and Healthy Europe K.-P. Adlassnig et al. (Eds.) IOS Press, 2009 2009 European Federation for Medical Informatics. All rights reserved. doi:10.3233/978-1-60750-044-5-1007
More informationA Quick Introduction to SOA
Software Engineering Competence Center TUTORIAL A Quick Introduction to SOA Mahmoud Mohamed AbdAllah Senior R&D Engineer-SECC mmabdallah@itida.gov.eg Waseim Hashem Mahjoub Senior R&D Engineer-SECC Copyright
More informationA Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus
A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus Karim M. Mahmoud 1,2 1 IBM, Egypt Branch Pyramids Heights Office Park, Giza, Egypt kmahmoud@eg.ibm.com 2 Computer
More informationFederal Enterprise Architecture and Service-Oriented Architecture
Federal Enterprise Architecture and Service-Oriented Architecture Concepts and Synergies Melvin Greer Chief Strategist, SOA / Cloud Computing Certified Enterprise Architect Copyright August 19, 2010 2010
More informationA Framework for Semantic Interoperability in Healthcare: A Service Oriented Architecture based on Health Informatics Standards
ehealth Beyond the Horizon Get IT There S.K. Andersen et al. (Eds.) IOS Press, 2008 2008 Organizing Committee of MIE 2008. All rights reserved. 759 A Framework for Semantic Interoperability in Healthcare:
More informationCombining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus
Combining Service-Oriented Architecture and Event-Driven Architecture using an Enterprise Service Bus Level: Advanced Jean-Louis Maréchaux (jlmarech@ca.ibm.com), IT Architect, IBM 28 Mar 2006 Today's business
More informationPlatform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture
Platform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture 1 B. Kamala 2 B. Priya 3 J. M. Nandhini - 1 AP-II, MCA Dept, Sri Sai Ram Engineering College, Chennai, kamala.mca@sairam.edu.in
More informationSOA Myth or Reality??
IBM TRAINING S04 SOA Myth or Reality Jaqui Lynch IBM Corporation 2007 SOA Myth or Reality?? Jaqui Lynch Mainline Information Systems Email jaqui.lynch@mainline.com Session S04 http://www.circle4.com/papers/s04soa.pdf
More informationService Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage because
More informationArchitectural Frameworks for Developing National Health Information Systems in Low and Middle Income Countries
Architectural Frameworks for Developing National Health Information Systems in Low and Middle Income Countries Thinasagree Mudaly 1, Deshendran Moodley 1, Anban Pillay 1, Christopher J Seebregts 1,2 1
More informationAn Oracle White Paper October 2013. Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus
An Oracle White Paper October 2013 Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus Table of Contents Introduction...
More informationUsing ESB and BPEL for evolving healthcare systems towards SOA
ehealth Beyond the Horizon Get IT There S.K. Andersen et al. (Eds.) IOS Press, 2008 2008 Organizing Committee of MIE 2008. All rights reserved. 747 Using ESB and BPEL for evolving healthcare systems towards
More informationService-Oriented Architectures
Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systems
More informationDevelopers Integration Lab (DIL) System Architecture, Version 1.0
Developers Integration Lab (DIL) System Architecture, Version 1.0 11/13/2012 Document Change History Version Date Items Changed Since Previous Version Changed By 0.1 10/01/2011 Outline Laura Edens 0.2
More informationService-Oriented Architecture: Analysis, the Keys to Success!
Service-Oriented Architecture: Analysis, the Keys to Success! Presented by: William F. Nazzaro CTO, Inc. bill@iconatg.com www.iconatg.com Introduction Service-Oriented Architecture is hot, but we seem
More informationGovernment's Adoption of SOA and SOA Examples
Government's Adoption of SOA and SOA Examples Presented by : Ajay Budhraja, Chief of Enterprise Services ME (Engg), MS (Management), PMP, CICM, CSM, ECM (Master) AIIM, ITIL-F Copyright 2008 Ajay Budhraja
More informationIntegration Information Model
Release 1.0.1 The openehr Reference Model a. Ocean Informatics Editors: T Beale a Revision: 0.6 Pages: 15 Date of issue: 22 Jul 2006 Keywords: EHR, reference model, integration, EN13606, openehr EHR Extract
More informationThe Open Medical Record System (OpenMRS)
The Open Medical Record System (OpenMRS) Christopher Seebregts CEO, Jembi Health Systems NPC Hon Assoc Prof, Discipline of Computer Science, UKZN OpenMRS Partnerships Lead Pascal Brandt Lead Developer,
More informationSOA Success is Not a Matter of Luck
by Prasad Jayakumar, Technology Lead at Enterprise Solutions, Infosys Technologies Ltd SERVICE TECHNOLOGY MAGAZINE Issue L May 2011 Introduction There is nothing either good or bad, but thinking makes
More informationESB as a SOA mediator: Minimizing Communications Complexity
ESB as a SOA mediator: Minimizing Communications Complexity Nadya Alexandra Calderón R., Sergio Daniel Moreno P. Universidad de los Andes. Ingeniería de Sistemas y Computación. Bogotá, Colombia n-calder@uniandes.edu.co,
More informationInteroperable Medical Record Exchange System among Hospitals in Ethiopia using EMR
Interoperable Medical Record Exchange System among Hospitals in Ethiopia using EMR Tigist Tedla HiLCoE, Computer Science Programme, Ethiopia tgyetedla@gmail.com Abrehet Omer HiLCoE, Ethiopia Department
More informationService-Oriented Architecture and Software Engineering
-Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based
More informationBusiness Process Management Enabled by SOA
Business Process Management Enabled by SOA Jyväskylä 8.5.2007 Kimmo Kaskikallio IT Architect IBM Software Brands Five middleware product lines designed to work together Service-Oriented Architecture (SOA)
More informationUnderstanding Service-Orientation Part II: The Principles
by Raj Balasubramanian, Enterprise IT Architect for IBM Software Group, Benjamin Carlyle, Architect in the Rail industry, Cesare Pautasso Assistant professor in the new Faculty of Informatics at the University
More informationITU-T Kaleidoscope Conference Innovations in NGN. Managing NGN using the SOA Philosophy. Y. Fun Hu University of Bradford y.f.hu@bradford.ac.
ITU-T Kaleidoscope Conference Innovations in NGN Managing NGN using the SOA Philosophy Y. Fun Hu University of Bradford y.f.hu@bradford.ac.uk Next Generation Network (NGN) A IP/IMS based network Provide
More informationEmerging Technologies Shaping the Future of Data Warehouses & Business Intelligence
Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence Service Oriented Architecture SOA and Web Services John O Brien President and Executive Architect Zukeran Technologies
More informationEnterprise Application Designs In Relation to ERP and SOA
Enterprise Application Designs In Relation to ERP and SOA DESIGNING ENTERPRICE APPLICATIONS HASITH D. YAGGAHAVITA 20 th MAY 2009 Table of Content 1 Introduction... 3 2 Patterns for Service Integration...
More informationInformation Models and Master Data Management in Business Process Management
Information Models and Master Data Management in Business Process Management Timo Itälä SoberIT, TKK Outline Example of a business process and business services Need for common master data in SOA Discovering
More informationService Oriented Architecture
Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline
More informationElectronic Medical Records Getting It Right and Going to Scale
Electronic Medical Records Getting It Right and Going to Scale W. Ed Hammond, Ph.D. Duke University Medical Center 02/03/2000 e-hammond, Duke 0 Driving Factors Patient Safety Quality Reduction in cost
More informationService Virtualization: Managing Change in a Service-Oriented Architecture
Service Virtualization: Managing Change in a Service-Oriented Architecture Abstract Load balancers, name servers (for example, Domain Name System [DNS]), and stock brokerage services are examples of virtual
More informationConcept of knowledge-based self-management pathways for the empowerment of diabetes patients
en12 Original Article Concept of knowledge-based self-management pathways for the empowerment of diabetes patients Holger Schmuhl 1, Hans Demski 1, Ilias Lamprinos 2, Asuman Dogac 3, Manuela Ploessnig
More informationSINTERO SERVER. Simplifying interoperability for distributed collaborative health care
SINTERO SERVER Simplifying interoperability for distributed collaborative health care Tim Benson, Ed Conley, Andrew Harrison, Ian Taylor COMSCI, Cardiff University What is Sintero? Sintero Server is a
More informationA Near Real-Time Personalization for ecommerce Platform Amit Rustagi arustagi@ebay.com
A Near Real-Time Personalization for ecommerce Platform Amit Rustagi arustagi@ebay.com Abstract. In today's competitive environment, you only have a few seconds to help site visitors understand that you
More informationA standards-based approach to application integration
A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist Macnair@us.ibm.com Copyright IBM Corporation 2005. All rights
More informationARTICLE IN PRESS. international journal of medical informatics xxx (2009) xxx xxx. journal homepage: www.intl.elsevierhealth.
international journal of medical informatics xxx (2009) xxx xxx journal homepage: www.intl.elsevierhealth.com/journals/ijmi The OpenMRS Implementers Network Christopher J. Seebregts a,b,, Burke W. Mamlin
More informationService Oriented Architectures
8 Service Oriented Architectures Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) alonso@inf.ethz.ch http://www.iks.inf.ethz.ch/ The context for SOA A bit of history
More informationTomáš Müller IT Architekt 21/04/2010 ČVUT FEL: SOA & Enterprise Service Bus. 2010 IBM Corporation
Tomáš Müller IT Architekt 21/04/2010 ČVUT FEL: SOA & Enterprise Service Bus Agenda BPM Follow-up SOA and ESB Introduction Key SOA Terms SOA Traps ESB Core functions Products and Standards Mediation Modules
More informationAdvanced and secure architectural EHR approaches
International Journal of Medical Informatics (2006) 75, 185 190 Advanced and secure architectural EHR approaches Bernd Blobel Chair of the EFMI WG Electronic Health Records, University Hospital Magdeburg,
More informationChapter 11 Mining Databases on the Web
Chapter 11 Mining bases on the Web INTRODUCTION While Chapters 9 and 10 provided an overview of Web data mining, this chapter discusses aspects of mining the databases on the Web. Essentially, we use the
More informationPractical Implementation of a Bridge between Legacy EHR System and a Clinical Research Environment
Cross-Border Challenges in Informatics with a Focus on Disease Surveillance and Utilising Big-Data L. Stoicu-Tivadar et al. (Eds.) 2014 The authors. This article is published online with Open Access by
More informationJOURNAL OF OBJECT TECHNOLOGY
JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 8, November-December 2008 What s Your Information Agenda? Mahesh H. Dodani,
More informationSERVICE ORIENTED ARCHITECTURE
SERVICE ORIENTED ARCHITECTURE Introduction SOA provides an enterprise architecture that supports building connected enterprise applications to provide solutions to business problems. SOA facilitates the
More informationVALLIAMMAI ENGNIEERING COLLEGE SRM Nagar, Kattankulathur 603203.
VALLIAMMAI ENGNIEERING COLLEGE SRM Nagar, Kattankulathur 603203. DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING Year & Semester : II / III Section : CSE Subject Code : CP7028 Subject Name : ENTERPRISE
More informationDefining the content of shared electronic medical records (emr)
Defining the content of shared electronic medical records (emr) An pragmatic and cost-saving initiative of the College of Family Physicians of Canada With over a 100 million consultations last year, the
More informationAchieving business agility and cost optimization by reducing IT complexity. The value of adding ESB enrichment to your existing messaging solution
Smart SOA application integration with WebSphere software To support your business objectives Achieving business agility and cost optimization by reducing IT complexity. The value of adding ESB enrichment
More informationEnterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing
Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Presented by : Ajay Budhraja, Chief, Enterprise Services ME (Engg), MS (Mgmt), PMP, CICM, CSM,
More informationService Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies
Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage because
More informationCSCI 5828 Spring 2010 Foundations of Software Engineering. - Arpit Sud
CSCI 5828 Spring 2010 Foundations of Software Engineering - Arpit Sud 1 Agenda What is it? Why to use it? When to use it? How to implement it? Where not to apply it? 2 Service oriented Architecture 3 What
More informationFor <Project> Version 1.0
Oklahoma Department of Human Services Data Services Division Service-Oriented Architecture (SOA) For Version 1.0 Table of Contents 1. Service Oriented Architecture (SOA) Scope...
More informationDelivering Heterogeneous Hydrologic Data services with an Enterprise Service Bus Application
18 th World IMACS / MODSIM Congress, Cairns, Australia 13-17 July 2009 http://mssanz.org.au/modsim09 Delivering Heterogeneous Hydrologic Data services with an Enterprise Service Bus Abstract: Bai, Q.F
More informationCooking Up An Open Source EMR For Developing Countries: OpenMRS A Recipe For Successful Collaboration
Cooking Up An Open Source EMR For Developing Countries: OpenMRS A Recipe For Successful Collaboration Burke W. Mamlin, M.D., Paul G. Biondich, M.D., M.S., Ben A. Wolfe, Hamish Fraser, M.B. Ch.B., M.Sc.,
More informationSOFT 437. Software Performance Analysis. Ch 5:Web Applications and Other Distributed Systems
SOFT 437 Software Performance Analysis Ch 5:Web Applications and Other Distributed Systems Outline Overview of Web applications, distributed object technologies, and the important considerations for SPE
More informationFive best practices for deploying a successful service-oriented architecture
IBM Global Services April 2008 Five best practices for deploying a successful service-oriented architecture Leveraging lessons learned from the IBM Academy of Technology Executive Summary Today s innovative
More informationMyths About Service-Oriented Architecture Demystifying SOA. producers can coexist, and still have no dependence on each other.
WSJ: SOA Myths About Service-Oriented Architecture Demystifying SOA Service-oriented architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers,
More informationThe ERS IC-EHR as Local, Regional and National ehealth Infrastructure July 2010
The ERS IC-EHR as Local, Regional and National ehealth Infrastructure July 2010 Table of contents Present situation!... 1 What healthcare wants!... 2 ERS IC-EHR: Introduction!... 4 ERS IC-EHR: Integrating
More informationGuideline. Enterprise Architecture Guide. 1. Purpose. 2. Scope. 3. Related documents. 4. Enterprise Architecture Guide
Guideline Policy # QH-GDL-402-6-3:2014 Guide 1. Purpose This Guideline provides an overview of the document structure of the Department of Health, an index to its contents and a consolidated definitions
More informationMDM and SOA Timo Itälä T-86.5161
MDM and SOA Timo Itälä T-86.5161 Outline Need for SOA Options for SOA Need for common master data in SOA Discovering master data Managing master data Managing external master data SOA and MDM 2 Recap:
More informationShort messaging solutions, including XMPP based instant messaging and text based conferences, between health care providers and general practitioners
Short messaging solutions, including XMPP based instant messaging and text based conferences, between health care providers and general practitioners Sokol Dhana One of the most challenging problems in
More informationUnlocking the Power of SOA with Business Process Modeling
White Paper Unlocking the Power of SOA with Business Process Modeling Business solutions through information technology TM Entire contents 2006 by CGI Group Inc. All rights reserved. Reproduction of this
More informationSOA REFERENCE ARCHITECTURE: WEB TIER
SOA REFERENCE ARCHITECTURE: WEB TIER SOA Blueprint A structured blog by Yogish Pai Web Application Tier The primary requirement for this tier is that all the business systems and solutions be accessible
More informationThe Service Revolution software engineering without programming languages
The Service Revolution software engineering without programming languages Gustavo Alonso Institute for Pervasive Computing Department of Computer Science Swiss Federal Institute of Technology (ETH Zurich)
More informationA Study on the Integration Model of EIS Based on SOA
A Study on the Integration Model of EIS Based on SOA Xu Yang and Zhanhong Xin School of Economics and Management, Beijing University of Posts and Telecommunications, Beijing 100876, P.R. China yangx.china@gmail.com
More informationOpportunities for mhealth in the Developing World: OpenMRS
Opportunities for mhealth in the Developing World: OpenMRS Hamish SF Fraser MBChB, MSc, FACMI Assistant Professor, Division of Global Health Equity, Brigham and Womens Hospital and Harvard Medical School
More informationSecondary Use of EMR Data View from SHARPn AMIA Health Policy, 12 Dec 2012
Secondary Use of EMR Data View from SHARPn AMIA Health Policy, 12 Dec 2012 Christopher G. Chute, MD DrPH, Professor, Biomedical Informatics, Mayo Clinic Chair, ISO TC215 on Health Informatics Chair, International
More informationUsing the OpenMRS. system to strengthen health care delivery in Rwanda
Using the OpenMRS electronic medical record system to strengthen health care delivery in Rwanda Dr Hamish SF Fraser Partners In Health Division of Global Health Equity, BWH Harvard Medical School Overview
More informationService Oriented Architecture for Enterprise Applications
Service Oriented Architecture for Enterprise Applications SHANKAR KAMBHAMPATY and SATISH CHANDRA Technology Architecture Group Satyam Computer Services Limited C5, TSR Towers, Raj Bhavan Road Somajiguda,
More informationIntroduction into Web Services (WS)
(WS) Adomas Svirskas Agenda Background and the need for WS SOAP the first Internet-ready RPC Basic Web Services Advanced Web Services Case Studies The ebxml framework How do I use/develop Web Services?
More informationEvent based Enterprise Service Bus (ESB)
Event based Enterprise Service Bus (ESB) By: Kasun Indrasiri 128213m Supervised By: Dr. Srinath Perera Dr. Sanjiva Weerawarna Abstract With the increasing adaptation of Service Oriented Architecture for
More informationSOA: The missing link between Enterprise Architecture and Solution Architecture
SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing
More informationSOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q. Exam Code: S90-03A. Exam Name: SOA Design & Architecture
SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q Number: S90-03A Passing Score: 800 Time Limit: 120 min File Version: 14.5 http://www.gratisexam.com/ Exam Code: S90-03A Exam Name:
More informationSOA @ ebay : How is it a hit
SOA @ ebay : How is it a hit Sastry Malladi Distinguished Architect. ebay, Inc. Agenda The context : SOA @ebay Brief recap of SOA concepts and benefits Challenges encountered in large scale SOA deployments
More informationService Mediation. The Role of an Enterprise Service Bus in an SOA
Service Mediation The Role of an Enterprise Service Bus in an SOA 2 TABLE OF CONTENTS 1 The Road to Web Services and ESBs...4 2 Enterprise-Class Requirements for an ESB...5 3 Additional Evaluation Criteria...7
More informationMethods and tools for data and software integration Enterprise Service Bus
Methods and tools for data and software integration Enterprise Service Bus Roman Hauptvogl Cleverlance Enterprise Solutions a.s Czech Republic hauptvogl@gmail.com Abstract Enterprise Service Bus (ESB)
More informationService Oriented Architecture: A driving force for paperless healthcare system
2012 International Conference on Computer Technology and Science (ICCTS 2012) IPCSIT vol. 47 (2012) (2012) IACSIT Press, Singapore DOI: 10.7763/IPCSIT.2012.V47.16 Service Oriented Architecture: A driving
More informationATHABASCA UNIVERSITY. Enterprise Integration with Messaging
ATHABASCA UNIVERSITY Enterprise Integration with Messaging BY Anuruthan Thayaparan A thesis essay submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in INFORMATION
More informationApplying SOA to OSS. for Telecommunications. IBM Software Group
IBM Software Group Applying SOA to OSS for Telecommunications Kevin Twardus Manager of Industry Architecture and Standards IBM Software Group Communications Sector IBM Corporation The Details of SOA depends
More informationDavid Pilling Director of Applications and Development
Service Oriented Architecture for Law Firms: SOA is inevitable, are you ready? David Pilling Director of Applications and Development "Things should be made as simple as possible, but no simpler. -- Albert
More informationCLOUD BASED SEMANTIC EVENT PROCESSING FOR
CLOUD BASED SEMANTIC EVENT PROCESSING FOR MONITORING AND MANAGEMENT OF SUPPLY CHAINS A VLTN White Paper Dr. Bill Karakostas Bill.karakostas@vltn.be Executive Summary Supply chain visibility is essential
More informationReverse Engineering in Data Integration Software
Database Systems Journal vol. IV, no. 1/2013 11 Reverse Engineering in Data Integration Software Vlad DIACONITA The Bucharest Academy of Economic Studies diaconita.vlad@ie.ase.ro Integrated applications
More informationDistributed systems. Distributed Systems Architectures
Distributed systems Distributed Systems Architectures Virtually all large computer-based systems are now distributed systems. Information processing is distributed over several computers rather than confined
More informationGetting Started with Service- Oriented Architecture (SOA) Terminology
Getting Started with - Oriented Architecture (SOA) Terminology Grace Lewis September 2010 -Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing systems it is neither a
More informationAquaLogic Service Bus
AquaLogic Bus Wolfgang Weigend Principal Systems Engineer BEA Systems 1 What to consider when looking at ESB? Number of planned business access points Reuse across organization Reduced cost of ownership
More informationISO 18308 INTERNATIONAL STANDARD. Health informatics Requirements for an electronic health record architecture
INTERNATIONAL STANDARD ISO 18308 First edition 2011-04-15 Health informatics Requirements for an electronic health record architecture Informatique de santé Exigences relatives à une architecture de l'enregistrement
More information