1 / 12

John J. Garguilo April 27, 2012 @ IHE-PCD Spring F2F – San Diego, CA

Standards Driving Interoperability HITTI - Healthcare IT Testing Infrastructure: Medical Device Communication Testing Object Identifier (OID) Discussion. John J. Garguilo April 27, 2012 @ IHE-PCD Spring F2F – San Diego, CA. OIDs: Discussion Points.

mickey
Download Presentation

John J. Garguilo April 27, 2012 @ IHE-PCD Spring F2F – San Diego, CA

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. Standards DrivingInteroperabilityHITTI - Healthcare IT Testing Infrastructure: Medical Device Communication TestingObject Identifier (OID) Discussion John J. Garguilo April 27, 2012 @ IHE-PCD Spring F2F – San Diego, CA

  2. OIDs: Discussion Points • Need: Identifiers that are guaranteed to be unique • Background / Perspective (IHE-PCD) • What are we trying accomplish with OIDs and their multiple uses? • Why? • What’s Needed to get usage? • How does IHE-PCD achieve usage of OIDs? • How committed are we; are IHE-PCD members able and ready? • “Transaction” versioning (added discussion point per Todd Cooper request/suggestion)

  3. Using OIDs in IHE-PCD: Perspective and Background Perspective from capturing and communicating (bi-directional) device data: • Between devices • E.g., Respirator reporting/communicating to Patient Monitor • Between devices (device gateways) and Enterprise • E.g., Medical Device reporting/communicating information to Electronic Medical Record or Electronic Health Record systems) • E.g., Communicating device alarm to nurse call station (or personal device on nurse)

  4. Using OIDs in IHE-PCD: Perspective and Background For IHE-PCD: This means encoded in communications – at all levels • @ Message Level: Definition via HL7, Constrained in IHE-PCD TF • @ Interaction Level: Between actors across all profiles (where applicable) • @ Transaction Level: Related Interactions between actors • @ Segment Level? (suggested add from Ioana S): * IHE-PCD must be aligned with ISO and IEEE on OID definition + usage PCD-01 (ORU^R01^ORU_R01) ACK-01 (ACK^R01^ACK) ACK-01 DOR PCD-01 DOC DOR DOC PCD-01 DOR DOC ACK-01

  5. OIDs: Discussion PointsWhy consider OIDs? • Provide implementers (and testers) a common approach of having a way to uniquely identify content and meaning • Vendor/Implementer Perspective - Enable conformance and semantic interoperability for all implementers • Testing Perspective - Concrete testable assertion when evaluating meaning of communicated information • Can be achieved via HL7 Standard – primary messaging standard used by IHE-PCD+ potentially involves coding (using OIDs) across HL7 Segments, Fields, Components, and Sub-components • Across several segments, e.g., MSH, OBX • Across several Fields (e.g., MSH.21, OBX.??)

  6. OIDs: Discussion Points: What’s Needed to get Usage? • Must take a holistic approach (full domain umbrella) • Identify precedence or adoption where available, use if appropriate • First take inventory or what’s out there to date • ISO, IEEE, HL7, other OID registration authorities? • Do existing hierarchies make sense for IHE-PCD domain? • Narrowing the Scope of Medical Device Communication Standards • Need to narrow the scope to be ‘usable’ (but ensure sustainability) • Must be forward and backward compatible

  7. OIDs: Discussion Points:How does IHE-PCD Achieve usage of OIDs? • Profiling – Constraints place on Standards – maybe through constrained value sets identified and/or pointed to IHE-PCD and/or built by IHE-PCD in TF • Could be at infrastructural level (SDOs) • Could be localizations (IHE-PCD constrained values) • By insisting use via Integration Profiles, Implementation Profiles, and Conformance Profiles • By consistently identifying OIDs and approach in all documentation and implementation agreements (including between domain working group efforts and with other organizations like FDA, AAMI, GS1 (VA), UDI, Continua, MDPnP/CIMIT, MDC standards bodies • How committed are we; are IHE-PCD members able and ready? • Common (harmonized) approach called out in IHE-PCD TF documentation (if not elsewhere) • Onus, at this point may be on IHE-PCD Working Group to get going… • However IHE-PCD must ensure not to replace or over-ride any existing OIDs

  8. OIDs: Discussion Points:How committed is IHE-PCD?Are IHE-PCD members able and ready? • Common (harmonized) approach called out in IHE-PCD TF documentation (if not elsewhere) • Onus, at this point may be on IHE-PCD Working Group to get going… • However IHE-PCD must ensure not to replace or over-ride any existing OIDs • Is this realistic? Will OIDs end up in products and production systems? • Or, is this really more an inventory or way of versioning necessity

  9. OIDs: Discussion Points:Work starting point (informal) • Informal inventory of other IHE Domains – mainly ITI • IHE-PCD Co-Chairs (John R. + John G.) IHE-PCD Wiki Page: • IHE-PCD "PCD_OID_Management" wiki page: http://wiki.ihe.net/index.php?title=PCD_OID_Management • Wiki page is first attempt to start documenting an OID structure or encourage more discussion – please take as totally informal

  10. OIDs: Discussion Points:What next? • Refine/Redo, based on today discussion PCD OID wiki page • Do more research if other efforts identified • Form a Tiger team to: • More formally define an OID structure that works for IHE-PCD (and if necessary points elsewhere) • Get documentation going on wiki page • Identify specific fields, components, sub-components OIDs might be applied to TF • Other thoughts?

  11. Resultant Discussion/Thoughts • Start with identification – are we after an Ontology for PCD? • What are our real-world “things”? • 1. Start by making an inventory (see wiki page- for start of that…) • 2. Versions of “things” – uniquely identifying each new instance of a “thing” • Integration Statements? • Profiles? Many types: • Vendor / Implementable Profiles • Constrainable • Conformance • Compatibility Profile (ref. Sender/Receiver pair compatibility matrix for both implementable and constrainable analysis and rules) • Define our “tree” of what we want to identify in our tree • Documentation issues • Instance issues • Structural issues • Conversational issues?

  12. Agreed upon next steps (@ F2F meeting, 4/27/2012) • John G. will take the lead • IHE-PCD members are asked to join in helping w/ a tiger team, possible candidates to help: • Ioana S. • John R. • Todd C. • Others? • Start moving this topic forward • Add to Action Item List (lead Garguilo) • Call for help • Form team • Report proceedings at bi-weekly TC TCons

More Related