PlugIT results: Open integration solution specifications and application interfaces

1. PlugIT results:Open integration solution specifications and application interfaces Context Management and Common Services Juha Rannanheimo, researcher, PlugIT-project Marko Sormunen, Mika Tuomainen, Juha Mykkänen, Jari Porrasmaa

2. Needs and requirements • The hospital information systems in Finland are reaching a mature age and many hospitals are in transition • New core hospital information systems • Legacy systems are being migrated into modern solutions • The number of specialized clinical information systems and regional information systems is increasing  systems and technical infrastructures are heterogeneous • systems have been implemented using variety of different technologies • there is also different kind of integrations and two-party agreements

3. Needs and requirements • Healthcare professionals may need 3–5 clinical and administrative applications simultaneously for a given service – each with their own access codes, patient files and code sets (duplicate data) • Consequently the usability of such clusters of software is very low • needs for increasing the compatibility of healthcare applications software  these developments needs create integration needs for the systems  there is need for shared data and functionality between processes and systems

4. Needs and requirements • HL7 messaging standard is in wide use in Finland and it must also be supported by new systems • However, there are also needs and requirements for other types of integration methods and technologies to be used • interoperability between heterogeneous systems is a major challenge • The focus of systems development and implementation should be in the enterprise and organizational level • supporting the needs of health service providers to develop their operation models and service chains • decreasing threshold of healthcare applications by developing more efficient and open solutions

5. Needs and requirements • Solutions should be faced • the requirements • the existing applications, and the architectures and technology • suitable open standards • new methods and technology  Can the international standardization and development work be used as a basis for shared services that can be incorporated into the existing Finnish software products?  Which shared services are the most crucial ones for the migration of the HIS and clinical information system (CIS) aggregate?

6. Two folded working methodology The standards and existing needs and products were analyzed and the gap between the two became the focus point of specification efforts • Top-down approach starting from finding, reviewing and adapting standards and research needs • HL7 CCOW, OMG standards, CEN HISA architectures were the most relevant sources of useful interfaces and information to be used in Finland • in long-term means international compatibility, maintainability • Bottom-up approach starting from existing two-party agreements and practical high-priority needs • The requirements from healthcare providers and IT departments were taken into account • Co-operation between participants was arranged through workshops

7. Open integration solutions • Requirements describe that there is clear need for: • shared common components/services • open and reusable integration solution specifications • standardized application interfaces • The idea of shared service/component between multiple systems has been described in numerous standards and development projects • Service-based integration model has been proposed to increase reuse and the decrease redundancy in healthcare applications  PlugIT's standard "plugs"

8. Standard "plugs" • Standard "plugs" are • which software companies will implement in their products • which enable pieces of applications software by different vendors to be plugged together into more usable comprehensive clusters of software • Minimizes duplication across applications • will benefit implementers of core HIS systems and the wider array of clinical information system (CIS) implementers. • To get all benefits, requires implementations • in core HIS systems, so clinical information systems implementers can utilize their products those interfaces

9. Direct benefits • Software vendors: • competitiveness is improved due to easy interconnectivity • increase reuse and thereby save time & money • the introduction threshold of new systems is reduced significantly • Healthcare organisations: • streamline data processing and thereby save time and improve efficiency • new applications can be taken into use more easily • enable healthcare facilities to select the functionally best software, even if it is not based on the same technology as their other applications Indirect benefits • Users: • better usability • avoid duplicated operations • more time to care • Patients: • better and faster care/service The benefits of standard "plugs"

10. Specifications • Context Management • Common Core Services • User authentication and user information • Person selection and information • Authorization • Terminology and classifications • The first set of specifications approved by the project Board in November 2003 • after they have been tried in practice in the pilot cases and scrutinized by partner organizations in a biannual project workshop • Further specifications and extended versions approved in April 2004, after the same procedure

11. Context Management • Clinical context integration (also visual integration) identified already in early discussions • end-user's one of the most practical problems was the time required for duplicate operations, such as login and patient selection • The idea of clinical context management is to "synchronize" the various separate applications from the end-user point-of-view • behind the scenes context manager coordinates context changes • Using a shared (clinical) context, different applications give a more unified view to the clinical user • includes single sign-on between the applications, and a definition of contexts, such as a patient, which all the participating applications share and synchronize to

12. Context Management • HL7 CCOW context management standard only open standard • Standards-based CCOW-solutions into existing applications provided too high an implementation threshold • Furthermore, the availability and licensing policies of the needed software packages were problematic for the end-user organizations.  lightweight solution based on the CCOW standard and the use of simple HTTP calls for the network communication • solve the most urgent needs of visual integration • enable a streamlined development process for all of the needed software • be extensible for new requirements

13. Context Management • Our goal was not to repeat all the requirements defined in the standard but to outline the minimum level of functionality required in reaching the visual integration  The level of solution is somewhat minimal, but it sufficiently solves the most urgent requirements in Finland

14. Common Services • A common service refers to a service definition which is typically implemented once in an organization and is then utilized by several information systems • The core HIS system is a natural provider of these services but there can be other providers as well. • Services are collections of interfaces, typically used over a network.

15. Common Services • The background studies on the different standards and on the PICNIC common services served as material for the selection of core services to be defined in the PlugIT  functionality of the services based on standards, like • OMG's Person Identification Service (PIDS) • OMG's Terminology Query Service (TQS) • Java Authentication and Authorization Service (JAAS) • even there was incompatibilities on integration technology, functional scope mainly fitted the requirements

16. Common Services • Application development seems to be more and more services based  Web-service-like implementations • are self-contained modules that have open, Internet-oriented, standards-based interfaces • allows to be accessed by customers, independent of hardware, operating system, or programming environment • no information about how the service is implemented is necessary in the contract • The interfaces have evolved into XML based messaging using HTTP(S) protocol

17. Common Services

18. Common Services

19. The architecture of XML messaging

20. Common Services • The main result was the set of common core services specifications • User authentication and user information • Person selection and information • Authorization • Terminology and classifications • and the reference implementations of these services • Prototype/reference implementations built were found useful from the viewpoint of companies and project workers. They promote the understanding of standards and can be used as basis for describing and discussion the standards in question.

21. Future • The interface specifications defined in the project are being offered to HL7 Finland for national acceptance (HL7 Finland Common Services SIG) • PlugIT experiences in the development of common services will also serve on the international level. • SerAPI: • suggested research project to FinnWell technology programme of TEKES • 2004-2007, implemented by same research units as in PlugIT project • possibility to continue open API interface work of PlugIT • participation in HL7 Finland and HL7 International Common Services?