Clinical Genetic Management and Information System

Size: px

Start display at page:

Download "Clinical Genetic Management and Information System"

Hilary Adams
6 years ago
Views:

1 Clinical Genetic Management and Information System for supply to the Health Trusts in Helse Vest Case No. 2012/068 Part 2 K Appendix 1, Attachment 2: Integration Requirements

2 Content 1 INTRODUCTION OBJECTIVES SYSTEM SKETCH OF INTEGRATIONS OVERALL CONSTRAINTS AND GUIDELINES FOR INTEGRATION ARCHITECTURE INTEGRATION STRATEGY ARCHITECTURE PRINCIPLES USE CASES RETRIEVING PATIENT DEMOGRAPHICS FROM THE PATIENT REGISTRY AND PERSON REGISTRY GETTING INFORMATION ABOUT FAMILY RELATIONS STARTING THE SYSTEM WITH START-UP PARAMETERS UPDATE PATIENT ID UPDATE PATIENT DEMOGRAPHICS RETRIEVE LABORATORY RESULTS EXPORT OF DATA FOR REPORTING EXPORT OF DATA TO RESEARCH AND QUALITY REGISTERS GENERAL TECHNICAL REQUIREMENTS SECURITY REQUIREMENTS REQUIREMENTS FOR MONITORING AND LOGGING Page 2 of 13

1 Introduction This document is a detailed description of the integration requirements for the procurement of a Clinical Genetic Management and Information System, hereinafter referred to as "the

3 1 Introduction This document is a detailed description of the integration requirements for the procurement of a Clinical Genetic Management and Information System, hereinafter referred to as "the solution", for Helse Bergen. It is desirable that the solution should be integrated with core services offered and used in Helse Vest, i.e. services, registers and functionality that are outside of the solution 1.1 Objectives The objectives of the technical descriptions that are set up in this document are: - To ensure that the functional requirements are supported by relevant technical integration descriptions / requirements - Ensuring that the solution is seen in the context of the existing infrastructure in the health region - To get the best possible overall picture of the technical aspect of a system delivery 1.2 System sketch of integrations The figure below provides an overview of the most relevant systems and equipment that are involved in clinical genetics activities, but the specific integration needs of the solution are described specifically in chapter 3 in this document. Figure 1 Solution for a Clinical Genetic Information System an integration sketch Page 3 of 13

4 2 Overall constraints and guidelines for integration architecture 2.1 Integration strategy Helse Vest has a regional integration strategy that is to be followed when implementing new integrations. The strategy is quality assured by Nasjonal ICT, and principles, requirements and recommendations are according to their report: Service oriented architecture for the specialist health care services. Some key elements from the integration strategy are summarized below: For message based services (asynchronous), the communication should go through Helse Vest s middle ware, Microsoft BizTalk Server. In accordance with Nasjonal ICT s architecture, the messages should be in the standard formats of KITH or HL7. For synchronous communication, a set of web services should be used. In accordance with Nasjonal ICT s architecture, these services will adhere to the ISO standard HL7 v3. Replication of data should only take place if business needs dictate that this is the only solution. In other cases, integrations/look-ups to source systems should provide data when the system itself is not master of the data elements. The solution should be implemented in accordance with Helse Vest s integration strategy and principles. Any deviations from this should be documented in the Solution Specification. 2.2 Architecture principles Helse Vest has defined a set of architecture principles that apply to all enterprises within the secondary health care in the region. These principles define stable, overarching rules and guidelines for management and further development of the architecture, and shall ensure that the architecture supports the business goals and purpose. In addition to the regional principles one has also chosen to fulfil the national architecture principles developed by DIFI (The Agency for Public Management and egovernment) and the Nasjonal ICT. Two important national architecture principles one has chosen to fulfil, are the service orientation and interoperability principles. The principle of interoperability is realized by connecting systems technically together using the Web services standard, and through information exchange using a common reference standard; HL7 version 3. Use of the reference standard HL7 v3 ensures a common understanding of the meaning content of the information exchanged between systems. The National ICT has in collaboration with the regional health care enterprises prepared implementation profiles for the use of HL7 v3 - in this context the profiles for patient demographic- and logistical services are relevant. Page 4 of 13

5 3 Use cases For some of the use cases, descriptive process diagrams have been added to illustrate how the solution should interact with core services. A subset of the standard BPMN notation has been used in the diagrams. 3.1 Retrieving patient demographics from the patient registry and person registry The web service AddGetDemographics must be used for retrieving name and address from DIPS PAS based on an F- or D-number. This service is an aggregated web service developed by Helse Vest IKT hosted on MS Biztalk server. It leverages HL7 standard service portfolio and the person registry (National Population Register). The solution does not have to consume underlying HL7 services. AddGetDemographics has an identical interface to the HL7 v3 service PatientRegistry.GetDemographics. AddGetDemographics will, when called, make an attempt to retrieve patient demographics by calling the service PatientRegistry.GetDemographics. If the patient does not exist person demography will be retrieved from the person registry by using the service PersonRegistry.GetDemographics. The person will then be added to the DIPS PAS registry by using the service PatientRegistry.Add. Patient demography will be returned to the calling client. The request and response interactions are identical with the interactions PRPA_IN201307UV and PRPA_IN201308UV02 that are used by the HL7 v3 service PatientRegistry.GetDemographics, they only differ by names. Request Response PRPA_IN201307UV02_HV PRPA_IN201308UV02_HV Page 5 of 13

6 Person registry Clinical Genetic Management and Information System Figure 2 AddGetDemographics Requirements for security: The use of the web service should satisfy security requirements as specified in 4.1. Page 6 of 13

7 Genetic information system 3.2 Getting information about family relations The solution must be able to call the web service familiefolkeregister to bring out the family relationships of a given person. Parameters to the web service are the person identity, and user code to the current user that calls the service. The return of the service provides a list of individuals with demographic information with the following possible relationship value to the given person: Mother, Father, Spouse, Separated, Partner, Son, Daughter, Sister, Brother, Sister, Half-Brother and 'Same Adresse'. 3.3 Starting The System with start-up parameters The active patient is transferred automatically from the patient registry (DIPS PAS) to the solution by starting the solution with (among other things) the patient Id as start-up parameter. The patient should be created in internal registry if it does not exist already, and a screen with the selected patient should be displayed in the solution Workflow Core services Cell therapy system User Select patient from DIPS appoinment diary Start professional system with selected patient Checks if patient is in internal register DIPS Tools Integration starts professional system with selected patient id No Get demographic data HL7 PatientRegistry. GetDemographics Yes Create patient in internal register Start registration Prepare for registration Figure 3 Receive a patient id and optionally create a patient Technical requirements It should be able to start The System using DIPS Tools Integration with context synchronization. There are two ways to start another application from DIPS EPR / PAS: 1. Starting the application by specifying the command line (CMD) with parameters 2. Registering a COM component that is loaded and called each time the user selects a specific menu item. a. Calls to a COM component that implements the interface IDIPSToolsIntegration b. IDIPSToolsIntegration has one method: execute (IStrings) Page 7 of 13

8 c. 3rd parties can integrate without being dependent on changes in DIPS client d. Can transfer a variety of parameters, e.g. patient Id and / or name. Note: It is not possible to send the password as a parameter. Username is however possible to submit, e.g. active user in DIPS. Upon receipt of a patient ID the System shall search for the patient in the internal register. If the patient does not exist it must be retrieved from the core patient registry (DIPS PAS) using the HL7 service PatientRegistry.GetDemographics, before it is created in the internal register. Request: PRPA_IN201307NO Response: PRPA_IN201308NO Context synchronization Context synchronization with DIPS requires the use of DIPS Context Manager (CM). Other client applications can subscribe to events from the DIPS CM application, such as the user switches to a different patient. DIPS CM is based on the CCOW standard (Clinical Context Object Workgroup from HL7), a framework for adapting to contexts from other products, and that can be used to integrate DIPS with context management products from other vendors. 3.4 Update patient Id The System should merge patient records if these refer to the same physical person. Example: a patient record with an H-number as identifier (H-numbers (help numbers) are used for new born children and persons with unknown identity) is updated to use the proper F/D number-identifier (social security number for Norwegian citizens/norwegian social security number for foreign citizens, respectively). DIPS will send a notification message to The System when the merge of patient records occur in DIPS. The action taken by The System upon reception of the notification message depends on the information already recorded on the patient in The System: Both old and new ID is known the patient records are merged, identified by the new ID. Only old ID is known ID should be updated Only new ID is known no update required Neither old nor new ID is known no update required Technical Requirements The System must be able to receive the message PatientRegistry.DuplicatesResolved. The message contains information on merged patient ids, and is distributed to subscribing systems. The System should update Page 8 of 13

9 patient demographics in the local database if the patient already exists. For unknown patients, the message should be discarded. The System must be able to send an acknowledgement that the original message was received. It should be configurable whether or not The System should send such acknowledgements. Message: PRPA_IN201304NO Acknowledgement: MCCI_IN000002UV01 DIPS MessageBroker DIPS BizTalk PatientRegistry.DuplicatesResolved PRPA_IN201304NO Receipt ack MCCI_IN000002UV01 Sammenslått pasient KITH XML AppRec KITH XML Clinical Cell therapy Genetic system Management and Information System 3.5 Update patient demographics Figure 4 Duplicates Resolved The System must update local patient demographics for patients that have an updated demographics record in DIPS. Page 9 of 13

10 This is particularly relevant for cases where the patient status is updated to dead in DIPS but it is also relevant for other changes in patient demographics Technical requirements The System must be able to receive the message PatientRegistry.RecordRevised. This message contains updated patient demographic data. The System should update patient demographics in the local database if the patient already exists. For unknown patients, the message should be discarded. In any case, The System must be able to send an acknowledgement that the original message was received. It should be configurable whether or not The System should send such acknowledgements. Both the original message and the acknowledgement are HL7v3 messages described in the implementation guide. Message: PRPA_IN201302NO Acknowledgement: MCCI_IN000002UV01 DIPS MessageBroker DIPS BizTalk PatientRegistry.RecordRevised PRPA_IN201302NO Receipt ack MCCI_IN000002UV01 Oppdatert pasient KITH XML AppRec KITH XML Clinical Cell therapy Genetic system Management and Information System Figure 5 Record Revised Page 10 of 13

11 3.6 Retrieve laboratory results Describe the solution's capabilities for retrieval of laboratory results from other specialized system or from the Electronic Health Record system DIPS. 3.7 Export of data for reporting Describe the functionality in the solution to extract data for reporting. 3.8 Export of data to research and quality registers Describe the functionality in the solution to extract data to research and quality registers. Page 11 of 13

12 4 General technical requirements 4.1 Security requirements Security in Web services To consume the web services, a user identity with corresponding password should be included in the SOAP header for the web service request. The SOAP header should look something like the below figure. <soapenv:header> <wsse:security xmlns:wsse="(..)" soapenv:mustunderstand="1">.. <wsse:usernametoken somenamespace:id= uuid-060c77ce-... > <wsse:username>wsconsumer</wsse:username> <wsse:password wsse:type=... >SecretPassword</wsse:Password> </wsse:usernametoken> </wsse:security> </soapenv:header> Figure 6 Example of SOAP header with security credentials The user identity will be specific to the system calling, intended solely for use of the web services. Identity and password are supplied by Helse Vest IKT. Channel of communication with the web services will be encrypted using SSL. 4.2 Requirements for monitoring and logging General requirements The system should log activity for users who search for and access patient information so that users who read and update patient information can be tracked. Information on patients should be treated according to LAW No. 31: Act concerning the processing of personal data and LAW No. 24: Act relating to health records and processing of health information Logging of web service calls DIPS will log all use of the HL7 interface, therefore, all queries must contain a user ID. Request messages to HL7 DIPS Connector include a ControlAct wrapper. This includes the following structure: <controlactprocess moodcode="evn"> <authororperformer typecode="aut">  <assignedperson>  Page 12 of 13

13 <id extension="teneur" root=" "/> </assignedperson> </authororperformer> <subject>... </subject> </controlactprocess> Id should refer to the logged in user in Helse Vest infrastructure. A more detailed description of the HL7 implementation Guide: Page 13 of 13

cxl ontology system, Cyscom Biznet Services work flow and business applications Get to know the power of cxl

cxl ontology system, Cyscom Biznet Services work flow and business applications Get to know the power of cxl cxl structures, enriches and semantically maps product data into a repository for work flow