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

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