# Presentation: 678789

## 239 Not Just Your Typical Building Blocks

- Bo Dagnall, HDR Architect, CDS Team Lead Matt Greene, RHIA, CCS

## HealtheVet Principles

- Distributed, networked collection of capabilities, aligned with business needs and encapsulated in services
- Consistency and governance of service interfaces (-> VDIM) and service payload/parameters (-> VHIM)
- Data is an Enterprise asset not owned by any one business unit application (-> HDR & ADR)

## Data in Modern Software

- The strategy used to be to define data at the database level only and then use loosely at the application level as parameters.
- Object-Oriented (OO) development changed the way data is used programmatically
- Procedural programming: data is used as parameters passed through business logic
- OO programming: everything is an object.
_**Data is materialized as data objects**_
- Every data structure becomes its own object with defined attributes and behavior

## Data in Modern Software

- Domain models:
- OO development necessitates that data be stringently modeled so that the data objects created accurately reflected the definitions, semantics and constraints that meet the business needs
- Modern OO applications have a domain model, which is a design pattern that creates a package of classes/objects that are the physical manifestation of the data model
- Domain models describe a system in terms of real world business entities such as "Patient", "Hospital", "Allergy"
- Domain models provide the benefit of separating business logic from data and by providing data with an object that can independently control behavior and provide state

## Data in Modern Software

- Enterprise development principles
- Reduce inter-service dependencies and network demand by moving from “fine-grained” data objects to “coarse-grained” data objects
- This requires defined payload structures
- Data is now used objectively and implemented in multiple layers
- Physical persistence – database level
- Run-time processing – the domain model level
- Parameter/payload structure and governance – the message level
- This approach requires an Enterprise information model that provides an enterprise standard for data definitions, semantics and constraints that can be used in all three layers

## Interoperability

- Semanticinteroperability

- Syntacticinteroperability

**in·ter·op·er·a·bil·i·ty**
- ability of a system...to use the parts or equipment of another system**	**Source: Merriam-Webster web site
**interoperability**
- ability of two or more systems or components to exchange information and to use the information that has been exchanged.	Source: IEEE Standard Computer Dictionary: A Compilation of  IEEE Standard Computer Glossaries, IEEE, 1990]

*Courtesy: Dr. Charlie Mead*

## Information is an Enterprise Asset

*Accessibility* of *quality* *computable* information enables an organization not only to function, but to manage its processes, rapidly adapt to change, and provide superior quality of service to its customers
- In the past organizations tried to enforce semantic interoperability by forcing all systems to use the same database structures, but this proved unworkable.
- Today, semantic interoperability is enforced by controlling the system interfaces and the payload from those interfaces
- Underlying database don’t need to be consistent to ensure interoperability, although there may be other benefits related to database maintenance, database splitting/merging and governance that still require consistency across databases.

## VHIM Basics

- The VHIM is the enterprise-wide information model
- The VHIM only models data that is important across multiple business applications within the enterprise system – HealtheVet “shareable” or “viewable” data
- The VHIM follows the information domain principle
- An information domain is grouping of data that represents a logical data division aligned with business uses of the data (e.g., lab, pharmacy, etc.)
- An information domain is pseudo-independent unit of data with inclusive semantics and integrity constraints
- A single clinical transaction is typically a subset of an information domain and follows the semantics and constraints defined within the information domain

## VHIM Basics

- The VHIM uses the Unified Modeling Language to model data
- UML class diagrams include constructs such as packages (domains), classes (data objects), attributes (data elements), data relationships (semantics constraints), data types (definition constraints), cardinality (required/optional constraints) as well as custom properties that can include other types of constraints (e.g., formats, valid ranges, permissible values, etc.)
- The VHIM uses class diagrams to provide a static view of the data without defining system or data behavior

## VHIM Basics

## VHIM Basics

- Note the cardinality: A vital sign ***must*** have ***one*** Hospital Location, and ***may*** have ***one*** Division

- Note that the ***domain*** model contains all elements for a subject area.  But not all are needed for each ***payload type***.  For instance, the home Appliance is only used by Home Telehealth

## VHIM Details

- How can one static data model meet all the implementation needs (database, domain model, payload structure)?
- Answer: Model transformations
- Computationally Independent Model (CIM) – conceptual model
- Platform Specific Model (PSM) – logic model
- Model implementation – physical model
- Model Driven Architecture (MDA) and UML software provide tools for automating model transformations

## VHIM Details

**Payload**

**Java Application**

**Database**

**VHIM CIM**

**Database PSM**

**Java Object PSM**

**Payload PSM**

**Conceptual to Logical: Model to Model Transformations**

**Logical to Physical: Model to Implementation Transformations**

## VHIM Details – CIM to PSM Example

- The VHIM model is a “Computationally Independent Model”, which does not have built-in bias towards a particular implementation platform
- Note that the model contains four subclasses to distinguish the type of the allergy. But databases don’t understand subclasses.  They use “type codes” to determine what kind of a thing is in the record.
- So, we transform the model into another model, which is more conducive to databases, from which we can then generate a database.  The same can be done for XML, Java, etc.
- The advantage is that from a single model, other models can be automatically produced for suit particular purposes – importantly, the derived models all have the same semantic meaning, thus preserving the integrity of the data regardless of how or where it’s used.

## VHIM Details – PSM to Implementation Example

-  <xs:element name="PatientIdentity" type="VaIdentity" substitutionGroup="personIdentity" />
- - <xs:complexType name="PatientIdentity">
- - <xs:complexContent>
- - <xs:extension base="PersonIdentity">
- - <xs:sequence>
- - <xs:element name="administrativeGender" type="AdministrativeGenderCode">
- - <xs:annotation>
-   <xs:documentation>A value representing the gender (sex) of a person.  The for allowable values for this field as specified by the DS DAT for Demographics are: F (Female), M (Male) and UN (unspecified).</xs:documentation>
-   </xs:annotation>
- ...

- public interface PatientIdentity extends personSRDTs.PersonIdentity
- {
-     livingSubject.AdministrativeGenderCode getAdministrativeGender();
-     void setAdministrativeGender(livingSubject.AdministrativeGenderCode administrativeGender);
-     livingSubject.AdministrativeGenderCode addNewAdministrativeGender();
-     livingSubject.BirthTime getDateOfBirth();
-     void setDateOfBirth(livingSubject.BirthTime dateOfBirth);
-     livingSubject.BirthTime addNewDateOfBirth();
- ...

**Java**

**XML Schema Definition (XSD) **

**VHIM Class Diagram**

## VHIM Details

- Challenge: model the future without full requirements, define constraints to enhance data quality, provide backwards compatibility to recent VistA data and really old VistA data
- Decisions and Gold Standards
- Requirements from reengineering teams
- SME reviews of models
- Consistency with current data standards
- HL7 Message Profile Specifications (which is not always used to validate message content)
- VistA Data Dictionary (which is not always enforced at the VistA data file level)

## VHIM Details

- Previous approach (versions 3.0-3.4)
- Take best guess at future model
- Get SME input
- Current approach (versions 3.5-3.6)
- Focus on primary customer: HDR
- Align model with HDR IMS HL7 Message Profiles
- HDR IMS data will seed HDR II

## VHIM Details – Alignment withHL7 Specifications

## VHIM Details – Alignment withHL7 Specifications

**Notes:**
I don’t see the connection between this view and the previous slide snapshot of the MWB

## VHIM Details – Evolution Strategy

**HDR Hx**

**HDR IMS / **
**HDR II **
**(today)**

- value = “136/74”
- units = “”

- value = “136/74”
- units = “mmHg”

## VHIM Details – Evolution Strategy

**HDR Hx**

**HDR IMS / **
**HDR II **
**(today)**

**HDR II **
**(after **
**re-eng)**

- value = “136/74”
- units = “”

- value = “136/74”
- units = “mmHg”

- diastolic
-   value (float) = 74
-   units (code)
-     code = 481298  VUID
-     displayText = mmHg
- systolic
-   value (float) = 136
-   units (code)
-      code = 481298  VUID
-      displayText = mmHg

## VHIM Details

- Role in data quality
- Incorporate data constraints into the model that can be used to validate the data as it is passed between applications
- Incorporate data constraints that can be reflected in the physical models derived from the VHIM
- Constraints
- Data types: definitional constraints
- Semantics: relationship constraints
- Cardinality: required/optional constraints
- Permissible Values: define that the concept “strawberry” belongs to the value set “fruits” – this provides the STS team requirements for what value sets are needed for coded data
- Regular expressions: can be used to define formats, ranges, etc.

## More HealtheVet Principles

- HealtheVet will use the Service Oriented Architecture (SOA) strategy
- Services are used to provide capabilities to meet business needs
- Data services meet the business need of providing access to data
- Data services abstract the details of data location, data persistence, data retrieval, data transformations, data validation and data packaging

## HDR Basics

- Data is a common asset that needs a common “home”
- HDR is the common, shared repository for clinical data
- The HDR data set is divided into the HDR IMS (HDR II in the future) and HDR Hx
- In the future, the HDR II databases will be regionalized (HDR Local) to increase performance, reduce scalability demands and partially meet failover and availability requirements

## HDR Basics

- Clinical Data Service (CDS) provides the service layer to abstract applications that use clinical data from where and how data is persisted, retrieved and manipulated.
- CDS will hide the details of interfacing with HDR II National, HDR II Local and HDR Hx
- In the future, CDS will also provide data access to VistA for clinical data not yet moved into the HDR
- CDS will adhere to enterprise requirements stating that the message payload coming into and out of CDS will be VHIM compliant

## HDR Basics

- In addition to providing data access to multiple, disparate data sources, CDS will also support payloads based on multiple VHIM versions

**Data**
**Source**

**Data**
**Source**

**Data**
**Source**

**CDS**

**VHIM version A**
**payload **

**VHIM version B**
**payload **

**VHIM version C**
**payload **

## HDR Details

- To support multiple data sources and to apply data aggregation and other processing logic, CDS needs one internal domain model to execute logic against

**Data**
**Source**

**Data**
**Source**

**Data**
**Source**

**VHIM version A**
**payload **

**VHIM version B**
**payload **

**VHIM version C**
**payload **

**CDS Internal **
**Domain Model**

**CDS**

## HDR Details

- To support multiple VHIM version specific payloads, CDS needs a VHIM derived domain model for each VHIM version supported

**Data**
**Source**

**Data**
**Source**

**Data**
**Source**

**VHIM version A**
**payload **

**VHIM version B**
**payload **

**VHIM version C**
**payload **

**CDS Internal **
**Domain Model**

**CDS**

**VHIM vers. A**
**Domain Model**

**VHIM vers. C**
**Domain Model**

**VHIM vers. B**
**Domain Model**

## HDR Details

- For HDR National Version 2, data models are implemented in the following areas
- HDR II National database schema
- HDR Hx database schema
- CDS internal domain model
- CDS VHIM version specific domain models
- VHIM version specific payloads
- MDA is used to auto-generate the VHIM version specific domain models and payloads
- CDS VHIM version specific domain models
- VHIM version specific payloads
- The VHIM is used as a blueprint for custom creation of the HDR II schema and CDS internal domain model
- HDR Hx is based on VistA and has no correlation to the VHIM

## HDR Details

**HDR II **
**National**

**HDR Hx**

**VHIM version A**
**payload **

**VHIM version B**
**payload **

**CDS Internal **
**Domain Model**

**CDS National**

**VHIM vers. A**
**Domain Model**

**VHIM vers. B**
**Domain Model**

**Created **
**directly **
**from the **
**VHIM (MDA)**

**Created **
**manually **
**using the **
**VHIM as a **
**blueprint**

**No**
**correlation**
**to the VHIM**

***Significant portions of the HDR II National and ***
***CDS National architecture are derived from the VHIM***

## HDR Details

**HDR II **
**Local**

**VHIM version A**
**payload **

**VHIM version B**
**payload **

**CDS Internal **
**Domain Model**

**CDS Local**

**VHIM vers. A**
**Domain Model**

**VHIM vers. B**
**Domain Model**

**Created **
**directly **
**from the **
**VHIM (MDA)**

**Created **
**manually **
**using the **
**VHIM as a **
**blueprint**

**No**
**correlation**
**to the VHIM**

***Significant portions of the HDR II Local and ***
***CDS Local architecture are derived from the VHIM***

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DB**

**VistA**
**DBs**

## Why should you care?

- The VHIM defines data content and structure
- The VHIM defines data quality constraints
- The VHIM is transformed into platform specific implementations ensuring that what is in the VHIM is reflected in the implementation
- The VHIM governs payload structure enforcing data quality constraints at the payload level

## Why should you care?

- The HDR holds all the clinical content you want
- The HDR / CDS system uses several different data models
- Most of these data models are derived from the VHIM
- As a result, if data is not modeled in the VHIM, that data will not be in the HDR!
- As a result, if payload sent to the HDR fails VHIM defined data quality constraint validation, it cannot be persisted in the HDR!

## Some Requests

- Continue to support the HDR
- Appreciate the architectural benefits creating the reliance of the HDR on the VHIM
- Embrace and understand the VHIM
- Review and approve the VHIM for
- Content (inclusion/exclusion)
- Content structures and semantics
- Data quality constraints
- Use the VHIM as the vehicle for changing the content, content structure and/or data quality constraints in the HDR
- Provide guidance on error resolution – what should the HDR do when it receives data that violates the validation constraints?