Clinical messages have always been an incomplete "soda straw" perspective of a very small amount of patient's clinical information. Messages are designed for communicating current information about a patient from one software system to another. HL7 v2 is the dominant industry standard used for expressing clinical messages.
HL7 v2 messages can be used to express different types of messages including Admissions and Discharges (ADT), Observation Result (ORU), Order Message (ORM). Additionally, HL7 v2 is a very old data standard, using a "pipe and hat format" approach to encoding the patient's clinical data. In order to parse an HL7 v2 message, you need to know the offset of data within an HL7 v2 message separated by "|" and "^" characters. For example, below is an example HL7 v2 message for a glucose reading.
MSH|^~\&|GHH LAB|ELAB-3|GHH OE|BLDG4|200202150930|
|ORU^R01|CNTRL-3456|P|2.4|PID|||555-44-4444|
|EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F|||
153 FERNWOOD DR.^^STATESVILLE^OH^35292||(206)3345232
|(206)752-121||||AC555444444||67-A4335^OH^20030520
|OBR|1|845439^GHH OE|1045813^GHH LAB|15545^GLUCOSE||
|200202150730||||||||
|555-55-5555^PRIMARY^PATRICIA P^^^^MD^^|||||||||F||
||||444-44-4444^HIPPOCRATES^HOWARD H^^^^MD|OBX|1|SN
|1554-5^GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN||^182|mg/dl|70_105|H|||F
This makes for a very brittle standard, that is machine interpretable, but not very easy to work with. By design, you probably would not want to persist HL7 v2 messages as the authoritative source of the clinical information about a patient. It is not going to be anything more than a soda straw of a few data points. To this end, moving forward to the turn of the 21st century... clinical documents could help... a little.
Clinical documents are designed to express a more complete picture of a patient's healthcare information at a specific date and point in time. Notable clinical document standards have included the ASTM CCR. HL7's CCD, CCDA, and QRDA Category I. MITRE also developed a standard for both representing and exchanging clinical documents called hData. Clinical documents differ from clinical messages in that documents are designed to contain more information extracted from an EHR system at a specific date and possibly a timestamp.
An example of an old CCR XML document representing a patient with hypertension and height/weight vitals follows:
<?xml version="1.0" encoding="UTF-8"?>
<ContinuityOfCareRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:astm-org:CCR CCR_20051109.xsd http://www.w3.org/2001/XMLSchema xmldsig-core-schema.xsd" xmlns="urn:astm-org:CCR">
<CCRDocumentObjectID>94461c3f-7dbf-4af1-aba9-ed4aac26bea4</CCRDocumentObjectID>
<Language>
<Text>English</Text>
</Language>
<Version>V1.0</Version>
<DateTime>
<ExactDateTime>2010-02-01T15:52:04Z</ExactDateTime>
</DateTime>
<Body>
<Problems>
<Problem>
<CCRDataObjectID>BB0001</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>1990-08-07T06:00:00Z</ExactDateTime>
</DateTime>
<Type>
<Text>Diagnosis</Text>
</Type>
<Description>
<Text>Hypertension</Text>
<Code>
<Value>403.10</Value>
<CodingSystem>ICD-9 CM</CodingSystem>
<Version>2005</Version>
</Code>
</Code>
</Description>
<Status>
<Text>Active</Text>
</Status>
</Problem>
</Problems>
<VitalSigns>
<Result>
<CCRDataObjectID>BB0009</CCRDataObjectID>
<DateTime>
<Type>
<Text>Start date</Text>
</Type>
<ExactDateTime>2005-09-24T04:00:00Z</ExactDateTime>
</DateTime>
<Description>
<Text>Height & Weight</Text>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<Test>
<CCRDataObjectID>BB0010</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Height</Text>
<Code>
<Value>50373000</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>155</Value>
<Units>
<Unit>cm</Unit>
</Units>
</TestResult>
</Test>
<Test>
<CCRDataObjectID>BB0011</CCRDataObjectID>
<Type>
<Text>Observation</Text>
</Type>
<Description>
<Text>Weight</Text>
<Code>
<Value>363808001</Value>
<CodingSystem>SNOMED</CodingSystem>
<Version>2005</Version>
</Code>
</Description>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
<TestResult>
<Value>55</Value>
<Units>
<Unit>kg</Unit>
</Units>
</TestResult>
</Test>
</Result>
</VitalSigns>
</Body>
<Actors>
<Actor>
<ActorObjectID>AA0001</ActorObjectID>
<Person>
<Name>
<CurrentName>
<Given>John</Given>
<Middle>N</Middle>
<Family>Doe</Family>
</CurrentName>
</Name>
<DateOfBirth>
<ExactDateTime>1960-08-23T06:00:00Z</ExactDateTime>
</DateOfBirth>
<Gender>
<Text>Male</Text>
</Gender>
</Person>
<IDs>
<Type>
<Text>SSN</Text>
</Type>
<ID>555-55-5555</ID>
<Source>
<Actor>
<ActorID></ActorID>
</Actor>
</Source>
</IDs>
<Address>
<Type>
<Text>Home</Text>
</Type>
<Line1>Main Street</Line1>
<City>Fort Lauderdale</City>
<State>FL</State>
<PostalCode>33011</PostalCode>
</Address>
<Source>
<Actor>
<ActorID>AA0002</ActorID>
</Actor>
</Source>
</Actor>
</ContinuityOfCareRecord>
This allows for additional data to express a more complete (but admittedly incomplete) picture of that patient's health.
Fast forward to today... as laid out in the latest JASON report... the trend is less towards messages or documents, and more towards open Application Programmer Interfaces (APIs) to access and exchange a patient's data.
In the FHIR RESTful framework, transactions are performed on the server using the HyperText Transfer Protocol (HTTP) request/response. FHIR's RESTful framework allows for services to create, read, update, and delete information exchanged from one service to another over a network.
There's levels of authentication to gate access that can be built into FHIR at various levels of a patient's record. So, if you wanted to request all the clinical information about a patient from a service, you would simply perform a "GET" request on that patient's identifier. Similarly, you could request a subset of finer levels of granularity for information such as that patient's conditions, medications, allergies, etc.
There are even some sexy things that you can do with FHIR's search capabilities of clinical data. For instance, you could perform search for any patient with a gender that has a code "male" with a query like:
GET [base-url]/Patient?gender=male
The data exchanged with FHIR is still clinical documents, but there's now a shift away from the CDA-based HL7 documents that I have not been a fan of, to FHIR's own approach to expressing clinical documentation with FHIR resources within the FHIR RESTful API.
Ultimately, I think this is where we should be going; both with focusing on how data will be accessed and exchanged while simultaneously ensuring that the clinical data used between different services is designed to be simpler and stricter.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. © Rob McCready, 2014.