Thursday, October 11, 2012

CDISC Discovers "Concept Maps"

My attention was drawn to interesting developments on the CDISC front by the following, from Kerstin Forsberg of AstraZeneca:

Checkout "mind maps" slide 13-15, 27 for#CDISC SHARE http://ow.ly/dHfy5  < Then have a look at http://code.google.com/p/ogms/

The CDISC slide deck she refers to does indeed contain interesting representations of, for example, deep brain simulation as a treatment of Parkinson's Disease (slide 14):




But the question arises: how are the nodes and edges in such a graph to be interpreted. On slide 14 we are told that:  
[the b]asic building block is a “concept” which is a piece of clinical information. Examples include:
–systolic blood pressure observation
–systolic blood pressure result
–sodium concentration in plasma observation
–subject's birth weight result
–study subject
–visit
Each of these concepts has component parts (including what we would conventionally call variables)
The 'treatment' and 'Parkinson's Disease' nodes in the above, therefore, represent pieces of clinical information. Given the context in which slide 14 appears, I assume that these are pieces of clinical information about some given patient. But how, on this basis, can we provide a coherent interpretation of the edges on the graph. How, for example, can 'implanted in' be understand as linking a piece of information about this patient's brain with a piece of information about some lead?

Questions such as this were addressed (and I had optimistically assumed) put to rest already in 2006. The answer to such questions is that there is no coherent interpretation of the edges in a graph of the sort displayed if the graph is taken to be about relations between concepts. The Ontology for General Medical Science (OGMS) shows, I believe, how to create and interpret such graphs in a coherent fashion -- paying careful attention to the distinction between portions of reality on the side of the patient -- for example actions of treating, brains, neurostimulators -- and the types of which these portions of reality are instances.

OGMS is built on the basis of the assumption that each term and each relation used in the graph representation of a clinical encounter needs to be defined in a logical way. Only thus can the information contained in the graph serve computational inference. It is sad that, after so many years, important groups investing considerable efforts in healthcare informatics have still not apprehended the need for such definitions.

Update: October 18, 2012

XML4Pharma submitted the following query:

Not being a specialist in ontologies, I need some more explanation.
Do you mean that for each node, the edges (predicates I presume in the RDF context) cannot be defined in a unique way, i.e. there is an infinite number of possibilities for each edge to be named? E.g.
1. What one person defines as "is part of" can be defined by another as "is component of". Is that the problem?
2. Or should there for each pair of nodes be only a distinct set of predicates available?
3. Or do you mean that to assign a name to an edge, some systematic rules must be followed?
Ad 1. Currently, the standards defined for RDF, as for OWL (as for XML), place very few restrictions on what relations and what sorts of relations can be used to link nodes in an ontology graph, and they place no restrictions at all on what such relations should be called. This leads to the same sort of chaos as would be created if diferent airlines used different standards for representing time in publishing their schedules. In "Relations in Biomedical Ontology" we suggested a solution to this problem, and this solution has been applied and refined within the framework of the OBO Foundry.

Ad 2. I believe that, for each pair of nodes, only a small set of relations will be meaningfully applicable.

Ad 3. As stated under 1., we need standards which will ensure that the same relations receive the same names on all occasions of use. OGMS is an attempt to set forth the needed standards for annotating data relating to clinical encounters.

Thursday, September 06, 2012

HL7 To Make Intellectual Property Available at No Cost

On Tuesday, HL7 International announced that, beginning in 2013, it will make most of its intellectual property, including standards, available at no cost under licensing agreements. 

For more details, see HealthcareInformatics, 9/4, which refers to:
a produced statement [from] John Halamka, M.D., MS, CIO at the Beth Israel Deaconess Medical Center and Professor of Medicine at Harvard Medical School: “This announcement is the most significant standards development in the past decade ... It ensures that every stakeholder will have ready access to the content standards they need for Meaningful Use.”
This statement may, however, be a mite misleading. As I understand matters, those wishing to satisfy Meaningful Use criteria  can use CCR from ASTM instead of CCD from the HL7 shop (and even CCD is now a chimera of CCR/HL7 CDA). HL7 seems to have been unresponsive to actual needs, to the degree that it was surprised and embarrassed by CCR.

Friday, August 03, 2012

Re-fur-bish (verb): To bish, again, with fur


Rene Spronk, in his new proposal to "Renovate HL7 version 3" recognizes that HL7 v3 has failed. As he points out, almost all implementations of v3 today are not in keeping with the original intentions of the v3 developers.  “I've been working on the HL7 version 3 standard for about 10 years - but based on experiences gained during consultancy projects with implementers, and based on experiences of implementers …, I see no other way forward for HL7 v3 then to embark on a renovation project.”

'Renovation', according to the dictionary means: to restore to an earlier, better state. For Rene, to renovate means:  to optimize "for the kind of HL7 v3 implementations that we actually see in use today".  He proposes three alternative paths to such renovation:
Proposal 1.  involves adding a new layer of "re-usable elements" to HL7 v3 and "getting rid of the 100s of different R-MIMs".  
But where will these new re-usable elements come from? And who, given the failures thus far, will trust a methodology based on the RIM to yield elements which will actually be reused?

More interesting are the proposed second and third alternative paths:
Proposal 2. is to renovate HL7 v3 by "moving everything to CDA R3, and to cease development related to HL7 v3 messaging."
Propose 3. is to renovate by "moving everything to FIHR [= Fast Healthcare Interoperability Resources] and to cease development of HL7 v3".
Thus in both cases ‘renovation’ in the sense of: abandonment. 

Everything in the FHIR (pronounced ‘Fire’) is, to be sure, required to have a ‘mapping to the RIM’. But this, we presume, is simply for reasons of nostalgia ... for earlier, better times.

Sunday, June 24, 2012

Death by HIPAA

From INFO/LAWhttp://blogs.law.harvard.edu/infolaw/2012/06/22/death-by-hipaa/:

Vioxx, the non-steroidal anti-inflammatory drug once prescribed for arthritis, was on the market for over five years before it was withdrawn from the market in 2004. Though a group of small-scale studies had found a correlation between Vioxx and increased risk of heart attack, the FDA did not have convincing evidence until it completed its own analysis of 1.4 million Kaiser Permanente HMO members.  By the time Vioxx was pulled, it had caused between 88,000 and 139,000 unnecessary heart attacks, and27,000-55,000 avoidable deaths.
The Vioxx debacle is a haunting illustration of the importance of large-scale data research….If researchers had had access to 7 million longitudinal patient record, a statistically significant relationship between Vioxx and heart attack would have been revealed in under three years. If researchers had had access to 100 million longitudinal patient records, the relationship would have been discovered in just three months….


Monday, March 12, 2012

HL7 RIM has done its job on HL7 V3. Now it’s time to undermine the V2 standard

I am noticing changes introduced in V2.7 of the HL7 standard – described by one Asian HL7 expert as ‘subtle, insidious and dangerous’ – which consist in the insertion of failed RIM strategies into the newer versions of V2.x. Simple, usable standards are thereby becoming progressively more complex. Mood Codes, for example, the source of so much of what is impenetrable in HL7 V3, are now being reverse-engineered into V2.7, even while the V2.7 documentation acknowledges that At this time, there are no documented use cases for this field. And the CWE ('coded with exceptions') data type, which in V2.6 had 9 components, has 22 components in V2.7 along with multiple new subcomponents.
While, therefore, it is being widely acknowledged on the one hand that HL7 V3 has failed, V3's defenders are on the other hand injecting into V2.x some of the very components of the V3 approach which had made it non-viable for messaging.

On Mood Codes in V2.7

For examples of insertions of Mood Codes in V2.7, see chapter 2, section 2.8.1 and Table 0725, and chapter 7, section 7.4.2 (OBX - component 22 - CNE - Mood code):
Definition: This field identifies the actuality of the observation (e.g., intent, request, promise, event). Refer to HL7 Table 0725 - Mood Codes for valid values. This field may only be used with new trigger events and new messages from v2.6 onward.
Note: OBX-22 Mood Code was introduced in v2.6 to support Patient Care messaging concepts and constructs. At this time, there are no documented use cases for this field in the context messages as described in this chapter. This statement does not preclude the use of OBX-22, but implementers should exercise caution in using this field outside of the Patient Care context until appropriate use cases are established. While a similar note exists for OBX-21 Observation Instance Identifier, particular care should be taken with OBX-22 as this could modify the intent of the segment/message and create backward compatibility problems.
5. V 2.7 - Chap 11.2.1.3 "The use of HL7 Version 2.x in clinical messaging has involved the use of segments in ways for which they were not originally intended, as well as the development of the REL segment to express important relationships between clinical data components. Such use has also necessitated the introduction of mood codes to allow for the richer representation of intent, purpose, timing, and other event contingencies that such concepts required. 
On CWE (coded with exceptions) in V2.6 and V2.7
In V2.6, CWE had 9 components as follows: 

SEQ
LEN
DT
OPT
TBL#
COMPONENT NAME
SEC.REF.
1
20
ST
O

Identifier
2.A.74
2
199
ST
O

Text
2.A.74
3
20
ID
O
0396
Name of Coding System
2.A.35
4
20
ST
O

Alternate Identifier
2.A.74
5
199
ST
O

Alternate Text
2.A.74
6
20
ID
O
0396
Name of Alternate Coding System
2.A.35
7
10
ST
C

Coding System Version ID
2.A.74
8
10
ST
O

Alternate Coding System Version ID
2.A.74
9
199
ST
O

Original Text
2.A.74


In V2.7, however, this has been expanded to 22 components, which are made even more complicated by the introduction of Value Sets and OIDs (unique object identifiers).
As of v2.7 a third tuple, formerly known as triplet, has been added to the CWE data type. Additionally, 3 new components were added to each tuple such that each tuple now has a total of 7 components.

So each set in V2.6 receives an additional OID (SEQ 14) and a value set OID (SEQ 15) . And this set of 6 is repeated 3 times.

HL7 Component Table - CWE – Coded with Exceptions

SEQ
LEN
C.LEN
DT
OPT
TBL#
COMPONENT NAME
1

20=
ST
O

Identifier
2

199#
ST
O

Text
3
1..12

ID
C
Name of Coding System
4

20=
ST
O

Alternate Identifier
5

199#
ST
O

Alternate Text
6
1..12

ID
C
Name of Alternate Coding System
7

10=
ST
C

Coding System Version ID
8

10=
ST
O

Alternate Coding System Version ID
9

199#
ST
O

Original Text
10

20=
ST
O

Second Alternate Identifier
11

199#
ST
O

Second Alternate Text
12
1..12

ID
C
Name of Second Alternate Coding System
13

10=
ST
O

Second Alternate Coding System Version ID
14

199=
ST
C

Coding System OID
15

199=
ST
O

Value Set OID
16

8=
DTM
C

Value Set Version ID
17

199=
ST
C

Alternate Coding System OID
18

199=
ST
O

Alternate Value Set OID
19

8=
DTM
C

Alternate Value Set Version ID
20

199=
ST
C

Second Alternate Coding System OID
21

199=
ST
O

Second Alternate Value Set OID
22

8=
DTM
C

Second Alternate Value Set Version ID