1. Care Coordination and Interoperable Health IT Systems
Unit 6: Implementing Health Interoperability
Lecture c – Implementation: “Design” Phase
Welcome to Care Coordination and Interoperable Health IT Systems, Implementing Health Interoperability, Lecture c.
This material (Comp 22 Unit 6) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Implementing Health Interoperability Learning Objectives
Objective 1: Identify major tasks required to implement interoperability (Lecture a)
Objective 2: Explain why interoperability implementation projects are needed. (Lecture a)
Objective 3: Define and discuss each phase of the interoperability implementation lifecycle (Lecture a-e)
Objective 4: Describe how to apply each phase of the interoperability implementation lifecycle to simple interoperability implementation problems. (Lecture a-e)
Objective 5: List types of production issues with interoperability and identify and describe support strategies (Lecture f)
This unit will cover the following learning objectives: 1) Identify major tasks required to implement interoperability; 2) Explain why interoperability implementation projects are needed; 3) Define and discuss each phase of the interoperability implementation lifecycle; Objective 4: Describe how to apply each phase of the Healthcare Interoperability Implementation Lifecycle to simple interoperability implementation problems; and 5) List types of production issues with interoperability and identify and describe support strategies. This lecture discusses the “Design” phase. We will discuss best practices for designing interoperability solutions and will look at some examples of design decisions.

3. Architecting a solution
In the design phase, you determine the best way to close the gaps
Be creative
Be open to the possibility of more than one solution
Think about robustness and re-use
Sometimes, you will find a feasible near-term solution and a longer-term ideal solution
Once the analysis step is completed, you now have a detailed understanding of the problem including the gaps that must be filled. In the design phase, you determine the best way to close the gaps and architect a solution. Be creative and open to the possibility of more than one solution. Think about robustness and reuse. And sometimes, you will find a feasible near-term solution and a longer-term ideal solution.

4. Architecting a solution (Cont’d)
Work with user(s) to design a future workflow in support of the desired state
Determine required work to fill gaps
Negotiate with user(s) and vendor(s) for a site-specific design solution
The design phase consists of working with the user or users to design a future workflow in support of the desired state. It also includes determining required work to fill gaps. This might require translations, mappings, filters, etc. During design, negotiation with the users and the vendors takes place. You need to determine the best place to do the configuration changes or coding based on price, complexity, ease of change, reusability, and maintenance and then negotiate a site-specific design solution. For example, maybe the vendor software will be changed or configured, maybe a user workflow will change, or maybe translations will be written on the interface engine. These are the kinds of decisions made during the design phase. Note that it is not uncommon for changes to occur on multiple systems. During design, you determine the best solution and develop a specification describing what changes need to be made across all systems involved.
Health IT Workforce Curriculum Version 4.0

5. Solution might include a multitude of changes: examples
Interface configurations on sending and receiving systems
Translations, filters, or mappings using interoperability tools
Vendor enhancements
User process changes, training, documentation
Screen / database / table configuration changes
Physical layout of department / space
Examples of the kinds of changes that occur to solve interoperability problems commonly include interface configurations on sending and receiving systems. Vendors often provide the ability to configure their interoperability capabilities to allow systems to successfully interface. Another common change are the addition of translations, filters, or mappings using interoperability tools such as interface engines, enterprise master patient indexes (EMPIs), terminology servers, and health information exchange (HIE) software. Sometimes, vendors must enhance that software to support a particular interoperability use case. Other changes can also help implement interoperability, such as user process changes; training; documentation; or screen, database, or table configuration changes on vendor systems. There could even be changes to physical layouts of the department.

6. Example: coordinating care at Good Health Clinic
Good Health Clinic requests notifications of their patients’ admissions and discharges from Caring Central Hospital
Caring Central Hospital (sending) system sends A01, A02, A03, A11, A12, and Z01, but Good Health Clinic (receiving) system can only receive A01 and A03
Can you determine the best way to resolve the incompatibility?
Let’s look at some examples. Recall Good Health Clinic’s request for notifications of their patients’ admissions and discharges from Caring Central Hospital. Consider the gaps found in the Analysis phase before. We determined that the sending system sends A01 for admit, A02 for transfer, A03 for discharge, A11 for cancel admit, A12 for cancel transfer, and Z01 for pediatric admission. But the receiving system can only receive A01 for admit and A03 for discharge. Can you determine the best way to resolve the incompatibility?

7. Identify the relevant incompatibilities
A02 and A12 refer to a patient being transferred while an inpatient at the hospital
There is no need to receive notifications of these events for the use case being implemented
A11 is for a canceled admission
This might be useful as the doctor would want to know that their patient was actually not admitted
Z01 is for pediatric admissions
This is important if the clinic sees pediatric patients
The Analysis step is when you find all the possible problems. The Design step is where you find a solution to the problems. Sometimes, you determine that some incompatibilities are not significant. For example, since Good Health Clinic does not need information about where a patient is within the hospital, it does not need A02 or A12 messages. A11 is for a canceled admission. This is important because it signals that the patient was actually not admitted. Z01 is for pediatric admissions so this is important if the clinic sees pediatric patients.

8. Determine the best solution for A11 (Cancel Admit) – negotiate
Should the receiving system add support for A11?
This would be ideal as sometimes this can be configurable as part of the implementation
What if they cannot? Should the sending system remove it?
It should not be removed if the sending system is sending it to other systems
Should the hospital interface engine do a translation?
One idea is to use the hospital’s interface engine to change the A11 to an A03-Discharge event and make the discharge reason “Admit canceled”
You need to resolve the problem of A11 not being supported by the Good Health Clinic EHR. One idea is the request an enhancement to the Good Health Clinic’s EHR asking them to support A11. That would be ideal as sometimes this can be configurable as part of the implementation. But what if they cannot? Should the sending system remove it? Caring Central Hospital should not remove the A11 code if they are sending it to other systems as well. One idea is to use the hospital’s interface engine to change the A11 to an A03-Discharge event code and make the discharge reason “Admit canceled”. When the Good Health Clinic’s EHR receives this message, it will indicate the patient as discharged from the hospital, but the reason will be a cancelled admission.

9. Determine the best solution for Z01 (Pediatric Admit) – negotiate
Should the receiving system add support for Z01?
Z01 is not standard so this might not be the best approach, but they could
However, if the vendor allows for site-specific configurability, this would be a good solution
What if they cannot? Should the sending system remove it?
It would be ideal to remove it if the sending system was using A01 instead, since that is the correct standard approach
What if they cannot remove it?
One possible solution is to use the hospital interface engine to change the Z01 to an A01-Patient Admit
Let’s look at the Z01 Pediatric Admit incompatibility and what could be done to resolve it. Should the receiving system add support for Z01? The best long-term solution would be to have the sending system replace the non-standard Z01 with the standard A01. Assuming that is not possible in the timeframe, one possible solution would be to use the hospital interface engine to change the Z01 to an A01-Patient Admit code. Then the Good Health Clinic EHR would be able to receive and process it.

10. Looking deeper at the problem
Recall that the clinic only wants information on their patients
Perhaps in your gap analysis you found that the clinic’s EHR had the ability to send an IHE Patient Cross Referencing message when it had a new patient to add the patient to an index
This might be useful to determine which patients are the clinic’s patients
The hospital’s patient management system does not honor these requests, but what if the hospital’s EMPI did?
There was another gap that was identified. The hospital system sends messages about every patient admitted to the hospital. However, the Good Health Clinic EHR only wants information about their own patients. This is not a simple filter. Perhaps in your gap analysis you found that the clinic’s EHR had the ability to send an IHE Patient Cross Referencing message when it had a new patient to add the patient to an index. This might be useful to determine which patients are the clinic’s patients. You find out that the hospital patient management system does not honor these requests. But what if the hospital EMPI did? All of Good Health Clinic EHR’s patients and all of the hospital’s patients could be added to the EMPI and cross-referenced to each other. Then when a Good Health Clinic patient is admitted to the hospital, the EMPI is queried for the patient and it is determined that the patient is a Good Health Clinic patient. The admit message is forwarded on to the Good Health Clinic EHR.

11. Design diagram: notifications for Good Health Clinic
Diagrams are very useful in the design process. The picture above is a common diagramming format used in health care interoperability. Each system is represented as a box on the diagram. There are arrows on the diagram representing each individual interface and the direction of data flow. Next to each line is information about the kind of data that is sent. This diagram represents the design for the problem of notifications for Good Health Clinic. The hospital patient management system sends patient administration messages about all patients admitted, transferred, and discharged at the hospital to the interface engine. In specific, it sends HL7 V2® events A01, A02, A12, Z01, A11, and A03. When the interface engine receives a message from the hospital patient management system, it queries the EMPI to determine if the patient is a Good Health Clinic patient using the IHE Patient Cross Referencing or PIX query. However, if the message is Z01, it transforms the message into an A01 by changing the message type. If the message is A11, it transforms the message into an A03 with Discharge Disposition set to “Admit Cancelled”. Also, whenever a new patient is added to the Good Health Clinic EHR, a message is sent via the interface engine to the EMPI to add the patient using the IHE PIX Add message. This diagram as well as narrative would be included in the design specification so that the builders will be able develop the necessary filters and transformations to implement the interoperability needed.
6.3 Figure (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

12. Solution is not necessarily “one size fits all”
HL7 Implementation
Solution is not necessarily “one size fits all”
Each new ancillary, patient population, vendor system, hospital, user community introduces new variables, nuances, and challenges.
Prior experience and sticking to standards help, but it is not enough
Examples:
New LIS is purchased so existing interfaces are replaced
EHR is implemented in another hospital so the care summary document for the new hospital must be sent to the patient portal
New EHR is implemented so make sure existing patient facing apps still work
Sometimes, implementers think that they can replicate or replace an interoperability solution without use case specific customizations. However, each new ancillary, patient population, vendor system, hospital, and user community introduces new variables, nuances, and challenges. Prior experience and sticking to standards help, but it is not enough. For example, if the hospital laboratory information system, or LIS, is replaced, it is not as simple as changing the existing interfaces to point to the new LIS. Instead, the existing interfaces will most likely need to be modified to work with the new LIS. This modification could potentially be done on the interface engine. And just because the care summary to portal interface works well for the main hospital does not mean that it will work on the new hospital. Careful testing and gap analysis are needed. If the EHR is replaced, any patient-facing app that the doctor or hospital recommends to patients should be checked and potentially modified. These are just three examples, but there are many more. So make sure to make decisions based on prior research, sticking to standards, and make sure to test.

13. Designing interfaces Stick to standards
HL7 Implementation
Designing interfaces
Stick to standards
Design for maximum re-usability
Use middleware translate / map capabilities sparingly
Ensure that patient confidentiality is not compromised
Designing takes skill and strategy. Some tips on how to design robust interoperability are as follows: 1) Stick to standards as much as possible so have vendors change to be more conformant. 2) Design for maximum reusability. That means, keep the system whose interoperability capability is used the most as standard and robust as possible. For example, if the sender provides the more reusable interface, convert the receiver. Just because middleware capabilities are available does not mean that they should be used to compensate for vendors not providing robust interoperability capabilities. Middleware configurations are costly to support and manage. Use them when it is the safest choice for the patient, when it is in the best business interest of the organization, and when it will make data more reusable. Be especially careful not to do unsafe translations. Also, always ensure that patient confidentiality is not compromised.

14. Designing for workflow efficiency: example of electronic lab orders interface
An electronic orders interface should help reduce manual work
But some manual work will still be required (e.g. collecting, labeling, and receiving specimen)
Need a way to reduce paper orders and re-entry into the LIS
One idea is for the LIS to generate labels for the specimen to be collected that already have the orders associated with them and the labels would be printed by the nurse
The lab clerk would have all the information needed to check-in the specimen on the LIS and get the orders started without a lot of re-entry
In addition to designing solutions that will require technology solutions, such as vendor or middleware configurations, new workflows also need to be designed. Recall the example in the lecture on Analysis where we discussed potential workflow issues with using an electronic lab orders interface in communicating lab tests to the laboratory. During analysis, we identified that an electronic orders interface should help reduce manual work, but some manual work will still be required, such as collecting, labeling, and receiving specimen. We need to design a way to reduce paper orders and stop requiring re-entry of orders into the LIS. One idea is for the LIS to generate labels for the specimen to be collected that include the lab order ID and patient demographic information. The nurse would use the LIS printed label to label the specimen when collected. The lab clerk would have all the information needed to check-in the specimen on the LIS and get the orders started without a lot of re-entry. As you can see, it is not all about designing system changes. Workflow may be redesigned as well.

15. Lab specimen processing workflow: current state
Here is an example of a workflow diagram depicting the current state of the lab specimen workflow as described on the previous slide.
6.4 Figure (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

16. Lab specimen processing workflow: future state solution
Here is an example of a workflow diagram depicting a possible solution of an improved lab specimen workflow for the process described previously.
6.5 Figure (Lorenzi, V., 2016)
Health IT Workforce Curriculum Version 4.0

17. Results of design phase
Agreed upon plan / blueprint for everything that needs to be built
Identification of potential halts and major issues
Refinement of estimates and project plan steps
Documentation of design
Note: it is common that the project appears bigger now so manage scope accordingly
Sometimes, people are tempted to skip formal design and go right into building solutions. The risk is that the solution was not carefully thought out and planned and can lead to just lengthening the build and test phases of the project. A worse outcome is implementing suboptimal solutions since advanced planning was not done. The output of the design process includes many benefits. Stakeholders have an agreed upon plan/blueprint for everything that needs to be built. Potential show stoppers and major issues were identified before time and effort were wasted in building a solution. The project plan can be refined both in terms of task identification and in terms of estimates since you now have a much better idea of exactly what needs to be done. A valuable output of design is a document that describes what is being built. This document is helpful to the builders and allows the builders to be different than the designers. The design document can also be used to build both a test plan and production documentation. Note that it is common in the design process that the scope might have increased so make sure to manage scope accordingly.

18. Unit 6: Implementing Health Interoperability, Summary – Lecture c, Implementation: “Design” Phase
In the design phase, closure of gaps between the current and future states of workflow includes collaborating and negotiating with users and vendors
There could be a multitude of solutions for a problem
One solution for one problem may not necessarily resolve a similar problem at another site
Design is not only applicable to systems, but also to workflows
The outcomes include a blueprint for building and documentation of the design
This concludes Lecture c of Implementing Health Interoperability. To summarize, in the design phase, closure of gaps between the current and future states of workflow includes collaborating and negotiating with users and vendors. There could be a multitude of solutions for a problem and one solution for one problem may not necessarily resolve a similar problem at another site. It is important to remember that design is not only applicable to systems, but also to workflows. The outcomes include a blueprint for building and documentation of the design.

19. Implementing Health Interoperability References – Lecture c
Royce, W. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON 26: 1–9.
Charts, Tables, Figures
6.3 Figure: Lorenzi, V. (2016). Design diagram: notifications for Good Health Clinic.
6.4 Figure: Lorenzi, V. (2016). Current State of Lab Specimen Processing Workflow
6.5 Figure: Lorenzi, V. (2016). Future State Solution of Lab Specimen Processing Workflow
No audio.

20. Unit 6: Implementing Health Interoperability, Lecture c – Implementation: “Design” Phase
This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
No audio.