1 / 24

caCIS Architecture: Proposed Approach

caCIS Architecture: Proposed Approach. caCIS Analysis and Architecture Team April, 15 2011. Agenda. Understanding of Problem & Objectives Approach Philosophy & Key Design Decisions Solution Overview Solution Component details Artifacts & Reuse Assumptions & Risks Questions.

iain
Télécharger la présentation

caCIS Architecture: Proposed Approach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. caCIS Architecture: Proposed Approach caCIS Analysis and Architecture Team April, 15 2011

  2. Agenda • Understanding of Problem & Objectives • Approach Philosophy & Key Design Decisions • Solution Overview • Solution Component details • Artifacts & Reuse • Assumptions & Risks • Questions

  3. Problem Statement The NCI is attempting to address two problems: • The TRANSCEND System (more specifically, it’s Clinical Data Management System Tolven), is unable to make electronic clinical information available to share with external EHR systems. Information can currently only be transferred through manual intervention, such as copying text from a TRANSCEND report screen and pasting it into an EHR that the user is concurrently logged into. This is an artificial barrier to patients’ continuity of care. • The NCI lacks a capability to efficiently collect patient-centered outcomes (PCO) information across its clinical trials and other trading partners. Collecting this information can eventually permit the study the patterns of treatment as it pertains to certain types of cancer, allowing researchers the ability to identify the best possible treatments.

  4. Objectives • Allow TRANSCEND Tolven instance to share data with PCO Tolven instance and other clinical applications via standardized exchange formats • Create PCO application to gather, edit and share Patient-centric Outcome Data • Maximize chances for uptake by other clinical systems in the oncology space • Allow extensibility for new data elements and new exchange formats • Solution to be tested and production-ready by Sept. 30 • Leverage artifacts and code from previous project phase if and where possible

  5. Approach Philosophy To achieve previous objectives, the solution was designed based on the following tenets: • 1. Leverage standards and off-the-shelf components • Minimizes risks, improves likelihood of adoption and addresses concerns raised from review of previous project • 2. Create only what will be tested by the current implementation • If it won’t be exercised in the production system, requirements are likely to be wrong, change before use, or need will never manifest • Ensures resources are focused on needed features and concrete requirements

  6. Approach Philosophy (cont’d) • 3. Design for anticipated growth and change • While we will not build data elements or features not required for the initial solution, we will predict likely extension requirements and future needs and design to make evolution as easy as possible.

  7. Key Design Decisions • Clinical services from prior project will not be used • Overly complex and risky for current requirements • Insufficient time to complete or leverage existing work • LOE for specification completion alone > 2.5 person-years • Success with this approach would require significant buy-in and participation from vendor community (no time in this project) • In the absence of this participation, there will be little likelihood of uptake/reuse by the community • Registry services from prior project will not be used • No requirement within scope of current project • Client lookup and id resolution functions may be needed in the future, but are better handled by standard interfaces, off-the-shelf components

  8. Key Design Decisions (cont’d) • External interfaces via IHE standards including XDS, ATNA and NAV • Significant existing vendor support • Leverages existing open-source components • Ability to use additional components to support future requirements • Internal Canonical Model based on CCD • Familiar to implementers • Easy to add new sections later • Will be most common exchange format • Services Based Architecture (SOA) • Services based interfaces • Loosely coupled – to support reuse goals of the project

  9. High-level design TRANSCEND Tolven PCOTolven Other Systems TRIM TRIM Semantic Adaptor Semantic Adaptor CCD, v2, V3 XML, etc. Canonical CCD Canonical CCD Integration Platform Integration Platform XDS / NAV

  10. Components • Function • Service Interface • Technologies • Benefits

  11. Component: Semantic Adaptor • Function • Convert between native format (e.g. TRIM) and Canonical format • Includes conversion of vocabulary, re-organization of data, generation of human-readable content • Common component but distinct configurations for each clinical application • Service Interfaces • ShareClinicalInformation • Converts local data to Canonical and invokes Integration Platform • LocalizeCanonicalInformation • Converts Canonical information to native format for import • Technologies • Evaluating Mirth Connect and Open e-Health Integration Platform • Benefits • User interface for performing mappings, support for XSLT

  12. Component: Canonical Format • Function • Provides single, monolithic semantically precise data structure for clinical applications to map their data to • Serves as the basis for generating Exchange views of the data • Technologies • Based on CCD with some additional custom sections • If necessary, use RIM extensions to allow expression of all data • Benefits • Existing standard, well recognized • Minimal transformation effort to most outputs • Easy to extend by adding new sections • Semantically rigorous

  13. Component: Integration Platform • Function • Most complex of the in-scope components • Four sub-components: • Canonical format validation • Use Schematron generated from CDA profiling tool (same tool that creates implementation guide) • Canonical format persisting • Use XDS document repository • Transformation of Canonical to Exchangable Format • Use same Integration engine as for Semantic Adaptor • Document exchange • Use NAV “Notification of Document Availability” and XDS “Get Document” • Also need glue logic to manage orchestration between components

  14. Integration Platform (cont’d) • Service Interfaces • ShareCanonicalInformation • Accepts Canonical information from Semantic Adaptor to be placed into document repository and, if necessary, sends out notification of the document being availability • GetDocument • Allows an interested clinical application to retrieve an identified document • NotificationOfAvailability • Receives a notification from another Integration Platform that a document is available for retrieval. Prompts the retrieval of the document, translation back to canonical form and passing to Semantic Adaptor for import into local application • Technologies • Evaluating Open eHealth Integration Platform and OpenExchange • Benefits • Most features are off-the-shelf components. Development effort limited to orchestration and glue logic

  15. Component: PCO Application • Function • Gather patient-centric outcomes data from TRANSCEND and other source systems • Provide a user-interface for editing and creation of additional PCO-related data • Support the export of PCO data to external systems for analysis • Technology • Transcend (as per scope)

  16. Component: Security • Function • Provide End-point authentication for document exchange, encryption and audit logging • Technologies • ATNA (IHE specification associated with XDS) • Dual-certificate endpoint authentication • Uses TLS 1.0, WS-I Basic Security Profile 1.1 • Benefits • Part of open-source XDS implementations • Out-of-box support for many clinical systems

  17. Architecture Artifacts • Service Specifications for Semantic Adapter and Integration Platform • Profile describing use of XDS, NAV and ATNA standards • Mappings and Transformations for: • TRANSCEND TRIM -> Canonical • Canonical -> Exchange CCD • Canonical -> HL7 v2 • Canonical -> XML ITS • Canonical <-> PCO CCD • PCO TRIM <-> Canonical

  18. Architecture Artifacts (cont’d) • Implementation guides for • Canonical CCD • Exchange CCD • PCO CCD • V2 messages • PCO Tolven business rules • PCO Tolven RMIMs and TRIMs • PCO GUI Wireframes – Time permitting

  19. Reuse • Semantic Adaptor • Technology should work with any clinical system export (v2, XML, fixed length, character delimited, etc.) • Mapping and configuration required for each communicating system • Canonical Format • Easily extended through addition of new sections, addition of optional data elements to existing sections

  20. Reuse (cont’d) • Integration Platform • Should work without re-configuration for any clinical application • Should be able to communicate with many client clinical applications “out of the box” • Easy to add support for new exchange formats • Will need to revise exchange format transforms as Canonical format evolves • Can easily expose additional IHE services for query, patient look-up, etc.

  21. Assumptions • Patient consent, user authority, business associate agreements (eg.HIPAA) for data exchange is sole responsibility of source clinical application • User identification and permission enforcement is responsibility of source clinical application • HL7 v2 instances will be treated as “documents” – no tight integration around trigger events, acknowledgements, etc. • Audit logs will be stored locally with each Integration Platform • Automated configuration of notification paths via publish-subscribe or similar mechanisms is out of scope • TRANSCEND Tolven instance will be modified as necessary to allow user to initiate export of data. Export will include user name, target application and target format

  22. Assumptions (cont’d) • All exports will be treated as “snapshot”, conveying the complete set of data needed to populate the Canonical format • XDS persistent store and ATNA log files will be stored within clinical application’s “trusted” data area • Communication between the Tolven instances, their Semantic Adaptors and between the adaptors and Integration Platform will be in a trusted network environment • Exchange artifacts will not be digitally signed • PCO stakeholders will define requirements (e.g. rules for viewing and amending PCO data, data sharing trigger events, etc) – in a timely fashion

  23. Risks • Solution is based on our current understanding of the requirements, which might be dated and/or incomplete • Initial data elements in Canonical format will be driven by TRANSCEND • Revision likely required for future integrated applications • Only one client and one target system to test exchange and mappings • Inclusion of external components can complicate maintenance due to version management issues • Transcend may not be able to make changes as needed during implementation

  24. Questions & Discussion

More Related