Governance

A lot of activity and progress is underway around the world right now, and has been for some time, regarding integrating and sharing health data for healthcare management and delivery purposes. Many standards, reference models and authorities have arisen to guide implementation and use of IT for these purposes, for example health information exchange standards driven by the Office of the National Coordinator for Health Information Technology (ONC – http://www.healthit.gov/).  Many very new and modern health IT capabilities and products are available now, alongside systems and data that may have been first created over 30 years ago (particularly in the Federal Government).

In the media and within procurement activity, the swirl of misused phrases and definitions isn’t clarifying many approaches.  Records vs. Data vs. Information. Interoperability vs. Integration. Standards vs. Policies. Systems vs. Software vs. Products or Solutions. COTS vs. Services vs. Modules vs. Applications. Open Source vs. Open Standards. Modern vs. Legacy vs. Current.

In Enterprise Architecture (EA) terms, the messages regarding Integrated Healthcare IT requirements aren’t commonly being presented at a consistent level of abstraction, according to a consistent architecture model and vocabulary. As well, the audience or consumers of this information aren’t being addressed in ways most impactful to their specific needs and concerns.

What are the audience concerns?  IT system owners need to maintain data security and system performance, within technology and investment constraints. Doctors need consistent, instant, reliable and comprehensive visualization of data and the point of care. Government oversight bodies need recurring validation that money is spent wisely and results meet both mission and legislative requirements. Veterans, soldiers and their families need absolutely private, accurate, real-time information about their healthcare status – wherever they are. The pharmaceutical and medical device industries need timely, useful data regarding outcomes and utilization – to drive product improvement and cost-effectiveness. Hospitals, clinics and transport services need utilization and clinical workflow measurements to manage personnel and equipment resources.

The highest separation of concerns can be segmented by standard Enterprise Architecture domains or “views”.  A very generic, traditional model is the “BAIT” model – i.e. Business, Application, Information and Technology. Note that this is very similar to the widely-known “ISO Reference Model for Open Distributed Processing” (RM-ODP) Viewpoints – which underpin evolving healthcare standards including the “HL7 Services Aware Interoperability Framework” (SAIF).

The “Business Domain” encompasses the discussion about business processes, financials, resources and logistics, organization and roles.  Who does what, under what circumstances or authority, and how outcomes are evaluated and purchased.  The business drivers and enablers of successful healthcare delivery, one might say.  

The “Application Domain” concerns automating the “practice of healthcare”. Automated systems (and their user interfaces) are very helpful in planning, monitoring and managing the workflow, resources and facility environments, and of course processing data for clinical care, surveillance and health data management and reporting purposes. This is where healthcare expertise is codified in software and device configurations, where medical intelligence and knowledge meets computer-enabled automation. This domain is the chief concern of clinical practitioners and patients – where they can most helpfully provide requirements and evaluate results.  Software that’s built to process healthcare data comes in many shapes and sizes, can be owned or rented, are proprietary or completely transparent.

The “Information Domain” is in essence the “fuel” for the Application Domain.  Healthcare practitioners and patients care that this fuel is reliable, protected and of the highest quality – but aren’t too invested in how this is achieved, beyond required or trained procedures.  It’s like filling the car with gas – there’s some choice and control, but fundamentally a lot of trust that the gas will do the job.  For those whose concern is actually delivering gas – from undersea oil deposits all the way to the pump – this domain is an industry unto itself. Likewise, collecting, repurposing, sharing, analyzing information about patient and provider healthcare status is a required platform on which successful healthcare user applications and interfaces are built. This is what “Chief Medical Information Officers” are concerned with, as are “Medical Informatics Professionals”. They are also concerned with the difference between healthcare “records”, “archives” and “information” – but that’s a discussion for another day.

It is critical to note that “Information” is composed of data; core or “raw” data is packaged, assembled, standardized, illustrated, modeled and summarized as information more easily consumed and understood by users. Pictures, sound bites and brief notes taken by an officer at an accident scene are data (as are “Big Data” signals from public social media and traffic sensors); the information packages include the accident report, the newspaper article, the insurance claim and the emergency room evaluation.  These days, with the proliferation of data-generating devices and sensors, along with the rapid data replication and distribution channels available over the Internet, the “Data Domain” itself can be a nearly independent concern of some – providing the raw fuel to the information fire, oil for refined gas.

The “Technology Domain” is essentially all of the electronic computing and data storage elements needed to manage data and resulting information, operate software and deliver the software results to user interfaces (like browsers, video screens, medical devices).  Things like servers, mobile phones, physical sensors, telecommunications networks, storage repositories – this includes the machine-specific software embedded into medical equipment.

Sidebar: Data Domain Standards

Quite a bit of work and investment is required to collect, filter, store, protect and make available raw data across the clinical care lifecycle, in order that the right kind of information is then available to be utilized by users or software. Most importantly, reusable, open standards and Reference Implementation Models (RIMs) concerned with the Data Management domain are foundation requirements for any effective healthcare information system that participates in the global healthcare ecosystem.

A RIM is basically working software or implementation patterns for testing and confirming compliance with standards, thereby promoting creation of software products that incorporate and maintain the standards.  It’s a reusable, implementable, working set of code with documentation – focused on a common concern, decoupled from implementation policies or constraints. RIMs are useful for facilitating standards adoption across collaborative software development communities at every layer of the Enterprise Architecture.

For example, a data-domain RIM developed several years ago by Oracle Health Sciences (in a clinical research setting) focused on maintaining role-based access security requirements when two existing sets of research and patient care data were merged for querying.  The design of the single RIM merged the HL7 Clinical Research Model (BRIDG) with an HL7 EHR Model (Care Record) to support a working proof-of-concept – that others could adopt as relevant.  The “concern” here was data security – separate from the information and application-level concerns of enabling multi-repository information visualization methods for researchers.

The point of this discussion on EA-driven separation of concerns is illustrated as follows. When a spokesman (or RFP author) says “the system will be interoperable” – it’s likely that by “system” the meaning is some segment of the “Application Domain” being able to exchange objects from the “Information Domain”.  Instead, a better phrase might be “the software application will be able to share standardized healthcare information with other applications”. This keeps the principle discussion at the application and information-sharing software level, and doesn’t make detailed assumptions or predictions regarding concerns in the Business, Data or Technology Domains.  Those are different, but related discussions, and may already be addressed by reusable, standard offerings, RIMs or acquisition strategies.   

Taking this approach to broadly interpret the recent announcement that the DoD will seek a competitive procurement for “Healthcare Management Software Modernization” – it appears the focus of this need is the Application Domain – i.e. software packages and/or services that generate and use healthcare information while managing healthcare processes and interactions.

To support these new software application features, separate but related activity is required to address “modernization” concerns among the other EA domains – concerns relating to datacenter infrastructure, data management and security services, end-user devices and interfaces, etc.  Some of this activity may not be dedicated to healthcare management, but be shared and supported for enterprise use, for other missions. That’s why use of a current, relevant EA frameworks (such as DODAF v2.02 and the OMB “Common Approach” ) is so important, managing shared capabilities and investments.   

Using standard EA viewpoints to separate concerns will also expose reuse opportunities (and possibly consolidate or reduce acquisition needs), i.e. leveraging existing  investments that are practical enablers. Some examples might include the developing iEHR health record structured message translation and sharing services, plus HHS/ONC initiatives including Health Information Exchange Networks and the “VA Blue Button” personal health record service.   

By Gloria Chou

When launching a formal EA program, Government organizations often begin by socializing the overall benefits of EA and developing an EA Charter and Plan.  However, while both of these are valuable, they are more useful as part of after-the-fact documentation and communication plans.  Having worked with a broad spectrum of government organizations across the US and Canada, our team, Oracle’s Public Sector Enterprise Strategy Team (EST), has found that the first and primary focus in launching an EA program should be on how to meaningfully engage top business leaders and other stakeholders to discover their needs, identify what would bring the most value to the organization, and obtain their buy-in and support for EA as a key enabler in helping the organization achieve its mission objectives. 

Why is launching (or re-launching) and EA Program relevant in the government space today?  Although state and local agencies may have had an EA team for years, many are just getting started on formalizing their practice and creating awareness of the team’s capabilities and purpose within the organization as a whole – though some are in fact successfully delivering Agency-wide Enterprise Architecture value.  Additionally, while a majority of Federal agencies have necessarily had established EA programs for over a decade in response to Clinger Cohen mandates, some are beginning to reshape their programs as they perceive the need to go beyond checkmark/compliance-based EA and demonstrate additional value to their respective organizations.  Governmental budget pressures are increasing the scrutiny on all resource allocation and deployment such that EA programs must stay relevant and drive acknowledged and desired benefits or else risk being cut.

I believe discovery and dialogue with executive leadership about their goals, objectives, strategies, and current planning processes has to come first as, only after this is known, can the team understand what is particularly valuable to the specific organization.  Too many Government EA programs seek to provide generic value and benefits, such as standardization and integration, that, while good aims in and of themselves, are not necessarily prioritized by the organization nor sometimes even compatible with their operating model and culture.  As a case in point, when working with a very large municipality in the West, the EST began discussing EA with a new, forward-thinking CIO who had been three months into establishing an EA program to change the way IT was viewed across the organization.  We had an initial meeting with the lead EA and found that the new EA team had been doing the expected: technology architecture current state analysis and building IT standards documents.  After three months, the team was well on their way to spending another year or more on documentation!  The question we posed was, how does this change the way IT is viewed across the organization? The answer was clear, it didn’t.  Understanding specific needs, gaps, and opportunities that the executives care about is essential to ensure EA is relevant and focuses on what the business needs to successfully execute on its strategies.   

Based on this understanding of the organization’s priorities and what would bring the most value, the EA team should analyze what needs to be done and propose how they can be a part of the solution.  In the example of the large municipality mentioned above, the EST helped the organization’s EA team identify areas of opportunity to engage with business leaders across the organization and facilitate meetings to better understand strategies, goals, capabilities and high-level value streams.  By starting here, we were able to get the EA team on a path to make better decisions on where they would invest their time to provide the most value to the enterprise.  As a part of this, the team needs to assess their own capabilities and competencies as well as that of other teams within the organization against what is needed and propose options as to how they might best help the organization and what other changes might be needed to achieve the organization’s goals.  In actuality, an EA approach would help facilitate this analysis and assessment of how EA itself could benefit the organization.  The team should consider developing the vision for change as well as current state and future state views of operations, analyzing the gaps, and developing recommendations and a roadmap for the successful introduction of EA into the organization.

Only after the recommendations have been presented, vetted, and selected by leadership should the team document the EA purpose, application, and approach.  While this information can be captured in the EA Charter and Plan, it only represents a part of the needed content.  The rest, especially the plan, can only be developed after seeking input from other stakeholders in the organization.  Even though the executives have weighed in with their input, direction, and approval, it is still often difficult to get an EA initiative started because so many other stakeholders also need to be convinced of the value.  For example, LOB leaders, business managers, and functional SMEs all have to be convinced of the value of EA or else they will not allocate the time and resource required to participate in facilitated sessions and verify/validate the architecture.  Executives and LOB leaders are critical in setting the vision for the future and describing the general goals for operations as well as communicating their overall investment and technology strategies.  However, even if the executives and leaders buy-in, the lower levels also have to perceive value/benefit or else they will put in minimum effort when you really need them to be fully engaged to provide detail as to the reality of operations, challenge the status quo of how things are done today, and ultimately take ownership of the architecture and support the transition to the future state.  Without the business fully on board, the EA recommendations and transition look good on paper but will never be executed. 

Similarly, other stakeholders including Corporate Strategy, Portfolio Management, Project Management, Lean/Six Sigma, and IT also need to fully support EA as they are also critical in the development, execution, and enforcement of EA.  The stakeholders in these other disciplines sometimes feel that EA encroaches on what they do and do not understand why it is necessary.  For example, Lean/Six Sigma practitioners and some business analysts already have great relationships with the business and have already documented and analyzed processes such that they believe they have already “modeled the business” such that EA business architecture development and analysis is extraneous.  IT organizations often point to their UML diagrams, systems engineering drawings, and infrastructure server drawings and say that they are already doing EA.  In seeking buy-in from these other groups, it is very important to first seek to understand and acknowledge the current state of operations – existing skills, processes, and assets – before proposing a future state of how EA enhances/complements.  Formal stakeholder analysis and RASCIs can be helpful, but I believe an attitude of respect for what others do and a collaborative approach is also critical as there are many organizational change issues and related sensitivities associated with introducing EA as a discipline as with any other transformation.  Once general buy-in and support for EA is established, the disciplines need to work out details around overall processes, governance, timing, inputs and outputs to understand synergies, cooperation, etc.  Again, this is something that can be documented via EA, further decomposing views that were used in the overall analysis for the introduction of EA.