10/9/ :26 AM Healthcare Services Specification Project Decision Support Service (DSS) Overview and Outstanding Issues Kensaku Kawamoto M.D.-Ph.D. candidate Duke University Kensaku Kawamoto M.D.-Ph.D. candidate Duke University January 11, 2006

Page 2 Agenda Healthcare Services Specification Project (HSSP) DSS Service Functional Model (SFM) Outstanding Issues Work Plan and Timeline

Page 3 Agenda Healthcare Services Specification Project (HSSP) DSS Service Functional Model (SFM) Outstanding Issues Work Plan and Timeline

Page 4 Healthcare Services Specification Project Effort to create common service interface specifications for services important to Health IT Joint project of HL7 and the Object Management Group (OMG) –OMG: vendor consortium producing specifications for interoperable enterprise applications; specified UML and CORBA Current services –Entity Identification Service (EIS) –Record Location and Access Service (RLAS) –Common Terminology Service (CTS) – owned by Vocab TC –Decision Support Service (DSS) – owned by CDS TC

Page 5 HSSP Process – HL7 Identification of standardization candidates Specification of Service Functional Model (SFM) –Use of Service Development Framework (SDF) & SFM template –Core SFM components: Business case and business scenarios Specification of service functionality Specification of service payloads as necessary Conformance profiles –Aspects not requiring specification by HL7 intentionally left for OMG to specify Quality assurance by HSSP Balloting as Draft Standard for Trial Use (DSTU)

Page 6 HSSP Process – OMG Coordinated by Healthcare Domain Task Force (DTF) HL7 SFM used as basis for Request for Proposal (RFP) –Request for specification of a platform-independent model (PIM) and at least one platform-specific model (PSM) (e.g. SOAP/XML) conforming to SFM requirements Letters of intent to specify and implement within 12 mo.  initial specifications  single revised specification based on merged efforts Approval by Healthcare DTF  Architectural Board  Technology Committee  Board of Directors Specification not adopted unless at least one implementation available commercially

Page 7 Agenda Healthcare Services Specification Project (HSSP) DSS Service Functional Model (SFM) Outstanding Issues Work Plan and Timeline

Page 8 DSS SFM – Business Purpose Clinical decision support systems (CDSS) have been shown to significantly improve care quality However, CDSS use is quite limited, due in part to cost and difficulty of implementing effective CDS capabilities CDS capabilities can be more easily implemented using services that provide required functionality, e.g. –Record Locate and Update Service  to retrieve required data –Decision Support Service  to draw conclusions about patient –CIS Action Brokering Service  to translate conclusions into CIS actions DSS purpose: to reduce cost and complexity of CDSS design, implementation, and maintenance

Page 9 DSS SFM – Functional Capabilities DSS provider = guardian of CDS knowledge modules A DSS evaluates patient data using knowledge modules and returns machine-interpretable conclusions Sample Evaluation InputSample Evaluation Output Medication ID, age, gender, weight, serum creatinine Recommended max/min doses, adjusted for renal clearance Age, gender, co-morbidities, chief complaint Admission order set in HL7 format Age, gender, co-morbidities, user role, task context Context-relevant information resource Insurance provider, data relevant to prescription Prior authorization to prescribe medication Operations provided to meet supplemental information needs (e.g. identification of relevant knowledge modules)

Page 10 DSS SFM – Scope of Specification Work DSS functional requirements Service payloads as necessary Conformance profiles

Page 11 DSS SFM – Benefits of Standard DSS providers (e.g. knowledge vendors, government) –Expansion of potential client base –Scalable deployment architecture –Minimal restrictions on how underlying knowledge is represented DSS consumers (e.g. CIS vendors, healthcare institutions) –Ability to easily integrate CDS capabilities into applications –Access to multiple knowledge bases through single interface

Page 12 DSS SFM – Service Operations Decision Support Service Service Client 1. Evaluate Patient Modules to use, required data, (eval. time) Knowledge module evaluation results 2. Find Knowledge Modules Search criteria Modules meeting criteria 3. Describe Knowledge Module Module of interest, sections of interest Description of module sections 4. Get Data Requirements Modules of interest, data avail. to client, (eval. time) Data requirements, whether avail. data sufficient *Version management operations intentionally left for OMG to specify

Page 13 Agenda Healthcare Services Specification Project (HSSP) DSS Service Functional Model (SFM) Outstanding Issues Work Plan and Timeline

Page 14 Summary of Outstanding Issues What to specify in HL7 and what to leave for OMG How to make service extensible and future-proof How to constrain service to enable interoperable use How to specify information payloads

Page 15 Roles of HL7 & OMG in Specification Work Rules of thumb –Specify business requirements at HL7, specify technical requirements at OMG –Specify within HL7 if important to HL7 community that something is specified within HL7 –Specify minimal amount as possible within HL7, leave everything else to OMG to specify Examples –Important to CDS TC what meta-data are associated with a knowledge module  specify within HL7 –Not important to CDS TC how knowledge module search criteria are specified or how such criteria are aggregated  leave for OMG

Page 16 Extensibility to Future-Proof Service Service payloads requiring high degree of extensibility –Knowledge module data requirements –Knowledge module evaluation results Service payloads not requiring extension (?) –Knowledge module meta-data / search criteria Strategy for allowing content to be extended –Establish repository of information models (e.g. RMIMs similar to Patient Care TC’s Care Record Query RMIM; specializations of a generic DSS knowledge module Entity) –Specify information payloads by calling out to repository contents Questions –Who maintains the information model repository, and how? –How do others search and use the repository?

Page 17 Care Record Query RMIM (Patient Care TC)

Page 18 Document Query RMIM (Medical Records TC)

Page 19 Potential DSS KM Data Requirements / Queries QueryResponse Care Statement QueryCare Statement Care Statement Query (constrained) Care Statement (constrained) Condition List QueryCondition List Condition List Query (constrained) Condition List (constrained) Other queries, dynamically specified Other query responses, dynamically specified

Page 20 Constraining Service for Interoperability Generic standards require constraints to achieve semantic interoperability –E.g. XML, SOAP, RIM, etc. DSS examples of issue –Want to allow flexibility in the data required by DSS modules, but want consistency in how common data requirements are specified –Want to allow flexibility in the patient evaluation inputs and outputs, but want consistency when similar CDS capabilities are provided Potential solution: use of profiles –Profile = any constraint pattern placed on DSS providers or on individual knowledge modules that profess to support the profile

Page 21 Sample Profiles Profiles applying to individual knowledge modules (KMs) –“Drug dosing KM profile” KM requires med. ID, age, gender, weight, serum creatinine KM returns min and max doses adjusted for renal clearance –“Health maintenance procedure KM profile” KM returns whether health maintenance procedure (e.g. mammogram) due; date last done; date procedure next due –“Basic data requirement KM profile” KM requires only demographic data and core, simplified Act data Profiles applying to a service –“Basic medication DSS profile”  DSS contains KMs implementing “Drug dosing KM profile,” “Drug-allergy KM profile,” & “Drug-drug interaction KM profile”

Page 22 Specification of Service Payloads Specification needs –DSS KM meta-data –DSS KM evaluation results –DSS KM data requirements (intended to be passable to RLAS to request record query) –Client data availability (intended to be compatible with what is returned by RLAS to describe supported queries) Possible specification needs –Communication of DSS KM evaluation results –Response to communication of DSS KM evaluation results Questions –How should we go about specifying these information models? –Which TCs/SIGs should manage this process?

Page 23 Agenda Healthcare Services Specification Project (HSSP) DSS Service Functional Model (SFM) Outstanding Issues Work Plan and Timeline

Page 24 Work Plan and Timeline Desired timeline –6/06: post RFI and scope statement to HL7 HQ –7/06: issue SFM as CDS TC DSTU ballot –9/06 (Boca Raton): committee ballot reconciliation –11/06: issue SFM as HL7 membership DSTU ballot –11/06: prepare OMG RFP based on SFM –Late 2007/early 2008: OMG specification adopted, commercial products available Work plan to realize timeline –Modeling of relevant information constructs –Establishment of mechanism for calling out to HL7 information constructs