This is part one of a series of blog posts on the Core Principles of NaviNet Open.
Unlike the rigid forms and functions that are the fruits of other engineering disciplines, software is highly malleable. Agile, on-the-fly development methodologies, design patterns, implementation frameworks, and massive computational power allow software engineers to render ideas in ways that would be unthinkable in the non-virtual arts. But the points at which software connects to the real non-virtual world are far less fungible and forgiving.
The data model is one such point. Most software projects begin with a data model. Here, business meets software architecture. Software engineers must first assert that a business runs in a particular way, with well understood entities working together in specific ways. Then, they can create a robust information map of those entities and relationships. This map is the information over which the software logic computes and processes. If the map changes, the software loses its way and must be revised.
Networks Are Dynamic
But what if the data model is rapidly evolving? How can we accommodate unforeseen new entities, relationships, and ways of interacting? The U.S. healthcare industry is cranking out new org charts and new partnerships at a rate that pushes software malleability to its limits. These new organizations are tasked with quickly and cheaply connecting into the growing and changing healthcare information infrastructure in meaningful and lasting ways. In the face of such a challenge, most architects would raise the level of abstraction, would "go meta". However, this can come at the price of specificity, semantic richness, simplicity and clarity. Instead there needs to be a way to raise the level of abstraction while still applying the specificity needed to get real work done. This was the challenge that our engineering team faced when first established the foundation for NaviNet Open.
Roles Are Not Fixed
Since NaviNet Open is a network, it is helpful to think in terms of its nodes and the relationships connecting them. In simplistic terms, a node in our network is a participant such as a payer, provider, patient, case manager, care coordinator, or administrator. It would be easy to simply represent these as the entities in our data model and call it a day, but these are really just roles that entities can take, not the actual entities themselves. Note the difference between being a thing and taking on the role of a thing. Participants are equals with respect to basic network connectivity, similar to the Ethernet in which any old device can connect and get an IP address. What differentiates network participants, whether on Ethernet or on NaviNet Open, are the roles they agree and/or are approved to take on. Role assignment should not be expressed as a rigid part of the data model. Instead an array of possible roles are represented in the model, and the actual role is assigned at runtime based on the context of an interaction. As new roles appear in the healthcare industry, existing participants need to be able to take them on without upheaval.
Relationships Represent Network Routes
Relationships between the entities also needed to be considered during the development of our data model. In network terms a relationship represents a network route between participants, much like the entries in a routing table for a physical network. Meanwhile in business terms, a relationship between participants enables collaboration on clinical, funding and healthcare operations activities. To synthesize these two concepts, a collaboration is the flow of information over the network routes that connect participating entities. Thus, relationships and roles, and the network routes used, change according to the context of the collaboration. For example, a given provider is the primary care provider (PCP) for one patient, while for another patient that same provider is a specialist. The nature of collaboration with this provider will change depending on the patient context, so the network must allow the participants in a collaboration to understand the context of each participant’s role.
Relationships are Ephemeral
Another interesting aspect of healthcare entity relationships is that they are often ephemeral, existing only for the duration of an interaction. We needed and designed NaviNet Open’s data model to allow these network connections to come and go with ease. Take a referral as an example. The PCP and the specialist need to form a collaborative relationship from the time the referral is initiated until all follow up visits with the specialist have been completed. At that point, these two participants no longer have a substantial relationship. In effect, they establish a network route, interact over that route via the “referral protocol”, and then disengage once the interaction is complete.
Subnets Simplify the Network
Finally, the data model required that entities cohere into meaningful organizational units. These organizational units provide rough constructs that can serve as proxies for the entities they contain, similar to subnets and their gateways in physical networks. For example, a group of providers represented as an organizational unit can have a "billing entity" relationship with a payer. The individual providers in that group do not need an explicit billing entity relationship with the payer. Providers' billing entity behavior can change simply through their billing entity organization membership.
Surfacing Data in Applications
In reality, the rubber meets the road when entities and relationships must show up in application features. Take the NaviNet Open Advanced Referrals application in which the list of servicing providers from which the user may select is based on the patient, the payer, the insurance product and the provider networks available to the user at their particular practice location. The assignment of entities to roles and the careful tracking of relationships of those entities in those roles allow us to determine the correct provider list to present to the user in any given context.
Tying It All Together
A software system can only be as malleable as its data model, but a data model that is too flexible, can too abstract, reducing the value it provides to the domain. With our flexible data model, NaviNet Open’s first Core Principle, we’ve created a model that defines participants’ network presence while letting their roles and relationships be contextually driven. This allows applications on the NaviNet Open network platform to surface the right data in the right context.
Stay tuned for the next installment in this series on the Core Principles of NaviNet Open, in which we'll discuss APIs. And as always feel free to give us your feedback on this blog series. What provisions have you made for your data model to evolve?
Learn more about NaviNet Open's Architecture in this recorded webinar: