Professional Documents
Culture Documents
Rodney Lemery, MPH, PhD Vice President, Safety and Pharmacovigilance BioPharm Systems, Inc.
PREVIOUS PREVIOUS
NEXT NEXT
Agenda
Project Initiation
Stakeholder Identification System Design Timeline
PREVIOUS
NEXT
Project Initiation
Stakeholder Identification
All information systems implementation projects in the area of health information begin by identifying key stakeholders.
These stakeholders must work in concert and collaboration in order to achieve their objectives as all of them are involved in the planning and execution of the project (OCarroll et al., 2003)
PREVIOUS
NEXT
Project Initiation
Stakeholder Identification
OCarroll et al describe these stakeholders as two camps:
IT View Business View
Some have suggested that given our fields stress on the regulatory process that a third camp also be considered:
QA View
PREVIOUS
NEXT
Project Initiation
IT Needs
How will the integration actually process?
Direct database to database connectivity? Web services? What is the system architecture being used?
The unique case ID that intermediate system may generate is there any value in it being an intelligent key like
<STUDY>_<USUBJID>_<AESEQ>_<SOME_SEQ_NUMBER> Or should it be a plain sequence number?
NEXT
Project Initiation
System Design Used in This Tutorial
PREVIOUS
NEXT
Project Initiation
IT Needs Answers in this Practical Example
How will the integration actually process?
A combination of database table manipulation in the LSH system resulting in the generation of an E2b(+) XML file that will be moved using Web Services into the appropriate Incoming folder for Argus Interchange
NEXT
Project Initiation
Business Needs
When should data be triggered for transfer from the source to the target systems?
Daily, Hourly?
What specific data should be copied from the source to the target system?
All laboratory data? All medical history data?
It is typical practice in a traditional safety practice to only enter the laboratory tests and medical history data for a participant that are deemed medically relevant to the event of interest for the case. How does this clinically challenging concept get applied to an information system?
PREVIOUS
NEXT
PREVIOUS
NEXT
Project Initiation
Business Needs Used in This Tutorial
When should data be triggered for transfer from the source to the target systems? This example integration has 5 data movements that require scheduling
1. 2. 3. 4. 5. OLX and OC/RDC data into LSH Transformation of LSH data into SDTM standard Creation of E2b(+) XML file from the SDTM standardized data and queue for transfer Transfer of XML file to network share via Web Methods Import into Argus via Interchange
PREVIOUS
1 0
NEXT
Project Initiation
QA Needs
Most of our client base would see this type of work as custom development and place a risk level of medium to high in its development This would mean a significant amount of testing usually in a phased approach popular with the FDA regulations
IQ Installation Qualification
Phase responsible for the documentation and testing of the installation process according to the system design documentation and usually governed by its own protocol and summary report.
OQ Operational Qualification
Phase responsible for the functional testing of the system according to the functional requirements specification and usually governed by its own protocol and summary report.
PQ Performance Qualification
Phase responsible for the user acceptance testing of the system according to the user requirements specification and usually governed by its own protocol and summary report. 1 PREVIOUS NEXT
1
Project Initiation
What is the timeline? Do any of the integrated systems have critical dates that may impact timeline?
PREVIOUS
1 2
NEXT
Development/Testing
Development/Testing
Mapping Must occur before development begins; iterative process involving users
Used to identify source for standard E2B fields and to define required extended tags
PREVIOUS
1 3
NEXT
Development/Testing
Mapping
First phase of development; Iterative process involving users Document the source locations, E2b tags, and Argus target fields Map standard E2b tags and define required E2b(+) tags
PREVIOUS
NEXT
E2b Tag
Leverage default E2b tags where possible Define placement and order of E2b(+) tags within standard sections E2b(+) tags names: _EXTENSION and <= 30 characters in Argus
Target (Argus)
Identify code list mappings Surface user defined fields if necessary
PREVIOUS NEXT
Development/Testing
Development/Testing
Argus configuration
Surface UD fields, configure products, studies, etc. Enable Interchange and required AG Services
PREVIOUS
1 6
NEXT
PREVIOUS
NEXT
Development/Testing
Synchronize Configuration (contd.)
Studies
Limitations on importing study products (ex. duplicate records)
PREVIOUS
NEXT
Development/Testing
Synchronize Configuration (contd.)
Products
Product names must match Argus Trade Names verbatim Evaluate central product repository for ease of integration
PREVIOUS
NEXT
Development/Testing
Development/Testing
Develop Argus custom profile and extended tags
Define custom, extended profile in ESM and custom DTD file Load extended tags in CFG_E2B and LM_ESM_ARGUS_MAPPING tables Add extended tags to DTD Develop custom import/export programming per extended tag.
Most of the export code is defined at the parent tag level (ex. drug) while the import code is defined per tag Import code leverages PL/SQL and Argus API while export code is basic SQL
PREVIOUS
2 0
NEXT
Development/Testing
Define E2b(+) Tags
Add tags to DTD
Location must match order in E2b file
Two Places
PREVIOUS
NEXT
Development/Testing
Define E2b(+) Tags (cont.)
Insert tag records
Use SQL*Loader for convenience Two tables: CFG_E2B and LM_ESM_ARGUS_MAPPING
PREVIOUS
NEXT
Development/Testing
Define E2b(+) Tags (cont.)
Add Receive Code
PL/SQL block per tag leveraging Argus API Helpful to use existing tags as examples
PREVIOUS
NEXT
Development/Testing
Define E2b(+) Tags (cont.)
Add Transmit Code
Only required for outgoing files (i.e. when Argus is the source) Basic SQL, usually defined at the parent element level (ex. Patient) Verify Column Position in CFG_E2B matches SELECT statement order
PREVIOUS
NEXT
Development/Testing
Add E2b(+) Profile
Copy existing Profile to create new Profile
PREVIOUS
NEXT
Development/Testing
Create E2b(+) Profile DTD
Copy and rename existing DTD
PREVIOUS
NEXT
Development/Testing
E2b Validation Rules
Modify for E2b(+) profile to ease import restrictions
Incoming files only need to meet minimum Argus case creation requirements (not regulatory ICSR requirements) Minimize number of mandatory and mandatory optional tags
CFG_E2B Table
Update MANDATORY and MANDATORY_DTD_ELEMENT columns
CFG_M2_ADDITIONAL Table
Contains additional E2b validation rules Rules can be added/removed according to requirements
PREVIOUS
NEXT
Development/Testing
Development/Testing
Configure Integration Points
Argus reporting destination configured to point to incoming/outgoing directories via Argus ESM (network paths ok) Mechanism for moving E2B files to/from directories?
Web services?
PREVIOUS
2 8
NEXT
Development/Testing
Configure Reporting Destination
Reporting Destination Code List
ESM Mapping
PREVIOUS
NEXT
Development/Testing
Development/Testing
Testing
Iterative process involving user groups Include several cycles of end-to-end testing
PREVIOUS
3 0
NEXT
Implementation/Maintenance
Implementation/Maintenance
Consider phased rollout ex. individual studies or limited data points supplemented by manual data entry Define process for configuration changes across systems Changes can impact multiple systems (ex. configuring a new product or study) Define process for bridge modifications (ex. addition of new extended tag)
PREVIOUS
3 1
NEXT
Challenges
Gotchas (examples)?
Synchronizing configuration across systems (ex. product configuration) E2B tag order must be appropriately configured within CFG_E2B table and match export SQL select order Extended tag names cannot exceed 30 characters Cannot add new parent tags or repeating sections Default logic for importing study products (potential for duplicate products)
Argus creates a single study product even if multiple products are delivered to the patient
Known limitations with device products Working within standard E2B specification
eMDR standards use HL7 formatted files
Argus does not delete records or clear out values on import of follow-ups
PREVIOUS
32
NEXT
Summary
Project Initiation
Stakeholder Identification System Design Timeline
PREVIOUS
33
NEXT
References
OCarroll, P. (2003). Public Health Informatics and Information Systems. Springer
PREVIOUS
34
NEXT
Contact
Rodney L. Lemery MPH, PhD Vice Pres. Safety and PV 2000 Alameda de las Pulgas Suite 154 San Mateo, CA 94403-1270 www.biopharm.com Tel (650) 292-5310 Fax (650) 292-5301 rlemery@biopharm.com
PREVIOUS
35
NEXT