PCD Detailed Profile Proposal 2009 SA WP

From IHE Wiki
Jump to: navigation, search


Proposed Workitem: White Paper - Medical Device Semantic Architecture

  • Proposal Editor: Todd Cooper
  • Editor: Todd Cooper, Jan Wittenber
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: PCD


The Problem

Medical device semantic interoperability is one of the primary IHE PCD mission objectives; however, achieving true interoperability requires leveraging many different informatics constructs and standards to develop both abstract semantic profiles, as well as the profiles that convey and record acquired medical device data. Understanding the relationship between the various abstract semantic components and how they can be combined to represent device data has historically proven difficult for many implementors. Navigating the maze of terminology, nomenclature, information models, templates, clusters, ... too often results in frustration and despair!

This white paper will provide an overview of the various issues around medical device semantic interoperability, and propose a semantic architecture that will clearly define the needed components and how they may be combined to represent IHE PCD content. Also, a roadmap will be detailed for how the IHE PCD and related standards organizations might address the missing components.

Key Use Case

<semantic interoperability from a clinical PoC device to a dashboard system>

<Semantic interoperabiltiy from a PoC device to an EHR to a document example>

<BP cluster example>

<terminology research use case example>

<terminology authoring example>

Proposed Topics / Outline

NOTE: The following proposed outline is highly subject to change!

Overview
  • Introduction
  • Scope
  • Audience
Use Cases
  • See above list
Architectural Model
  • Terminology Metamodel
  • <...>

<TBD>

Physiological Context Groups
Conformance
Tool Support
Roadmap
  • IHE PCD Profiling
  • SDO Engagement

Discussion

<Include additional discussion or consider a few details which might be useful for the detailed proposal>

<Why IHE would be a good venue to solve the problem and what you think IHE should do to solve it.>
<What might the IHE technical approach be? Existing Actors? New Transactions? Additional Profiles?>
<What are some of the risks or open issues to be addressed?>

Impact on existing integration profiles

<Indicate how existing profiles might need to be modified.>

New integration profiles needed

<Indicate what new profile(s) might need to be created.>


Breakdown of tasks that need to be accomplished

<A list of tasks would be helpful for the technical committee who will have to estimate the effort required to design, review and implement the profile.>


Support & Resources

<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>

Risks

<List technical or political risks that could impede successfully fielding the profile.>

Open Issues

<Point out any key issues or design problems. This will be helpful for estimating the amount of work and demonstrates thought has already gone into the candidate profile.>

<If there are no Open Issues at Evaluation Time, it is usually a sign that the proposal analysis and discussion has been incomplete.>

Tech Cmte Evaluation

<The technical committee will use this area to record details of the effort estimation, etc.>

Effort Evaluation (as a % of Tech Cmte Bandwidth):

  • 35% for ...

Responses to Issues:

See italics in Risk and Open Issue sections

Candidate Editor:

Todd Cooper & Jan Wittenber