"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!

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!