The HL7V3.0 Primer

What is HL7V3.0 ?

HL7V3.0 is a model based messaging specification which was proposed to resolve the weaknesses of HL7V2.x. The aim of a model based messaging standard is to create a standard set of structures for the sharing of healthcare information and support binding of standard clinical terminologies to the model. The creation of a standard clinical model with standard terminology establishes a healthcare domain specific common language which would allow any healthcare application model to map onto the reference model. This mapping would allow interoperability with other applications apart from allowing re-use of healthcare data in the application which has mapped its model onto the model.

Methodology Overview

Figure below shows the methodology used in HL7V3.0

The different processes in the HL7V3.0 methodology to obtain the message specifications are described below

Use Case Modeling:

The Use case Model consists of the following definitions

Ø Scope statement: A high level use case for the entire project

Ø Use case: Describes specific situations in which communication between healthcare entities is needed

Ø Actor: An entity which initiates or participates in the use case. Discovered in the process of developing use cases

Ø Use Case Diagram: Provides a graphical form to develop the use case model from the business process analysis and makes it easy to show the relationship between use cases

Interaction Modeling:

The Interaction Model

Ø Describes roles to which systems may claim conformance

Ø Fine-grained abstraction; every system will claim several roles

Ø Not standardizing system or application functions, only messaging roles

Ø Basis for contractual agreement

Ø Potential basis for conformance testing

Ø Captured in a MODEL, a TABLE, and a DIAGRAM

Each Interaction consists of:

Ø Trigger event :Event dependency usually expressed as the state of one or more classes

Ø Message ID : Each interaction sends one particular message

Ø Sender role

Ø Receiver role

Ø Receiver responsibility :A specific functional responsibility for the receiver to initiate another (consequential) interaction

Information Modeling:

The information model consists of the following

Ø A detailed and precise definition for the information from which the data content of HL7 messages are drawn.

Ø Follows object-oriented modeling and diagramming techniques, and is centered on a depiction of the classes that form the basis for the objects in HL7 messages.

Ø Provides a means for expressing and reconciling differences in data definition independent of message structure.

Ø Forms a shared view of the information domain used across all HL7 messages.

The Information Model defines

Ø classes, attributes, data types, and relationships

Ø vocabulary domains, code systems, and value sets

Ø states, trigger events, and transitions

Reference Information Model:

The model which forms the basis for the development of HL7V3.0 message specifications labeled RIM (Reference Information Model) is an object oriented model where the information is organized into classes that have attributes and that maintain associations with other classes. The information-related content of HL7 3.0 protocol specification standards is drawn from this model. RIM uses notation based on the Uniform Modeling Language (UML) and information modeling conventions outlined in the HL7 message development framework. RIM provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

RIM is conveniently fashioned into three areas – semantic control, structured documents and message control.

The backbone of RIM consists of four primary classes and two linking classes. The four primary classes in the semantic content partition of the RIM are

Act: An Act is defined as intentional healthcare related action in the business domain of HL7. An instance is a record of an act. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. An act is represented by a brick colored block in the RIM as following example

Act has the following sub-classes

Ø Account

Ø ControlAct

Ø DeviceTask

Ø DiagnosticImage
Ø Diet

Ø FinancialContract

Ø FinancialTransaction

Ø InvoiceElement

Ø Observation

Ø Participation

Ø PatientEncounter

Ø Procedure

Ø PublicHealthCase

Ø SubstanceAdministration

Ø Supply

Ø WorkingList

Entity: Entity is a physical thing or organization and grouping of physical things. A physical thing is anything that has extent in space, mass. Excludes information structures, electronic medical records, messages, data structures, etc. An Entity is represented by a green colored block in the RIM as following example

Entity has the following sub-classes

Ø Container
Ø Device

Ø LanguageCommunication

Ø LivingSubject

Ø ManufacturedMaterial

Ø Material

Ø NonPersonLivingSubject

Ø Organization

Ø Person

Ø Place

Role : For people, role is usually positions, jobs, or ‘hats’ and for places and things are what these places or things are normally used for. Each role is “played by” one Entity and is usually “scoped” by another. Thus the role of Patient is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, an Employee role is scoped by the employer. A role is represented by a yellow colored block in the RIM as follows



Role has the following sub-classes:

Ø Access
Ø Employee

Ø LicensedEntity

Ø Patient

Participation: Role exists only within the scope of one act. Acts have multiple participants, each of which is an entity in a role. Role signifies competence while participation signifies performance. Participation is represented in the RIM by the following block

Participation has ManagedParticipation sub-class.

Act Relationship: ActRelationship is association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance.Act Relationship is represented in RIM by the following block

ActRelationship has no sub-classes

Role Link: Role Link is a relationship between two entity roles. For example Clinicians relationship with a Hospital and a Patients relationship with a Hospital to express the doctor and patient relationship. Role Link is represented in RIM by the following block

RIM Classes Example

Figure below shows the relationships between the different classes in the RIM with an example

In the above example the Act Examination is performed by Entity Person A in his role as GP and the Subject of the Examination is the Entity Person B in his role as Patient.

Attributes:

Class attributes are the core components of the information model. The attributes are the source for all the information content of HL7. There are three special kinds of attributes in the information model: identifier attributes, classifier attributes and state attributes.

Ø Identifier attributes: Identifier attributes can be used to identify an instance of a class. Values of identifier attributes never change. Examples of identifier attributes from the RIM include Entity.id and Act.id, which uniquely identify a particular Entity or Act respectively

Ø Classifier Attributes: The classifier attributes are a critical aspect of the classes forming the backbone of the RIM. The classifier attributes are named "classCode".

Ø Structural Attributes: Structural attributes are those attributes whose coded values are needed to fully interpret the classes that they classify. ClassCode together with moodCode, typeCode and determinerCode are the structural attributes.

Ø State Attributes: A state attribute is used in subject classes (classes that a Technical Committee designates as the central focus of a collection of messages). It contains a value that concisely indicates the current state (named condition) of the class.

Message Design:

The Message Design in HL7V3 from RIM is obtained as follows Message Design Overview

Domain Message Information Model:

DMIM is

Ø Full description (model) of the information classes within a domain and the way in which they are being used

Ø Classes are ‘cloned’ (copied and adapted) and renamed (alias) according to the way they are used in the domain context

Ø Data Types and vocabulary for attributes are specified

Ø Every RIM class category has its own colour; this makes the model description more visual

To obtain D-MIM from RIM

Ø Select RIM classes to be included in D-MIM Select the subset of RIM classes relevant to the problem domain.

Ø Clone subset classes of the RIM If the same RIM class is selected to meet different information needs then create as many clones of the RIM base class as needed. Ø Select a subset of class relationships Add relationships between the D-MIM clones consistent with existing class relationships in the RIM.

Ø Select a subset of class attributes For each D-MIM clone select the applicable attributes from its RIM base class.

Ø Select a subset of attribute data types and vocabulary domains Assign data types and domains to D-MIM attributes that are consistent with assigned data types and domains in the RIM

Refined Message Information Model:

R-MIM is

Ø Same type of representation as D-MIM

Ø Aimed for a specific category of interaction (e.g. all inpatient admission related messages) Ø Special form of an R-MIM are the Common Message Element Types (CMETs).These express common and reusable ‘information units’, that are derived from a D-MIM (like all R-MIMs) but can be used in other D-MIMs (and therefore R-MIMs) as building blocks (e.g. ‘patient’)

To obtain R-MIM from D-MIM

Ø Create clones of D-MIM classes and attributes Further specialize D-MIM classes by creating additional clones for each unique collection of attributes

Ø Assign alias class and relationship role names Assign domain specific names to class clones Ø Eliminate unnecessary class hierarchies Remove classes with no attributes and relationships from the class hierarchy

Ø Finalize class relationships and cardinality Alter relationship cardinality to reflect the appropriate minimum and maximum class occurrences

Ø Finalize attribute data types and domains Replace data type and domain specifications with the most appropriate constrained version of each

Hierarchical Message Definition

HMD is a further restriction of an R-MIM:sequentialized/serialized; represented in a different format. To create a HMD

Ø Select a root class for the message Chose a class to serve as the starting point for message content

Ø Arrange classes and attributes hierarchically Follow the relationships from class to class and add the attributes to the HMD.

Ø Declare inclusion and repetition constraints For each attribute specify if its presence in message content is optional, mandatory, or conditional and specify the number of times the attribute may repeat

Ø Declare data type and domain value constraints Declare additional constraints on the data types and domain values

Ø Assign message element names Assign a final meaningful business name to each attribute in the HMD

HL7 V3.0 Data Types:

HL7 data types define the structure and constrain the allowable values of attributes in the RIM. The HL7 data type specification declares the set of data types, identifies components of complex types, and defines relationships between data types. The HL7 data type implementation technology specification defines constraints and operations for data types and describes how data types are to be represented in XML. Data types are reusable atomic building blocks used to create all HL7 V3 information structures. Each RIM attribute is assigned one data type; each data type is assigned to zero, one, or more RIM attribute. Few of HL7V3.0 data types are given below

• AD: Postal Address
• ANY: DataValue

• BAG: Bag

• BL: Boolean

• CD: Concept Descriptor

• CE: Coded With Equivalents

• CS: Coded Simple Value

• ED: Encapsulated Data

• EN: Entity Name

• GTS: General Timing Specification

• HIST: History

• II: Instance Identifier

• INT: Integer Number
• IVL: Interval
• LIST: Sequence
• MO: Monetary Amount
• ON: Organization Name
• PN: Person Name
• PPD: Parametric Probability Distribution
• PQ: Physical Quantity
• REAL: Real Number
• RTO: Ratio
• SC: Character String with Code
• SET: Set
• ST: Character String
• TEL: Telecommunication Address
• TN: Trivial Name
• TS: Point in Time
• UVP: Uncertain Value - Probabilistic

HL7V3.0 Vocabulary Specification:

The HL7 V3 Vocabulary Specification defines vocabulary domains used in RIM coded Attributes and coded data type properties. A vocabulary domain is an abstract collection of interrelated concepts. It describes the purpose or intent of a coded attribute. A value set is a collection of coded concepts drawn from a single code system. A vocabulary domain may be associated with many value sets. A context expression provides a means of designating which value sets within a given domain are applicable for a given usage context. A coded concept has a concept code assigned by the coding system and a concept designation which names the referenced concept. A coded concept may be a parent concept for a collection of additional concepts within the same code system.

HL7 XML Schema Generator:

The HMD’s constrained with HL7 Vocabulary Specification and HL7 Data Type specification to a HL7XML schema Generator gives the XSD the schema definition of an HL7V3.0 message. Figure below shows the set up for the generation of XSD.

Links, References, Acknowledgements and Copyright

http://www.hl7.org

Brazil NHCP

I have been too pre-occupied with my work to do some quality blogging; I have not written anything till now about my favorite topic – Electronic Health Records. This is first of serious of blogs on various EHR initiatives around the world.Most of the information that will be included is public information and my intention is to simplify the information about the implementation from what i understand while allowing the users also to examine the contrast in the patterns used by different implementations. I have been told that Brazil is one of the first countries to have a successful implementation of Nation Wide Electronic Health Records. The project was termed NHCP – National Health Card Project. This project began as early as 1999 and a clinical pilot began in 2001

Aim of NHCP

The project was started to create national patient identification and information system for the Brazilian Unique Healthcare System called SUS -- Sistema Único de Saúde. Its aim is to collect patient treatment information in a national repository of clinical data.


Architecture Principles and Components

Figure below shows the logical architecture of the project. NHCP System is divided into 5 hierarchical levels, from the bottom: Point of Care Level, Municipal Level, Concentrator Level, State Level and Federal Level. The top three levels of the system has Permanent IP based network and the lower two levels has Dial Up Network as shown in Figure below.

NHCP Project has five major components

Ø Telecommunication infrastructure
Ø Point of care terminals;
Ø Servers and database facilities
Ø Point of care terminal and servers software
Ø Security issues and national standards to represent transmit and store health information.

The architecture of the NHCP is centered on patient and users having health cards. The health cards adopted in the project are used only for IDENTIFICATION purposes of users and health professionals and not to store clinical data. Both the users’ and health professionals’ cards have embossed the unique identification number, name, date, city and state of residence. The point of care equipment specially developed for this project has the card reader. The access to the system is limited to health professionals authenticated by the card and password. All data captured at the point of care is stored in the servers at the municipal, state and federal level

The technologies that were used are based on Java technology and the XML data format. The Java framework is based on the following concepts

Ø The NHCP is XML message-based; all communication between machines is XML over HTTP.
Ø Every server node can send and receive XML messages to and from any another server node.
Ø XML messages are associated to Java business classes.
Ø All XML data is handled dynamically using Java Reflection.

All XML is validated according to a rigid specification (DTD, infrastructure, and domain), which provides the flexibility necessary to add or remove business classes, and to modify the XML validation rules. In addition, servers and clients must authenticate to a server node using digital certification. The figure below depicts a generic server node with its principal building blocks and data flows.

Standards and Data Sets

The transport protocol used is HTTPS (HTTP +SSL). The terminals of care and municipal servers communicate using XML. The specifications were not HL7 but specifications agreed between Ministry of Health and the providers contracted for the development of the project. Document Type Definition (DTD) has been used for specifications.

The essential encounter data set contains the following information

Ø Reason for the encounter
Ø Diagnosis
Ø Procedures Performed
Ø Patient’s work-out
Ø Medication
Ø Follow Up

The diagnosis information is entered using ICD-10

Informational Governance

The use of the database of the National Health Card aims to only the management of health services by the different spheres of government and was guaranteed not to be used for commercial purposes or for any reason which hinders with constitutional rights of the Brazilian citizens. The architecture incorporates a Information Governance policy covering five basic requirements: privacy, authenticity, integrity, access control and audit of health data tied to the National Health Card.

For authentication any addition or alteration of information in the system is linked to an operator duly registered both for operation of the server and the terminal. All the health professionals responsible for the entry of data to the system are authenticated using health professional card which contains a encrypted password on the card.For access control, the system allows the implementation of a policy of setting privileges of access to classes of operators and standards of disclosure. All attempts to access information and functions of the system are stored for auditing purposes.

From IG point of view the systems offline are treated the same way as that of online systems. The traffic between a terminal and a server, upload between servers or service is performed on the HTTPS protocol, or HTTP protocol (Hypertext Transfer Protocol) protocol on the SSL (Secure Sockets Layer).

Scalability

Since spring 2003, the pilot infrastructure has been fully operational, consisting of:

Ø 8 million patient ID health cards
Ø 50,000 professional ID cards
Ø 3200 point-of care-clients
Ø 2 federal servers
Ø 27 state servers
Ø 13 concentrator servers
Ø 44 municipal servers

In parallel with the pilot project and in anticipation of consolidation for the rest of the country, 80 million people have been uniquely identified in the NHCP database, representing 40% of the Brazilian population. Interoperability with external systems is also operational. Systems from external vendors are communicating with the NHCP by exchanging XML documents.

NHCP server -side data:

Ø 180 different use-cases
Ø 1,800 Java classes
Ø 230,000 lines of code
Ø 700 different database tables
Ø 160 different XML message types
Ø 50 gigabytes of data/million users/year

Advantages

NHCP allows data to be queries and profiled; for example diagram below shows actual data queried from the NHCP system for San Jose dos Campos, a city of 500,000 people near Sao Paulo. The x axis shows the treatment procedures codes, the y axis the date, and the vertical z axis shows the corresponding quantity. So what happened to cause this peak? From the data, it was possible to identify that the peak was due to the annual influenza immunization program; it was in winter, and over a two-week period, nearly 5000 people got their influenza shots.

My Observations

The project is simple implementation but strictly not a EHR implementation per-se and looks more of a data ware house implementation. There were claims that the message specifications were done after debate with clinicans who were the main users. It did not follow any reference model based specs so any of the changes to the specifications to keep in line with advances with clinical terminology and data will be adhoc. Also usage of ICD10 will limit the amount of data collected considering that its mostly disease based. The data sets indicate minimal information is captured and also a mechanism to retrieve from central repository to point of care systems is not well defined. The integration mechanism looks like a hardcore java implementation and non-implementation of a standard middle ware implementation will have its own technological refresh problems and scalability problems. Also some of the technologies used like DTD , XML binding has since become rarely used with the advent of XSD , SOAP , JAXB etc as the artcile on the SUN website indicates.

But the framework on the whole is a good start but building on the top of it may be bit difficult and any extensions to it may look out of place considering the usage of HL7V3.0 , SNOMED have become more wide-spread now.

Links, References, Acknowledgements and Copyright

http://java.sun.com/developer/technicalArticles/xml/brazil/

Lemos M, Leao de Faria B. The Brazilian national health card project. Proceedings of the International Nursing Informatics Conference. Rio de Janeiro; June 2003.

http://dtr2001.saude.gov.br/cartao/ - Official Site with detailed info