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 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.