Ihe cardiology profiles for year 1
This presentation is the property of its rightful owner.
Sponsored Links
1 / 33

IHE Cardiology Profiles for Year 1 PowerPoint PPT Presentation


  • 144 Views
  • Uploaded on
  • Presentation posted in: General

IHE Cardiology Profiles for Year 1. Tom Dolan, Philips Co-editor, IHE Cardiology Technical Committee. Presentation structure. IHE Cardiology profile context What we are covering and why Cardiology Catheterization Workflow Overview, benefits, actors/transactions, highlights ASSUMPTIONS

Download Presentation

IHE Cardiology Profiles for Year 1

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ihe cardiology profiles for year 1

IHE Cardiology Profiles for Year 1

Tom Dolan, Philips

Co-editor, IHE Cardiology Technical Committee

IHE Educational Workshop 2005


Presentation structure

Presentation structure

  • IHE Cardiology profile context

    • What we are covering and why

  • Cardiology Catheterization Workflow

    • Overview, benefits, actors/transactions, highlights

  • ASSUMPTIONS

    • Basic understanding of IHE concepts from earlier sessions

IHE Educational Workshop 2005


Three profiles selected for year 1

Three profiles selected for year 1

  • Cardiac Catheterization Workflow

    • Based on IHE Radiology Scheduled Workflow and Patient Information Reconciliation Profiles

  • Echocardiography Workflow

    • Based on IHE Radiology Scheduled Workflow and Patient Information Reconciliation Profiles

  • Retrieve ECG for Display

    • Based on IHE IT Infrastructure Retrieve Information for Display Profile

IHE Educational Workshop 2005


Why these profiles

Why these profiles?

  • High return on investment - important integration problems

  • Standards in place (DICOM, HL7)

  • Leverage IHE Radiology and IT Infrastructure

  • No “political” challenges – just technical

  • Restricted scope for “quick win”

IHE Educational Workshop 2005


Cath lab

Cath Lab

(A) room for improvement !

IHE Educational Workshop 2005


Cath workflow management multi modality intra lab issues

Cath Workflow Management Multi-Modality, Intra-Lab issues

  • Multiple re-entry of Patient ID

  • Error prone

  • Results fragmented across systems

  • Custom solutions needed for data sharing

  • Difficult to manage

IHE Educational Workshop 2005


Cath workflow management extra lab issues

Cath Workflow Management Extra-lab issues

  • Un-ordered cath exams (emergency)

  • Unidentified patients

  • Uncoordinated with Hospital Information System

  • Diagnostic and interventional procedures

  • Ad hoc scheduling of cath labs

  • Change of rooms during procedure

  • … and interactions among these issues!

IHE Educational Workshop 2005


Cardiac catheterization workflow what s in

Cardiac Catheterization Workflow- What’s in?

  • Management of cath exams (in-lab portion)

    • Similar to IHE-Radiology SWF

    • Multi-modality, multiple procedure steps

  • Reconciliation of patient information

    • Similar to IHE-Radiology PIR

    • Unscheduled cath is the norm, not the exception

  • Time synchronization

    • Modalities must support IHE-ITI Consistent Time

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Cardiac Catheterization Workflow- What’s OUT?…for year 1

  • Pre-cath and post-cath activity

  • Hemo waveforms and reports*

  • Procedure logs

  • QCA/QVA*

  • Final cath reports*

  • Supply chain

    *Archives must support storage, but no actors specified for display

But on the 5-year roadmap!

IHE Educational Workshop 2005


Actors transactions take away

Actors/Transactions take-away

  • NO new actors

    • Same actors as Radiology scheduled workflow

  • 4 “modified” transactions

    • Existing Radiology-based transactions have been modified to accommodate cardiology specifics

IHE Educational Workshop 2005


Cardiac cath 8 use cases

Cardiac Cath – 8 use cases

  • All use cases must be supported

  • Case C1: Patient Registered at ADT and Procedure Ordered at the Order Placer

  • Case C2: Patient Registered at ADT and Procedure Ordered at DSS/OF

  • Case C3: Patient Registered at ADT and Procedure Not Ordered

  • Case C4: Patient Registered at DSS/OF and Procedure Ordered

  • Case C5: Patient Not Registered

  • Case C6: Patient Updated During Procedure

  • Case C7: Change Rooms During Procedure

  • Case C8: Cancel Procedure

IHE Educational Workshop 2005


Benefits

Benefits

  • Simplify Management of Cath exams (In Lab)

    • High-value, high-complexity workflow addressed

      • Basic lab-centric workflow addressed

      • Worklist-driven for speed and accuracy

      • Solid basis for extension in future

  • Reuse of existing standards

    • Similar to IHE-Radiology SWF means savings in training, development and reduced risk

    • But cath-specific issues addressed

  • Aim to remove the integration-barriers compromising efficiency and safety between cath-modalities/vendors

IHE Educational Workshop 2005


Actors

ACTORS

  • Acquisition Modality – A system that acquires and creates medical images or waveforms while a patient is present, e.g., an X-ray angiography or hemodynamic measurement system. A modality may also create other evidence objects such as Structured Report Documents containing measurements.

  • ADT – A system responsible for adding and/or updating patient demographic and encounter information (Admission/Discharge/Transfer). In particular, it registers a new patient with the Order Placer and Department System.

  • Department System Scheduler/Order Filler – A department-based (for instance, Cardiology or Radiology) information system that provides functions related to the management of orders received from external systems or through the department system’s user interface.

  • Image Archive – A system that provides long term storage of evidence objects such as images, presentation states, Key Image Notes and Evidence Documents.

IHE Educational Workshop 2005


Actors1

ACTORS

  • Image Display – A system that offers browsing of patients’ studies. In addition, it may support the retrieval and display of selected evidence objects including sets of images, presentation states, Key Image Notes, and/or Evidence Documents.

  • Image Manager – A system that provides functions related to safe storage and management of evidence objects. It supplies availability information for those objects to the Department System Scheduler.

  • Order Placer – A hospital or enterprise-wide system that generates orders for various departments and distributes those orders to the correct department.

  • Performed Procedure Step Manager – A system that re-distributes the Modality Performed Procedure Step information from the Acquisition Modality to the Department System Scheduler/Order Filler and Image Manager.

  • Time Client – A system unit that synchronizes its time of day clock to the correct time provided by a time server

IHE Educational Workshop 2005


Transactions

TRANSACTIONS

  • Patient Registration – The ADT system registers and/or admits a patient and forwards the information to other information systems. [RAD-1]

  • Placer Order Management – The Order Placer informs the Order Filler of the initiation or cancellation of an order. The Placer/Filler Order Management transaction will sometimes be referred to as “-New” when a new order is being initiated, or as “-Cancel” when an existing order is canceled. [RAD-2]

  • Filler Order Management – The Order Filler informs the Order Placer of the initiation, cancellation, or change in the status of an order. The Placer/Filler Order Management transaction will sometimes be referred to as “-New” when a new order is being initiated, or as “-Cancel” when an existing order is canceled. [RAD-3]

  • Procedure Scheduled – Schedule information is sent from the Department System Scheduler/Order Filler to the Image Manager. [RAD-4]

  • Query Modality Worklist – Based on a query entered at the Acquisition Modality, a modality worklist is generated listing all the items that satisfy the query. This list of Scheduled Procedure Steps with selected demographic information is returned to the Acquisition Modality [RAD-5].

  • Modality Procedure Step In Progress – An Acquisition Modality notifies the Performed Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs the Department System Scheduler/Order Filler and Image Manager. [CARD-1, derived from RAD-6]

IHE Educational Workshop 2005


Transactions1

TRANSACTIONS

  • Modality Procedure Step Completed – An Acquisition Modality notifies the Performed Procedure Step Manager of the completion of a Procedure Step and the PPS Manager informs the Department System Scheduler/Order Filler and Image Manager. [RAD-7]

  • Modality Images/Evidence Stored – An Acquisition Modality sends acquired or generated images, waveforms, or other evidence documents to the Image Archive. [CARD-2, derived from RAD-8 and RAD-43]

  • Storage Commitment – A requestor (Acquisition Modality) requests that the Image Manager confirm ownership for the specified DICOM objects (images, waveforms, evidence documents, or any combination thereof) that the requestor stored in the Image Archive, thus allowing the sender to delete those objects now owned by the Image Manager. [CARD-3, derived from RAD-10]

  • Patient Update – The ADT Patient Registration System informs the Order Placer and the Department System Scheduler/Order Filler of new information for a particular patient. The Department System Scheduler may then further inform the Image Manager. [RAD-12]

  • Procedure Update – The Department System Scheduler/Order Filler sends the Image Manager updated order or procedure information. [RAD-13]

  • Query Images – An Image Display queries the Image Archive for a list of entries representing images by patient, study, series, or instance. [RAD-14]

  • Retrieve Images – An Image Display requests and retrieves a particular image or set of images from the Image Archive. [CARD-4, derived from RAD-16]

  • Maintain Time – Synchronize the local time with the time maintained by the Time Server. [ITI-1]

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 1 : Patient Registered at ADT and Ordered at the Order Placer

  • Clinical Context

    • Corresponds to traditional Radiology workflow

    • Order placed in central system

    • Also deals with case where emergency identifier has been created

    • Common identifiers known ahead of time

  • IHE Context

    • MPPS in Progress from first modality used to update worklists for others

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 2 : Patient Registered at ADT and Ordered at DSS/OF

  • Clinical Context

    • Slight difference to Case 1

    • Order placed NOT in central system but in department

    • Department system provides info to Central ordering system

    • Typical of many institutes, relieves need for HIS terminal in lab

  • IHE Context

    • Filler Order Management (New Order) transaction [RAD-3] is sent from Department System Scheduler/Order Filler to the Order Placer.

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 3 : Patient Registered at ADT and ProcedureNot Ordered – Schedule on MPPS

  • Clinical Context

    • Procedure not ordered at hospital/dept. e.g. due to time-constraints.

    • A modality initiates creation of common identifiers on Departmental system

    • Allows multiple modalities participating in the case to be synchronized

  • IHE Context

    • DSS/OF creates a Requested Procedure/Scheduled Procedure Steps in response to the first MPPS-In-Progress

    • Requested Procedure created without waiting for response from Order Placer. This improves speed of cross-modality synchronization

  • TO BE CONTINUED……

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 4 : Patient Registered at Department System Scheduler/OF and Procedure Ordered

  • Clinical Context

    • Variation on Case 2 (procedure ordered in Department)

    • Patient registered NOT in central system but in department

    • Covers emergency case or when HIS is unavailable

    • Temporary Patient identifier used,

    • Manual reconciliation with official HIS ID later is used to update department records and ordering system

  • IHE Context

    • Temp ID is used to schedule procedure steps to modalities as normal.

    • Filler Order management is not invoked until after the reconciliation with official ID occurs. This is trigger to update DSS/OF, Image Manager and Order Placer with official patient, and order numbers

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 5 : Patient NOT Registered

  • Clinical Context

    • Combination of Case 3 and Case 4

    • No information/time to create patient/order identifiers at HIS or Department system

    • Patient ID entered at first modality is adopted for other modalities (as in Case 4)

    • procedure triggered by first modality shared across other modalities (as in Case 3)

  • IHE Context

    • DSS/OF creates a Requested Procedure/Scheduled Procedure Steps in response to the first MPPS-In-Progress

    • Filler Order management is not invoked until after the reconciliation with official ID occurs. This is trigger to update DSS/OF, Image Manager and Order Placer with official patient, and order numbers

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 6 : Patient Update During Procedure

  • Clinical Context

    • unidentified patient registered at the ADT system and brought into the cath lab with temporary patient demographics

    • Patient is identified and official ID/demographics sent by HIS while procedure is in progress.

    • Some data in the procedure is produced with temporary info and some with official.

    • This must be reconciled across the procedure

  • IHE Context

    • Modality may continue to transmit data with temporary identifiers

    • DSS/OF and Image Manager must continue to automatically reconcile such incoming data with the official data throughout procedure.

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 7 : Change RoomsDuring Procedure

  • Clinical Context

    • Not uncommon – diagnostic interventional, equipment failure,…

    • procedure is halted in one room, with one set of modality equipment, and resumed in another room with different equipment

    • For continuity of clinical data, it is critical that this be treated as a single Procedure

  • IHE Context (no comparable case in Radiology TF)

    • Each modality in the first room will issue a Modality Procedure Step Completed or Discontinued

      • Note – not required prior to moving, can be done later, but needed to complete the step at end of procvedure.

    • DSS/OF used to can reassign the Requested Procedure to a new room and create Scheduled Procedure Steps for those modalities who use WLM to restart procedure

    • IF no re-assignment - new modalities can issue broad (not own AE Title) query to get original SPS and then append an MPPS to that

IHE Educational Workshop 2005


Ihe cardiology profiles for year 1

Case 8 : Cancel Procedure

  • Clinical Context

    • When cases are cancelled it’s important that information systems reflect same so that staff are informed and can respond appropriately.

    • Case covers procedure cancelled prior to start

  • IHE Context

    • DSS/OF notifies the Order Placer system and Image Manger.

    • All three systems may maintain information about the cancelled Order and Requested Procedure for a pre-determined length of time.

IHE Educational Workshop 2005


Case 3 significant transactions

Case 3 : Significant Transactions

  • MWLM query (not shown) will not return a response for current patient (from card/wristband)

  • Unscheduled Performed Procedure Step created

  • DSS/OF recognizes patient and room from data in MPPS-In-Progress [CARD-1] (i.e. Patient ID and AE Title)

  • DSS/OF creates a (generic/specific) Requested Procedure/Scheduled Procedure Steps for other modalities in room using info above. Different than Radiology !

  • Order Placer and Image Manager informed of new, active procedure.

  • Requested Procedure created without waiting for response from Order Placer. This improves speed of cross-modality synchronization.

  • Subsequent MWLM queries [RAD-5] from equipment in this cath lab will receive the appropriate scheduled procedure steps including the necessary patient/study identifiers

IHE Educational Workshop 2005


Case 3 highlights

Case 3 : Highlights

  • Contributions

    • Multi-modality synchronization supported

    • Modality-initiated, ad-hoc, cases become “managed”

      • Time delays between first MPPS and shared SPS are seconds/minutes

      • Avoids trying to synch multiple studyUID’s later (not addressed)

  • Different…. not Deviant 

    • Auto create of Requested Procedure contradicts “letter” of IHE-R – but not “spirit”

      • Goal is to reconcile and unscheduled PPS with a Requested Procedure

IHE Educational Workshop 2005


For more info

For more info:

  • IHE Cardiology Technical Framework version 1.0 for Trial Implementation at:

    • www.rsna.org/ihe

    • www.acc.org/quality/ihe.htm

  • Submit questions and comments to:

    • http://forums.rsna.org

IHE Educational Workshop 2005


Ihe scheduled workflow concepts

IHE Scheduled Workflow Concepts

IHE has addressed the definitional problem of workflow processes by selecting three UNAMBIGUOUS HL7/DICOM TERMS :

  • PROCEDURE STEP : The smallest unit of managed workin the workflow:Scheduled Procedure Step: ‘A unit of work to do’Performed Procedure Step: ‘A unit of work done’

ORDER : A request for departmental service

REQUESTED PROCEDURE :Unit of work resulting in one Reportwith associated codified, billable acts


3 level w orkflow s tructuring c oncept is user oriented

CLINICIANOR REFERING DOC:The Imaging Dept Customer

CARDIOLOGIST : In Charge of producing

the Report

TECHNOLOGIST(and CARDIOLOGIST)In charge of acquiring images, etc.

3 level workflow structuring conceptis useroriented

ORDER:A request for departmental service

(Accession Number)

REQUESTED PROCEDURE : Unit of work resulting in one Reportwith associated codified, billable acts(Requested Procedure ID)

PROCEDURE STEP :The smallest unit of managed workin the workflow

(modality worklist entry)


Simple workflow

One or more series of images

Simple Workflow

Imaging Department

  • One Order – One Procedure – One Study – One Report

ORDER

A request for DepartmentalService

Set of Codifiable,

Billable, Acts

Requested

Procedure

Report

Acquisition Modality

Study is the container for the series of image/evidence objects

(denoted I-Study in IHE Rad TF Vol. II Fig. A-1)


Study uids in simple workflow

Study UIDs in Simple Workflow

  • Requested Procedure identifies Order Filler-specified Study UID

  • Modality uses that Study UID to store its images/evidence

  • Both Requested Procedure and I-Study (the object container) use same Study UID

    • Classic DICOM did not distinguish between these two concepts


Multiple modality steps

DICOMModality Worklist

ScheduledProcedure

Step A

Report

ScheduledProcedure

Step B

One or more series of images

One or more series of images

DICOMModality Worklist

PerformedProcedure

Step P1

PerformedProcedure

Step P2

AcquisitionModality

AcquisitionModality

Multiple Modality Steps

Imaging Department

ORDER

A request for DepartmentalService

  • One Order – One Procedure – One Study – One Report

Set of Codifiable,

Billable, Acts

Requested

Procedure

1


Study uids in multi modality

Study UIDs in Multi-Modality

  • Requested Procedure identifies Order Filler-specified Study UID

  • Each Modality uses that Study UID to store its images/evidence

  • All images/evidence stored under same I-Study

    • Again, Study UID shared between Requested Procedure and I-Study


  • Login