4. Streaming Data Source¶
4.1. Introduction¶
This chapter describes the Aperture streaming data interchange format called base value. The base value format captures the smallest information parts from HL7v3 clinical documents, FHIR resources or other formats.
4.2. Logical Record Format¶
The base value record format is an Entity Attribute Value Time record format. The base value format is designed to:
Record properties of persons, devices and other entity like data
Record these properties at any point in time
Record properties with appropriate data types
Support additions or removal of data without the need to add or alter tables
The record format can capture properties of events in which one or more entities are participants. These entities are called the units of analysis. The temporal extent of the event is either a point in time, or a time interval. At the point in time, or during the entire time interval, a certain property holds. The name of this property is called feature. As such, the feature can be regarded as a function from unit of analysis and time to the range of allowed values:
f(u,t) = v
f is the feature, the name of the property
u is the set of units of analysis, the set of entities for which the property holds.
t is the point in time or time interval
v is the value
For instance, a “systolic blood pressure of 120 mm[Hg] was measured at Jan 1 2015 for patient 1” can be expressed in base values from as:
systolic_blood_pressure({(patient, 1)}, 'Jan 1 2015') = '120 mm[Hg]'
An order to measure blood pressure at Jan 2 2015 for patient 1 was issued at Jan 1 2015 by author 2, is expressed as follows:
systolic_blood_pressure_observation_order({(patient, 1),(author, 2)}, 'Jan 1 2015') = 'Jan 2 2015'
These two examples show that proper naming is important to discern the many ways in which properties can be expressed, and that the values of the properties can have different data types.
4.3. Physical Record Format¶
The record format uses the PostgreSQL COPY -Text Format-form, of the table with the following signature:
CREATE TABLE base_values_format (
unit_of_analysis JSONB NOT NULL,
unit_update BOOL,
feature JSONB NOT NULL,
datatype TEXT NOT NULL,
value TEXT,
time_lowvalue TIMESTAMP WITH TIME ZONE NOT NULL,
time_highvalue TIMESTAMP WITH TIME ZONE,
time_availability TIMESTAMP WITH TIME ZONE
);
These attributes relate to the logical form as follows:
the
unit_of_analysisis u.unit_updateis a boolean that indicates whether the units in unit of analysis should be used for reference only (Null or False) or to update the unit information in the database (True).the
featureis fdatatypeis a text field that holds the name of the datatypevalueis vtime_lowvalueandtime_highvalueare t.
Each of these attributes is described below:
4.3.1. unit_of_analysis¶
Data can be analysed at multiple levels, for instance at the care provision, patient, practitioner and organizational levels. The unit of analysis is a composite object that can hold any number of unit objects. Each entity that plays a role for the specific base value record must be listed in the unit of analysis object.
The next example shows a unit of analysis object with 6 unit objects, in JSON form:
{
"subject": {
"id": "Patient 1"
},
"organization": {
"id": "Hospital 19"
},
"performer": {
"id": "Practitioner 123",
"class": "Role"
},
"author": {
"id": "Practitioner 123",
"class": "Role"
},
"carePlan": {
"id": "Diabetic Treatment 12345"
},
"dataEnterer": {
"id": "Practitioner 123"
}
}
Note
The base value record may not contain newlines. For the sake of readability only, the examples are pretty printed with newlines.
4.3.1.1. Unit object¶
The objects that are associated with each key describe the units. Every unit object itself can have any number of (nested) properties. Two keys in the unit objects have special meaning:
id(mandatory) contains the unique identifier of the unit. Theidvalue is used to look up an existing record at data import.class(optional) holds the name of the class in which theidvalue should be looked up. Ifclassis not listed, the reference to the unit,subjectororganizationin the example above, is used as class. In the example abovePractitioner 123is bothperformerandauthor, but refer the same object in the class Role.
The next example shows class usage. This is a unit of analysis
created from a HL7v3 CDA based Portavita Benchmark document:
{
"performer": {
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.3",
"extension": "18"
}],
"class": "Role"
},
"author": {
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.3",
"extension": "18"
}],
"class": "Role"
},
"dataEnterer": {
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.3",
"extension": "18"
}],
"class": "Role"
},
"custodian": {
"representedCustodianOrganization": {
"class": "Organization",
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.2",
"extension": "0"
}],
"name": "Portavita B.V."
},
"class": "Role",
"id": {
"_rimname": "Role",
"_mif": "POCD_MT000040",
"representedCustodianOrganization": {
"_clonename": "CustodianOrganization",
"name": {
"content": "Portavita B.V.",
"dataType": "ON"
},
"classCode": "ORG",
"_mif": "POCD_MT000040",
"determinerCode": "INSTANCE",
"_rimname": "Organization",
"id": [{
"dataType": "II",
"root": "2.16.840.1.113883.2.4.3.31.3.2",
"extension": "0"
}]
},
"classCode": "ASSIGNED",
"_clonename": "AssignedCustodian"
}
},
"Organizer(170744004)": {
"id": 1,
"class": "Act"
},
"legalAuthenticator": {
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.3",
"extension": "18"
}],
"class": "Role"
},
"recordTarget": {
"id": [{
"root": "2.16.840.1.113883.2.4.3.31.3.3",
"extension": "290"
}],
"class": "Patient"
},
"Organizer(170744004)-2": {
"id": 2,
"class": "Act"
}
}
Note
Aperture has no knowledge of the meaning of each of the additional attributes. Adding the additional keys only serves the purpose of adding information that might be used for output in data columns, or for constructing new features.
All values can be selected as a column in a data set. Aperture does not dictate a vocabulary for the unit of analysis keys.
The next example is from the Perinatology (Dutch) registry. In this example there are 9 units of analysis.
{
"CareProvisionEvent(atLevel6)": {
"class": "Act",
"id": [{
"dataType": "II",
"extension": "152004",
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.3.1"
}]
},
"Message": {
"acceptAckCode": "AL",
"class": "Message",
"creationTime": "20150709164642",
"id": {
"extension": "79",
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.1.1"
},
"interactionId": {
"extension": "REPC_IN004014NL",
"root": "2.16.840.1.113883.1.6"
},
"profileId": {
"extension": "810",
"root": "2.16.840.1.113883.2.4.3.11.1"
}
},
"RegistrationProcess(900000)": {
"class": "Act",
"id": [{
"dataType": "II",
"extension": "rps4632856243",
"root": "2.16.840.1.113883.2.4.99.23444.6"
}]
},
"authorOrPerformer": {
"Organization": {
"addr": ["Lomanstraat 59 1075 PW Amsterdam"],
"class": "Organization",
"code": {
"code": "G3",
"system": "2.16.840.1.113883.2.4.15.1060"
},
"id": [{
"extension": "00013482",
"root": "2.16.528.1.1007.3.3"
}, {
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1"
}, {
"extension": "08000000",
"root": "2.16.840.1.113883.2.4.6.1"
}, {
"extension": "1410",
"root": "2.16.840.1.113883.2.4.3.22.96.6"
}],
"name": ["PRN Kernset Testpraktijk-1410-Scenario-4"]
},
"assignedPrincipalChoiceList": {
"class": "Person",
"id": {
"_clonename": "Person",
"_mif": "COCT_MT090100",
"_rimname": "Person",
"classCode": "PSN",
"determinerCode": "INSTANCE",
"name": [{
"dataType": "EN",
"family": [{
"content": "Loman",
"dataType": "ENXP",
"integrityCheckAlgorithm": "SHA-1",
"mediaType": "text/plain",
"partType": "FAM",
"representation": "TXT"
}],
"given": [{
"content": "Lonke",
"dataType": "ENXP",
"integrityCheckAlgorithm": "SHA-1",
"mediaType": "text/plain",
"partType": "GIV",
"representation": "TXT"
}],
"use": "L"
}]
},
"name": ["Lonke Loman"]
},
"class": "Role",
"code": {
"code": "03.000",
"system": "2.16.840.1.113883.2.4.15.111"
},
"id": [{
"extension": "000012349",
"root": "2.16.528.1.1007.3.1"
}, {
"extension": "08000000",
"root": "2.16.840.1.113883.2.4.6.1"
}, {
"extension": "8080",
"root": "2.16.840.1.113883.2.4.3.22.98.2"
}]
},
"overseer": {
"Organization": {
"addr": ["Lomanstraat 59 1075 PW Amsterdam"],
"class": "Organization",
"code": {
"code": "G3",
"system": "2.16.840.1.113883.2.4.15.1060"
},
"id": [{
"extension": "00013482",
"root": "2.16.528.1.1007.3.3"
}, {
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1"
}, {
"extension": "08000000",
"root": "2.16.840.1.113883.2.4.6.1"
}, {
"extension": "1410",
"root": "2.16.840.1.113883.2.4.3.22.96.6"
}],
"name": ["PRN Kernset Testpraktijk-1410-Scenario-4"]
},
"assignedPrincipalChoiceList": {
"class": "Person",
"id": {
"_clonename": "Person",
"_mif": "COCT_MT090100",
"_rimname": "Person",
"classCode": "PSN",
"determinerCode": "INSTANCE",
"name": [{
"dataType": "EN",
"family": [{
"content": "Loman",
"dataType": "ENXP",
"integrityCheckAlgorithm": "SHA-1",
"mediaType": "text/plain",
"partType": "FAM",
"representation": "TXT"
}],
"given": [{
"content": "Lonke",
"dataType": "ENXP",
"integrityCheckAlgorithm": "SHA-1",
"mediaType": "text/plain",
"partType": "GIV",
"representation": "TXT"
}],
"use": "L"
}]
},
"name": ["Lonke Loman"]
},
"class": "Role",
"code": {
"code": "03.000",
"system": "2.16.840.1.113883.2.4.15.111"
},
"id": [{
"extension": "000012349",
"root": "2.16.528.1.1007.3.1"
}, {
"extension": "08000000",
"root": "2.16.840.1.113883.2.4.6.1"
}, {
"extension": "8080",
"root": "2.16.840.1.113883.2.4.3.22.98.2"
}]
},
"receiver": {
"class": "Device",
"id": [{
"extension": "HL7Test",
"root": "2.16.840.1.113883.2.4.3.38.1.1"
}]
},
"sender": {
"class": "Device",
"id": [{
"extension": "1",
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.2.3"
}],
"name": ["Orfeus 3.10.17 - (08-07-2015)-PRN Kernset Testpraktijk-1410-Scenario-4"]
},
"subject": {
"addr": ["4589 BA"],
"class": "Patient",
"id": [{
"extension": "850810711",
"root": "2.16.840.1.113883.2.4.6.3"
}, {
"extension": "42185,4143981481",
"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.4.1"
}]
},
"verifier": {
"class": "Role",
"id": {
"_clonename": "AssignedPerson",
"_mif": "COCT_MT090100",
"_rimname": "Role",
"classCode": "ASSIGNED",
"representedOrganization": {
"_clonename": "Organization",
"_mif": "COCT_MT150000",
"_rimname": "Organization",
"classCode": "ORG",
"determinerCode": "INSTANCE",
"id": [{
"dataType": "II",
"extension": "1410",
"root": "2.16.840.1.113883.2.4.3.22.96.6"
}]
}
},
"representedOrganization": {
"class": "Organization",
"id": [{
"extension": "1410",
"root": "2.16.840.1.113883.2.4.3.22.96.6"
}]
}
}
}
4.3.2. unit_update¶
If this attribute is Null or False, the unit of analysis objects will only be used to lookup existing units in the target database. If no existing unit is found, it will be created using the information provided in the Unit object.
If this attribute is True, any existing information in the target database will be updated with the information provided for all Unit object in the unit_of_analysis column. If unit_update is True, the feature and value columns are ignored: no value needs to be provided to perform a unit update.
4.3.3. feature¶
The feature attribute uniquely identifies the measured property. Required are the id and display keys.
id is a string that uniquely identifies the feature. The identifier string itself bears no additional meaning. The next
example is taken from the Portavita Benchmark. The last part of feature.id is formed by the Observation.code
attribute. The observation code is augmented with information from the organizer in which the observation was listed.
In a similar way, the display key is constructed:
{
"id": "DOCBODY|DOCSECT|CLUSTER(Portavita141:2.16.840.1.113883.2.4.3.31.2.1)|OBS(22298006:2.16.840.1.113883.6.96)",
"display": "StructuredBody Section Organizer Risicofactoren Myocardial infarction"
}
Note
The base values record does not have a specific attribute for a negation indicator, as is known from the HL7v3 standard. If the negation indicator is interpreted as a value negation indicator, it often replicates expressiveness already present in the value domain of an existing data type. If the negation indicator is interpreted as an action negation indicator, such as do not administer drug x, this can be regarded as a new feature. If a non null negation indicator is listed in source information, the only option is to include its value in the name of the feature.
Below follow two examples from the Perinatology (Dutch) registry.
All container like acts are named in the id and display, so features read from e.g. the history part of the
document can be discerned from features of the current delivery.
Also note how negationInd is recorded in the second
feature. By including an existing negationIndicator value in the feature name,
it is possible to express that it is known that the patient has no diabetes.
{
"id": "REG(900000:2.16.840.1.113883.2.4.15.4)|PCPR|CONTAINER(248983002:2.16.840.1.113883.6.96)|PROC(236973005:2.16.840.1.113883.6.96)|PROC(Baring:2.16.840.1.113883.2.4.3.22.1.3)|OBS(301334000:2.16.840.1.113883.6.96)",
"display": "Perinatale Care Provision CareProvisionEvent Obstetric history Delivery procedure (procedure) Procedure(Baring:2.16.840.1.113883.2.4.3.22.1.3) Birth weight centile (observable entity)"
}
{
"id": "REG(900000:2.16.840.1.113883.2.4.15.4)|PCPR|CONTAINER(417662000:2.16.840.1.113883.6.96)|CONTAINER(312850006:2.16.840.1.113883.6.96)|OBS(73211009:2.16.840.1.113883.6.96)N",
"display": "RegistrationProcess(900000:2.16.840.1.113883.2.4.15.4) CareProvisionEvent Past history of clinical finding History of - disorder Diabetes mellitus (disorder) (Negated)"
}
4.3.4. datatype¶
All datatypes that the target database supports can be used. Since PostgreSQL is an extensible database, the complete set of supported types depends on the extensions that are loaded, such as the MGRID Healthcare Datatype Library.
Commonly used types are the following:
4.3.4.1. text¶
The text value format is the format to go to when the data type or quality of incoming data is not known. By importing into text format, all data can be accepted in base_values form, for later data cleaning into new base values with proper types with feature construction.
4.3.4.2. numeric¶
Numeric values, also known as real values.
4.3.4.3. integer¶
Discrete integer values.
4.3.4.4. code¶
The code datatype can be used for categorical variables that have an underlying code system. While categorical data can also be stored using a string value alone – the code in the value_text attribute – by capturing the full code system information together with the code system version, more knowledge is kept about the meaning of a certain code. This is useful for longitudinal analysis and detection of sources of discontinuities.
The json blob must be formatted like the FHIR Coding datatype:
{
"system" : "<uri>", // Identity of the terminology system
"version" : "<string>", // Version of the system - if relevant
"code" : "<code>", // Required, symbol in syntax defined by the system
"display" : "<string>", // Required, representation defined by the system
"userSelected" : <boolean> // If this coding was chosen directly by the user
}
For instance, the following value encodes normal ECG finding in the SNOMED-CT codesystem:
{
"code": "102593009",
"system": "2.16.840.1.113883.6.96",
"display": "Normal ('normal ECG (finding)')"
}
When a coded value is exported in a column in a data set, the Aperture user can choose any key to export. In many cases,
exporting only the code property will suffice, but for cases where the code alone does not guarantee unique values,
it is also possible to add an additional column to export any other property of the value_code attribute.
The following datatypes of MGRID HDL Simple Types are also useful:
4.3.4.5. pq¶
The physical quantity datatype as implemented by the MGRID healthcare datatype library. The PQ datatype accepts only input that strictly conforms to the PQ and UCUM specifications. See the PQ documentation for more information about the accepted literal forms and supported operators for calculations.
4.3.4.6. ivl_pq¶
This datatype can store and perform calculations on intervals of physical quantities. Therapeutic ranges are examples of intervals of pqs. See IVL_PQ for a description of the literal form. Like the pq type, ivl_pq will reject incorrect values. If it is unknown whether all ivl_pq values will conform at data load time, use value_text to import data, and use feature construction to convert to ivl_pq and catch errors.
4.3.4.7. cv¶
The cv datatypes provides an alternative to code to store coded categorical values. The CV datatype enables containment and subsumption calculations. Since value_cv will raise errors (or warnings, depending on a configuration setting), it is advised not to populate cv values on data source input. Instead, convert value_code to value_cv using feature construction, to enable further cv calculations.
4.3.4.8. bl¶
This boolean datatype can store true, false and all HL7 NullFlavors. See the BL documentation.
4.3.4.9. ts¶
The value_ts attribute can store temporal data. The accepted literal forms are described in the TS documentation.
Storing temporal data other than the time_* attributes is useful for capturing appointment data, for instance when
on Jan
1 2015 a next appointment for observation on Jan 7 2015 was made, value_ts can be used to store Jan 7 2015.
4.3.5. value¶
The value attribute in the base value record must contain the text literal form of the value,
as is appropriate for the corresponding datatype. If the value is null (expressed in COPY form as \N),
any existing value in the database for exact same set of units of analysis will be deleted.
4.3.6. time_lowvalue¶
time_lowvalue is one of three attributes in in the base value record that describe temporal information of the base values event. For point observations, time_lowvalue is the point in time. For time intervals, time_lowvalue is the start time of the interval. This is a required attribute.
4.3.7. time_highvalue¶
time_highvalue defines the end time of the time interval during which the information described by the base values record was true.
4.3.8. time_availability¶
The time at which this base value record became known to this system.
4.4. Example¶
The next line shows an example of a complete physical form base value record. The unit of analysis and
feature json objects are not pretty printed, and the standard PostgreSQL delimiter and null characters are used:
columns are separated by the tab character, and Null’s are represented
by the literal \N. More information about this format is provided in the documentation of the
PostgreSQL COPY command in the Text Format section.
{"CareProvisionEvent(atLevel6)": {"id": [{"dataType": "II", "root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.3.1", "extension": "152004"}], "class": "Act"}, "RegistrationProcess(900000)": {"id": [{"dataType": "II", "root": "2.16.840.1.113883.2.4.99.23444.6", "extension": "rps4632856243"}], "class": "Act"}, "sender": {"class": "Device", "name": ["Orfeus 3.10.17 - (08-07-2015)-PRN Kernset Testpraktijk-1410-Scenario-4"], "id": [{"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.2.3", "extension": "1"}]}, "Organizer(417662000)": {"id": 1, "class": "Act"}, "authorOrPerformer": {"code": {"code": "03.000", "system": "2.16.840.1.113883.2.4.15.111"}, "Organization": {"addr": ["Lomanstraat 59 1075 PW Amsterdam"], "class": "Organization", "code": {"code": "G3", "system": "2.16.840.1.113883.2.4.15.1060"}, "id": [{"root": "2.16.528.1.1007.3.3", "extension": "00013482"}, {"root": "2.16.528.1.1007.3.3.53543.1.2.3.1"}, {"root": "2.16.840.1.113883.2.4.6.1", "extension": "08000000"}, {"root": "2.16.840.1.113883.2.4.3.22.96.6", "extension": "1410"}], "name": ["PRN Kernset Testpraktijk-1410-Scenario-4"]}, "assignedPrincipalChoiceList": {"id": {"_clonename": "Person", "name": [{"dataType": "EN", "given": [{"integrityCheckAlgorithm": "SHA-1", "partType": "GIV", "dataType": "ENXP", "mediaType": "text/plain", "content": "Lonke", "representation": "TXT"}], "use": "L", "family": [{"integrityCheckAlgorithm": "SHA-1", "partType": "FAM", "dataType": "ENXP", "mediaType": "text/plain", "content": "Loman", "representation": "TXT"}]}], "classCode": "PSN", "_mif": "COCT_MT090100", "determinerCode": "INSTANCE", "_rimname": "Person"}, "name": ["Lonke Loman"], "class": "Person"}, "id": [{"root": "2.16.528.1.1007.3.1", "extension": "000012349"}, {"root": "2.16.840.1.113883.2.4.6.1", "extension": "08000000"}, {"root": "2.16.840.1.113883.2.4.3.22.98.2", "extension": "8080"}], "class": "Role"}, "receiver": {"id": [{"root": "2.16.840.1.113883.2.4.3.38.1.1", "extension": "HL7Test"}], "class": "Device"}, "verifier": {"id": {"_rimname": "Role", "_mif": "COCT_MT090100", "representedOrganization": {"_clonename": "Organization", "classCode": "ORG", "_mif": "COCT_MT150000", "determinerCode": "INSTANCE", "_rimname": "Organization", "id": [{"dataType": "II", "root": "2.16.840.1.113883.2.4.3.22.96.6", "extension": "1410"}]}, "classCode": "ASSIGNED", "_clonename": "AssignedPerson"}, "representedOrganization": {"id": [{"root": "2.16.840.1.113883.2.4.3.22.96.6", "extension": "1410"}], "class": "Organization"}, "class": "Role"}, "overseer": {"code": {"code": "03.000", "system": "2.16.840.1.113883.2.4.15.111"}, "Organization": {"addr": ["Lomanstraat 59 1075 PW Amsterdam"], "class": "Organization", "code": {"code": "G3", "system": "2.16.840.1.113883.2.4.15.1060"}, "id": [{"root": "2.16.528.1.1007.3.3", "extension": "00013482"}, {"root": "2.16.528.1.1007.3.3.53543.1.2.3.1"}, {"root": "2.16.840.1.113883.2.4.6.1", "extension": "08000000"}, {"root": "2.16.840.1.113883.2.4.3.22.96.6", "extension": "1410"}], "name": ["PRN Kernset Testpraktijk-1410-Scenario-4"]}, "assignedPrincipalChoiceList": {"id": {"_clonename": "Person", "name": [{"dataType": "EN", "given": [{"integrityCheckAlgorithm": "SHA-1", "partType": "GIV", "dataType": "ENXP", "mediaType": "text/plain", "content": "Lonke", "representation": "TXT"}], "use": "L", "family": [{"integrityCheckAlgorithm": "SHA-1", "partType": "FAM", "dataType": "ENXP", "mediaType": "text/plain", "content": "Loman", "representation": "TXT"}]}], "classCode": "PSN", "_mif": "COCT_MT090100", "determinerCode": "INSTANCE", "_rimname": "Person"}, "name": ["Lonke Loman"], "class": "Person"}, "id": [{"root": "2.16.528.1.1007.3.1", "extension": "000012349"}, {"root": "2.16.840.1.113883.2.4.6.1", "extension": "08000000"}, {"root": "2.16.840.1.113883.2.4.3.22.98.2", "extension": "8080"}], "class": "Role"}, "Message": {"class": "Message", "profileId": {"root": "2.16.840.1.113883.2.4.3.11.1", "extension": "810"}, "interactionId": {"root": "2.16.840.1.113883.1.6", "extension": "REPC_IN004014NL"}, "creationTime": "20150709164642", "acceptAckCode": "AL", "id": {"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.1.1", "extension": "79"}}, "Organizer(312850006)": {"id": 1, "class": "Act"}, "subject": {"addr": ["4589 BA"], "class": "Patient", "id": [{"root": "2.16.840.1.113883.2.4.6.3", "extension": "850810711"}, {"root": "2.16.528.1.1007.3.3.53543.1.2.3.1.1.1.4.1", "extension": "42185,4143981481"}]}} \N {"id": "REG(900000:2.16.840.1.113883.2.4.15.4)|PCPR|CONTAINER(417662000:2.16.840.1.113883.6.96)|CONTAINER(312850006:2.16.840.1.113883.6.96)|OBS(42030000:2.16.840.1.113883.6.96)", "display": "RegistrationProcess(900000:2.16.840.1.113883.2.4.15.4) CareProvisionEvent Past history of clinical finding History of - disorder Observation(42030000:2.16.840.1.113883.6.96)"} code {"code": "61373006", "system": "2.16.840.1.113883.6.96"} 20140807 20140915 \N