Conceptual Mapping of Health Standards

Current Standards focus on implementation first and foremost, even FHIR which seeks to provide "concise and easily understood specifications" has a "strong focus on implementation". But this makes it hard to see the wood from the trees, and hard for people not really interested in implementation details to understand or validate the underlying principles and assumptions.

First we need a conceptual model (CM) for health interoperability and informatics.

This can then inform a technology independent model (TIM) which is not the same as a conceptual model. One is to communicate the concepts the other to tightly specify the details.

Finally we can map the TIM to technology specific models (TSM), i.e. XML, SOAP, REST, also CSV, binary, Java bindings, C# bindings, SQL DDL storage, NoSQL Modelling, different types of workflow/process modelling, etc. etc. This list changes as technology changes.

Putting technology to one side, the TIM will change as healthcare delivery models change. Keeping the TIM separate from TSMs allow us to better manage change - business and technology.

Commentary on HL7 Data Type

In the HL7 standards there is a strange bag of datatype (I think historic from HL7v2 and before). Before we look at these lets consider what we would expect at the conceptual and technology independent logical levels:

• Primitives - There are basic (I could say axiomatic) primitive data types - and there is no reason why these should not be the very common IT datatypes we all know and love. When defining standards you need to be rather pedantic but it must be more sensible to reference existing ISO standards rather than redefining for healthcare.

At a conceptual level we would expect : Integer, Real, Boolean, String (to indicate 1 line of text), Text (to indicate a block of potentially formatted text), Date (to the day), DateTime.

For the the logical TIM model we could stop at these, however there is an argument that we need to worry about Short vs  Long, and Float/Single vs Double, etc.  Rather than always assuming the highest precision (i.e. always using Double) we should use Long/Short or int16, int32, int65, etc.

The following table details some suggested logical type.

* variable length - maxlength is an implementation technology constraint

We need to talk about null values - see later ...

• Complex Classes - These are classes (or structures), that require more than one attribute/value/vector, and which would be expected to be used more that once in HL7 entities.
  • Currency Could be one (an example which exists in healthcare, but maybe we could use a more finacial definition: Value (decimal64), CurrencyCode (string[3]), EffectiveTime (datetime).
  • Coded values
  • Address
  • Also it can only have one attribute but constrained. E.g. Telephone Number is a single string but with a particular format. A HL7 example for a single value datatype is Date-of-Birth (DOB), but this just a date of course - DoB is an attribute not a datatype.
• Entities - These represent "real" things that the healthcare domain is interested in, these have attributes (primitives or of complex type). Examples could be Patient, Patient Carer, Provider Organisation, Clinical Practitioner, Location.

Note: An Address is not the same as a Location. An Address can be an attribute of a Location, and indeed of a Patient, Carer, Organisation, etc. It is a communication end-point - A POSTAL Address, a EMAIL Address, a Telephone number, a Fax Number.

A Location is a spatial point in the physical world - often a postal address specifies where it is (but not always, think of post box addresses, or a central head office handling all post). So a Google Maps reference, or longitude/latitude could be an option.

A facility (like a hospital) often has a location and address. But I guess a location could move around - like a facility on a ship.

Null Values

HL7 defines a concept of Null Values and these are endemic in their data model as it is defined as an aspect of all datatypes. In creating a conceptual (and logical) models we will need to decide how to handle these. One option is to ignore them!

The problem is that these "null" values are really "notifications" associated with an attribute ... maybe of an observation. 

Essentially we have 3 types of Null values:

• Where there is no value this is just attribute optionality - i.e. "0..1".
• Infinity - i.e. Not a Number (NaN). These are already handled by standards like IEEE 754 for floating point numbers - that is to say the primitive types can already handle this situation (some thought might be needed to ensure this).
• Notifications like "Patient could not remember". This so obviously should not be coded as a Null data type aspect that I won't even bother discussing it further; just to say the "Null" list seems incomplete anyway, what about all the other types of alerts, "patient does not speak the vernacular language", "Patient was intoxicated", "Patient's mother needed a cup of tea"!

So these are notifications that need to be attached to the entity or attribute when relevant. And by the way, a value might not be missing but still need a notification ...

We will revisit this once we look at the HL7 data types and RIM.

FHIR

Before looking at HL7v3 data types and RIM lets look at the FHIR datatypes - and develop a Conceptual FHIR data model. FHIR aims to provide a more agile standards framework.

See the FHIR data type specification for full details.

The following table maps the FHIR item to a conceptual item.