1 / 63

PCD Infusion Pump WG 2012 Spring Summit

PCD Infusion Pump WG 2012 Spring Summit. Updated: 2012.03.27. Welcome to San Diego …. “America’s Finest City!”. IHE PCD Infusion Pump Spring Summit. Summit Objectives: Establish the technical content and approach for the five Technical Framework Device Specialization Documents:

aideen
Download Presentation

PCD Infusion Pump WG 2012 Spring Summit

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PCD Infusion Pump WG2012 Spring Summit Updated: 2012.03.27

  2. Welcome to San Diego … “America’s Finest City!”

  3. IHE PCD Infusion Pump Spring Summit • Summit Objectives: • Establish the technical content and approach for the five Technical Framework Device Specialization Documents: • Device Specialization – General Content Module • DS – Infusion Pump – General Content Module • DS – Infusion Pump – LVP Profile Supplement • DS – Infusion Pump – Syringe Profile Supplement • DS – Infusion Pump – PCA Profile Supplement • Plan for document & profile development & prototyping • Review IHE PCD Technical Framework CPs • Challenges: • Time Management – Way more than a week’s worth of discussion! • Focus on technical issues – address editorial later • …

  4. IHE PCD Infusion Pump Spring Summit • Tuesday Agenda: • Q1: • Introductions & Agenda Review & Logistics • Review General Work Plan • Review Proposal Slide Deck (level setting) • TF Supplement Templates • Medication Administration Strategy White Paper • Call for CPs of Pump WG Interest • Q2: • Device Specialization – General Content Supplement • Device Online/Offline Status Event Reporting (in PCD-01) • Device Specialization – Infusion Pump – General Supplement • Q3 / Q4: • Device Specialization – Infusion Pump – LVP Profile Supplement (Including IPEC Content Review)

  5. IHE PCD Infusion Pump Spring Summit • Wednesday Agenda: • Q1 / Q2: • Syringe Pump Device Specialization • Q3 / Q4: • PCA Device Specialization (Discussion agenda for each specialization) • Device Characterization & Use Cases • 11073 Terminology & Model • Alarms w/ Evidentiary Data • Operational Modes & Event Semantics (w/ state/context data) • Auto-programming Support

  6. IHE PCD Infusion Pump Spring Summit • Thursday Agenda: START @ 08:00!!! • Q1: • Mixed Modality Modeling (e.g., LVP w/ PCA Module Attached) • PCIM Technical Review • Review PCIM use cases / requirements / Scope • Resolve technical direction • Establish profile elements & work plan • Q2 / Q3: • Future Development Cycle Proposals (e.g., drug library support, or intra-operative anesthesia pumps, etc.) • Review new term process, tooling & proposals • Pump-related CPs Review (2nd pass) • Review Summit Action Items & Work Plan Adjourn by 15:00!!!

  7. IHE Development Process

  8. IHE PCD Profile Life Cycle We are here!

  9. IHE PCD Profiles

  10. IHE Infusion Pump Device Specialization ProfilesTechnical Framework Considerations

  11. Device Specialization – Infusion Pump • Why for a DS-IP Work Item? • Lack of consistency in how the same semanticcontent is reported from various vendors (terms & models) • Can’t conformancetest for specific device modalities • IHE Integration Statement (IIS)languagenotclear per device modality • IP users have to look at a list of items for RFPlanguage (not in their words “syringe pump profile”!) • IP users can’t easily identify what exactly hasbeentested (using IHE databases) • Not easily integrated into otherprofiles (e.g., PCC PW) • Challenges: • Consistency w/ The IHE Way • Minimize unnecessary work • Ensure extensibility to new modalities / capabilities

  12. DS-IP: Anticipated Benefits • DS-IP “Success Factors”: • Stronger testing of specificdevicemodalities • Especially semantic content testing & consistency • Devicesidentified clearly in testingresults & IIS • Consumer (e.g., DOC) applications would be “simplified” • End users would benefit from knowing that the “widgets” that they are interested in have been validated … directly … • Easieruptake of PCD TF components, both in PCD & other domains • Extension to newdevicemodalities (both therapeutic & diagnostic) – vents, physiological monitors, SpO2, … beds! • What will it take to define new DS-X’s?! • Value sets only? • When does it “justify” a profile? • Time lag / effort to develop specializations?

  13. IHE TF Examples: PCC Perinatal Workflow (PW) • Actor Names: • DOR & AM … grouped? • Device Observation Recorder? • Device Gateway? • The Device Gateway Actor coordinates communication between the recording / viewing equipment and specialized monitoring (e.g., electronic fetal monitoring [EFM]) or treatment (e.g., Infusion Pump) devices. Transactions: Actor end points? Direction? (e.g., PCD-05) Typo Specific devices: Hearing Screening Device … IHE PCC-PW (rev 1.1, 2010-08-30) Figure X.3-1 PW Actor Diagram

  14. DS-IP: Scope & “Deliverables” • DS-IP Deliverables: • Define pump-specific semantic content modules: • Parameters (settings, observations, status) • Alarms / Alerts • Events • Bind to DS-G w/ IP guidance & constraints • Support device subtypes, including information models & value sets: • General infusion pump (incl. LVP?) • Syringe • PCA • Bind to existing transactions / foundational profiles: • DEC (periodic reporting) • ACM (alarm/alert reporting) • PIV / PCD-03 (device programming) • IPEC (event reporting) • Define new transactions (TBD)

  15. IHE PCD TF Components Note: 1st pass model – this may be broken into layers as more detail is added.

  16. Flashback: PCD TF a la 2009 Very high level – “Devil in the details!” Focus was on testing of transactions vs. semantic content Device specializations seen as v3 content – messaging / transport a separate problem Note: This was for discussion only – never balloted in PCD.

  17. PCD Technical Framework - Today • Notes: • Read mostly top-down • Dotted ovals are TI versions • IPEC is intended to become EC • “Basic Models” includes TF-2 Appendix D • “Alarms” includes ACM alarm model + params • Narrow profile use? • DEC – Periodic updates • ACM – Episodic delivery to a clinician • EC – Episodic delivery to a system Not shown are format specifications and content bindings …

  18. PCD Technical Framework++? • Consider… • Specialized applications will focus on binding to existing general / foundational transactions • PIV left independent for historical purposes but will also be an option for DS-IP; should it remain standalone? • DS-IP content modules will include LVP, syringe and possibly PCA • IPEC => EC, with DS-IP[-xyz] including an EC binding to PCD-10 + DS-IP[-xyz] (events) content module.

  19. DS-IP: Tech Framework Approach • Notes: • Agent / Manager … ? • OR … Specialize IP Actors per pump type • Profile dependencies are for required functionality • For dependent profiles, Initiating & Receiving Actors are “grouped” with IP Agent or Manager Actors • Event Communication (EC) an option or dependency? • OIDs (MSH-21) indicate content bindings + options • Content binding => New Transactions? • “PnP Connect” Option w/ DPI profile binding? How would that affect the Dependencies? Do they have DPI option? This is still a tortured diagram …

  20. DS-IP: Actors – Grouped & Fused • Notes: • Alternative to having single DS-IP-LVP Agent & Manager actors is to have a combination of grouped actors + a fused actor that combines all the functionality. • Grouped actors represent the binding between the profile transactions and the appropriate content model • This would allow for testing, for example, of the LVP specific alarm transactions separately from the DEC or EC transactions.

  21. IEEE 11073 Stds. vs. IHE Elements

  22. IHE PCDTechnical Framework Supplements

  23. NISTTest Tooling Support

  24. NIST Test Tooling

  25. NIST Test Tooling

  26. NIST Test Tooling

  27. NIST Test Tooling

  28. NIST Test Tooling

  29. IHE Medication Administration Clinical Integration Strategy White Paper

  30. IHE Med Admin Strategy WP Addressed by PIV Profile Scope of the White Paper

  31. IHE Med Admin Strategy WP

  32. IHE Med Admin Strategy WP

  33. IHE Med Admin Strategy WP

  34. IHE Medication Administration Clinical Integration Strategy WP • White Paper Development Target: Summer ‘12

  35. IHE PCD Technical Framework Change Proposal … Proposals

  36. IHE PCD TF CP Discussion • Issues for Tech Framework CPs … • <see proposed TF CPs list> • <TBD> • … • …

  37. Device Specialization - General

  38. Device Specialization - General • Device Specialization – General … • Review Volume 3 Content • Review TF-2 • MSH Fields • OBX-18 • Other? • Review 11073-10201 System Objects Attribution • Coordination w/ MEM-CMMS Profile • Multi-patients per Box – Modeling Guidance • Additional information: • Device IP / MAC / AP addresses • I/F properties (BT, Ethernet … properties, state, etc.) • Switch between transports & reason • EC for DevMgmt – Clock Updated + source of change + new val. • Device online/offline status reporting in PCD-01

  39. Device Specialization – Infusion Pump – General

  40. DS – IP – General • Device Specialization – Infusion Pump – General … • Review Volume 3 Content • General Considerations • VMD scope: per Delivery Channel? • OBX-18 • Other? • Additional Content? • From PIV? • … • …

  41. Device Specialization – Infusion Pump – LVP

  42. DS – IP – LVP • Device Specialization – Infusion Pump – LVP … • Review Content from TF-3 Infusion Pump • Review IPEC Content • Review PIV Content (from general DS discussions) • Device Characterization & Use Cases • 11073 Terminology & Model • Alarms w/ Evidentiary Data • Operational Modes & Event Semantics (w/ state/context data) • Auto-programming Support • …

  43. Device Specialization – Infusion Pump – Syringe

  44. DS – IP – Syringe • Device Specialization – Infusion Pump – Syringe … • Device Characterization & Use Cases • 11073 Terminology & Model • Alarms w/ Evidentiary Data • Operational Modes & Event Semantics (w/ state/context data) • Auto-programming Support • …

  45. Device Specialization – Infusion Pump – PCA

  46. DS – IP – PCA • Device Specialization – Infusion Pump – PCA … • Device Characterization & Use Cases • 11073 Terminology & Model • Alarms w/ Evidentiary Data • Operational Modes & Event Semantics (w/ state/context data) • Auto-programming Support • …

  47. Additional Considerations

  48. PCD TF Issues: “Fused” DOFR? • Discussion: • Should a fused DOFR actor be defined for DEC? • Companies today implement DOFR • NIST testing assumes a DOFR • Making the change would: • Reflect reality! • Simply IIS • …

  49. PCD TF Issues: Containment Message Header MDS Channel #1 Parameters Message Header Message Header Message Header Channel #2 MDS MDS MDS Channel #1 Channel #1 Channel #2 Parameters Channel #2 Parameters #1 Parameters #2 Parameters #1 Parameters #2 Question: How should static containment information be sequenced in a PCD-01 message? Option 1: Interleaved Option 2: Containment Block + Parameter Block Option 3: 1 Source/Delivery Set / Message (+ #1 / #2) • Discussion: • PCD TF should make some statement • Option #1, #2, #3 or all of the above? • Pros & Cons for DOR vs. DOC? • Choosing one would simply implementations • Is it too late to choose?

  50. PCD TF: OID Allocation • Content: • Bring in basic table w/ architecture from wiki page @ http://wiki.ihe.net/index.php?title=PCD_OID_Management • Discussion • Use multiple OIDs in MSH-21 to identify specifications for message, starting with PCD-x conformance spec + options + semantic content “modules” + … • Identify other OID bindings to HL7 v2 messages + CDA documents • Identify other OID usages … ??? • Does OID architecture follow IHE TF object model? • OIDs should be associated objects / classes in the preceding UML model • …

More Related