Reference Architecture for Healthcare (RA4H) – Core Capabilities

By Oliver Matthias Kipf, Software Lead EU MDR Program, Philips

About this Paper

In this third article, I discuss core capabilities of a Reference Architecture for Health (RA4H), based on the following domains:

  • RA4H – as a Product/Service: How to obtain, implement, tailor, use, and improve the reference architecture over time 
  • Integrating Health Enterprises: How to use the reference architecture in a partner network to establish and manage distributed and federated capabilities to ensure interoperability and foster collaboration
  • Architecting: How to use the reference architecture to manage the life cycle of elements (health services, care processes, medical devices, etc.)[1]
  • Architecture: The categories of elements, and where applicable, relevant set of elements the reference architecture should provide (example: reference classification of health interventions, healthcare quality reference model)[2]
  • RA4H – Standards: How to establish and manage a repository of facts, and standards relevant to the healthcare organization and its partner network

This document takes an evolutionary approach to align with and build upon existing or upcoming frameworks, standards, and best-practices, such as the TOGAF® standard, Archimate® Modeling Language, or ISO 9001 for healthcare. All application-related screenshots in this article are based on a prototype, modelled in Enterprise Architect.

Purpose

Based on the set of guiding principles that were introduced in the first blog posting, and the design ideas and concepts, discussed in the second, the purpose of this article is to provide the input to how to build and deliver our Reference Architecture for Health.

Reference Architecture for Health – Overview

Users

Let us revisit the healthcare landscape that I introduced in the first article to outline the primary users of the Reference Architecture:

Organizations that participate in the delivery of health services, directly as providers of care, or indirectly as suppliers of products, pharmaceuticals or supporting services.

Figure 1: Reference Architecture for Health: User Community

Scope

The scope of the reference architecture is on concepts, logical elements and associated models that you can use to apply and implement in a healthcare organization.

Example:

The reference architecture provides a conceptual model of care processes, preferably based on ISO 13490. It may also provide further logical models of digital care pathways that realize care processes. Based on the conceptual and logical model, the user can apply these care process models in an implementation and concrete IT tool, such as a Clinical Decision Support System.

Figure 2: Reference Architecture for Health: Scope

Approach and Focus

The ultimate aim of this reference architecture is to help improve healthcare, and human health. Its focus is on the person health journey, how we aim for a healthy life and receive health services as patients. At every step on this journey, the reference architecture needs to support healthcare organizations to perform and deliver high-quality services in a safe, and secure way:

Figure 3: Reference Architecture for Health: Focus on the Person

It also needs to ensure that we can connect the delivery domains along this journey, where we receive care or use technologies at home, get treated in the hospital, or when vital health information is exchanged at the health system level.

To illustrate this further, take a person’s health journey, and in every step, map out the required inputs (people, services, processes, products, and data), to deliver the desired outputs (improve health, meaningful health information).

Figure 4: The Person Health Journey

The reference architecture needs to provide capabilities to integrate services, processes, data, and technologies from various players along this journey. Take for example a health condition that requires emergency care, where the family doctor, as the initial point of contact, calls for the ambulance, which in turn ensures safe and secure transport to the nearest hospital, where appropriate treatment is provided. All along the way, health workers need to work together, use various devices, and generate data that you want to make available when and where needed.

Once in the hospital, and within a single episode of care, we reach the level of clinical processes. This is where health experts use a multitude of point-of-care devices and technologies and connected systems to deliver care, as shown in the following diagram:

Figure 5: Care process reference model based on ISO 13490

Reference Architecture for Health – Core Capabilities

RA4H – as a Product/Service

Users of the reference architecture are planners, managers, and architects. They need to be able to deal with various aspects – the delivery of healthcare, use of technology, commercial viability, adherence to quality, regulatory compliance. They need to plan, establish, and maintain capabilities required in their healthcare organization.

For these users, we need to provide a formal and versioned specification that outlines the elements of the reference architecture, and how these elements relate to each other. In addition, this specification needs to provide guidance how to implement and use the reference architecture.

To make the reference architecture actionable asks for a reference implementation, which is a released model of the specification. Ideally, the authors of the reference architecture should make this reference implementation available for download. Let us assume the reference implementation is developed in a specific modeling tool. For users of different modeling tools, the reference implementation should also be available in a neutral industry-standard exchange format, such as XMI or MOF.

Figure 6: Reference Architecture for Health as a Product

This defines the Reference Architecture for Health as a Product: the specification, reference implementation, and exchange model.

Healthcare organizations can use this product for implementation and as a pathway for certification and accreditation.

Example

In many countries, healthcare organizations need to establish a Quality Management System. They want to use a blueprint to achieve compliance with ISO 9001 for healthcare. The reference architecture should provide the methodology, guidance, and critical-to-quality elements to support hospitals on their certification journey.

Figure 7: Standards Information Base with EN ISO 9001 for Health

In addition, the reference architecture should provide the following capabilities:

  • Define and describe all architecture elements in the specification, and provide the elements in the reference implementation and exchange format
  • Establish a governance framework, to manage, communicate and version changes to the specification and reference implementation
  • Ensure that users from various backgrounds and levels of maturity – from hi-tech, to low-tech – can use the specification and reference implementation
  • Provide federation capabilities, via integration profiles or similar, for organizations that team up in a partner network
  • Reference and relate to regulations, standards, and best-practices, such as ISO 9001 for Health, HL7 FHIR, BPM+ for Health, or guidelines on cybersecurity (NIST, MDCG, etc.)

Specification

The specification is the document that defines all elements of the reference architecture, and how they relate to each other. It provides guidance how to develop, implement and use the reference architecture, based on the following core capabilities:

  • Version-enabled, and written in a standard notation
  • Initial development, and maintenance of the specification to meet ISO Conformity Assessment Criteria
  • Provide guidance on use and implementation of the specification
  • Outline a lifecycle model how to implement, tailor, and use the Reference Architecture
  • Outline a path for certification, and/or accreditation
  • Provide a reference to standards, and/or proven practices used in the specification  

Reference implementation

Users, who take the reference implementation and apply it to their concrete business situation, need

  • An Element Catalog, where you can manage the elements provided by the product, and/or create user-specific elements
  • A Workspace, where you can relate the elements to each other to develop the implementation architecture,
  • A Standards Information Base, which lists all standards used by the Reference Architecture itself, and where the user can add and manage regulations and standards

In addition, the reference implementation should provide the following capabilities:

  • Implement a quality framework, and/or management system, based on standards such as ISO 9126, or ISO 9001 for healthcare
  • Support audits by reference/traceability of individual elements of the reference architecture to applicable quality standards
  • Compare and benchmark individual implementations of the reference architecture through unique identifiers, assigned to each element
  • Provide tags whether an element of the reference architecture is required, and whether the user can tailor the element
  • Enable localization and use of language-specific terms
  • Allow users to add references (e.g. industry standard, local regulation, etc.) to an element of the reference architecture, based on a reference identifier
  • Provide additional tags, so that users can add risk and quality-related aspects
  • Meet functional and non-functional requirements, such as adaptability, customizability, etc., via use of tagged values or similar.

The following example outlines a set of tagged value types our reference architecture should provide:

Figure 8: Example of element tags (i.e. custom attributes to use to tag an element of the architecture)
Figure 9: Example of an element, here Quality Goal, with tagged values

Exchange Format

Users who choose the exchange format want to be able to download the full reference implementation, and/or a subset of elements, such as the reference information model, the list of quality objectives, or the list of security controls. As with the reference implementation, all downloadable artifacts should be versioned accordingly.

Integrating Health Enterprises

To receive coherent and interconnected health services over time, and consistent with our health needs and preferences, requires care providers to team up. The reference architecture needs to provide integration profiles to ensure uninterrupted flow of health services, and supporting processes, products, and information, both within and across episodes of care, and to identify and remove bottlenecks and roadblocks along the way.

Integration profiles allow us to model various aspects of the person health journey, such as sequence and combination of health services and associated care processes, use of technologies, or aspect related to quality and applicable regulations.

Figure 10: Integration Profile Conceptual Model

Example:

The following screenshot shows the IHE International integration profile for Patient Administration Management [PAM], with additional diagrams to model the flow of care, data, and products and medicine.

Figure 11: Example Integration Profile – Patient Administration Management (PAM) based on IHE

Architecting

Architecting the health enterprise and partner network in a meaningful way must reflect the nature and way of working in healthcare:

Plan where you want to be and how to get there. Build, deliver, operate and continuously improve capabilities accordingly. Ensure to manage risks and apply change control to every element (service, process, resource, technology, etc.) in your organization and partner network over its lifetime.

Figure 12: ISO 9001 for healthcare and the Plan-Do-Check-Act Cycle

The reference architecture for health needs to provide a workspace, so that users can traverse the value streams from Strategy to Plan, Build to Deliver, and Operate to Evolve.

Figure 13: Reference Architecture for Health – Workspace

Further, the reference architecture needs to provide clear guidance on the required input, resources, activities, and expected results in every phase of the architecture development.

Example:

The first phase under ‘Strategy to Plan’ value stream is the identification of an organization’s vision, mission, and goals, as well as its main actors and affected interesting parties. The following screenshot outlines the how-to develop the required work results in phase ‘Vision, Mission, and Goals’.

Figure 14: Example – Guidance how to determine Vision, Mission, and Goals

Strategy to Plan

Strategy to plan helps you identify the capabilities you need to establish in your organization and partner network. At the most abstract level, you want to understand and plan for delivery of health services, and supporting services and products to meet demand.

Therefore, the reference architecture needs to provide a structured way to assist users understand what kind of services and associated capabilities they need to provide, the capacity required to meet demand, and the affected health services domains. It also needs to enable the user to model how services and products relate to a single customer journey, and patient population.

Build to Deliver

Build & Deliver is where you build the Capabilities required by your organization and partner network.

For this value stream, the reference architecture needs to provide adequate change and transformation management capabilities to manage requirements, design and develop elements, control external resources, and verify and release elements to production.

Operate to Evolve

In the Operate & Evolve section, you run and continuously improve your business and partner network.

For this value stream, the reference architecture needs to provide capabilities to define and manage operational elements, associated business measures, and Key Performance Indicators, analyze business performance and conduct external and internal audits, and actions to evolve and perform corrective and preventive actions for continuous improvement.

Architecture

Users of the reference architecture need an Element Catalog, where they can access and manage all elements in a user-friendly way, whether initially provided by the reference architecture, or created during an implementation. To that effect, the reference architecture may utilize a framework, such as Archimate, as shown in the following example:

Figure 15: Example of Element Catalog based on Archimate

For important aspects, the reference architecture should provide elements out-of-the box. The following example shows an Element Catalog that comes populated with Quality Goals based on ISO 9001 for healthcare. Note that you can establish and maintain your own elements in the Catalog.

Figure 16: Element Catalog with pre-defined Goals

Standards

Compliance to standards and industry best practices are important value drivers for your health organization and partner network. The Standards Information Base (SIB) is the place where you capture industry standards and best-practices.

To help use standards and a common vocabulary across the healthcare organization and its partner network, the reference architecture should provide a structured Standards Information Base with pre-defined content. The following example shows the integration of the ISO 13485 standard for Medical Device Manufacturer into the SIB:

Figure 17: Standards Information Base – Example of pre-configured content

Where an element of the reference architecture is based on a standard, the mapping should be visible to the user.

Example: The reference architecture provides healthcare organizations a pathway to certification and accreditation. Therefore, the relevant sections and elements of the reference architecture should map/trace to the elements of the corresponding standard, as shown below with the example of Vision, Mission, Goals, and how they map to elements of ISO 9001 for health.

Figure 18: Standards Information Base – Example of SIB to RA4H mapping

About the author

Oliver Matthias Kipf is a Process and Solution Architect and certified Master Architect; He provides thought leadership, innovation and architecture expertise in healthcare. You can contact him at oliver_kipf@hotmail.com.

References

European Union, 2017: Regulation (EU) 2017/745 on medical devices: https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32017R0745

European Union, 2016: Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data; https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&from=EN

European Standard, 2017: NEN-EN 15224:2017 Quality Management Systems – EN ISO 9001: 2015 for Healthcare

Future Care Finland: P4 medicine and healthcare emphasizes predictive, preventive, personalized, and participatory healthcare instead of reactive disease care. https://futurecarefinland.fi/en/p4-healthcare/

HITRUST, 2016: Healthcare Sector Cybersecurity Framework Implementation Guide. February 2016.

ISO/IEC/IEEE 42010, 2011: Systems and software engineering — Architecture description. 2011-12-01.

ISO/IEC/IEEE 42020, 2019: Software, systems and enterprise — Architecture processes. First edition 2019-07

ISO/IEC/IEEE 42030, 2019: Software, systems and enterprise — Architecture evaluation framework. First edition 2019-07.

ISO, 2016: ISO 13485 Medical devices — Quality management systems — Requirements for regulatory purposes. Third edition 2016-03-01

ISO/IEC, 2020: ISO/IEC 17000 Conformity assessment – Vocabulary and general principles, Second edition 2020-05

ISO/IEC, 2009: ISO/IEC 17001 Conformity assessment – Guidance for drafting normative documents suitable for use of conformity assessment. First edition 2009-09-15

MDCG, 2019: MDCG 2019-16 Guidance on Cybersecurity for medical devices. https://ec.europa.eu/docsroom/documents/41863

IHE International: Integrating the Health Enterprise

NEN-EN-ISO, 2016: ISO 13940 Health informatics — System of concepts to support continuity of care

OECD, 2011: A System of Health Accounts; http://www.oecd.org/els/health-systems/a-system-of-health-accounts-2011-9789264270985-en.htm

Object Management Group (OMG), 2015: XML Metadata Interchange; https://www.omg.org/spec/XMI/2.5.1/PDF

SCOR: Supply Chain Operations Reference (SCOR) Model.

https://www.apics.org/apics-for-business/frameworks/scor

The Open Group: Welcome to the Archimate® 3.1 Specification, a Standard of The Open Group: https://pubs.opengroup.org/architecture/archimate3-doc/

The Open Group: THE TOGAF STANDARD, VERSION 9.2. https://publications.opengroup.org/c182?_ga=2.71570323.1251902770.1598437305-900111004.1591272250

United Nations: Disaster Risk Management. http://www.un-spider.org/risks-and-disasters

US National Library of Medicine: National Institutes of Health – Using the World Health Organization health system building blocks through survey of healthcare professionals to determine the performance of public healthcare facilities; https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5651704/

World Health Organization: National Health Planning Tools – Health System Building Blocks: https://extranet.who.int/nhptool/BuildingBlock.aspx

World Health Organization: Framework on integrated people-centred health services: https://www.who.int/servicedeliverysafety/areas/people-centred-care/en/

World Health Organization: Health Systems Strengthening Glossary: https://www.who.int/healthsystems/hss_glossary/en/index5.html

World Health Organization Europe, supported by The European Commission, 2011: Hospital emergency response checklist. An all-hazards tool for hospital administrators and emergency managers  

World Health Organization, 2009: Hospital preparedness checklist for pandemic influenza. Focus on pandemic (H1N1) 2009

Acknowledgements

The author likes to thank his colleagues at Philips and the team of The Open Group Healthcare Forum for their inspiration; and above all, his family for their great support.


[1] ISO IEC 42010: architecting
process of conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout a system’s life cycle

[2] ISO IEC 42010: architecture
(system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution

http://www.opengroup.org @theopengroup