Hi David,
OIDs play a vital role in many of the standards (HL7v3, CDA, HL7v2, etc.) and assist in the identification of objects (devices, patients, facilities, organizations, policies, etc.) within several of the products in OpenHIE. There are many ways in which OIDs can be used but I like to think that every entity within a health infrastructure should have a way to uniquely identify itself, and its subsystems. OIDs allow us to easily see what system/authority generated or is responsible for a particular object.
I’ll use the Client Registry as an example of where OIDs are used and how they should be assigned. The client registry’s primary job is managing demographic and identification information about patients. For example, I know that the OID 1.3.6.1.4.1.33349.3.1.1.2.1 belongs to Mohawk College (1.3.6.1.4.1.33349), I can contact the custodian (Mohawk College) to figure out what .3.1.1.2 points to (it actually points to .3 = applied research, .1 = health informatics, .1 = physical infrastructure, .2 = client registry cluster, .1 = host A). Any audits, SNMP traffic, etc. I can track this physical machine’s actions. A logical identifier (for patients, facilities, etc.) are organized under 1.3.6.1.4.1.33349.3.1.2, this identifier represents a tree where I can determine the custodianship of data or devices. Having this level of planning makes managing a large infrastructure (SNMP, Audits, etc.) much easier than, say, assigning a random UUID to these objects or using other means of identification (such as hostname, IP address, etc.).
These OIDs can be used in a variety of ways, for example, in an audit message, I could look see this:
I know that this represents an audit generated by the node A of the client registry cluster (whereas the hostname cr.marc-hi.ca will point to a number of machines).
Whereas in a PIXv3 message, I can see that a particular patient exists as key #40 on the client registry (it is assigned under the .3.1.2 or logical identifiers tree node):
<v3:id root=“1.3.6.1.4.1.33349.3.1.2.2.0.0” extension=“40”/>
Per question #2, anything that can be identified qualifies to have an OID. It really depends on what needs to be identified. In the MEDIC infrastructure each project will get its own root OID under the “Projects” OID (1.3.6.1.4.1.33349.3.1.100..<project_#>) and it is a project planning step to identify which pieces need OIDs.
Per question #3, each system allows you to configure OIDs in different ways. The MEDIC-CR uses an OID registry (or a list of OIDs) in a configuration file, whereas OpenXDS (the registry) will use a series of configuration files to control OIDs, and OpenSHR uses OpenMRS properties to do the job. Typically you don’t want the OIDs to change once you get data into the system as (in practice) you have to cascade that identity change across multiple systems.
Question #4 I’d say at the beginning, before you install. For anyone who has setup an Active Directory infrastructure it is akin to re-organizing your corporate forest or org-units, which is possible but a very painstaking process. I always encourage that those implementing their infrastructures carefully plan (just like deploying a corporate active directory system). Setup is usually the last step and careful planning makes expanding the infrastructure much easier in the future. That being said, there are templates and best-practices guides on how to organize a directory, and many of those apply to OIDs as well.
Hope that makes sense and wasn’t a TLDR response …
Cheers
-Justin
···
On Thursday, June 11, 2015 at 12:36:43 PM UTC-4, David Radune wrote:
Hi all,
During a recent call on the subject of DATIM and OpenHIE, a series of questions regarding OIDs surfaced and it was suggested that we post our questions to the OpenHIE Architecture Community. Here are the questions:
- How are OIDs used
within OpenHIE?
- What qualifies an object to be assigned an OID? In the example OID plan that I’ve seen,
physical/virtual servers get them, but so do OpenHIE components (Facility
Registry, Interoperability Layer, etc.), as do some entities within the underlying
project-specific data model (e.g., Site ID, Person ID, etc.).
- Do the OHIE
components allow for setting OID system variables so that they can be
easily configured as software changes move through dev, test, stage and production
instances?
- In an OpenHIE distro, how would OIDs be configured and at what point would they be configured?
If anyone can shed some light on these issues, that would be greatly appreciated. Thanks!