This wiki has undergone a migration to Confluence found Here
Difference between revisions of "JSON based ITS"
Jump to navigation
Jump to search
| Line 96: | Line 96: | ||
==Discussion== | ==Discussion== | ||
* Validation using OCL? | * Validation using OCL? | ||
| + | * Validation using JSON Schema, see [http://blogs.zdnet.com/service-oriented/?p=3847 New 'Orderly' schema threatens XML dominance?] | ||
* Polymorphism and "xsi:type". In this example we see the "xsi:type" attribute being demoted to an "ordinary" attribute. In fact this should signal the JSON-processor that it should deserialize the data to a certain type. Unfortunately JSON does not yet support this kind of typing. How to handle this? | * Polymorphism and "xsi:type". In this example we see the "xsi:type" attribute being demoted to an "ordinary" attribute. In fact this should signal the JSON-processor that it should deserialize the data to a certain type. Unfortunately JSON does not yet support this kind of typing. How to handle this? | ||
Revision as of 20:10, 4 January 2010
Summary
JSON encoding rather than XML. Or even binary/zipped. See also "(informational only) New ITS - RIM based ITS" RIMBAA_200901_WGM_Minutes
Analysis
XML is not the most performant way to send information. Image taken from: http://viswaug.wordpress.com/2008/01/23/json-over-xml/ JSON has proven to be much more efficient in parsing and size. One thing I did not expect is that the JSON version (1596 chars) is larger than the XML version (1346 chars).
Example XML
<organizer classCode="ORGANIZER" xmlns="urn:hl7-org:v3">
<templateId root="2.16.840.1.113883.2.4.3.8.1000.9" extension="660d999b-0157-41c2-8f2b-762d101aa279"/>
<code code="RJM2009021801" codeSystem="2.16.840.1.113883.2.4.3.8.1000.21" codeSystemName="UMCG Tijdelijk">
<originalText>Diagnosis</originalText>
</code>
<recordTarget typeCode="RCT">
<patient classCode="PAT">
<id root="2.16.840.1.113883.2.4.3.8.12" extension="2761703" assigningAuthorityName="UMCG"/>
</patient>
</recordTarget>
<component typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<id root="2.16.840.1.113883.2.4.3.8.1000.31" extension="491216"/>
Example JSON
"organizer": { "@classCode": "ORGANIZER", "@xmlns": "urn:hl7-org:v3",
"templateId": {
"@root": "2.16.840.1.113883.2.4.3.8.1000.9",
"@extension": "660d999b-0157-41c2-8f2b-762d101aa279"
},
"code": {
"@code": "RJM2009021801",
"@codeSystem": "2.16.840.1.113883.2.4.3.8.1000.21",
"@codeSystemName": "UMCG Tijdelijk",
"originalText": "Diagnosis"
},
"recordTarget": { "@typeCode": "RCT",
"patient": { "@classCode": "PAT",
"id": {
"@root": "2.16.840.1.113883.2.4.3.8.12",
"@extension: "2761703",
"@assigningAuthorityName": "UMCG"
}
}
},
"component": { "@typeCode": "COMP",
"observation": { "@classCode": "OBS", "@moodCode": "EVN",
"id": {
"@root": "2.16.840.1.113883.2.4.3.8.1000.31",
"@extension": "491216"
},
"code": {
"@code": "DX",
"@codeSystem": "2.16.840.1.113883.1.11.16228",
"@codeSystemName": "ObservationDiagnosisTypes"
},
"text": null,
"effectiveTime" { "value": "20060329" },
"value": { "@xsi:type": "CD",
"@code": "474.10",
"@codeSystem": "2.16.840.1.113883.6.103",
"@codeSystemName": "ICD-9-CM"
"originalText": "Otitis media / niet gespecificeerd"
}
"author": { "@typeCode": "AUT",
"assignedEntity": { "@classCode": "ASSIGNED",
"id": {
"@root": "2.16.840.1.113883.2.4.3.8.1000.8",
"@extension": "KNO"
}
}
}
}
}
};
Discussion
- Validation using OCL?
- Validation using JSON Schema, see New 'Orderly' schema threatens XML dominance?
- Polymorphism and "xsi:type". In this example we see the "xsi:type" attribute being demoted to an "ordinary" attribute. In fact this should signal the JSON-processor that it should deserialize the data to a certain type. Unfortunately JSON does not yet support this kind of typing. How to handle this?
