Last week two new students joined the lab. Both are working on aspects of importing documents. One of the aspects is looking at trying to extract discharge medication data from textual discharge summaries.
To help understand the prescription instructions, I have created a short (less than 8 min) sketch cast.
Apologies for my physician handwriting.
Last weekend was the BC OSCAR conference and there was a great energy from the users.
McMaster was there showing a lot of the next version of OSCAR. Some great headway being made. I was pleased to see the refined workflows and user experience.
We spent some time discussing how we can work on some of the BC specific needs including results importing from Excelleris and BC billing bugs.
I’m happy to say we have some students who have just started with us and will be working on some of this with us.
March 1, 2013 we had the first meeting at UVic with members of the Physician Data Collaborative, AMCARE, UVic and UBC. It was a good meeting with sharing and discussion on the design plans that have been developing at UVic.
I wanted to thank all those who attended and also share my slides from the day. Most of the material is available already, but this is a useful package for anyone who is interested.
The most recent LeadLab development effort is enhancing OSCAR to support the new BC Interoperability Specification for Primary Care (See PITO EMR-TO-EMR DATA TRANSFER & CONVERSION (E2E-DTC) SPECIFICATIONS).
The E2E-DTC is a CDA-based spec. Some new lab members are now getting their feet with with HL7, the RIM, and all these wonderful things.
More recently the focus has been on mapping medications from OSCAR to the E2E spec. There is some very detailed analysis happening on medication codes, form codes, route codes, etc. However, because OSCAR relies heavily on the DPD this mapping work is almost like mapping purely from the D2D to E2E.
To help me I quickly created a MySQL table structure so I could query the DPD export tables in a relational fashion. The SQL script to create this database can be downloaded here.
After you have created the empty database in MySQL, you will need to download the HC DPD extract files here. Simply download the “All Files” option.
Next you can load the extract files into MySQL using the following statements (Note: there is an assumption here that since you want to navigate the DPD in MySQL that you actually know enough about MySQL to run these commands from the right location).
LOAD DATA INFILE 'drug.txt' INTO TABLE QRYM_DRUG_PRODUCT FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, PRODUCT_CATEGORIZATION, CLASS, DRUG_IDENTIFICATION_NUMBER, BRAND_NAME, DESCRIPTOR, PEDIATRIC_FLAG, ACCESSION_NUMBER, NUMBER_OF_AIS, @date, AI_GROUP_NO)
SET LAST_UPDATE_DATE = str_to_date(@date, '%d-%b-%Y');
LOAD DATA INFILE 'comp.txt' INTO TABLE QRYM_COMPANIES FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, MFR_CODE, COMPANY_CODE, COMPANY_NAME, COMPANY_TYPE, ADDRESS_MAILING_FLAG, ADDRESS_BILLING_FLAG, ADDRESS_NOTIFICATION_FLAG, ADDRESS_OTHER, SUITE_NUMBER, STREET_NAME, CITY_NAME, PROVINCE, COUNTRY, POSTAL_CODE, POST_OFFICE_BOX);
LOAD DATA INFILE 'form.txt' INTO TABLE QRYM_FORM FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, PHARM_FORM_CODE, PHARMACEUTICAL_FORM);
LOAD DATA INFILE 'ingred.txt' INTO TABLE QRYM_ACTIVE_INGREDIENTS FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, ACTIVE_INGREDIENT_CODE, INGREDIENT, INGREDIENT_SUPPLIED_IND, STRENGTH, STRENGTH_UNIT, STRENGTH_TYPE, DOSAGE_VALUE, BASE, DOSAGE_UNIT, NOTES);
LOAD DATA INFILE 'package.txt' INTO TABLE QRYM_PACKAGING FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, UPC, PACKAGE_SIZE_UNIT, PACKAGE_TYPE, PACKAGE_SIZE, PRODUCT_INFORMATION);
LOAD DATA INFILE 'pharm.txt' INTO TABLE QRYM_PHARMACEUTICAL_STD FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, PHARMACEUTICAL_STD);
LOAD DATA INFILE 'route.txt' INTO TABLE QRYM_ROUTE FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, ROUTE_OF_ADMINISTRATION_CODE, ROUTE_OF_ADMINISTRATION);
LOAD DATA INFILE 'schedule.txt' INTO TABLE QRYM_SCHEDULE FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, SCHEDULE);
LOAD DATA INFILE 'status.txt' INTO TABLE QRYM_STATUS FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, CURRENT_STATUS_FLAG, STATUS, @date)
SET HISTORY_DATE = str_to_date(@date, '%d-%b-%Y');
LOAD DATA INFILE 'ther.txt' INTO TABLE QRYM_THERAPEUTIC_CLASS FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, TC_ATC_NUMBER, TC_ATC, TC_AHFS_NUMBER, TC_AHFS);
LOAD DATA INFILE 'vet.txt' INTO TABLE QRYM_VETERINARY_SPECIES FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' LINES TERMINATED BY '\r\n' (DRUG_CODE, VET_SPECIES, VET_SUB_SPECIES);
I recently chaired the first OSCAR EMR Academic / Research Group meeting. We had had discussions about forming an autonomous group that would meet regularly to share ideas and designs that would promote research with the open source OSCAR EMR.
The first meeting had attendees from three Canadian universities. For a first meeting, it was a positive turn out with some very good discussion.
Discussion on research topics ranged from collecting data from OSCAR/MyOSCAR for clinical trials to using OSCAR and MyOSCAR as a research platform to assess ways of improving care. User experience and assessing behaviour changes of different clinical decision support approaches was one example of something that could be assessed by collectively developing tools inside OSCAR/MyOSCAR.
For me, the best part of the discussion was that I didn’t suggest the idea of evaluating decision support, something near and dear to me.
We’ll continue to meet over the next year and see how this group evolves. It is good to see this kind of multi-university collaboration.
Last week we had an excellent discussion – in the midst of our sprint – on the importance of paying down our software debt early and regularly. We made some design decisions to meet targets. That is common, indeed.
Some would say this is part of best practice. (And some did say that last week)
Our current approach is agile and feature focused, using prototypical questions to define our targets and goals for each sprint. Formally, we have not had time blocks for refactoring and clean up without adding features.
What we feel we need to add into our process now is some debt payment. We were all agreed. For the first few sprints we’ve been testing a range of architectural options and debt payment was not as critical. Now as we have made some solid progress, it is a good time to add debt payment into our process.
So this week, we pay down debt before we start on the next sprint without increasing the feature set.
Big milestone was reached this week by the team working on SCOOP. They were able to export a valid E2E document from an EMR. This is foundational to our current architecture and could be the first time one of these (well 8 of these) was exported from an EMR.
We haven’t gotten everything into the E2E document yet – far from it. We are not ready to do anything with our code outside of the lab, either. There is a lot to do before we get there. But we do have well formed E2E documents with limited demographic and medication data.
That is just enough to answer a polypharmacy question.
And that was our goal for this sprint.
Well done team.
hQuery is designed by our friends at MITRE near Boston. So although we cannot take credit for it – maybe we can help document it.
It does not follow a traditional approach to business intelligence, far from it. Innovative – definitely. Useful – to be determined (other more mature query health tools have been found very useful).
MongoDB is the database management system that holds the individual records at the endpoint. This is a NoSQL database – meaning non-relational. And there are no mechanisms for referential integrity. It is well-proven in terms of scalability and performance. For hQuery, information is inserted and stored in the form of JSON documents (JavaScript Object Notation).
Inside of the query-gateway, Mongoid exposes the JSON model as Ruby. Specifically this logic is in the health-data-standards ruby library, also developed by MITRE and used by a few other mitre projects. The object model is based on the HL7 “Green CDA” model of patient data . As the gateway receives records it marshals the data into the ruby object model. The Record object is the root of the object model. It is also a Mongoid document. This means that the whole object model can be automatically converted to a JavaScript object model (JSON document) as the record is inserted into MongoDB.
The query-composer encodes queries in JavaScript. Core to this feature is PatientAPI, a CoffeeScript API that is manually synchronized with the health-data-standards library. JavaScript objects produced from the query-gateway(via HealthDataStandards) and JavaScript Objects produced by the query-gateway (via PatientAPI) should be identical. Queries written in the client web browser are encoded directly in JavaScript.
The patient api is also used in the query-gateway when running the JS query. Essentially the JSON is pulled out of the database and a PatientAPI instance is created using that JSON document as the data backing it. The JS query is then run against the patient api instance.
These are the mechanics for data structures in the hQuery components. It took me some time to figure out – digging through code and jumping around MITRE projects on github. I have not gone into the details of the hData model content. Perhaps this will be a future post.
Special thanks to Marc Hadley at MITRE for reviewing and correcting the details included in this post.
The SCOOP development team follows an iterative, agile process. Each cycle builds on the previous. Now we are working on our third iteration.
Each iteration is based on a new research question. The research question for this cycle was finding the age distribution of patient population by gender. This requires demographic data only.
We used very simple data structure to transfer individual information from the EMR to the SCOOP Endpoint repository (hQuery Gateway). This meant one XML document was transferred per individual with a record in the test EMR (OSCAR).
The system had a middleware component (Mirth) to transmit data from the EMR to the SCOOP endpoint repository. Mirth accessed the OSCAR database directly, assembled the individual XML-document, then sent it via restful webservice to the hQuery Gateway.
This setup worked well. Ten thousand individual records could be transferred in about 10 minutes over a LAN. This is a diagram illustrating the deployment view of this architecture.
We approached a more difficult research question for this iteration. We’d like to find out polypharmacy rates in the elderly. So this combines demographic information and medication information.
Another progressive step for this iteration involved adopting the HITSP C32 standard as the data structure for transferring information from the EMR to the hQuery Gateway repository. It made sense; it contained structured data sections for most types of data the network would like to answer questions about. In addition, hQuery Gateway already supports the import of C32 Patient Summary documents.
The architecture was kept the same for this iteration. Mirth would access the OSCAR database directly, assemble the individual XML-document, then send it via restful webservice to the hQuery Gateway.
This is where challenges came up. The data structure was too complex for Mirth to handle. The aggregation required multiple calls to the OSCAR database while processing a batch of individuals. Mirth has an operational model that does not easily facilitate this. We contacted Mirth to ask if training would help us get it working (because the public Mirth documentation is sparse and does not include this). The Mirth representative said that training would not cover this. The best way to make Mirth do what we want is to hire them for consulting services. The research project budget could not cover the fees of a consulting company from California.
So we briefly dug into Pentaho Data Integration. We made more progress with PDI than we did with Mirth. But this was largely due to the flexible data flow model combined with the user-defined java classes (small units of java logic embedded in the data flow). The amount of custom java code was becoming excessive considering that we were adopting an ETL tool.
The time box ended on this cycle without a working version of the system. We re-grouped and revisited our approach as a team.
We decided to use the exact same research question from the previous iteration. This iteration will be functionally equivalent to the previous objective. But we designed a new architecture. The systems view of the architecture is illustrated by the following image.
1. We are enhancing OSCAR to export the patient summary document, either for a single individual or by batch for all individuals with a record in the EMR
2. The data transfer format will be an emerging Canadian standard, the E2E developed by the BC PITO program. It is an HL7 CDA-based XML document. Because we are enhancing an open source Canadian EMR – it only makes sense to support a Canadian standard.
3. The middleware (Mirth) will play a much smaller role in this design. It will simply transfer individual summary documents between the EMR and the hQuery Gateway. It will not perform any aggregation or transformation.
4. hQuery Gateway will be enhanced to support the import of E2E patient summary documents. This is not a complex change because it is CDA-based and extremely similar to the already supported C32 document.
This iteration concludes near the end of September. Stay tuned.
Just a quick post and link to a very recent BMJ article on open source EMRs for resource poor environments. It is good to see OSCAR in there as well as openMRS. Getting this kind of exposure is excellent for all.