gpi gordon point informatics Information Decomposition at NCI Jean Duteau HL7 UK RIMBAA Conference, November 4, 2010

gpi Jean Duteau Has been involved with HL7 implementations since 2000, both v2.4/2.5 and v3 Worked with Canada Health Infoway as a Standards Subject Matter Expert (SME) and a Jurisdictional SME. Current Modeling facilitator for Pharmacy, Past Publishing facilitator for Patient Care Co-chair of Modeling & Methodology, Implementable Technology Specifications, and Tooling workgroups Currently involved in HL7 activities in Canada, United States, and Europe Currently working at NCI as the Information Analyst/Architect – in charge of producing all of the information models Nov 4, 2010© 2010, Gordon Point Informatics Ltd.2

gpi Outline 1. Introduction to the caCIS project 2. Information Models 1. Constrain the DAM 2. Service Composition 3. Current challenges 4. Wrap up / Q&A Nov 4, 2010© 2010, Gordon Point Informatics Ltd.3

gpi Nov 4, 2010© 2010, Gordon Point Informatics Ltd.4

gpi caCIS Originated to produce a set of services to extend traditional EMR into the realm of Oncology (Cancer EHR) Focused on a few main categories of services: Referral Management Outcomes Management Patient Trial Finder Chemotherapy Management Order/Request Brokering Nov 4, 2010© 2010, Gordon Point Informatics Ltd.5

gpi Nov 4, 2010© 2010, Gordon Point Informatics Ltd.6

gpi Domain Analysis Model (DAM) Domain Analysis Model is produced Uses as input: Existing HL7 UV Domain models NCI’s BRIDG (Biomedical Research Integrated Domain Group) DAM Other relevant specifications – CCD, Imaging models, etc. Supplementary Information Patients, Performers, Material Main Information Treatment Plan Order, incl. Referral, Document Exchange, Laboratory, Procedure Outcomes Allergies, Medications, Immunizations, etc. Nov 4, 2010© 2010, Gordon Point Informatics Ltd.7

gpi Information Models (RMIMs) Once the DAM concepts have been created and the Architecture team determines the service specifications (which tends to work hand-in-hand), HL7 RMIMs are created to enable the services We are creating payloads that are used as parameters in the service operations These HL7 RMIMs have a direct relationship (traceability) to the DAM and are used to generate PSM artifacts such as Schemas Nov 4, 2010© 2010, Gordon Point Informatics Ltd.8

gpi Proper Abstraction Level Initial RMIMs are simple constrained versions of UV material or cloned versions of Canadian material They will contain a lot of their context: Patients, Record Targets, Providers, etc. Working with the architects, the breakdown of the full payload into appropriate parameters is done: Patient becomes a separate parameter Various providers are either service context or separate parameters Actual information payload becomes just the required information Finally, the context of the service operation, eg. Create referral, is made explicit in the structural semantics of the RMIM Consequence: There are no models that will have multiple mood codes. Nov 4, 2010© 2010, Gordon Point Informatics Ltd.9

gpi Nov 4, 2010© 2010, Gordon Point Informatics Ltd.10

gpi Service Operation Decomposition Naïve Service implementations in NCI have had two services: do and get We are building an Interoperability Specification that describes the orchestration between the services This requires a much more fine-grained service decomposition than do or get! Constraints we put on the information model also require this decomposition: Fixed mood codes and/or status codes means that we need separate operations for create and update Nov 4, 2010© 2010, Gordon Point Informatics Ltd.11

gpi Nov 4, 2010© 2010, Gordon Point Informatics Ltd.12

gpi Query-By-Example Our architecture provides for a query-by- example (QBE) model Given that the current state of queries in HL7 are all query-by-parameter (QBP), this is new ground My experience has been in QBP so my QBEs look an awful lot like a bunch of parameters. Still exploring what a QBE actually represents Provides the query parameters Indicates the format that the query results should be returned in Nov 4, 2010© 2010, Gordon Point Informatics Ltd.13

gpi Transport Wrapper and Control Act Services started out simple: return doSomething(parameter, parameter, …) As we considered handling faults, we realized that every ‘doSomething’ would need to include managed faults as a parameter and would need to return detected faults To provide context for how to process downstream services, we need to provide some ‘infrastructure’ information in each operation We are now struggling with the fact that our service operations are starting to mimic a message interaction Need to find the right balance between a context-free service operation and a context-rich message interaction Nov 4, 2010© 2010, Gordon Point Informatics Ltd.14

gpi Nov 4, 2010© 2010, Gordon Point Informatics Ltd.15

gpi Summary Summary points… Nov 4, 2010© 2010, Gordon Point Informatics Ltd.16

gpi March 3, 2010© 2010, Gordon Point Informatics Ltd.17 Thanks! gpi Jean Duteau Gordon Point Informatics Ltd.