Page tree
Skip to end of metadata
Go to start of metadata

"Hanging Gardens of Babylon" 

Pictures are wonderful things - some say, "if you cannot draw it, you cannot build it".  And in the areas of device interoperability, conceptual models and frameworks abound, having built up sometimes over decades of work by different (and sometimes the same) groups around the world.  In the case of SDPi+FHIR the question is how to craft a clear "picture" for the work being conceived, utilizing this rich history but at the same time capturing new perspectives and vision for the future.

And every picture needs a good name:  

"Cathedral" Model (MDI) is painted by the ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards community

"Temple" Model (SES) is painted by the ISO/IEC JWG7 standards community

Question:  What about SDPi+FHIR?   What picture and analogy would be ... inspiring?

Answer:  The Hanging Gardens of Babylon, of course!


Source:  Maarten van Heemskerck (Public Domain)

NOTE:   Tower of Babel is in the background ... semantic interoperability anyone?!


With this picture in mind, the following sections provide:


Finally, note that "gardens" are full of growing, constantly changing beautiful life - expect some cultivating, weeding, pruning, re-planting ... along the way!


What Lays Below ...

"Hanging Gardens" SES MDI Model - Gemini SDPi+FHIR Standards Coordination Model


Overview & Origins

The gardens model had its beginnings in the "Cathedral" Model below, since as illustrated above, the ISO/IEEE 11073 SDC family of standards provide the primary medical device interoperability (MDI) section of the garden.  In addition to the obvious common elements brought from one to the other, effort was made to utilize the color scheme as well for new but related subject areas (e.g., shades of green for the SES garden areas).

Though the Cathedral captured one part of the picture - namely the SDC standards family - another major aspect needed to be integrated:

SDPi+FHIR also factors ...

Additional Subject Areas

Additional Standards / Standards Families

Across multiple organizations and programs!

With that in mind, another source of inspiration for the garden model that incorporates these additional perspectives is a slide from the HIMSS'20 Digital presentation by Cooper / Klotz, "Secure and Safe Medical Device Interoperability in Acute Care":


Source:  Cooper / Klots HIMSS'20 Presentation

This slide represents the first time the "SDC+FHIR" label was proposed[1] with the Cathedral shown at the left, but then adding subject areas (e.g., top level "Applications" narratives & use cases), standards families (e.g., HL7 FHIR), and organizations (e.g., Johns Hopkins University / Applied Physics Lab - JHU/APL).   Additionally, it built on the IHE SDPi Compendium of Use Cases document and showed the flow of requirements from the narratives level, through each layer to the interface level.   And finally, it recognized the notion that the concept of "device" gets fuzzier each day, and especially when considering the various organizations, standards and focus-areas contained within this layers model.  (See the related Gemini "What is a 'device'?" white paper for more discussion)

Layers Rationale 

<repeat"useful but not perfect">

<mix of logical specification groups, various stakeholders, specifications themselves, subject areas>

<Layers that go "all the way" across ... those that are only partially covered">

<requirements in ... added ... required below>

<ReqIF model ... layer specific?>

Garden Tour

Enjoy walking through the various areas of our Hanging Gardens ... rest and contemplate ... be careful not to fall over the edge!


Garden AreaArea ConceptPlant Selection
User Narratives / Use Cases / RequirementsCollection of real-world challenges and needs stories that ultimately determine whether an SDPi+FHIR solution meets expectations.After decades of work in the area of MDI, there is a wealth of stories and use cases to understand the problems and requirements to be addressed via interoperable technologies.  See Narratives & Use Cases for more background and extensive examples.  For SDPi+FHIR, the intent is to capture a formal computable representation of use case requirements that can then be mapped through the subsequent layers below to ensure that they are traceable to the final product interface.  See Tools & Conformity Assessment for more on this subject.
Gemini SDS MDI (group)

This set of layers generally comprise the specification / standardization focus of the Gemini SDPi+FHIR program.  

<why does the dotted line go through RA below?>

<why not SDPi+FHIR group?>

<profiling vs. core standards (below)>

<note these layers go all the way to the right edge> - tech agnostic

Reference Architectures / FrameworksImplementation technology agnostic constructs that provide a set of constructs that help decouple the problem space (top layer) with the increasingly specific solution space layers below.

<MDIRA/ICE>

<may be a null layer>

<IHE actors / roles / transactions / ...>

Device / Health Software SpecializationsNamed collections or "bundles" of sensor, actuator and intelligence that are often found in 

<rationale for named "specializations"?>

<what is there today j- value sets ...>

<what will comprise this layer>

<why is this ABOVE Gemini SDPi+FHIR?>

<relationship to -1072X below?>

Key Interoperability Purposes (PRACtical KIP)Clear statement of the intended purposes for which a communications interface is provisioned in an interoperable product, along with the resulting SES requirements

<PRACtical is a forward-look at the PKP areas of:  Plug-and-play connectivity, and medical Reporting, Alerting & (external) Controlling>

<relationship to -1070x below>

<why a full length layer?>

See the Paper: SES MDI white paper for additional perspective.

SDPi+FHIR Profiles / IGsIHE SDPi profiles and HL7 FHIR Implementation Guides that support the requirements of the layers above.

<explain IHE profiles & FHIR IGs vs. FHIR profiles, etc>

<concept of "profiling">

See the related IHE & FHIR profiles Projects: SDPi discussion.

ISO / IEEE 11073 SDC (group)

Integrated family of Service-oriented Device Connectivity standards 

<family ... integrated ... why a contained layer>

<reference the Cathedral model ... below>

<SOA architecture to WS-* at the bottom ... as the #1 option>

IEEE 11073-1072x to -10799 ModSpecsDevice specializations as expressed in BICEPS constructs<expressing Device Specializations using SDC/BICEPS constructs>
IEEE 11073-1070x PKPSDC SOA "Participant" Key Purposes standards

<expressing the key purposes (see KIP above) for PRACtical interoperability> 

<conformance principles - ... explain linkage here>

11073-10207 DIM & Service ModelSDC/BICEPS standardBICEPS (Basic Integrated Clinical Environment Protocol Specification) - abstract (non-implementation technology specific) constructs, leveraging the IEEE 11073 nomenclature and domain information model, but updated and adapted for SOA (Service Oriented Architecture) architecture.
11073-20701 - Architecture & ProtocolService Oriented Medical Device Clinical Environment standardProvides architectural "glue" between the abstract SOA BICEPS model and the implementation specific communication standards such as MDPWS below.
11073-20702 - MDPWSMedical Device Profile for Web ServicesProfile supporting the requirements identified in the preceding layers using off-the-shelf WS-* capabilities, plus a few extensions to support unique needs of medical device communication (such as "safety critical" exchange.
-2070x - REST, IoT, DDS, ...Potential future "lower-layers "extensions

<none being proposed BUT if there is an identified market need ... these can be added as well>

<reference the MDP-DDS research paper ... DDS under -20701>

Physical Layers (Ethernet, Wi-Fi, BT, etc.)IP-based lower-layers technology
HL7 Devices on FHIRFHIR Implementation Guides and Profiles specialized to support health device informaticsSee Projects: FHIR for more detail.
HL7 FHIRFast Healthcare Interoperability Resources standard.

General  standards that primarily leverage RESTful technology to exchange and use information between health information systems.

See HL7.org/fhir for additional information.

(crosscutting verticals)
ISO/IEEE 11073 Nomenclature & DIMFamily of standards broadly used for semantic interoperability with health devices.

Nomenclature / terminology focusing on the semantic representation of concepts exchanged by health devices.

Domain Information Model (DIM) for representing device concepts in a standard abstract manner.

ISO/IEC JWG7 SESSet of standards used for establishing the safety, effectiveness & security of integrated health technology

<see model below>

<80001-1 / -2-x, 81001-1 / -2, 62304, 81001-1>


Affiliated Gardens

<links to where this model is used elsewhere in this project>


"Cathedral" MDI Model - IEEE 11073 SDC Standards Family

The ISO/IEEE 11073 Service-oriented Device Connectivity (SDC) standards for medical device interoperability (MDI) are depicted in the "Cathedral" Model:

Source:   ORNET.org SDC standards development programs


A general overview of the IEEE 11073 SDC family of standards is provided on this Wikipedia article.  

As seen in the Cathedral model above:

  • SDC comprises three groups of standards: 
    1. Core connectivity (published as ISO/IEEE 11073 today);
    2. Key Purposes for why connectivity is needed - the intended functional contribution; and
    3. Device Specializations, starting with High-frequency surgery devices
  • "Classic" ISO/IEEE 11073 semantic standards (here the nomenclature is leveraged) are normatively referenced throughout


"Temple" SES Model - ISO/IEC JWG7 Standards Family

The ISO/IEC JWG7 standards "conceptual" framework is illustrated in the "Temple" Model:


Source:   81001-1:2020 under Open Government License:  see https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/ 


The "temple" pediment introduces the SES acronym phrase: Health software and safe health IT systems - Safety, Effectiveness and Security (SES) across the life cycle, which has subsequently become a handy way of referencing not only the subject matter contained in the model but the work of JWG7 in general.

NOTE:  Joint Working Group 7 (JWG7) is a formal collaboration body between ISO/TC 215 and IEC/SC 62A.

SES Model - Genesis

This Temple model had its genesis after JWG7 published its first foundational standard IEC 80001-1:2010 on the application of risk management to the "right side" of the above model, which is focused on healthcare delivery organizations (HDO) as the primary stakeholder.  The question was how this particular subject area (risk management during implementation and use in a "go live" environment) integrated with the technology life cycle on the "left side" as well as balancing with other key areas such as quality management, security & privacy management, (hospital) safety management, etc.  It also recognized that the terms and definitions that are used in the various standards across this space, which were "overloaded" in the various normative standards that had specific application in this SES space.  For example, "implementation" has a fundamental different meaning if you are a technology designer / developer vs. an healthcare delivery organization integrating - "implementing" - technology from a wide set of vendors in a user operating environment.

SES are the three "key properties" that are identified in 80001-1:2010 as targets or objectives of the risk management activities.  These evolved over 2+ years of discussion by subject matter experts who came to consensus agreement that:

Safety is the #1 objective - safety of the patient, personnel, environment, etc.

Effectiveness includes all functional & non-functional requirements of a product - including interoperability

Security (System & Data) ensuring confidentiality, integrity and availability (CIA) as foundational to any product that communicates with other systems and health software applications.

Finally, it should be noted that they are listed in the above order to indicate priority:  though security is important (that's why it is on the list), the top priority ... higher than the capabilities provided by the product ... is ensuring safety of everyone and the environment of care.

NOTE:  The 80001-1:2010 standard is completing its 2nd edition revision, maintaining and building upon the above SES approach, but adding 10+ years of experience + factoring emerging technologies that will bring new SES risk management challenges.

SES Model - Left / Right Interoperability "Trust Gap" 

It is common to hear reference to the "left side" vs. "right side" of the temple model.  This refers to the life cycle with the left being focused on those life cycle activities for which the Accountable Manufacturers bear primary responsibility, and the right being focused on  life cycle activities for which the HDO bears primary responsibility.  This has become a useful differentiation in that most of the standards considered by JWG7 experts tend to focus on either the right side or the left side (mostly the left side), and very few explore the "Life cycle foundation" that ensures concept and process continuity from left to right.  This is specifically the subject matter of the emerging 81001-1 standard, as illustrated in the bottom "gray" boxes.  

A key focus of the original 80001-1:2010 standard though was to focus on the right side, but to ensure that left side HDO's implementing the standard had sufficient information and clear problem resolution paths to be able to ensure "safe health IT systems" and safe "health software".   One of the main drivers of the original 80001-1 standard was the fact that increasingly, regulated medical technology was being implemented / deployed using hospital-owned and managed IT infrastructure.  (note:  previously the medical device manufacturer had complete control of the "special purpose" infrastructure that was used to exchange information with their devices and systems.)    This emerging health I.T. world (in the early 2000's) was not equipped to grapple with how to establish confidence (trust) between all stakeholders (HDOs, technology developers, integrators, regulators ... clinicians!) that the mix of integrated - sometimes somewhat interoperable - technologies would perform as expected,  when needed - safely, effectively and securely..  Of course, lawyers got involved to ensure business risk (especially) was properly mitigated (e.g., in Service Level Agreements / contracts).  

Today - 10 years after the publication of 80001-1 - this Trust Gap situation is little better ... arguably even worse!

And though the publication of 80001-1 was highly anticipated and heralded, it remains little implemented - Why?  


Exploring "Why?" and how to navigate the "SES MDI Trust Gap" going forward in the 2020's is a core topic in the Paper: SES MDI white paper.  




[1] Note that the original "SDC+FHIR" was changed to "SDPi+FHIR" when it was realized that though the meaning of SDC is clear in the device informatics world, in the general health informatics world SDC = "Structured Data Capture" resulting in considerable confusion!