| OHDSI Home | Forums | Wiki | Github |
Using this to provide more visibility for the Procedure, Measurements, Devices, Specimens, and Observations.
The wiki URL for this sub-group is:
http://www.ohdsi.org/web/wiki/doku.php?id=projects:workgroups:themis:focusgroup1
If you would like to join this sub-group, just call into our bi-weekly call or contact @mvanzandt
We will use this to post any activity that goes on with the group or decisions made by the group.
Issue: What to do when the quantity field for Procedures are set to null or 0
Decision: Default the quantity field in the procedure_occurrence table to 1, if the quantity from the source is 0 or null. A new rule will be added to Achilles Heels - Quantity in the Procedure_Occurrence table cannot be 0
Issue: Do we combine the quantity of multiple procedure records when the procedures are the same?
Decision: Aggregate the quantity if the unique combination of the record is the same. The unique combination is Person_ID, Procedure_Concept_ID, Procedure_Date/Time, Provider_ID, and Visit_Occurrence_ID.
We are going to be scheduling regular bi-weekly calls for this sub-group. Please use this doodle pool to decide which day works best for everyone.
Regarding setting procedure_occurrence.quantity = 1, are you also recommending this for device_exposure and drug_exposure under the same situations (null or 0 in the source)?
Thanks,
@mkwong. We do have the same recommendation for Device, but havenāt completely discussed it with the sub-group.
Regarding Drugs, I wi direct your question to that sub-group.
Then we should also make quantity a required (not null field), with default value 1 - CDM change?
How about visit_detail? If we have datetime this may not be an issue, but if we only have procedure_date - then visit_detail (e.gā¦ same procedure done in ICU, and then in step down unit) on same day.
@Gowtham_Rao - Both of your suggestions makes sense. We will incorporate into the documentation of the THEMIS group. Any changes to the CDM will be proposed to the CDM working group.
We have established a reoccurring bi-weekly call starting from this Thursday (January 18th) at 1 PM EST. Please feel free to join us if you are interested in this sub-group.
@MNairn - Can you please provide the meeting information here. Thanks.
Hi All,
Below is the information for our bi-weekly meetings:
ā¦
ļ Join Skype Meeting
Trouble Joining? Try Skype Web App
Join by phone
+16468382458 (Dial-in Number) English (United States)
Find a local number
Conference ID: 30512988
Forgot your dial-in PIN? |Help
Commonly used Skype Dial-in numbers :
United States-New York City - +1 (646) 838-2458
United Kingdom-London - +44 (20) 33215269
India-Mumbai - +91 (22) 60014106
India-Bangalore - +91 (80) 60014106
Japan-Tokyo - +81 (3) 45107221
Singapore-Singapore - +65 (3) 1576500
China-Shanghai - +86 (40) 08428071
[!OC([1033])!]
ā¦
All,
Here are the meeting notes from two previous meetings held in December:
THEMIS - Procedure, Device, Obsevration, Measurement Subgroup Notes 120517.docx (13.8 KB)THEMIS Procedures Device Observation Measurement Subgroup Notes 121917.docx (13.6 KB)
Hi All,
Here are the meeting notes from January 18, 2018:
All,
Here are the meeting notes from January 18,2018.
THEMIS Procedures Device Observation Measurement Subgroup Notes 011818.docx (13.4 KB),2018.
Hi All,
Here are the meeting notes from Febrauary 1,2018:
THEMIS Procedures Device Observation Measurement Subgroup Notes 020118.docx (13.3 KB)
Just as an update (and we can discuss tomorrow), the new visit detail table allows us to link together procedures. So, one possible approach to modifiers is to drop the modifier column, and to treat modifiers as procedure records. These can all share the same visit id as the HCPCS code to which they are associated, and they can also share the same visit detail id. Hence, it should be easy to keep them together, regardless of whether there is 1 or 10 modifiers.
We will still have to map some of the modifiers to other domains, but the process will still work. That is, even if a modifier is a condition occurrence, it can have the same visit id and visit detail id as the original HCPCS code.
We can discuss this at the next meeting.
The Themis network study (labs and units) has updated results.(ThemisUnits)
see them here https://github.com/OHDSI/StudyProtocolSandbox/tree/master/themis/extras/partial_results
The Themis WG1 group discussed and approved a draft plan how to best integrate the output of the analysis into Achilles Heel checking.
The proposal is now also on the Achilles github here https://github.com/OHDSI/Achilles/issues/250
The updated results show data from 14 datasets. (see datasets.csv)
A view with one row per lab test (units condensed) is
available here https://github.com/OHDSI/StudyProtocolSandbox/blob/master/themis/extras/partial_results/C-tests-aggregated.csv
Today the WG1 discussed the implementation in Heel of the decisions made by Themis group. (see posts above)
For example, for a given new Themis convention (e.g., weight is measured in nonsensical units (e.g., g/dL)) - what kind of Heel error severity should be the result.
There are three Heel error levels: error, warning and notification (ordered by importance). (and a category tracking high quality data).
We discussed definitions for the three severity levels (no final definitions were approved). The proposal discussed was to put most of the new Heel rules into the warning category. (But allow users on the forum or Heel github issues to propose a revision of an implemented Themis-authored convention checking).
tentative boundaries:
error - severe error in data
warning - issue with data that complicates analysis but is not a severe error
notification - āgood to know aboutā least significant issues with data
high-quality - silent type of message. So that Heel does not only point to problems but also rewards ETL-ers. āAPGAR score for your databaseā
This is an important discussion, because it defines what deviations we tolerate, and which are unacceptable. Achilles has to know this, but of course the conversation is much larger.
How about this:
Would that work? Can we even decide on the category for each test?
This thread had a lot of conversation for Duplicate Records in Devices and Procedures. Just to let everyone know where we landed.
RECOMMENDATION
`When these fields are the same, the ETL must determine whether to sum them up into 1 record or keep them as multiple separate records. Things to consider are:
NEXT STEP
Updated the PROCEDURE_OCCURRENCE portion of the WIKI under conventions.