Notifications
Clear all
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
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
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
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
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
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
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
Topic starter
That answered my question. Thank you for walking me through that.
Posted : May 10, 2017 8:25 am
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
