Gemini Public
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata

Traditionally, standards crafting and utilization have taken the same document-centric approach as the technical experts utilize in their organization's development / implementation processes, methods and tooling.  In the case of IHE and HL7, this largely remains the case, where standards projects develop document-based specifications and related collateral such as test scripts, terminology value set tables, etc.  Maintaining these artifacts and keeping them in "sync" is a challenge within a single organization - and a Sisyphean proposition in the resource-challenged inter-organizational (often "Frenemies") context of standards development.  In recent years, though, advancement in tool technologies, information model representation, and engineering methodologies has opened the door to transition from a document-centric to a model-centric "single source of truth" approach.   This is especially the case for large complex projects, and those that are safety critical - such as MedTech / medical device development, where enabling simulation, ensuring requirements traceability and coverage, "getting it right the first time" ... are all "no brainer" necessities.

In the case of health informatics standards and specifications – those supporting the health / medical technology industry – the question should be asked:  If this is the engineering approach being taken for product development inside these companies, should not the standards they utilize be formalized in the same way and seamlesslly integratable into their internal product development tool chains?  Is this "boiling the ocean" or given technology advances, an achievable objective?

Postulation:  Moving the Gemini SES MDI program from document-centric to model-centric for MedTech solutions is both feasible and advisable 

To answer these questions, a pilot project has been initiated in the joint IHE-HL7 Gemini SES MDI SDPi+FHIR project to determine if Model-Based Systems Engineering (MBSE methodology) & Systems Modeling Language (OMG SysML, a profile/extension of UML) can be used to specify a single source of truth "model" for the Gemini SES MDI specifications, starting with the SDPi profiles and then the MDIRA profile.  For any pilot, you have to make some choices and put some stakes in the ground - realizing that the longevity of those decisions may change after completion of the pilot - even during its execution!  For this effort, MBSE (methodology), SysML (language) & 3DS Cameo Systems Modeler (tool) were chosen because they were the technologies being used by all those interested in participating in the pilot project!

NOTE:  See the resources section below for additional tools + the Tooling Considerations section for more complete perspectives

Ultimately, the pilot project will answer the question of whether MBSE/SysML can provide the core "source of truth" for the RI-TF-CA initiative within the Gemini SES MDI program and usher in a new era of standardization for health informatics ... that's all!  (smile) 

This page will anchor much of the discussion and decisions and approaches being taken in applying MBSE/SysML to  Gemini SDPi+FHIR profile development.

Enjoy!


What Lays Below ...

 


Document-centric to Model-centric - A Necessary Transition for MedTech Standardization 

A central premise of MBSE is to establish a single source-of-truth from which all stakeholders can craft the view-point-specific information they need.  For example, stakeholders who are looking at interoperability specification requirements for a specific profile actor or transaction, can generate model-based reports of precisely that information - tailored for their needs.  Those who are focused on conformity testing can look at the same information but generate content specific for their uses.  The following "pitch" presentation captures the fundamental premise of this initiative and motivation for the pilot project:

NOTE:  See Unity MBSE Webinar reference below for the complete set of slides and recording that are included in this presentation

Gemini MBSE SysML Pitch - Unity Inspired - 2021-04-09 (10.5 minutes; YouTube)

And slide #6 from the above presentation paints a very clear picture of the value proposition:

Understandably, standards organizations like IHE, IEEE, HL7 and many others develop collections of specification artifacts (documents - primarily, spreadsheets, diagrams, etc.) as are used by the development departments of their organizations.  In the case of interoperability, though, that is based on multi-organizational INTERPRETATION of these specification artifacts – where there is no clear single source of truth – divergent implementations result and realizing interoperability requires significant – inefficient and unnecessary – testing and re-engineering and re-testing etc.  Some have stated that when 

Why is this such a challenge and need for the MedTech industry?  

<Unique requirements of the regulated MedTech industry - regardless of the regulatory processes / requirements>

(hint:  complexity!) + other rationale from webinar screen shots today at Neurase 

Simulation, process quality, efficiency, regulatory ...


How hard will this be?  Haven't many tried in the past and failed?!  

******************

  1. Value propositions (purpose) of doing MBSE / SysML for SES MDI specifications 
    1. lower adoption barrier / incl. product development $$$
    2. pathway to simulation (virtual V&V)
    3. higher quality from a single shared source of truth (not having to interpret spec provisions)
    4. Automated CA, including acceptance testing, test scripts, etc.
    5. ...
  1. Strategy for artifacts and "documents" (incl. TF spec Word documents / HTML documents) generated from the system model repository - link to section below or move to section below


Regulatory Connections 


  1. Regulatory Considerations
    1. SES RM standards requirements 
    2. RM RCM for a given standard 
    3. Simulation as source of evidence 
    4. Link to FDA ASCA ... Model => Test Cases => Requirements coverage & test instance valuation
    5. Link to SES MDI CA "regulatory submission ready" w/ package that includes model-based specifications of component standards 

See list from Neurase webinar on this topic

  1. Link to CA:  Real-Time Certification topic (smile)  


MBSE Rationale & Fundamentals

Rationale ...

MBSE vs. MDA (ISO 10746) & RUP ... 

vs. TDD / ATDD / BDD etc.  Agile methods 

<provide high level intro to concepts for those just wanting to get a clue about the methodology>

<start with Unity RALP (question) framework?>

<INCOSE references>

<MBSE:  Method + Language + Tooling>

<link to resources below>


SysML Rationale & Fundamentals

<goal:  interoperability specifications language>

<provide general intro to core components of SysML>
<indicate that this is a strict profile of UML>

<SysML 2.0? vs. XMI>

  1. OMG SysML 2.0 (and OMG Systems Modeling Language 1.4 was ratified by ISO as ISO 19514:2017) 
    1. Support for SysML 1.6 (latest?)
    2. Support for UML Diagram Interchange (DI) standard in tools like Magicdraw?

<link to resource below>


Tool Chain Considerations 

<Why cameo? Others?>

<cautionary tale (???) of Sparx / Enterprise Architect AND HL7>

<Enter:  SysML 2.0 and tool independence>

Use of git hub

Integration with Word specification (see TF using V2+ tooling)

  1. Strategy for ensuring that adopters / users - like med tech product developers - can leverage the SDPi / MDIRA system models to integrate with their internal tool chains to do code generation through to testing w/ traceability & coverage

<RI Pilot and use of RM Tooling & ReqIFStudio, DOORS etc. >


Applying MBSE/SysML to SDPi+FHIR Specification Models


<Models of Models:  SDPi Profiles leverage many component standards>

Hierarchy of models:  

- One per standard?

- One per profile

- One base spec to profile to profile-on-profile to device specializations to ensembles 


TF in SysML Mappings / Approach

> Profiles in SysML Mappings / Approach

<Achieving RI using SysML/Requirements Modeling => ReqIF ... - link to the ReqIF pilot as well>

Requirements Interoperability (RI) via Requirements Modeling / ReqIF ...

  1. Can you use a SysML RM to not only capture those of a given specification / standard but also to integrate BETWEEN modeled standards?

<SysML Model as a standard - how's that going to work?  Reviewing / balloting / viewing / managing etc.>

  1. Mappings / constraints from SysML as applied to IHE TF constructs & underlying standards


Designing the Hanging Gardens Model Library

<goal:  establish a library of models that can be used to compose additional specifications and used to drive simulation, CA etc.>

OR separate subsection?  > Tour of Models:  MDIRA (very early example model not representative of the current MDIRA specification (1.0 and beyond)) + BICEPS infusion pump SysML model - how it was done ... big picture not the specific IP model.  Include validation via the BICEPS XSD 

  1. Strategy for sharing system models between organizations / contributors and tool chains 


Model Library Collections

An initial collection is building in the sdpi-fhir github repository:

  1. BICEPS Infusion Pump Model (Stefan Schlichting)
    1. BICEPS Infusion Pump 20210511 Export.zip 
    2. Model Tour by Stefan 2021.06.03 (YouTube; 39 minutes) 
  2. JHU/APL MDIRA (early example only) Model (Steven Griffiths)
  3. ...


Topics of Interest – Discussion to Guidance

<capture key discussion topics that come up, the resulting discussion and conclusion => guidance / practice>

  1. Heuristics on usage of a spreadsheet (and column definitions) and graphical representations / views
  2. How best to capture requirements "optionality" & "conditionality"?
  3. Integration of "assurance cases" on a model basis (how to represent) + composable in a model library sense


Pilot Project Management

<action plan>

<status update>

<discussion notes  or links to notes>


References & Resources 

The following items provided helpful background and support for this pilot project: 

NOTE:  Inclusion in this list is not an endorsement for any particular organization or individual ... just ... proven helpful!  

  1. MBSE General Information 
    1. <incose link>
    2. Presentation:  MBSE in a Slide (Jon Holt / Swiss Society of Systems Engineering)
  2. OMG SysML Information 
  3. Tooling Resources
    1. <open tools>
    2. <3DS / Cameo Systems Modeler etc.>
    3. <Sparx/Enterprise Architect>
    4. <IBM Rational Rose>
    5. ...
  4. Educational Resources 
  5. Gemini SES MDI Project Links
  6. ...


OMG Webinar 2017.11.10 https://www.brighttalk.com/webcast/12231/270815 

https://mbse4u.com/2020/12/21/sysml-v2-release-whats-inside/

You can find a good description of what’s in SysML 2 here: 
https://mbse4u.com/2018/11/13/next-generation-modeling-part-0-sysml-v2-and-sysml-api-services/ 


1 Comment

  1. John Rhoads

    What a fine thing it would be if all our ontologies / models could be accessible to everyone who is interested and has something to say about them. Modeling tool friction from poor interoperability of file formats and so forth wastes a lot of everybody's time. And hacky proprietary documentation formats like the appalling Microsoft Word may even be more productivity-killing. Let's work towards a cleaner kind of information flow in the aid of better standards.