1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CLINICAL LOINC COMMITTEE
Proposed use of LOINC document ontology codes for data segmentation (Draft)
David A Stumpf, MD, PhD on behalf of ILHIE & SHARPS1
Background
HIPAA, state legislation and regulation, ARRA/HITECH, health care delivery entities and other authorities
have requirements for protecting defined types of information. The Office of the National Coordinator
(ONC) has commissioned and funded the Strategic Healthcare IT Advanced Research Projects on Security
(SHARPS)2 to research and recommend solutions. ONC also funded state HIE projects, including the
Illinois Health Information Exchange (ILHIE).
SHARPS and ILHIE have proposed a requirement for four independent domains: clinical data, policies,
consent, and a knowledge repository. This strategy would allow experts to manage each domain and for
electronic systems to link them using ontologies. In this use case, LOINC codes are envisioned as one
component of the knowledge domain which provides an ontology linking together the other domains.
The Clinical LOINC Committee would create, publish, and maintain suitable LOINC codes. The clinical
data is tagged when a document is created and this tag is static; that is, it does not change. The clinical
data tagging does not presume whether data is sensitive. The system requirements for flexibility are
enabled by dynamic policy and consent domains referencing the LOINC ontology and also using OIDs.
The LOINC code defines the nature of the protected information and the OID a specific policy or rule.
There may be multiple OIDs per LOINC because various entities have differing interests in protecting
information. The consent domain may use a LOINC code to address a type of protected information
generically (e.g., applies to all OIDs) or specifically reference each OID separately.
Multiple levels of segmentation can be defined and ordered by the complexity of their implementation.
LOINC minimizes the complexity. For example:
28
29
30
31
32
33
34
35

36
37
38
ILHIE intends to deploy Level 1 and 2 capabilities initially because of their robustness and relative ease of
implementation.




1
2
Level 1 would use identifiers at the document level; for instance, a psychiatric consult note,
LOINC=34788-0, could subject an entire document to a policy or consent.
Level 2 would use identifiers to selectively apply policy or consent at the section level; such as
42768-2 for HIV lab result or 11350-6 for history of sexual behavior.
Level 3 would use the curated value sets such the value sets in NQF EBM rules defining depression.
Level 4 would use non-curated ontology derived codes; an example would be using UMLS semantics
to define a protected concept such as psychosis.
Level 5 could be free text translated using NLP into standard codes.
Contributors to this document include Michael Berry, Ivan Handler, Mark Chudzinki, and Carl Gunter
http://sharps.org. SHARPS is managed through the University of Illinois, Urbana campus, School of
Engineering.
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
To illustrate further, we provide examples of classes of information requiring protection3:
 Federal code 42 CFR Part II pertaining to alcohol and substance abuse clinical data can be placed in a
section tagged by a level 2 LOINC code.
 Illinois state legislation and regulation offers opt-in protection for certain information. Persons must
specifically consent to its release. LOINC codes would be required for each type of data:
o Mental health/behavioral health/developmental disability
o Psychotherapy notes
o Substance abuse
o Genetic test data
o HIV/AIDs - consent for testing for insurance
o HIV/AIDs – consent for disclosure of test results
 Illinois state legislation and regulation offers opt-out protection for certain information. Persons
must specifically restrict release. LOINC codes would be required for each type of data:
o HIV/AIDs consent for testing
o Immunization registry consent for inclusion
 HIPAA section 522 also allows providers to withhold information regardless of the type of data. This
generic provision can be implemented by placing such clinical data in a section tagged by a level 2
LOINC code. The generic nature of this provision makes this a “catch all” for the many items that
physicians and others encounter that requires segmentation. Obviously, there will be numerous
codes needed to differentiate data types.
Proposed LOINC Roles
The domains proposed each require special expertise and autonomy to maximize their overall
effectiveness. We propose LOINC and its Clinical LOINC Committee as the entity to develop ontology
codes supporting identification of protected classes of information. This will require coordination with
the other three domains. Such channels of collaboration currently exist for the clinical domain. New
collaboration partners are needed for the proposed policy and consent domains. SHARPS and ILHIE are
proposed as the initial partners, recognizing that other interested parties (discussed below) will be
essential participants.
LOINC and its Clinical LOINC Committee might consider several sequential steps:
 Determination of the domain requirements from a LOINC perspective
 Deciding whether LOINC is appropriate for these requirement
 Deciding whether LOINC will expand its scope and commit to supporting this domain
 Defining the process for producing the desired LOINC codes
 Implementation of the defined process
SHARPS and OHIT have not made final decisions on the use of LOINC for data segmentation. Their
considerations are similar:
 Determine the interest and feasibility of using LOINC as described
 Determine whether LOINC is the preferred solution after these determinations
 Define the process for coordination with LOINC
3
ILHIE Authority Data Security and Privacy Committee, “Briefing Summary: Policies # 1, 3 (Panel
#1) -- Patient Choice, Opt-in/Opt-out” Available at
http://www2.illinois.gov/gov/HIE/Documents/3_BriefingSum_Pan1_071612.pdf
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Other Considerations
The use of protected information also requires insights about the roles of requestors and the context of
data use. One axis (Scale) defines a LOINC code as a document ontology code. The other five axes of
LOINC document ontology provide such insights about context and roles at the document level. These
LOINC codes are readily identified by their Scale attribute of “Doc”. Section level LOINC ontology codes,
identified by the Scale attribute of “Nom”, are not expected to convey similarly robust information
about roles or context. We might consider whether we introduce another Scale value for data
segmentation (SEG) or rely on the existing Doc and Nom values.
Other Interested Parties
Each of the other three domains has industry champions, many with interests in several domains. These
entities will need to be aware of this project and offered opportunities to contribute. We have
identified the following as potential participants:
 Integrating the Healthcare Enterprise (IHE)
 Health Level 7 (HL7)
 Standard and Interoperability (S&I) Framework
 Health Information Management Association (HIMSS)
o EHR Association4
o State Advisory Roundtable5
 American Medical Association Council on Medical Services6
 American Civil Liberties Union (ACLU)
 American Bar Association Health Law Section7
 {other suggestions}
Next Steps


4
Consensus on whether to proceed (ASAP)
Thereafter – to be determined
EHR Association has recommended specific strategies: http://www.ihealthbeat.org/articles/2012/6/21/himssehr-association-calls-for-greater-focus-on-nwhin-governance.aspx
5
http://www.himss.org/policy/d/20120605StatesWillTransformHealthcare.pdf
6
http://www.ama-assn.org/ama/pub/about-ama/our-people/ama-councils/council-medical-service.page
7
http://www.americanbar.org/groups/health_law.html