Lab Mapping OSCAR to E2E
The E2E Labs section contains data pertaining to the specific patient's laboratory test results. It aims to give detailed information about the labs performed, their statuses, and their results.
User Assumptions
- The provider will import external lab results into OSCAR through the HL7 Lab Upload form inside Inbox
- The input labs will be HL7 v2.x, with Excelleris formatting
- The provider will manually match unmatched lab reports based on their name, dob, and hin
Data Assumptions
- The lab import data is considered accurate and complete within Excelleris' standards
- The patient and associated lab matching is assumed to be correct
- HL7 lab parses will be stored in OSCAR and represented correctly in the associated tables
- Imported labs weren't getting parsed in OSCAR - they were only stored and encoded in the hl7 tables
- Hl7 lab parsing wasn't apparent
Options
- Write our own HL7 parser to extract the data we needed such as LOINC codes, status, and result
- Extract only the immediately available lab data to put into exporter
Decision
- After learning that at the time, our OSCAR master branch build just had a broken measurements table, we revisited the issue on the stable 12.1 release branch and saw that the labs were being parsed to measurements
- We do not need to write our own hl7 parser, and we can draw from the measurements/measurementsExt table for the LOINC codes, status and result
- E2E labs group at the entire lab report level, a battery/organizer level, and the individual entry level
- OSCAR's data structure was not very conducive of the E2E's data structure
- Grouping at the battery/organizer level was possible, but would lack info on what the group was
Options
- Model labs such that each entire lab report would have one battery/organizer which would contain all the individual entries
- Separate all the entries into their respective battery/organizer groups to maintain structure, but have missing battery/organizer information
Decision
Team meeting 22-Feb-2013
- We decided to maintain as much of the structure as possible in the E2E spec, even though there may not be complete information for each group
- Thought behind it was that the inherent groupings of the entries would still yield more information for the recipient than if they were in one blob of entries
- OSCAR doesn't represent these battery/organizer groups well in the tables, so a custom data structure has to be created to handle this decision
- In some lab results, the freetext field contains the html break tag
- This tag breaks XSD validation as it does not expect that element in there
Options
- As that the html break tag is just miscoded for a newline, replace all instances of the break tag with newlines
- Excise all html break tags from the string without inserting newlines
- Ignore this instance of error as the content is technically still valid
Decision
Team meeting 13-Mar-2013
- We decided to implement the first option where all the html break tags would be replaced to have newline characters
- As this result data is typically multi-part, and the newlines are inserted for easier human readability, we decided that replacing the tags with newlines would be best - it closest matches original intent while allowing the XSD to validate
Relevant OSCAR DB Tables: patientLabRouting, Hl7TextInfo, measurements, measurementsExt
SCOOP is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
