I think option 2 is better. Jurisdictions will determine what is the requirements for the form of the unique identifier. In California it will be an oid.
···
On 8 October 2014 13:26, Carl Leitner litlfred@gmail.com wrote:
Hi,
I would prefer to go in with a concrete proposal (or few) that would address Rob’s concerns and I think we can make some slight changes/compromises to keep everyone happy. There are actually two contexts which we are discussing the use of URNs vs OIDs and I think we can alleviate concerns if we clearly separate these out:
- A Care Services Source Directory (SD) wants to publish the care/heath services that it offers to the system. Note that the SD doesn’t really care what happens to their data, it’s not per-se directly participating in the IHE.
- A Care Services Finder (SF) needs to know an enterprise ID to reference the facility, health worker, organization or service. It needs to be confident that this is a globally unique ID and that other systems will use the same reference.
It is in the first context where things like DHIS2 and iHRIS are operating in and wish to avoid being responsible for the generation of OIDs as this presents a barrier to implementation.
I think it is the second context that Rob is most concerned with and wishes to use OIDs to ensure consistent policies for the generation of ‘database/enterprise identifers’. Note also, from what I understand, I think the use of a UUID in lieu of an OID would also be acceptable to Rob.
Luckily between these two contexts sits the Care Services Info Manager (tra-la-la) which can mitigate the concerns. We have a few options here.
Option 1: Add language to the effect of:
For any entity (hw, facility, organization, service) published by a SD which does not have their @urn attribute according RFC 4122, the Care Services InfoManager SHOULD:
- Add (if it does not already exist) an csd:otherID/ element to the entity such that:
- @code is the value of the entity’s @urn attribute as specified by the SD
- @assigningAuthorityName is the value of the @sourceDirectory attribute of the entity’s unique csd:record/ child element
- Generate a UUID and set the @urn attribute of the entity according to RFC 4122
- In the entity’s unique csd:record/ child element:
- Set the value of the @sourceDirectory attribute to be the URI of the Care Services InfoManager
- Set the @updated attribute with the current date-time.
Note, this is not a SHALL, though I suppose it could be.
Option 2: Note that we already have a point in the CSD spec which describes the behavior of the InfoManager went it merges directories together. Here, the InfoManager is supposed to go into a fault condition if there is some issue with the SD data sources. We add language to clarify that it is acceptable for a jurisdiction to define additional data governance policies beyond the scope of the CSD standard to be enforced at this step. Then, Rob’s issue becomes an issue of data governance: namely that a SD not using an UUID or OID as an URN does not adhere to the data governance policy of the HIE. In such a case, the InfoManager goes into a fault condition and can, for example, proceed with the three steps outlined in Option 1.
Cheers,
-carl
On Oct 8, 2014, at 7:05 AM, Bob Jolliffe bobjolliffe@gmail.com wrote:
On 8 October 2014 02:48, Derek Ritz derek.ritz@gmail.com wrote:
Good night, Bob. And thanks for the clarification. An 11 character alphanumeric which is randomly generated has a collision space of 36^11. A collision between 2 facility IDs within this space would truly make me believe in religion… if not systems engineering! 
Its a little larger than that. The first character cannot be numeric (to ensure that that it is also a kosher xml:id). And the alpha is case sensitive. So more like:
52 * 62^10
Let’s make our cogent case to Rob Horn, and others on the IHE ITI committee, that we want to use URNs as our CSD ID coding spec… for all the right reasons. Nothing about it will prevent any of the ~20 countries who can use OIDs from continuing to use OIDs. And it will make bringing on the other ~230 all that much easier.
Warmest regards,
Derek.
On Tue, Oct 7, 2014 at 9:13 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Derek
I should be in bed now instead of replying to this, but just one important point below …
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
On 8 October 2014 01:40, Derek Ritz derek.ritz@gmail.com wrote:
Hi all.
As I understand this issue, from Rob’s standpoint at least, it is that the enterprise ID is being confused with the administrative ID. The former is a unique ID used at the database and data exchange levels. It’s job in life is to be unique… like only-one-in-the-universe unique. And in Rob’s experience (which goes back to the 70’s)… OIDs are the data format of choice for being only-one-in-the-universe unique.
The latter ID, the administrative ID, is what a ministry or a district might assign to the item in question (a facility, for example). These have been meticulously created and are curated and are the IDs that people use and know. This is the ID that no one wants to be an OID. I think the thing that is lost in our discourse so far is that absolutely no one, including Rob (or anyone else that I know of) wants the administrative ID to be an OID.
The crux, here, seems to be centred around a confusion between the administrative ID and the enterprise ID. Am I misreading all of this – or is the argument centred around the idea that we absolutely MUST use the administrative ID as the enterprise ID?
I’ll be frank… I’m not, personally, a fan of OIDs. We use them here in Canada so I have lots of experience with them and I know they work. When I was operating software companies, back in the day, we always used GUIDs for our enterprise IDs and they worked great and they didn’t need any external governance at all. I prefer GUIDs… but that’s just me. What we never did, however, was use a local administrative ID as an enterprise ID. That just doesn’t work in an interoperable context. It can’t work.
So… I’m in favour of the URN change request for CSD because of my great experience using GUIDs as enterprise IDs and because I believe that such a practice, since it is not so governance-burdened as OIDs, would be well-suited to the environments where we work. But I think I’m hearing pushback because of a need to use administrative IDs as if they are enterprise IDs. This latter argument is not, for me at least, at all compelling. I do not think it will be compelling to Rob, either, or to others with lots of interoperability experience.
Am I missing a landscape issue, here? It sounds like all of the existing DHIS2 systems presently are using administrative IDs as their enterprise IDs and there is too much installed base out there to go about changing it. Do I understand this correctly? If that’s the case – and it is a pretty daunting thing to think about altering that many systems – then let’s just work through solving it as a systems engineering problem (not as a religious problem). It’s easily enough addressed, in all kinds of ways. If you take something that is locally unique and append it to something that is globally unique you have something that is still globally unique… right?
Nobody is really suggesting using the administrative id. I maybe created some confusion initially when I gave a historic account of how in the past we (dhis) actually had nothing better than the name to go by in terms of uniqueness. And an internal database primary key.
You will still find this commonly the case with the many excel spreadsheets out there which act as the authoritative source of MFL.
What we have on all our internal objects is an internal 11 character ID which is randomly generated. Looks for example like “h47tUYYTgg7”. Its not quite as large a collision domain as a UUID, but large enough that we really haven’t seen clashes anywhere. The character set is larger than the case-insensitive UUID so the permutations are really quite large - don’t remember exactly but a very big number. It can very easily be appended to a urn preamble, for example “urn:dhis2:facility.h47tUYYTgg7”.
Thats our system. Other systems are out there with their own approaches. None using oids from what I have seen. But all of which can be creatively used to form global identifiers.
Even a uuid can be similarly appended to a urn in a reasonable way. The problem of encoding uuids in oids is they become ridiculously long - certainly longer than the expected space in most systems I have come across.
Having said all that, I don’t quite swallow the argument that oids are somehow not administrative (or administered). The whole structure of the tree implies a high degree of curation from top to bottom. Granted the leaf part can be generated algorithmically, but I don’t see how there is anything magical in the oid properties which make it particularly less administrative than anything else being proposed. Other than its a very real problem to get a root oid registration authority for Liberia. If it wasn’t we would have seen these authorities blossoming everywhere already.
I’m not being religious about this. If anything I am trying to resist what seems like a faith-based, totalizing approach which doesn’t seem in any way practical to reality as we find it. You can look at the ITU registration authorities and see for yourself. Or even look at the hl7 country authorities. They cover a grand total of less than 20 countries or somewhere in that region.
I think using recognized oids for classes of object can be quite practical and also useful harmonisation. For instances of facilities, providers, etc it is a recipe for chaos (or more likely non-adoption).
Bah, its past 2am. I must go to bed …
Bob
PS. Isn’t software engineering also a religion of sorts? Just teasing …
Rob likes OIDs. He probably also has a favourite colour and a favourite movie. We should not be promoting URNs in our CSD spec because we want to use weak enterprise interoperability practice; we should be promoting URNs in the CSD spec so we can use GUIDs or some other perfectly credible alternative to OIDs to operationalize strong enterprise interoperability practice.
I hope this is helpful. Of course, if I’ve completely lost the plot, I’m sorry (and I wish I’d made the email shorter to have wasted less of everyone’s time).
Warmest regards,
Derek.
On Tue, Oct 7, 2014 at 4:05 PM, Jim Grace jimgrace@gmail.com wrote:
Thanks, Bob. We’ll see how it plays out…
–
You received this message because you are subscribed to the Google Groups “Facility Registry (OHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to facility-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Derek Ritz
This email may contain confidential information intended only for the recipient. If you receive it by accident, please delete it.
On Tue, Oct 7, 2014 at 2:54 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Hi Jim (and apologies for cross-posting)
Just to be clear, we are talking about a change to CSD here rather than DXF, though the same set of arguments will apply. So our interest in CSD is more about identifiers for facilities and organisations and services rather than the fuller metadata model of dataelements, indicators etc.
Robs argument about all those other (well-maintained or not) identifiers is that they are well and good, but we do in addition need to have a “system” identifier which is somehow uber- and also authoritative. And that should be an oid.
I think in part its a cultural thing - for systems to fit into the rest of the hl7 (and it seems IHE) universe they really need to go with the flow of the rest of the suite, which uses oids for just about everything. The problem of course is that that universe is far from global. Besides a strong uptake of these consortium standards in North America and to a lesser extent in Europe, the rest of the world, for all manner of better and worse reasons, exists largely outside of it.
Of course if that world consisted of nothing but the dark emptiness of pre-colonial space then an argument along the lines of starting with an oid registry might make sense. But again it is not like that … there are systems existing in that space which have evolved over quite some time to meet particular health challenges which are peculiar to that space. We can consider dhis as one but there are many others.
I think its cultural in another sense as well. To the best of my knowledge I have seen that facility identifier oids in the US for example, seem to be largely assigned through the hl7 root oid (somebody please correct me if I am wrong). This in some way seems to reflect the more private nature of large sections of the health system there, with many health facilities being part of consortiums, franchises or what have you. In most of the African contexts (and elsewhere) the government, through the Ministry of Health, plays a much larger, though certainly not exclusive, role in health service delivery. And there is no local hl7 international affiliate. And so there is also a question of sovereignty and some tension between public and private sector mandate.
Leaves me at a bit of a loss. We can not wish these oids into existence. And if all of these ehealth standards (specifically hl7 and ihe) require oids we might be barking up the wrong tree, at least in the short term. But we will keep trying to make the case.
Bob
On 7 October 2014 19:13, Jim Grace jimgrace@gmail.com wrote:
Hi All,
I may be naïve about this, but it seems to me that the main purpose of this data exchange format standard is to avoid vendor-lock in a proprietary solution, but rather to promote a standard way of writing software so that things are done in a well-thought-out way where you can use software components from a variety of vendors that support the standard.
Of course metadata coding is very important, but I think it would be quite counterproductive to require any particular kind of metadata coding syntax for this standard, whether it’s OIDs or anything else.
The metadata coding syntax will depend on the requirements for each implementation. For example in real-world work we are doing with DHIS 2 for a multi-national client, they are maintaining their own metadata coding scheme for hundreds of data elements, and another scheme for identifying many thousands of locations worldwide. They have invested a huge amount of effort in developing and maintaining these codes. These codes are private, well-defined, and not OID-based. If we say that they must use OIDs in order to conform to some standard, they will not. I suspect this is more the norm than the exception. Countries generally already have their own standard location codes, data codes, etc.
If we have a standard that does not dictate the form of metadata coding, it will provide all the benefits described above. If we have a standard that insists on a particular syntax of metadata coding, whether OIDs or anything else, the standard will be irrelevant in most of the use cases I know of.
Having said this, I’m all for metadata standards. But I see this as a separate effort. The use case for standardizing metadata is significant, but it is necessarily smaller than the use case for a data exchange protocol. There will always be proprietary metadata coding schemes that are the most natural for certain implementations. Then there are other cases where a standard metadata coding scheme is needed. We should let all the implementations use a standard protocol – and the cases that need to can also use a standard metadata coding scheme. But let’s not confuse the two types of cases by requiring a particular metadata coding scheme for the general data exchange format.
Cheers,
Jim
On Tue, Oct 7, 2014 at 1:28 PM, Bob Jolliffe bobjolliffe@gmail.com wrote:
Ouch. so many calls … thanks for the reminder.
We need to strategize a bit on how we are going to get through this. A few thoughts (trying to catch myself up):
- Rob rightly wants to distinguish between administratively assigned, curated identifiers and machine generated (or at least for machine use), database unique identifiers. But it becomes confusing in the context of oids, because, as we know, there is a significant degree of curation involved generally with oids. Even if that is at the simple level of determining a root id.
Nevertheless we can agree that there is a difference between the globally unique identifier and other identifiers which may be in use. And we foresee that in the csd schema:
<xs:element name=“facilityID”
type=“xs:ID” />
<xs:element name=“otherFacilityID”
type=“Identifiers”
minOccurs=“0”
maxOccurs=“unbounded” />
- There is a maturity model which we are obliged to somehow get right. Even if we do agree from Rob’s 25 years of experience, that the oid is the “best” solution (which I don’t necessarily) the concrete reality remains that national oid registries are not functional anywhere where we work. So we can put CSD on hold for a year, or two, or ten while this state of affairs matures, or we are obliged to be innovative and maybe a litle flexible.
- Rob seemed to be suggesting at some point last week that one could perhaps circumvent the problem of national registries, through the use of some enterprize branch. I think his words were that there was “probably not legislation that required facility oids to be located under a national registry”. Perhaps he will elaborate further on this, but it seems deeply problematic to me.
- I am more than ever convinced, having read around a bit, of the wisdom of those comments I referred to on the german hl7 group. That oids have historically worked well at the identification of classes of objects rather than their instances, at least this seems to be the case with respect to patients, healthworkers and health facilities. Where they also can work well is in the identification of systems and devices - hence the sysObjectId ( 1.3.6.1.2.1.1.2 ) in SNMP to which the enterprize which produced the switch, router, fax machine, x-ray machine or what have you can assign a unique identifier from within its own enterprise space.
Not sure where we will continue with this … I’ve sounded out a bit in SA and the response I am getting from there as well is that nobody uses them.
–
You received this message because you are subscribed to the Google Groups “Open HMIS” group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-hmis+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On 7 October 2014 13:57, Carl Leitner litlfred@gmail.com wrote:
Making sure you saw this… it is for 10am Chicago time.
Cheers,
-carl
Begin forwarded message:
From: Lynn Felhofer felhofer.lynn@gmail.com
Subject: [ititech:4685] Oct 3 ITI CP call minutes
Date: October 7, 2014 at 8:55:24 AM EDT
To: “IHE ITI Technical Committee (ititech@googlegroups.com)” ititech@googlegroups.com
Notes from Friday’s ITI Tech Committee CP processing call are here: http://wiki.ihe.net/index.php?title=ITI_Change_Proposals_2015#Minutes
Next is our “third Thursday” CP call on October 16, 9-11am
The agenda will be split:
- 9-10am: Process Incoming and Assigned CPs ready for review. I need a volunteer to run this portion of the meeting. I can prepare the agenda so the meeting is ready to go, but I will be at the Eye Care connectathon and unable to join. *Anyone willing?**? *if so, please send me a note. thx.
- 10-11am: Continued consideration of Friday’s Unique ID discussion raised by CP-ITI-800. This portion will be led by Rob Horn. There will be material sent to the ITI Tech mailing list in advance to prime the discussion.
Lynn
–
You received this message because you are subscribed to the Google Groups “IHE ITI Technical Committee” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ititech+unsubscribe@googlegroups.com.
To post to this group, send email to ititech@googlegroups.com.
Visit this group at http://groups.google.com/group/ititech.
For more options, visit https://groups.google.com/d/optout.