Keith Boone put up on his blog an informative piece on how to get and use OIDs. If you are in need of an unique object identifier, either for healthcare or otherwise, you should probably head over and take a look.
For myself, I really do not like OIDs at all (here comes the opinionated self back to the surface): OIDs and many similar identifiers carry information, but are not resolvable without a lot of pain. For example, each of the numbers in the OID is assigned to some sort of entity, like an organization (like the ITU-T), a country (like the USA), or a thing (the Internet). The dot notation is organized hierarchically, implying that you can “walk” that tree. Great. But you cannot, since each node owner (e.g. the owner of 1.3 = ISO Identified Org) can setup a registry for this branch and make it accessible to the wold, but the owner of e.g. 1.3.24 = DEC will probably not make their entire subtree resolvable to everyone. As such, if you encounter (hypothetically) an OID of value 1.3.24.0.1000, good luck figuring out what that may ever have meant. Even if HP wanted to make this available, it would take some heroic effort to find a public registry for 1.3.24 and then resolve this to some HP property.
On the other side, there are identifiers like IPv4 addresses which are – thanks to the wisdom of CIDR – essentially free of any special semantics: they are simply numbers. IPv6 does even a better job in making sure that the components of an IP address are not overloaded with meaning.
Finally, there are URLs that point to resources – and they have the wonderful feature that they can be fully resolved. If you are presented with a URL, you can immediately figure out where to go on the network to get to that resource. The path to the resource may not be clear (there could be firewalls or even air gaps in the way), but – in principle – your URL tells you exactly what to do if you want to get to the resource. Now, given that a URL points to exactly one resource, they make ideal identifier: they are unique (thanks to DNS and HTTP), they may carry some reasonable meaning (e.g. http://example.com/customers/1234/?invoice=9876 is pretty suggestive), and they can be resolvable into a representation of the resource.
Pick you own favorite.