So, what is the connection between a community of practice with a mission to improve global healthcare through implementation-based health information exchange architecture and the process of designing the layout and infrastructure for a town? In this blog, we will demystify OpenHIE–and our architecture–by comparing these two very different concepts!
Let’s start with urban planning
Planning the layout of a town involves knowledge of the town as it is and how it could be; the terrain, buildings, streets, sewers, electricity – and most importantly the interconnection between all of these things. These items must exist and operate individually and within the confinement of the town – but can and should connect through pathways. Additionally, it is not enough to stop at the establishment of these items and their connectivity – there must also be roles and processes in place to maintain operations, growth, and interconnectivity.
Connecting to Principles of Health Information Exchange
These principles are also true for health information exchange. In place of buildings, we can substitute individual business domain services (i.e. shared health records, finance and insurance services) and registry services (i.e. terminology services, client registries, product catalogues). In place of roads and electricity infrastructure, we can substitute interoperability strategies.
The business domains and registry services are important as they make up the components that are the heart of health information and accessible through points of service like electronic medical records and other systems. However, these items will quickly become outdated and backlogged without a point of connection to the other systems and to procedures that are reasonably maintained through people. This is where the interoperability layer comes in. The interoperability layer is important to stand up the people and process practices to interwork the components. This is the exchange.
Both the urban plan and the health information exchange, on paper, seem workable with all their points of connection and maintenance procedures. The bigger picture of both is that they exist in real-world settings, where town infrastructures run into decaying materials and health information exchanges run into outdated software–among the many other issues they could come up against. While people and processes, in terms of an interoperability layer, help to address these issues, there is an even more important component that is also unique to OpenHIE: community.
The Community Process
The community process is what stood up the OpenHIE architecture as we know it and continues to make improvements based on the implementations of it around the globe. It is the community who implements the solutions and reports back on their approach and what modifications were needed – this information is then distilled to others who are looking to implement and the cycle continues. The world is not a perfect terrain to implement these types of strategies in a one-size-fits-all capacity and so the community is necessary to set-up a structure that can be customized for other situations.
When you look at real-world environments, even those rich in resources, you can see where health exchange systems were built without a plan, an urban plan, in place and their system’s value has been limited by the inability for these exchanges to integrate with each other. Many emerging economies are wondering if they could start by building these systems alongside a plan. In creating a health information exchange architecture, we hope builders will be open to seeing what OpenHIE can offer – by sharing best practices and real-world instances of the success of a plan-based approach as well as a community who has defined these and can offer support along the process.
If this topic helped to break down some of the concepts of OpenHIE and you’d like to dig even deeper, be sure to go to the Academy where you can take courses over concepts that relate to the work of OpenHIE!