J P Systems, Inc.

J P Systems, Inc.

UML Modeling

J P Systems personnel have played key roles in the establishment of both the VHA Health Information Model (VHIM) and the Federal Health Information Model (FHIM) projects, and are currently actively engaged in various interagency initiatives, including the DOD/VA integrated Electronic Health Record (iEHR), the Federal Health Architecture (FHA), and the ONC Standards and Interoperability Framework.

J P Systems has provided expertise to the VHA Business Architecture Services Program in the areas of information modeling for VHA information domains and strategic initiatives. The project involved active participation in intradepartmental projects and interagency endeavors. The project developed guidelines not only for VHA business-level information modeling, but also contributed to developing processes integrating business information architecture activities and artifacts into VHA enterprise architecture and the integrated Electronic Health Record (iEHR) Joint Process.

JP Systems leads the modeling effort for the FHIMS.org model, which is a UML information model with over 40 healthcare domains. JP Systems' personnel developed current and future-state VHA information models for health care information domains such as pharmacy, immunizations, and laboratory. The future-state models represented joint DoD/VA models for the iEHR Project. Architecture best practices were applied to create information leveraging common information classes across domains as applicable. The future-state models also integrated content from healthcare interoperability standards and content from the Federal Health Information Model (FHIM).

The primary purpose of these efforts was to develop and publish logical business information models representing either the business content of VHA's existing information systems and processes or future-state information models of specific initiatives, such as iEHR clinical and administrative capabilities. These information models were developed using Unified Modeling Language (UML) class diagrams using integrated modeling tools. The UML class diagrams incorporated major business entity concepts, their attributes, and their associations, as well as business metadata. These efforts required conducting analysis of program documentation and subject matter expert interviews. Depending on the effort, the modeling efforts also included analysis and integration of content from health interoperability standards and collaboration with terminology experts to identify content necessary to support information exchange.

In addition, J P Systems' personnel were actively engaged in various Federal and interagency initiatives, including the Federal Health Architecture, various ONC activities, and various DOD/VA collaborations, including the VA/DOD Health Architecture Interagency Group (HAIG), and the iEHR. J P Systems' personnel lead federal terminology modeling efforts under the Federal Health Terminology Model Project.

J P Systems personnel helped define the Modeling Conformance Rules in UML for attributes. In UML 2, an “attribute” is any property of a class whose type may be a primitive data type (such as String), or reference to another complex class. HL7 models use the term “attribute” to mean those class properties that have an HL7 data type as their type, such as ST, II, CS, CE, etc. When we refer to attribute constraints in this guide, we are referring to this more limited interpretation of HL7 attributes inherited from the base CDA (and ultimately the HL7 Reference Information Model) classes.

UML Modeling Style Guide Manual

J P Systems helped write guideslines for the UML Modeling Style Guide Manual for clinical documents. This manual outlines the answers to oft heard questions about how the model corresponds to the data. One common question is on managing template classes.

  • Each CDA template is represented using one UML Class.
  • Each CDA template has exactly one template ID assigned, which serves to identify use of this template in a CDA document instance.
  • The template ID is defined in the class metadata, using a UML stereotype. All model relationships and constraints refer to the template class names, not their IDs. A template ID should never be used when specifying constraints or template relationships.
  • A “conforms to” rule, also called “implies”, is represented using a UML Generalization, i.e. a template class has another template or CDA type as its superclass.
    • Direct conformance: immediate parent
    • Indirect conformance: parent of a parent
  • Each CDA template class must conform to exactly one CDA base class, either as direct superclass or indirectly via a parent template. For example, a template conforms to CDA Section or Observation.
  • All conformance rules from all superclasses are inherited into each template.
    • A template class may redefine (or, replace) conformance rules inherited from superclass templates. Any class attribute having the same name as an attribute from a parent template redefines that inherited rule.”

Most CDA templates fall into three categories, with a small number of examples in the fourth category. The published implementation guides use these four categories as primary sections of the guide.


Header constraints on subclasses CDA Clinical Document


Subtypes of CDA Section

Clinical Statement

Subtypes include: Act, Observation, Encounter, Organizer, Supply, and others

Other Classes

Classes within CDA header, e.g. Patient

Classes derived from ActRelationship, or Participation

Validation Characteristics

Each conformance rule has the following characteristics:

  • Validation severity (a.k.a. “conformance verb”): SHALL, SHOULD, or MAY
  • One or more Rule ID(s):
    • Multiple rule IDs are present only when a single modeled constraint implements more than one rule from the source text of a specification. These are used infrequently. o Enter multiple IDs in the MDHT editor by separating IDs with a comma.
    • In MDHT proper>ties view, the derived Conformance Rule message is displayed as read‐only text
  • CDA profile stereotypes:
    • Validation

OMG UML specification

OMG Certified UML Professional™ Overview: OCUP is a rigorous, comprehensive, and fair test of a person’s knowledge of OMG’s specifications for unified modeling language. The worldwide UML Certification Program provides an objective measure of your UML 2.x Specification knowledge. OCUP Certification will benefit you by giving you an important documentation to present to employers and clients. It also benefits companies looking for skilled UML practitioners like you, by giving them a basis for making hiring and promotion decisions.

There are three levels of certification for the OMG UML specification. The three OCUP Exams include Fundamental, Intermediate and Advanced. Each Exam tests your knowledge of a different subset of the UML.


A member of a UML development team should have the knowledge and skills to acquire this certification.


A senior member or group leader of a UML development team should have the knowledge and skills to acquire this certification.


A Technical Manager of a UML development project should have the knowledge and skills to acquire this certification.

Each level has its own examination, testing progressively more complex concepts and usage of the UML 2.X Specification. All three exams cover the Superstructure; the Advanced exam also covers the Infrastructure. The maintenance updates that yield the point releases 2.1, 2.2, and the forthcoming 2.3 did not modify the language enough to affect examination coverage, so you will be well-prepared regardless of the point version you are familiar with.

More information on the Exams