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 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) Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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)

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) DOR DOC PCD-01 ACK-01 DOR DOC DOR DOC PCD-01 ACK-01

OIDs: Discussion Points Why 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.??) Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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 Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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 Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

OIDs: Discussion Points: How committed is IHE-PCD 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 Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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 Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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? Group has traditionally worked with and built tooling for various healthcare IT domains HL7 V2, HL7 V3, XDS, CDA, Patient Care Devices, NHIN Built test tools one at a time (independently) At the end of the day you’ve built one test tool (which is great, but…) In the process we need to gain domain expertise; is this really a NIST function? Necessary to some extent to test our tooling methodology (and the IT part) Many shortcomings with specifications and testing process became apparent Demand greatly outpacing industry capabilities to produce test tools Recognized a need to work more efficiently Need to “build tools to build tools” Don’t duplicate tooling (not only at NIST but in the community), we’re starting… V2 Tool Kit (leveraged for CCHIT Message Generation, PIX/PDQ, PCD, connectathon) External validation services (V2 and CDA); common interface/reporting More and more to come… Easier said then done—more applicable in some areas then others TI is not a do over; we’ll build on or adapt existing toolkit design/code base—not everything can be assimilated (cost/benefit)

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?

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