“In theory there is no difference between practice and theory. In practice there is.”
We’ve previously discussed the role of innovation in IT to help drive down costs to the system overall1, and how adhering to the principles of open system architecture (OSA) facilitates adoption by service consumers and lowers IT costs related to maintenance and scalability.
Over the last year and a half we’ve had several opportunities to apply the OSA principles on projects across Canada and around the world. In the spirit of this article’s opening quote, we thought others might benefit from our experiences applying these principles.
As a reminder, OSA is essentially the design of IT systems – such as jurisdictional EHRs and their various sub components – with the goal of making them easier to swap components or add new ones to extend the useful life, functionality, interoperability, and overall value provided to the organization and its stakeholders.
Literature describing OSA varies depending on the source. The following is our synthesis of common OSA principles that we use in system design and evaluation:
- Use of proven, open, standards: An open architecture enables the deployment of multiple integration methods based on established standards that are consensus-based, widely used, and easily accessible to potential users.
- Use of emerging/popular standards: This may seem contradictory to the first principle, but that’s only if you view data exchange as a choice of one standard over another. Systems using open architecture support the ability to stand up new APIs or adaptersto support emerging and popular standards, which allow new consumers to connect to the back-end systems without forcing existing consumers to change their applications.
- Use of non-proprietary technologies: An open system architecture is a standards-based architecture and does not expose any proprietary technologies or integration methods for service delivery. Removing proprietary integration points and services allows for a less complicated and more responsive integration environment.
- Use of abstraction: One of the foundational architectural concepts of an open system is abstraction. With purpose-built integration and access services sitting between participating applications and back-end services, any changes made to the back end won’t affect connections to participating applications. Abstraction of the service interfaces means participating applications are loosely coupled. Loosely coupled solutions have the additional benefit of reducing change and release management activities and of reducing the risk and complexity of any changes made.
- Use of APIs: The architectural principle that enables rapid adoption is API-led connectivity. The fundamental building blocks of open system architecture are development of APIs in order to meet application requirements, while establishing policies and managing access to back-end data through the deployment of a configurable set of security and privacy services. This principle is closely related to the previous one – APIs are a form of abstraction.
- Scalable and extensible: The architecture should support multiple standards for the same function, such as supporting both HL7 v2 and FHIR for data structure and XML and JSON for data syntax.It should enforce the separation of concerns between different layers and functions, such as an integration layer, service access layer, privacy and security, core business services, and reporting. Finally, it should support adding capacity, which can mean several things such as the ability to rapidly increase simultaneous users with increased storage, bandwidth and processing.
From Theory to Practice
The point of principles is to use them to guide everyday decisions, and to evaluate options for complex decisions. The following are several examples of real-world decisions we’ve encountered when attempting to apply these principles.
OSA Principles in System Design
Applying OSA principles to system design is much easier when starting from scratch and deploying into ‘greenfield’ spaces. Unfortunately, there are very few of those in Canada’s digital health landscape. The reality is that most new systems have to integrate with existing systems, which will lead to design constraints that may compromise one or more of the OSA principles.
One way to deal with the tension of meeting near-term constraints is to use the principles as architectural goals that can be met over time using a phased implementation approach. This allows systems to be implemented in a way that might compromise an OSA principle in the short term, which is completely acceptable if there is a corresponding roadmap to evolving the system in a manner that will eventually support all of the principles.
Another challenge is related to borrowing best practices from other industries that don’t have the same privacy constraints as we do in health care. For example, companies operating in industries outside of health care often design their APIs to expect some minimum data and to ignore extra or unexpected data. This design supports many of the OSA principles at a practical level, but leads to challenges in the digital health industry as the following example illustrates.
Imagine there is an EMR that can submit immunization data to an API in Ontario. The Ontario API requires the EMR to send nine mandatory elements. If that same EMR needs to send immunization data to an API in Alberta that only requires five of the mandatory elements, the EMR vendor does not need to change their product and can send the nine mandatory elements. The Alberta API will look for the five elements it cares about and ignore the rest.
In theory, this is a great idea because it lowers total cost of ownership by not forcing the EMR vendor to create and maintain a separate interface for Ontario and Alberta. In practice, it contravenes the basic privacy principle of only sending the minimum data required to meet business and technical requirements, and contributes to the explanation of why every province seems to have distinct interfaces for similar data exchanges.
OSA Principles in System Evaluation
Another practical application of open system architecture principles is to translate them into a score card or evaluation matrix that can be used to evaluate systems for anything from RFP responses to value for money audits.
Applying the OSA principles requires breaking them down into specific evaluation criteria relevant to the initiative. For example, an RFP that simply asks respondents to indicate if their system supports HL7 FHIR is insufficient. A system that uses HL7 FHIR and has a published API implementation guide could claim to meet principles 1, 2 and 3. However, that system could implement HL7 FHIR ignoring best practices, which effectively creates a unique approach that is contrary to those principles. Similarly, the principle of enabling rapid adoption is meaningless without specific criteria defining what ‘rapid’ means in terms of duration, cost and effort.
The OSA principles have many useful applications as demonstrated above. It’s important to remember that they are principles that can be used to guide a conversation or frame a challenge. They are not strict rules, nor are they an architectural development framework like TOGAF’s architecture development methodology. The OSA principles are easier to apply in greenfield environments, but they are not limited to those environments. They can be applied to mature environments in an evolutionary manner, and support other IT frameworks such as disciplined agile delivery and the scaled agile framework (SAFe). In many cases, the OSA principles are most valuable when there is an absence of defined methodologies and roadmaps. Architects that apply these principles to system design decisions can be reasonably confident they’re moving in the right direction.