Background

What is the FHIM?

The FHIM is an information model of healthcare data.  An information model is needed to create Electronic Healthcare Records, (EHR), just like a blue print is needed to build a proper building.  To see the FHIM, first click on 'View the FHIM model'.   Then select the subject area desired. An area of healthcare is called a domain.  The model is organized into domains.  Each healthcare domain is modeled as a UML package.  Examples of domains would be allergies, surgery, or dentistry. The main diagram of the model shows all the domains. The domains are color coded based on their status. Green domains have been completed. Yellow domains are in progress, and red domains have not been changed from the original VHIM model (now the VIM).  VHIM stands for the VHA Health Information Model.  The VHIM was many years in the making and has over ten thousand hours of design work invested in it.  This is why it was chosen as a basis for the FHIM. 

For more information on class diagrams, see Wikipedia: Class Diagrams. Any UML tool can be used to work with the FHIM model.The website may take a while to load the pictures into the frames depending on your connection speed. The navigation menu is on the left. This web page is meant to mimic the display format of the software modeling tool used to create the model.  The modeling software draws the lines, boxes and labels on the diagrams based on the class diagrams.  The lines indicate the relationships between the classes.  There are several dozen categories of lines.   It may seem simple at first glance, but when you are modeling a complex process such as a surgery and the preparation and testing needed before hand, diagrams can get very involved if they are to accurately depict the real world events.  Maintaining the model diagrams is equally complex which is why the modeling software is needed.

What are the Goals of FHIM?

The FHIM project seeks to develop a common Logical Information Model or Computationally Independent Model (CIM), depending on what jargon one wishes to use, for use by the partner agencies. This model describes the information of importance to the agencies at a level of detail that is precise enough for business or clinical experts, but does not include implementation-platform specific details. For example, the FHIM might define a particular data element as a "string"; whereas an implementation model targeting an Oracle database could be derived from the FHIM in which that data element might be defined as a VARCHAR(20).

The primary purpose of the FHIM is to provide a basis for the Information Architecture aspect of the partner agencies' Enterprise Architecture. Information which is common among partner agencies is defined in the FHIM - agencies would extend the FHIM with agency-specific requirements. Initially, we are concentrating on those data that are required for information exchange, especially those defined by the Health IT Standards Panel (HITSP) and/or required to achieve Meaningful Use of EHR criteria.

The FHIM was initially populated by existing models provided by the partner agencies, including the VHA Health Information Model, the BRIDG model, Structured Product Label, Common Product Model, Integrated Case Safety Report, and the Public Health Information Model. The FHIM is expressed in Unified Modeling Language (UML), and is organized by "domains", which are semi-arbitrary groupings of related information. For example, the FHIM contains a Laboratory domain and a Pharmacy domain. The organization by domain also facilitates the management of the modeling efforts, as the work is broken into manageable parts. As each domain is analyzed, relevant content from SDO's such as HL7 are also studied. Among the goals of the project is that an implementation compliant with the FHIM would also be compliant to - or be easily mapped to - the appropriate industry standard. Since the members of the FHIM project are also active in the various SDOs, it is anticipated that any changes needed to the standards can be communicated to the SDO by team members.

One of the barriers to the uptake of healthcare industry standards is that there are multiple standards which sometimes overlap or have gaps between them. These standards are very different from one another, and several have been developed without the benefit of an over arching model to ensure consistency within the standards. A secondary goal of the FHIM project is to provide a single model that covers the concepts of the differing standards in such a way that the concepts could be mapped to the original standards. This effort could be used to "harmonize" the standards themselves through agency participation directly in the SDOs or in collaborative efforts such as the SDO Coordinating Organization (SCO).

The FHIM capitalizes on advanced use of Model Driven Architecture (MDA) techniques, which allows us to generate from the FHIM other models that are more suited for particular purposes. This model-to-model transformation is critical to the FHIM's success. The FHIM model is a Computationally Independent Model (CIM) expressed in the Unified Modeling Language (UML). This CIM can be transformed into a Platform Specific Model (PSM) through a transformation process. Often, some additional information is needed in order to inform the transformation. This information can be stored in a UML Profile. While it is commonly understood that a UML model can be converted to source code such as Java, we've discovered that one can target multiple platforms with a single model with a judicious use of UML Profiles. An important insight is that HL7 Version 3 or NIEM can be considered a "platform" for the purposes of artifact generation.

Another FHIMS initiative is the Federal Health Terminology Model project, which coordinates partner agencies' efforts to develop healthcare terminology models (i.e., new content), and to specify content that can be associated with the Information Model.  Just as the Post Office had to once upon a time decide whether Missouri was MI or Mississippi was MI, we must now decide which healthcare words and abbreviations to use.  The Terminology Model is closely related to the Information Model, as they are each describing the same real-world concepts from two different angles. The Information Modeling team will work very closely with the Terminology Modeling team to identify those concepts which should be enumerated in a value set, to define that value set, and to define the members of the value set.

What is an information model?

 "An information model is a set of metadata types that describe a tool, application, data structure, or information system. You can model a business process, for example, to describe the progression of an order as it moves from order entry to final invoicing. If you model a database application, your information model describes the tables and columns that are supported by the application. If your goal is to define an application for booksellers, your information model will include elements that describe books, authors, and publishers. Books, authors, and publishers are the kinds of data that a bookseller application would need to manipulate. 

Notice that these examples depict types of data rather than instances of data. The first example describes an order process, not the specific orders placed by a customer. Similarly, an information model for a database application describes tables, keys, constraints, and stored procedures, but not the actual data that these elements store and manipulate. In the same way, the information model for the bookseller application describes the concept of a book, but not data about individual books. As you can see, information models articulate things that are always two steps removed from end user instance data."  More Microsoft MSDN.

Entities, Acts, Roles, and Participations Explanation

When viewing the model, you will notice up to four different colors of boxes in the various diagrams.  If you cannot see a diagram when you click on a domain, look for the bar labeled "Diagrams" and click on the item in purple below it.  When inside the domain diagrams, the main color scheme is evident.   Green boxes represent entities.  An entity can be a device, an insurance company, a hospital or even a prescription drug. Yellow boxes represent a role someone is playing, such as patient, doctor or nurse.  Red boxes represent an act, such as an observation, requesting a lab test, or giving a flu shot. Blue boxes mean that an entity is participating in an act.