Welcome to the NEW CHUG— your ultimate destination for cutting-edge insights and discussions at the intersection of healthcare and technology.

Our platform is dedicated to exploring the dynamic landscape of healthcare technology, empowering professionals, enthusiasts, and innovators alike with the knowledge and resources to navigate the rapidly evolving field.

From telemedicine revolutionizing patient care to the transformative potential of artificial intelligence in diagnostics, we delve into a myriad of topics shaping the future of healthcare delivery. Whether you’re a seasoned healthcare IT professional, an aspiring entrepreneur in the digital health space, or simply curious about the latest innovations, our curated content, expert interviews, and thought-provoking articles provide a comprehensive exploration of healthcare technology’s most pressing issues.

Join us as we navigate the forefront of innovation, driving forward the transformation of healthcare for a healthier, more connected world.

Have questions or suggestions? Please use the contact button below.

Notifications

Clear all

How does XID work?

MEL, SQL, Oracle

Last Post by Anonymous 1 second ago

9 Posts

5 Users

0 Reactions

68 Views

RSS

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

I have a technical question regarding XID values. Initially, we thought that an XID value of 10^18e (or however you notate all those zeroes...) always represented the most recently entered OBS value, and that previously entered OBS values were assigned a specific value.

However, recently we discovered a few OBS terms that were saving consecutive values with XID values of 10^18e, which leads me to believe that we are wrong in our assumptions.

Is this a weird error caused by... something? Or do I not understand how XID actually works?

Posted : May 8, 2017 10:35 am

jfitzmd

(@jfitzmd)

Posts: 419

Reputable Member

From Centricity Database Documentation:

XID

The XID (Expiration ID) indicates that a row has expired or has been designated as no longer valid by the user.

Because XIDs contain a time/date stamp, you can use XIDs to view the contents of a table as it appeared at a particular time in the past.

You can filter out all lines with XIDs smaller or larger than a particular number.

Sorting by XID shows only the information that was entered in the database before or after a particular date.

XIDs only indicate when the information was entered in the database.

A user can manually set or change clinical dates such as start dates and stop dates when entering clinical information. Therefore, the date in an XID is not necessarily the clinically relevant date.

An XID value of 1.E35 indicates a clinical condition that is active. Because active conditions do not have a stop date, all stop dates for active clinical conditions are set far in the future, either to December 31, 4700 or to a date outside the possible range for the condition.

For example, the following illustration shows a chain of observations:

Posted : May 8, 2017 12:29 pm

ntaylor

(@ntaylor)

Posts: 79

Estimable Member

Here's the description of the XID field from the OBS table documentation as well. Hope this is helpful.

The expiration ID, used to keep track of a chain of rows that record
changes to one of a patient's observations. For details of the XID, see
"About identifiers (IDs)" in "About the data schema."
A chain consists of one active row and zero or more inactive rows. The
head of the chain is the active row. All other rows in the chain are
inactive. The XID value of an active row is 1e35; an inactive row's XID
value is set to the OBSID of the newer row in the chain.

Posted : May 8, 2017 6:02 pm

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

Thanks for the responses. That's how I thought XIDs were supposed to work, but that's not how it's working in our database.

Our OBS aren't creating new XID numbers. Instead, new values are being written and are being assigned the XID of 1e18. Any idea why this is happening? We have older XID values that aren't 1e18, so clearly it worked for us in the past.

We are using custom MEL forms that use OBSNOW and OBSPREV. Whenever we enter data into a form and sign it, the XID value for the OBS is written as 1e18, every time. We can't see how this chain is created that forces the previous value to chain to the newest value for the same patient.

Posted : May 9, 2017 10:38 am

DavidShower

(@davidshower)

Posts: 1255

Noble Member

Are you sure about the XID in the OBS table? The only time it shouldn't be 100000000000000000000000000000000000 (1e35) is when the existing data in the flowsheet has been edited. Then the XID turns into the OBSID of the now active row.

Posted : May 9, 2017 12:57 pm

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

To clarify, do you mean when data has been edited via the flowsheet, not when a patient gets an updated OBS value on their follow up visit?

Posted : May 10, 2017 2:19 am

DavidShower

(@davidshower)

Posts: 1255

Noble Member

Yes, obs terms from each update are discrete and not chained. The only time they get changed is when you edit them directly in the flowsheet. You are changing an existing value, therefore a chain is needed. Adding a new value, like an additional WEIGHT, creates a new independent row and doesn't affect any existing entries in the OBS table.

Posted : May 10, 2017 2:30 am

vrdlc

(@vrdlc)

Posts: 135

Estimable Member

Topic starter

That answered my question. Thank you for walking me through that.

Posted : May 10, 2017 8:25 am

rwilliams

(@rwilliams)

Posts: 454

Honorable Member

Your account says you are on C-EMR (oracle) but you mentioned 1e18 which is a CPS value. In CEMR it is 1e35. (if you are on CPS you should update your chug account)

As others have mentioned, the XID is specific to the current update. The only time you will see it change is if the value has been edited/deleted.

If you are trying to write a SQL query to get the latest observation you can do something like this:
select * from ( select row_number() over (partition by obs.pid order by obs.obsdate desc) rn, obs.obsvalue, obs.obsdate, person.seachname from obs inner join obshead on obshead.hdid = obs.hdid and obshead.name = 'BMI' inner join person on person.pid = obs.pid where obs.change in (2,6) and obs.xid = 1e+35 ) t where t.rn = 1

This query will return the latest BMI from all patients in the database. I think this query should work on both CPS and CEMR with the exception of the XID.

Posted : May 18, 2017 9:05 am

24 Forums
9,940 Topics
39.9 K Posts
3 Online
6,470 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed