kensaku kawamoto m.d.-ph.d. candidate duke university [email protected]

04/21/23 04:04

Healthcare Services Specification Project Decision Support Service (DSS) Overview and Outstanding Issues

Healthcare Services Specification Project Decision Support Service (DSS) Overview and Outstanding Issues

Kensaku Kawamoto

M.D.-Ph.D. candidate

Duke University

[email protected]

Kensaku Kawamoto

M.D.-Ph.D. candidate

Duke University

[email protected]

January 11, 2006January 11, 2006

AgendaAgenda

• Healthcare Services Specification Project (HSSP)

• DSS Service Functional Model (SFM)

• Outstanding Issues

• Work Plan and Timeline

Healthcare Services Specification ProjectHealthcare 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

HSSP Process – HL7HSSP 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)

HSSP Process – OMGHSSP 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

AgendaAgenda





DSS SFM – Business PurposeDSS 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

DSS SFM – Functional CapabilitiesDSS 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 Input Sample 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)

DSS SFM – Scope of Specification WorkDSS SFM – Scope of Specification Work

• DSS functional requirements

• Service payloads as necessary

• Conformance profiles

DSS SFM – Benefits of StandardDSS 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

DSS SFM – Service OperationsDSS SFM – Service Operations

Decision Support Service

Decision Support Service

Service Client

Service Client

1. Evaluate Patient1. Evaluate PatientModules to use, required data, (eval. time)Modules to use, required data, (eval. time)

Knowledge module evaluation resultsKnowledge module evaluation results

2. Find Knowledge Modules2. Find Knowledge ModulesSearch criteriaSearch criteria

Modules meeting criteriaModules meeting criteria

3. Describe Knowledge Module3. Describe Knowledge ModuleModule of interest, sections of interestModule of interest, sections of interest

Description of module sectionsDescription of module sections

4. Get Data Requirements4. Get Data RequirementsModules of interest, data avail. to client, (eval. time)Modules of interest, data avail. to client, (eval. time)

Data requirements, whether avail. data sufficientData requirements, whether avail. data sufficient

*Version management operations intentionally left for OMG to specify*Version management operations intentionally left for OMG to specify

AgendaAgenda





Summary of Outstanding IssuesSummary 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

Roles of HL7 & OMG in Specification WorkRoles 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

Extensibility to Future-Proof ServiceExtensibility 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?

Care Record Query RMIM (Patient Care TC)Care Record Query RMIM (Patient Care TC)

Document Query RMIM (Medical Records TC)Document Query RMIM (Medical Records TC)

Potential DSS KM Data Requirements / QueriesPotential DSS KM Data Requirements / Queries

Query Response

Care Statement Query Care Statement

Care Statement Query (constrained)

Care Statement (constrained)

Condition List Query Condition List

Condition List Query (constrained)

Condition List (constrained)

Other queries, dynamically specified

Other query responses, dynamically specified

Constraining Service for InteroperabilityConstraining 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

Sample ProfilesSample 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”

Specification of Service PayloadsSpecification 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?

AgendaAgenda





Work Plan and TimelineWork 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

kensaku kawamoto m.d.-ph.d. candidate duke university [email protected]

Documents