The health informatics community seems to have a fondness for mythological metaphor. On December 4th at the HL7 Policy Conference, Chuck Jaffe announced the HL7 Argonaut Project as a new initiative to accelerate adoption of FHIR® and to address recommendations from the ONC’s JASON Task Force report (see my summary of the JASON report in a previous blog post). In Greek mythology, the Argonauts accompanied Jason in his quest for the Golden Fleece, aboard their ship Argo.

Back to modern day software development, I believe that the goal and promised outcomes of HL7’s Argonaut Project will transcend mythology and deliver useful standards, implementation guides, and productive collaboration for healthcare interoperability. The HL7 Argonaut Project is comprised of eleven organizations, including EHR giants Cerner and Epic, and influential providers Intermountain Healthcare and Mayo Clinic. I was also happy to see the SMART project at Boston Children’s Hospital included as one of the project contributors. Their SMART on FHIR open source project has been very helpful ground-breaking work that significantly reduced my learning curve while developing an iOS mobile app using FHIR data.

From the HL7 press release:

The purpose of the Argonaut Project is to rapidly develop a first-generation FHIR-based API and Core Data Services specification to enable expanded information sharing for electronic health records and other health information technology based on Internet standards and architectural patterns and styles. The project will accelerate current FHIR development efforts to provide practical and focused FHIR profiles and implementation guides to the industry by the spring of 2015.

John Halamka, HIT Standards Committee Co-Chair and CIO of Beth Israel Deaconess Medical Center, wrote a blog post about HL7’s Argonaut Project where he states that two FHIR profiles are needed. The first for discrete data elements specified by the Meaningful Use Common Data Set, and the second for document retrieval. His blog post includes a list of the Common Data Set from the 2014 EHR Certification Criteria. I expect that corresponding FHIR profiles will be part of the initial deliverables from HL7’s Argonaut Project.

On the first day after HL7’s announcement, I received several email queries about the relationship between HL7 Argonaut Project and the Health Services Platform Consortium (HSPC). Why wasn’t HSPC mentioned in the HL7 press release? Are these competing initiatives? I believe they are very complementary. And several of the organizations included in the HL7 Argonaut Project are also founding members of HSPC. HL7’s Argonaut Project is a product of the HL7 organization and will deliver standards and implementation guides, whereas HSPC will deliver a reference implementation and testbed for services that likely will be a superset of those from HL7 Argonaut. Quoting HSPC’s blog, “The Health Services Platform Consortium (HSPC) is a not-for-profit community of healthcare providers, software vendors, educational institutions and individual contributors striving to increase the quality and lower the cost of healthcare by:

  • Facilitating clinical application interoperability and data sharing by defining open, standards based (HL7 FHIR, SNOMED, LOINC, etc) specifications for enterprise clinical services and clinical applications.
  • Accelerating software development through adoption of standards and providing “sandbox” environments for testing, conformance evaluation and certification of software.
  • Supporting a marketplace or “App Store” for the distribution of interoperable, shareable clinical applications.”

The first HSPC deliverable will overlap, and hopefully include, the specifications from HL7’s Argonaut Project. However, the last two HSPC deliverables are unique and hold potential to significantly accelerate implementation and “lower the bar” for developers. Is this the Golden Fleece that we all seek for health informatics?

SNOMED CT is one of the foundational terminology systems used in electronic health record (EHR) systems, along with the LOINC and RxNorm terminologies. SNOMED CT contains over 300,000 concept terms and more than 1,300,000 relationship between those concepts. Thus, it is important to have effective tooling that enables modelers to browse, search, and visualize these ontological structures while applying them in the design of clinical information models. Binding SNOMED CT concepts to information model elements, and constraining coded values, is an integral requirement for the Clinical Information Modeling Initiative (CIMI).

Wikipedia contains a nice summary of the primary four components used in SNOMED CT structure:

  1. Concept Codes – numerical codes that identify clinical terms, primitive or defined, organized in hierarchies
  2. Descriptions – textual descriptions of Concept Codes
  3. Relationships – relationships between Concept Codes that have a related meaning
  4. Reference Sets – used to group Concepts or Descriptions into sets, including reference sets and cross-maps to other classifications and standards.

I have been working on new Eclipse-based tooling for integrating terminology with information modeling. This post provides a short summary, and a bunch of screenshots, for this tooling that uses IHTSDO RESTful services to read (but not modify) SNOMED CT terminology. I expect to have a test build available for download sometime in November. This post describes only the functionality for browsing and displaying details of SNOMED CT concepts within an Eclipse workbench.  I will write several follow-up posts about using this terminology browser as part of an integrated informatics development workbench to:

  • Bind concepts and value sets with UML clinical information models
  • Use terminology binding in UML models to display concept meaning within SNOMED CT
  • Generate FHIR ValueSet resources from SNOMED CT refsets
  • Generate domain-specific Java APIs for FHIR profiles, including value set bindings that are imported from SNOMED CT refsets

First, let’s start with the current IHTSDO web browser application for SNOMED CT. You can access and test this yourself at http://browser.ihtsdotools.org. A screenshot is included below (click the image for a larger view) that shows the concept taxonomy and details for the clinical finding, “Bleeding from nose”.

IHTSDO WebBrowser

IHTSDO has defined an initial set of RESTful services for accessing the terminology database; these same services are used by the web browser application. For example, to retrieve a JSON representation for the concept “Bleeding from nose”, click on this link:

http://browser.ihtsdotools.org:3000/snomed/en-edition/v20140731/concepts/249366005

These RESTful services are used to retrieve all terminology content for presentation in an Eclipse workbench. The following screenshot illustrates the Eclipse tooling interface that I have implemented:
Eclipse Terminology Workbench

A primary goal of my design is to provide an interface that follows recommended Eclipse presentation and use. An Eclipse view with the terminology concept taxonomy is included on the left (but you can drag this view to other positions, based on your personal preferences or task workflow), and I use the shared Properties view with tabs that are displayed for the selected terminology concept. The following two screenshots show Descriptions and Relationships for the “Bleeding gums” concept selected in the taxonomy view. Later in this article I will describe the Refsets tab and the graphical diagram view.

Descriptions
Relationships-Stated

The Relationships tab includes a toggle button to display either the stated or the inferred relationships for a concept. Stated relationships are defined using the selected concept as their source, whereas inferred relationships include those inherited from parent concepts in the hierarchy. Inferred relationships for “On examination – bleeding gums” are shown below:
Relationships-Inferred

There is a basic search capability to find concepts in the Taxonomy view. Click on the flashlight icon in the Taxonomy toolbar, which opens a search dialog like that shown on the left below.  You can choose a top-level parent concept to limit search results, e.g. find only concepts with a description containing “systolic” and under the Clinical Finding hierarchy. The search results are displayed in a second dialog as shown below on the right. When you select one of these concepts and click OK, the Taxonomy view is expanded to show the selected concept.

SearchDialog   SearchResults

The graphic display utilizes an approach that has been a core capability of my hyperModel tooling for almost 15 years. I call them Dynagrams, because they enable a dynamic diagram layout that is created on-the-fly from an underlying model. My original use case was to display a diagram of the types and element relationships defined in a large XML Schema. I later adapted this for displaying UML models, OWL ontologies, and now for SNOMED CT terminology concepts. These diagrams use a notation based on the UML class diagram standard.

With the dynagram display, you can:

  • Click on any concept in the taxonomy and use the context menu to Show Dynagram.
  • Click on any concept or relationship type in the dynagram to see its detail in the Properties View.
  • Double-click on any dynagram concept to create a new dynagram from that point of view e.g., a new diagram for “Face structure”.
  • Right-click on a concept in the dynagram and choose Show Associations to include relationships from that concept.
    • This was done for “Bleeding from nose” in the dynagram shown in the first Eclipse screenshot. Relationships can also be shown for any other concept in the diagram.
  • Change “depth” of relationship traversal from the original concept.  By default, 3 relationships are included and nodes beyond that depth are shown collapsed with a blue color.

In the following dynagram (click for a larger view), I expanded the depth to 15 so that I include all parents up to the root SNOMED CT Concept.

Expanded Concept Dynagram

Finally, access to SNOMED CT reference sets (refset) is an important part of integration with information models. A refset defines a group of concepts based on some clinical criteria, and is often used to specify an enumerated “value set” of codes required in an interoperability standard such as CDA or FHIR. There are no clinical refsets included in the IHTSDO International Edition, but there are numerous useful refsets defined in the Australian extension. You can choose to view the Australian extension in the IHTSDO web browser application, where you can select the “Adverse reaction type reference set”, and then select the Members tab in the details view to see a list of 15 members in this refset. Two screenshots from the IHTSDO web browser application are included below.

IHTSDO-AU-WebBrowser  IHTSDO-AU-WebBrowser-Members

By switching to the Australian release in my Eclipse tooling, you can browse to the Australian reference sets in the Taxonomy view, as shown below:

Australian-Taxonomy

Select a reference set in the taxonomy, then select the Refsets tab in the Eclipse Properties view. There are two sub-tabs: Member Of and Members. The first lists any refsets that contain the selected concept (the selected concept is a Member Of these reference sets). As shown here, select the “Bleeding (finding)” concept and discover that it is included in five Australian reference sets.

Australian-RefsetMemberships

When you select one of the reference set concepts in the Taxonomy, the Members sub-tab displays an enumerated list of concept members. For the Australian release, select “Specimen collection procedure reference set” and see the Members as shown below.

Australian-RefsetMembers

 

The ONC’s JASON Task Force (JTF) delivered its final report on October 15th to a joint meeting of the Health IT Standards Committee and Health IT Policy Committee. The task force recommendations are published in presentation slides and in a detailed report. The original JASON report completed in November 2013, titled “A Robust Health Data Infrastructure”, has been criticized as being neither robust nor realistic. The ONC task force was convened to analyze and respond to the JASON report.

The task force report addresses limitations and includes broad ranging policy recommendations for improving health data interoperability in the U.S. It also includes updated system architecture recommendations on how to achieve interoperability. Not surprisingly, HL7’s FHIR draft standard plays a central role in these recommendations. For other viewpoints the ONC meeting and these recommendations, see two articles published by Healthcare IT News:

Keith Boone also blogged about the JTF report, where he concludes:

Right now, HL7, CDISC, DICOM, IEEE, OpenEHR, and IHE have all rallied around FHIR as the way forward for a variety of different use cases (see for example IHE’s Mobile Access to Health Documents effort). Major vendors, national programs, industry consortia, and other organizations have publicly announced support for FHIR in products, programs and services currently being developed. This kind of thing is nearly unprecedented in health care. To come upon if after the fact and try to impose some US federally crafted plan to make it happen is just a bit ambitious don’t you think?

A JTF recommendation that is most relevant to my current work is to create a “Public API” for EHR system interoperability. The JTF presentation outlines the general rationale for a Public API, but the report gets more specific on recommending FHIR as the best candidate standard for defining this API:

FHIR as the Public API Technical Standard:

  1. Current exchange APIs (such as XDS/XCA) allow access to structured and unstructured documents, but do not allow direct access to individual data elements. There is currently no widely accepted healthcare industry API that provides discrete data-level access to EHR data.
  2. A healthcare Public API needs to enable access to both clinical documents (e.g., referral summary, discharge summary, etc) and discrete data elements (e.g., medications, labs, problems, etc)
  3. The JTF believes that HL7 FHIR (accompanied by FHIR profiles) is currently the best candidate API approach to data-level and document-level access to healthcare data. (See the Technical Appendix for details.)

The JTF report includes this diagram in its Technical Appendix. It is based on the original proposed JASON architecture diagram, with updates and additions. The blue boxes are additions, and the red text/boxes represent recommended updates based on current standards and practice. FHIR, not even mentioned in the original report, plays a significant role in the updated recommendations.
JTF Public API

I am (finally) ramping up blogging activity to describe my current R&D on:

  • Designing FHIR profiles in UML
  • Binding terminology to information models
  • A UML profile for ISO 11179-3 Metadata Registry (used for binding terminology)
  • Healthcare Services Platform Consortium (HSPC)
  • Clinical Information Modeling Initiative (CIMI)
  • Model Driven Health Tools (MDHT) as a platform for design and deployment
  • Other topics related to implementing these tools in the Eclipse platform

You can import one or more XML Schema files into a UML model, where XSD structures are mapped to UML packages, classes, data types, and associations. Large sets of interrelated schemas may be imported (e.g. several hundred XSD files) and xsd:import or xsd:include statements will be processed and imported into UML packages. The UML profile for XML Schema is applied to the new UML model for representing additional metadata, e.g. the schema target namespace URI.

  1. If you are starting hyperModel with a new empty Eclipse workspace, then you must create a new project before starting the XSD import wizard. This project, or a folder within it, will hold the imported UML model. You may also add the XSD source files into a folder in this project. To create a new project, choose: File > New > Project, then choose General > Project. To create a new folder wihin a project, right-click on the Project and choose: New > Folder.
  2. Start the wizard using: File > Import XSD…
  3. Select the XSD file(s) to import. If your schemas are included in an Eclipse workspace project, then select that folder before starting the wizard and all contained schemas will be automatically added to the import list. See screenshot below. If you choose the option to Add Folder…, then all XSD files included in that folder and its child folders will be added to the list.
  4. Select the Root package that specifies which file folder is mapped to the root UML model package. Large sets of XSD files are often organized in a file folder hierarchy, and it is usually desirable to reflect that same folder hierarchy in the UML model packages. To do this, you must tell the wizard which file folder should be the root of the UML package hierarchy (usually the most specific file folder that contains all schemas and folders to be imported).
  5. You may optionally import the schemas into an existing UML model. When you are new to using this wizard, leave the Model selection empty and allow the wizard to create a new model.
  6. On the second page, select a project folder where the new model will be created and enter the new model file name, e.g. FpML-4-2.uml
  7. On the third page, leave the default values for Model Object and XML Encoding, unless you know that an alternative XML Encoding is required for your schema character set.
  8. On the fourth page, choose import options that may affect the resulting UML model element naming. See the second screenshot below.
    • Global elements: leave this unselected unless you know that your schemas use all global elements for content. Currently, this does not affect the UML model import structure, but simply sets a profile stereotype property.
    • complexType suffix: If all of your schema complexType names use a common suffix (e.g. “Type”) then enter it here and that suffix will be removed from complexType names when mapped to UML class names. That suffix is retained in a model stereotype and will be re-appended to class names when generating XML Schemas from this model.
XML Schema import options that guide mapping to UML:

hyperModel provides several different ways to visualize UML models. To get started, use the hyperModel perspective in Eclipse for quick access to all of these features, although these views are available in any Eclipse perspective.

Menu: Window > Open Perspective > hyperModel


Project Explorer

To open a UML model, double-click on a .uml file in the Project Explorer view, or right-click and select Open With > UML Table editor. This will open the UML Table Editor as the default editor and will also expand a tree navigator of the model content within the Project Explorer.

The Properties view displays editable detail for selections in most UML editors and views:


Dynamic Class Diagrams (dynagrams)

To open a dynamic class diagram created from any model classes:

  • select one or more classes in the Project Explorer, then right-click and choose Open With > Class Dynagram

In this example screenshot, two classes were selected from the FpML model: Bond and Cash. A UML class diagram will be created on-the-fly using the selected classes as the root nodes and expanding the related classes via associations for the (configurable) number of steps away from these root classes.

You can drill-down into a new class diagram created from one class within this diagram. Just double-click on one of the class names in this diagram (you must click on the class name, not elsewhere in the class box). Right-click on the class name for a context menu of other actions and alternative views, as shown in this screenshot.

Use the window toolbar for other dynagram commands that zoom in/out or change the depth/breadth of diagram expansion.

Note that the identical dynagram functionality is available if you install hyperModel plugins into IBM’s Rational Software Architect®. Just use RSA’s Project Explorer view to open the dynagram for selected packages or classes.


Class Diagram Editor

We are working on integrating Eclipse.org Papyrus class diagram editor with hyperModel. Watch this site’s blog (home page) for status and announcements!


UML Table Editor

The UML Table Editor provides an excellent tool for viewing and editing class properties, or for adding new model content. When creating models that are planned for generation to XSD, you can quickly reorder the properties using drag/drop to design the sequence of XSD complexType element content. The table editor is also an intuitive overview of message content.

To open this editor:

  • Select one or more packages or classes in the Project Explorer
  • Right-click, and choose Open With > UML Table
  • You can also open this editor for the selected class in the class dynagram by using its context menu.

Note that the identical table editor is available if you install hyperModel plugins into IBM’s Rational Software Architect®. Just use RSA’s Project Explorer view, and choose Open With > UML Table for the selected package(s) or class(es).


Message Hierarchy View

When working on UML models that are planned for generation to XSD, many modelers find it helpful to visualize the ultimate structure of XML messages using a hierarchical tree of XML elements and attributes. The hyperModel Message Hierarchly View allows you to quickly see the message structure while working directly on the UML information model.

To open this view

  • select one class in the Project Explorer, right-click, and choose Open With > Message Hierarchy
  • You can also open this view from the selected class in the class dynagram by using its context menu.

Enter your email address to receive notifications of new posts.

Archives