1. 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, 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)
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)

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

5. 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)

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
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)

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
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)

8. 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)

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:
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)

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?
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)

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