Organising data
Case study:
Docdoc
Summary
Docdoc enables patients all around the world to schedule medical appointments with specialists in their or other countries.
Due to a combination of rapid growth and multiple sources of truth, data quality issues started impacting the quality of services rendered. We were hired to organise the data and improve the backend so that the company’s operations could proceed smoothly.
We built a clean data model of every activity in the company, and implemented it within the constraints of the company’s existing operations and technology. This included creating a new database, migrating old data to it, and interfacing it with every system and process in the company.
Example
The following fictional story illustrates one of many data quality issues that can impact customer experience at a company like DocDoc.
Mr. Lim had increasing left knee pain. His general practitioner in Jakarta recommended a left knee replacement. Mr. Lim met two orthopedic surgeons in Jakarta, but when he asked them how often they performed the operation, they hesitated and said "often enough” which made him uncomfortable.
Mr. Lim began by searching Google for surgeons, however although he managed to get a list of hospitals, he could not find out which performed the procedure. He then visited healthcare forums but most of the posts were from the UK and the US and did not help him in his search for a better surgeon. Finally, he contacted DocDoc to explore options abroad (“medical tourism”).
A DocDoc agent searched internally for knee replacement and found twelve surgeons with high volume, good patient experience, and reasonable price. Mr. Lim cared most about volume and price, so the agent offered the top two surgeons by volume in the budget price bracket, and Mr. Lim booked an appointment with the first, at a Malaysian clinic which specialised in the procedure.
Unfortunately, the agent did not see five other relevant surgeons, including one in Singapore that also specialised in the procedure, because they had listed it as "knee replacement” or "total knee arthroscopy” which did not come up in a search for “total knee replacement”. Although Mr. Lim received higher quality and lower price care than he would have found on his own, if procedures had been standardised in the database, he would have had more options and potentially better treatment.
Initial state
When we first met with Docdoc, we realised that they had multiple systems running in parallel and with overlapping functionality.
This made it difficult to determine the source of truth for data ranging from Mr. Lim’s name to his appointment’s clinic address or the details of their contract with Docdoc.
Solution
We talked extensively with all managers in the business until we had catalogued every process and data source.
We spent the next few months structuring it with the help of the executives, translating their domain knowledge into code and assisting them in formally defining previously implied logic. What is a clinic? What is a patient? What are the stages of an appointment? Which agents are allowed to call which clinics?
In one case, we reduced a backend database of 500 tables with 16,000 columns into 120 tables with 400 columns. We forced an explicit definition of everything from identification types to communication methods.
One issue faced by the company was a messy, healthcare provider-defined ontology of procedures and specialties. Working with a medical informatics team and the marketing department, and leaning on the Chairman’s previous experience in healthcare, we enforced a standardised ontology based on internationally used coded concepts (such as CPT and SNOMED).
As an example of what this enabled, all dentists will now show up on a search for the standardised specialty “General dentistry” whereas those previously registered under “Dental” would not have appeared. We also know that “Reproductive Endocrinology” should point to “Obstetrics & Gynecology”.
HR and migration
Having defined and constrained the data model, we needed to work on migrating the old data from multiple production systems to the database on which it had been implemented.
We helped Docdoc find a professional database administrator (DBA), who was hired full time to effect the migration. Her role would then transition into supporting the engineering department and auditing the application for data quality, working as the company authority on and owner of the data model.
We reverse-engineered, then interfaced with all systems so that all data would eventually flow through the central database, and thus exist in the correct format.
Today
N.B.: this case study was approved for release in April 2017.
Docdoc is working on connecting the database to its website, including the launch of a portal through which healthcare providers can access and edit their information, made possible by the new data model, the cleanup and the migration. Both the company operations and business intelligence could then run without data issues, and with much better performance.
The only exception was appointments data. This is because a large customer service team had evolved a very high Net Promoter Score over many years of continuous improvement, using well established processes that relied on the company CRM, NetSuite. As such we designed the system so that NetSuite would remain the source of truth for appointment data, interfacing with the database in a careful way that maintained data integrity, allowing the customer service team to continue operating undisturbed.
Not only should appointment data flow from the CRM to the database, the database needs to copy all other information to the CRM (such as a clinic’s most recent address, for our Mr. Lim to make it to his appointment).
We also integrated data from the web logs into the database to allow web tracking to be done internally, and for Docdoc to link customer website activity (including referrers and past visits) to appointment activity.
A series of new features will be enabled allowing Docdoc to become more competitive against international competition. Processes within the company have only been minimally altered, allowing operations to continue as usual throughout.