The two doctors were able to obtain some funding to develop a prototype, and your team was selected to support them. You and your team have some items to consider:
• What data elements will you need?
• What is the source system for those elements? (the surgical team has multiple systems they work in)
• How will you collect and store all of those elements together?
• Which members of the clinical team will you need to include? (Nursing, Pharmacy, Anesthesiology…)
• How will you find out how the teams currently do their work?
• What logic will be needed to “enrich” the data (see below for deeper discussion on this topic)
• What information will be needed to display?
• How will you design for a mobile device when previously all EHR data was displayed on desktop computers?
• What metrics of success should you use?
• What technologies will you need?
Data enrichment is a term that describes the output of rules and logic built into the code. For example, one thing a surgeon needs to be aware of is whether the patient is bleeding internally. Since this is not something that can be detected visually, it is monitored by measuring changes in hemoglobin levels in the patient’s blood. If the hemoglobin level falls 3 points between lab draws, there is a good chance the patient has internal bleeding. Normally, this is determined when the clinician reviews the lab results and manually compares them to previous results. She documents the need to investigate the potential bleed and her planned next steps in a clinical note using free text.
Dr. Tucker wants you to write code that will automatically identify any significant drops in hemoglobin levels and alert the clinician immediately, so she does not have to rely on memory to check the previous levels and mentally calculate the difference. The trigger to send the alert is “enriched” data and becomes a new data element to keep in the chart. Your challenge is to figure out how to create that calculation, present the data to the care team, and store it somewhere for future reference.
Zelda Medical Center has a catchy, clever name for nearly every project. Your team wants to build not only a Colon Rectal Surgery tool, but the design of a base for all Enhanced Recovery Pathways, so you name your project Surgical Medical Optimization Design (SMOD).
Please address the following to get started with Case Study Two
Your team will need make other decisions:
- Will you implement all sites at once, or will you implement each individually?
- Will you implement the entire EHR at once, or will you start only in the inpatient or outpatient practice?
- How much feedback and input do you want from each site? What level of detail will the internal customers see?
- How much historical data will be put into Vapid? Clinicians need to know the history of a patient, and they prefer to see it in the current EHR. A cognitive burden is added if they have to go between two systems for a single task.
- What will your training process be?
- Will the EHR be hosted on-premise and supported by MMC staff, or will you purchase that functionality from Vapid?
- How will IT support the EHR after it is fully implemented?