OIDs and IDs in C-CDA Samples

[Brian Weiss]

In this topic I want to try and establish a consistent approach for "OIDs and IDs" in the samples we create.

Brian

[Brian Weiss]

Brett,

I saw a post of yours yesterday on the NIST TTT Google Group on a thread about OIDs.  Very helpful, as usual, thanks.

In looking at the C-CDA IG samples, I see various approach to "sample identifiers" (see some examples below that I copied).  If there's a systemic approach here, I can't figure it out.  Do you know if there was any overall guidance on how to generate OIDs and IDs in the C-CDA IG samples (or in other HL7 IGs and specifications)?  If not, can you point me at someone who might know?

If there are guidelines for generating OIDs and IDs for samples, I'd like us to follow that in the samples we create.  If not, then I'd like to come up with some guidelines so that the samples are consistent.  Perhaps we register with HL7 a root OID for "C-CDA Samples" and then, in alignment with the HL7 OID guidance document you referenced in your post, we create our "fictitious sample organization OID and ID policy".  

Along similar lines, we'll want to create a pool of providers, patients, organizations, etc. that we use throughout the samples.  Here too it would be interesting to know if HL7 or S&I or anyone has established the "fictitious environment" in which samples are written...

Examples of C-CDA IG ids

Figure 217, page 459

<act classCode="ACT" moodCode="INT">

…

<id root="1.2.3.4.5.6.7.8" extension="1234567"/> 

…

<performer>

<assignedEntity>

<id root="1.2.3.4" extension="1234"/> 

...

<representedOrganization>

<id root="2.16.840.1.113883.19.5"/>

Figure 219, page 471

<procedure classCode="PROC" moodCode="EVN">

...

<id root="e401f340-7be2-11db-9fe1-0800200c9a66"/>

Figure 230, page 492

<act classCode="ACT" moodCode="EVN">

...

<id root="1.2.840.113619.2.62.994044785528.20060823223142485051"/>

[Brian Weiss]

I have registered an OID for CDA PRO and have established (in accordance with the guidelines in the document that Brett referenced: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210) a set of OIDs I will use in our samples.   See attached table:

This is for the root portion of the identifier.  For the extension, the convention I am thinking of (since no real system is generating identifiers in a database) is something like this:

YYYMMDDHHMMSS-<descriptive text>

So, for example, a sample C-CDA CCD document that I am working on today has the following id element under ClinicalDocument:

<id root="2.16.840.1.113883.3.3208.101.1" extension="20130607100315-CCDA CCD Sample Document">

I would appreciate any feedback on the above.  Much easier to improve/change now then it will be when we have lots of samples...

Brian

On Wednesday, June 5, 2013 8:11:03 AM UTC+3, Brian Weiss wrote:

[Lisa Nelson]

Brian,

 

Generating meaningful id elements in the examples is a really good thing to do, but we will need to think it through further.  Many id’s are needed throughout a document.  We need to invent a way to do it for the document, all the header components, the section, the entries….sometimes you don’t care what the id is, you just need to be sure it is unique. Other times, when the sample is demonstrating internal reference linking, like between a result observation and the associated procedure, then you care to show in the sample how the id’s are used to establish the linkages.

 

Having this base root oid will help – thanks for setting it up – but we’ll still need to work out ways to add extensions in some efficient and effective way for hand-generated examples.

 

Lisa

 

Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net

 

 

From: ccda_s...@googlegroups.com [mailto:ccda_s...@googlegroups.com] On Behalf Of Brian Weiss
Sent: Friday, June 07, 2013 3:05 AM
To: ccda_s...@googlegroups.com
Subject: {C-CDA Samples} Re: OIDs and IDs in C-CDA Samples

 

I have registered an OID for CDA PRO and have established (in accordance with the guidelines in the document that Brett referenced: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210) a set of OIDs I will use in our samples.   See attached table:

 

This is for the root portion of the identifier.  For the extension, the convention I am thinking of (since no real system is generating identifiers in a database) is something like this:

YYYMMDDHHMMSS-<descriptive text>

 

So, for example, a sample C-CDA CCD document that I am working on today has the following id element under ClinicalDocument:

 

<id root="2.16.840.1.113883.3.3208.101.1" extension="20130607100315-CCDA CCD Sample Document">

 

I would appreciate any feedback on the above.  Much easier to improve/change now then it will be when we have lots of samples...

 

Brian

 

On Wednesday, June 5, 2013 8:11:03 AM UTC+3, Brian Weiss wrote:

In this topic I want to try and establish a consistent approach for "OIDs and IDs" in the samples we create.

 

Brian

 

--
You received this message because you are subscribed to the Google Groups "C-CDA Samples" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ccda_samples...@googlegroups.com.
To post to this group, send email to ccda_s...@googlegroups.com.
Visit this group at http://groups.google.com/group/ccda_samples?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Weiss]

Agreed!

 

I found myself “making up conventions” as I created the various fictional players in the first CCD sample I just posted.

 

What we really need is a full “context scenario” (including patients, caregivers, facilities, etc.).  I think at some point we will naturally get there – but I didn’t want to make that a pre-condition for the first sample (especially since all it says is “I have no information about anything”).

 

And of course, establishing the “scenarios” will be even more key when we get into samples that reflect more complex clinical scenarios that need to “make sense” clinically...

 

Brian

[Kumara Prathipati]

Lisa and Brian,

It is not mandatory every EMR vendor to have a registered root OID to use for CCDA requirements .

My assumption is many EMR products are using GUID ??.

In any case, it is good our samples organization has a OID.

We have to define and describe how we select extension, so others can have good understanding of extensions and our policy in examples.

This ID is very critical  since it will this ID will be used to overwrite if I send 2nd CCD document with corrections and deletions.

The primary keys we all use in storing allergy information, problem list information , current meds information etc... can become the extension.

If  "2.16.840.1.113883.3.3208.101.1" is our root ID

we should assign

problem list domain = 2.16.840.1.113883.3.3208.101.1.1

allergies list domain = 2.16.840.1.113883.3.3208.101.1.2

current medicines domain = 2.16.840.1.113883.3.3208.101.1.3

labs domain = 2.16.840.1.113883.3.3208.101.1.4

etc..

Then the primary key in the database for each domain table can become the extension.

If we want to use root ID + extension different way,

we should explain for benefit of every one clearly and with examples.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: 'Lisa Nelson' <LisaR...@cox.net>; ccda_s...@googlegroups.com
Sent: Friday, June 7, 2013 6:44 AM

[Brian Weiss]

Correct – registration of OIDs is not mandatory.  But it is a good practice and guided to by this HL7 document:

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=210

 

I also agree that in our annotated samples we have to explain our approach to IDs.

 

However, I’m not sure what you are indicating below about IDs being critical for overwriting, etc. is so relevant for samples?  It is in the sense that implementers need to understand that in the real world, IDs matter.  In any case, we need to make the IDs/OIDs discussion part of the review call.  The idea of using a different root for different domains is interesting (though not called out in the document I linked to above).  Instead, it distinguishes entries/clinical statements, sections, encounters, orders, etc.  Not sure what is best, we should discuss…

 

Brian

[Kumara Prathipati]

Brian,

I am assuming OID + extension is better system for examples.

Each section can have different last digit of OID.

Primary keys maintained by the EMR in practice database can be used for extensions.

But in any case, this is not the main focus of our goals at this time.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: 'Kumara Prathipati' <kuma...@yahoo.com>; 'Lisa Nelson' <LisaR...@cox.net>; ccda_s...@googlegroups.com
Sent: Sunday, June 9, 2013 6:57 AM