Hello again!

While some in our PaTH network have already incorporated many of the flowsheet 
items you nicely crosswalked to LOINC codes, we are gearing up for a more 
network-wide implementation in the coming cycle.

One of our members asked why PHQ was being placed in the Obs_clin table when it 
could be considered a PRO measure and placed in the PRO_CM table.  Looking at 
the content of that table, the information certainly fits the structure.  My 
sense was that in the past, it was directed at specific PRO measures like 
PROMIS, but now that you can specify LOINC codes for PRO measures in the PRO_CM 
table, the PHQ data could just as easily fit there as in OBS_CLIN.

What are your thoughts on where PHQ data belongs?

Thanks!

Mark


From: Weiner, Mark
Sent: Thursday, July 12, 2018 3:06 PM
To: 'Campbell, James R'; GPC STANDARDS; Research Informatics Group, UNMC
Subject: RE: PCORI OBS_CLIN

Thanks for your detailed reply and slide decks.  My sense is that the hard part 
is what you seemed to do manually - map the FLO_MEAS_ID from the IP_FLO_GP_DATA 
table into LOINC codes.  The good news is that many of your commonly recorded 
flowsheet items (like braden score and GCS data) are  also frequently recorded 
within our institution, and within the other institutions within our PaTH CDRN. 
 That means, to the extent there are matches, we can leverage your  LOINC 
mappings to allow us to use our flowsheet rows in the CLIN_OBS table without us 
having to reinvent the wheel.  This is especially useful for the "low" numbered 
FLOW_MEAS_IDs which are standardized by Epic,

Of course, local variation creates more work.  For example, for some reason, 
the FLO_MEAS_ID for our R_PAIN_SCORE is in the  "custom" ID range with a value 
of 3040104280, so a blind application of your mapping into our system would 
make it seem we didn't have any pain scores, when in fact, the absence is 
related to a mismatch in code - we aren't using the 6066 code for some reason.  
We also have a number of variations on the theme of a "generic" pain score with 
an OB pain score, a PEDS PAIN SCORE, among others.  Not sure if these 
inflections have different LOINC codes, but I'm sure you also have a sense for 
this variation.

I wonder if there is a way we can crowdsource this project to map the 
FLO_MEAS_IDs that should be common across institutions into the associated 
LOINC codes.  It will add to the ability of the Epic institutions in PCORI to 
fill their OBS_CLIN table and would ensure a consistent mapping to the extent 
there may be two similar LOINC codes that COULD match to a single FLO_MEAS_ID.

I'm not going to push this issue to hard within my network for the current 
cycle of data characterization, but after this first CDM 4.1 submission, we may 
be able to work to collectively expand the mapping.

Mark

From: Campbell, James R [mailto:campb...@unmc.edu]
Sent: Thursday, July 12, 2018 1:50 PM
To: Weiner, Mark; GPC STANDARDS; Research Informatics Group, UNMC
Subject: Re: PCORI OBS_CLIN

WARNING: **** EXTERNAL Message. DO NOT open attachments or click links from 
unknown senders or unknown emails. ****
________________________________


Hi Mark!

I include below the stats for frequency of occurrence of LOINC coded data that 
we store in our first roll-out of OBS_CLIN.  I am also enclosing two 
presentation from Epic meetings in 2016-7 where we demonstrated our 
implementation of clinical and laboratory facts in i2b2  (and then to CDM) 
using ONC standards SNOMED CT and LOINC.



You are quite correct in your analysis of Epic Clarity data structures and 
clinical/lab data that begins with an order event ends up in ORDER_RESULTS.  
The clinical observations that are listed however are all flowsheet data in our 
deployment of Epic, and the extract that I developed to load those facts 
employs a map from Flowsheet row to LOINC code that supports coding of the 
data.  I have not been successful with our build team in deploying flowsheet 
maps into Epic data structures and so the map file resides with our extract 
library at this point.



We have published our extracts on the userweb - you can find them I think in 
the slide set.  If you are interested, Nebraska will be glad to share our code 
with you for this or any other feature we have deployed.

Jim




OBSCLIN_CODE

RAW_OBSCLIN_NAME

COUNT(*)--SELECT*

8867-4

Heart rate

41195391

9279-1

Respiratory rate

30020150

8310-5

Body temperature

22551370

8478-0

Mean blood pressure

19685904

8462-4

Diastolic blood pressure

17794069

8480-6

Systolic blood pressure

17794069

39156-5

Body mass index (BMI) [Ra

7574390

38208-5

Pain severity - Reported

7039613

50064-5

Ideal body weight

6583916

8302-2

Body height

6524735

3141-9

Body weight Measured

5922939

9267-6

Glasgow coma score eye op

4270690

9268-4

Glasgow coma score motor

4268539

9270-0

Glasgow coma score verbal

4266029

9269-2

Glasgow coma score total

4262288

3140-1

Body surface area Derived

3301569

38222-6

Sensory perception Braden

2827295

38229-1

Moisture exposure Braden

2827250

38223-4

Physical activity Braden

2827192

38224-2

Physical mobility Braden

2827028

38225-9

Nutrition intake pattern

2826941

38226-7

Friction and shear Braden

2826089

38227-5

Braden scale total score

2824397

9187-6

Urine output

2536706

3151-8

Inhaled oxygen flow rate

2194966

59576-9

Body mass index (BMI) [Pe

334323

11784-6

Cervical canal external o

102323

11867-9

Effacement Cervix

90605

11881-0

Uterus Fundal height Tape

84044

11876-0

Fetal presentation palpat

43333

79991-6

Left ventricular Ejection

36724

8287-5

Head Occipital-frontal ci

32128

55283-6

Fetal Heart rate

22784




________________________________
From: Weiner, Mark 
<mark.wei...@tuhs.temple.edu<mailto:mark.wei...@tuhs.temple.edu>>
Sent: Wednesday, July 11, 2018 9:59:39 AM
To: Campbell, James R
Subject: PCORI OBS_CLIN

Non-UNMC email




Someone circulated data on the Nebraska experience with populating he PCORI CDM 
OBS_CLIN table using data from the EHR that corresponded to LOINC codes having 
a LOINC_CLASS = 2.



We have Epic an our institution, and we were doing the same thing with data 
that happened to be in our ORDER_RESULTS table where most tests have a 
component_ID that was linked to a LOINC code directly in our Clarity system.  
In that way, we  were able to pick up non-blood/urine tests like PFTS that were 
stored in the same ORDER_RESULTS table as more routine blood tests.



I saw in your data that you had other items like Braden scores, GCS, and pain 
scores.  We had that data too, but it was in our flowsheet data, not the 
order_results table, and we didn't have an easy crosswalk between those 
flowsheet items and the corresponding LOINC code.



Presuming you use Epic, too, what was the Clarity source for most of your 
OBS_CLIN data?  Did you have an automated crosswalk between items like Braden 
Score and the associated LOINC code?  I can see looking it up manually, or 
doing a string match with the LOINC dictionary, but I envision that will not 
have a perfect alignment.



I appreciate your insight.  Thanks!



Mark



-------------------

Mark Weiner, MD, FACP, FACMI

Assistant Dean for Informatics

Professor of Clinical Sciences and Medicine

Lewis Katz School of Medicine at Temple University

3440 N. Broad Street, Kresge Hall, Rm 219

Philadelphia, PA 19140

t 215-707-8079

f 215-707-3160





________________________________

This electronic message is intended to be for the use of the named recipient, 
and may contain information that is confidential or privileged. This 
communication may contain protected health information (PHI) that is legally 
protected from inappropriate disclosure by the Privacy Standards of the Health 
Insurance Portability and Accountability Act (HIPAA) and relevant Pennsylvania 
Laws. You can direct questions concerning PHI or HIPAA to the Corporate 
Compliance and Privacy Officer at (215) 707-5605. If you are not the intended 
recipient, please note that any dissemination, distribution or copying of this 
communication is strictly prohibited. If you have received this message in 
error, you should notify the sender immediately by telephone or by return 
e-mail and delete and destroy all copies of this message.

The information in this e-mail may be privileged and confidential, intended 
only for the use of the addressee(s) above. Any unauthorized use or disclosure 
of this information is prohibited. If you have received this e-mail by mistake, 
please delete it and immediately contact the sender.
_______________________________________________
Gpc-dev mailing list
Gpc-dev@listserv.kumc.edu
http://listserv.kumc.edu/mailman/listinfo/gpc-dev

Reply via email to