"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":
This slide represents the first time the "SDC+FHIR" label was proposed 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)
<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?>
Enjoy walking through the various areas of our Hanging Gardens ... rest and contemplate ... be careful not to fall over the edge!
|Garden Area||Area Concept||Plant Selection|
|User Narratives / Use Cases / Requirements||Collection 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 / Frameworks||Implementation 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.|
<may be a null layer>
<IHE actors / roles / transactions / ...>
|Device / Health Software Specializations||Named 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 / IGs||IHE 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 ModSpecs||Device specializations as expressed in BICEPS constructs||<expressing Device Specializations using SDC/BICEPS constructs>|
|IEEE 11073-1070x PKP||SDC SOA "Participant" Key Purposes standards|
<expressing the key purposes (see KIP above) for PRACtical interoperability>
<conformance principles - ... explain linkage here>
|11073-10207 DIM & Service Model||SDC/BICEPS standard||BICEPS (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 & Protocol||Service Oriented Medical Device Clinical Environment standard||Provides architectural "glue" between the abstract SOA BICEPS model and the implementation specific communication standards such as MDPWS below.|
|11073-20702 - MDPWS||Medical Device Profile for Web Services||Profile 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 FHIR||FHIR Implementation Guides and Profiles specialized to support health device informatics||See Projects: FHIR for more detail.|
|HL7 FHIR||Fast 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.
|ISO/IEEE 11073 Nomenclature & DIM||Family 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 SES||Set 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>
<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:
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:
- Core connectivity (published as ISO/IEEE 11073 today);
- Key Purposes for why connectivity is needed - the intended functional contribution; and
- 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.
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.
 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!