Evaluation of ISO EN 13606 as a result of its implementation in XML
Identifieur interne : 000189 ( Pmc/Corpus ); précédent : 000188; suivant : 000190Evaluation of ISO EN 13606 as a result of its implementation in XML
Auteurs : Tony Austin ; Shanghua SunSource :
- Health Informatics Journal [ 1460-4582 ] ; 2013.
Abstract
The five parts of the ISO EN 13606 standard define a means by which health-care records can be exchanged between computer systems. Starting within the European standardisation process, it has now become internationally ratified in ISO. However, ISO standards do not require that a reference implementation be provided, and in order for ISO EN 13606 to deliver the expected benefits, it must be provided not as a document, but as an operational system that is not vendor specific. This article describes the evolution of an Extensible Markup Language (XML) Schema through three iterations, each of which emphasised one particular approach to delivering an executable equivalent to the printed standard. Developing these operational versions and incorporating feedback from users of these demonstrated where implementation compromises were needed and exposed defects in the standard. These are discussed herein. They may require a future technical revision to ISO EN 13606 to resolve the issues identified.
Url:
DOI: 10.1177/1460458212473993
PubMed: 23995217
PubMed Central: 4107818
Links to Exploration step
PMC:4107818Le document en format XML
<record><TEI><teiHeader><fileDesc><titleStmt><title xml:lang="en">Evaluation of ISO EN 13606 as a result of its implementation in
XML</title>
<author><name sortKey="Austin, Tony" sort="Austin, Tony" uniqKey="Austin T" first="Tony" last="Austin">Tony Austin</name>
</author>
<author><name sortKey="Sun, Shanghua" sort="Sun, Shanghua" uniqKey="Sun S" first="Shanghua" last="Sun">Shanghua Sun</name>
</author>
</titleStmt>
<publicationStmt><idno type="wicri:source">PMC</idno>
<idno type="pmid">23995217</idno>
<idno type="pmc">4107818</idno>
<idno type="url">http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4107818</idno>
<idno type="RBID">PMC:4107818</idno>
<idno type="doi">10.1177/1460458212473993</idno>
<date when="2013">2013</date>
<idno type="wicri:Area/Pmc/Corpus">000189</idno>
<idno type="wicri:explorRef" wicri:stream="Pmc" wicri:step="Corpus" wicri:corpus="PMC">000189</idno>
</publicationStmt>
<sourceDesc><biblStruct><analytic><title xml:lang="en" level="a" type="main">Evaluation of ISO EN 13606 as a result of its implementation in
XML</title>
<author><name sortKey="Austin, Tony" sort="Austin, Tony" uniqKey="Austin T" first="Tony" last="Austin">Tony Austin</name>
</author>
<author><name sortKey="Sun, Shanghua" sort="Sun, Shanghua" uniqKey="Sun S" first="Shanghua" last="Sun">Shanghua Sun</name>
</author>
</analytic>
<series><title level="j">Health Informatics Journal</title>
<idno type="ISSN">1460-4582</idno>
<idno type="eISSN">1741-2811</idno>
<imprint><date when="2013">2013</date>
</imprint>
</series>
</biblStruct>
</sourceDesc>
</fileDesc>
<profileDesc><textClass></textClass>
</profileDesc>
</teiHeader>
<front><div type="abstract" xml:lang="en"><p>The five parts of the ISO EN 13606 standard define a means by which health-care records
can be exchanged between computer systems. Starting within the European standardisation
process, it has now become internationally ratified in ISO. However, ISO standards do not
require that a reference implementation be provided, and in order for ISO EN 13606 to
deliver the expected benefits, it must be provided not as a document, but as an
operational system that is not vendor specific. This article describes the evolution of an
Extensible Markup Language (XML) Schema through three iterations, each of which emphasised
one particular approach to delivering an executable equivalent to the printed standard.
Developing these operational versions and incorporating feedback from users of these
demonstrated where implementation compromises were needed and exposed defects in the
standard. These are discussed herein. They may require a future technical revision to ISO
EN 13606 to resolve the issues identified.</p>
</div>
</front>
<back><div1 type="bibliography"><listBibl><biblStruct><analytic><author><name sortKey="Tange, Hj" uniqKey="Tange H">HJ Tange</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Kalra, D" uniqKey="Kalra D">D Kalra</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Lloyd, D" uniqKey="Lloyd D">D Lloyd</name>
</author>
<author><name sortKey="Kalra, D" uniqKey="Kalra D">D Kalra</name>
</author>
<author><name sortKey="Beale, T" uniqKey="Beale T">T Beale</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Grimson, J" uniqKey="Grimson J">J Grimson</name>
</author>
<author><name sortKey="Grimson, W" uniqKey="Grimson W">W Grimson</name>
</author>
<author><name sortKey="Berry, D" uniqKey="Berry D">D Berry</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Sottile, Pa" uniqKey="Sottile P">PA Sottile</name>
</author>
<author><name sortKey="Ferrara, Fm" uniqKey="Ferrara F">FM Ferrara</name>
</author>
<author><name sortKey="Grimson, W" uniqKey="Grimson W">W Grimson</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dixon, R" uniqKey="Dixon R">R Dixon</name>
</author>
<author><name sortKey="Grubb, Pa" uniqKey="Grubb P">PA Grubb</name>
</author>
<author><name sortKey="Lloyd, D" uniqKey="Lloyd D">D Lloyd</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Hurlen, P" uniqKey="Hurlen P">P Hurlen</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Kay, S" uniqKey="Kay S">S Kay</name>
</author>
<author><name sortKey="Marley, T" uniqKey="Marley T">T Marley</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Rossi Mori, A" uniqKey="Rossi Mori A">A Rossi Mori</name>
</author>
<author><name sortKey="Kalra, D" uniqKey="Kalra D">D Kalra</name>
</author>
<author><name sortKey="Rodrigues, Jm" uniqKey="Rodrigues J">JM Rodrigues</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Hopkins, R" uniqKey="Hopkins R">R Hopkins</name>
</author>
<author><name sortKey="Gr Tan, T" uniqKey="Gr Tan T">T Grøtan</name>
</author>
<author><name sortKey="Nystadnes, T" uniqKey="Nystadnes T">T Nystadnes</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Markwell, D" uniqKey="Markwell D">D Markwell</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Turner, L" uniqKey="Turner L">L. Turner</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Pitty, D" uniqKey="Pitty D">D Pitty</name>
</author>
<author><name sortKey="Gordon, C" uniqKey="Gordon C">C Gordon</name>
</author>
<author><name sortKey="Reeves, P" uniqKey="Reeves P">P Reeves</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Bray, T" uniqKey="Bray T">T Bray</name>
</author>
<author><name sortKey="Paoli, J" uniqKey="Paoli J">J Paoli</name>
</author>
<author><name sortKey="Sperberg Mcqueen, Cm" uniqKey="Sperberg Mcqueen C">CM Sperberg-McQueen</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Dolin, Rh" uniqKey="Dolin R">RH Dolin</name>
</author>
<author><name sortKey="Alschuler, L" uniqKey="Alschuler L">L Alschuler</name>
</author>
<author><name sortKey="Bray, T" uniqKey="Bray T">T Bray</name>
</author>
</analytic>
</biblStruct>
<biblStruct><analytic><author><name sortKey="Takeda, H" uniqKey="Takeda H">H Takeda</name>
</author>
<author><name sortKey="Matsumura, Y" uniqKey="Matsumura Y">Y Matsumura</name>
</author>
<author><name sortKey="Kuwata, S" uniqKey="Kuwata S">S Kuwata</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Austin, T" uniqKey="Austin T">T Austin</name>
</author>
<author><name sortKey="Lim, Ys" uniqKey="Lim Y">YS Lim</name>
</author>
<author><name sortKey="Nguyen, D" uniqKey="Nguyen D">D Nguyen</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Sun, S" uniqKey="Sun S">S Sun</name>
</author>
<author><name sortKey="Austin, T" uniqKey="Austin T">T Austin</name>
</author>
<author><name sortKey="Kalra, D" uniqKey="Kalra D">D Kalra</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct><analytic><author><name sortKey="Meyer, B" uniqKey="Meyer B">B Meyer</name>
</author>
</analytic>
</biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
<biblStruct></biblStruct>
</listBibl>
</div1>
</back>
</TEI>
<pmc article-type="research-article"><pmc-dir>properties open_access</pmc-dir>
<front><journal-meta><journal-id journal-id-type="nlm-ta">Health Informatics J</journal-id>
<journal-id journal-id-type="iso-abbrev">Health Informatics J</journal-id>
<journal-id journal-id-type="publisher-id">JHI</journal-id>
<journal-id journal-id-type="hwp">spjhi</journal-id>
<journal-title-group><journal-title>Health Informatics Journal</journal-title>
</journal-title-group>
<issn pub-type="ppub">1460-4582</issn>
<issn pub-type="epub">1741-2811</issn>
<publisher><publisher-name>SAGE Publications</publisher-name>
<publisher-loc>Sage UK: London, England</publisher-loc>
</publisher>
</journal-meta>
<article-meta><article-id pub-id-type="pmid">23995217</article-id>
<article-id pub-id-type="pmc">4107818</article-id>
<article-id pub-id-type="doi">10.1177/1460458212473993</article-id>
<article-id pub-id-type="publisher-id">10.1177_1460458212473993</article-id>
<article-categories><subj-group subj-group-type="heading"><subject>Articles</subject>
</subj-group>
</article-categories>
<title-group><article-title>Evaluation of ISO EN 13606 as a result of its implementation in
XML</article-title>
</title-group>
<contrib-group><contrib contrib-type="author" corresp="yes"><name><surname>Austin</surname>
<given-names>Tony</given-names>
</name>
<aff id="aff1-1460458212473993">University College London, UK</aff>
</contrib>
<contrib contrib-type="author"><name><surname>Sun</surname>
<given-names>Shanghua</given-names>
</name>
<aff id="aff2-1460458212473993">St. George’s, University of London, UK</aff>
</contrib>
</contrib-group>
<contrib-group><contrib contrib-type="author"><name><surname>Hassan</surname>
<given-names>Taher</given-names>
</name>
</contrib>
<contrib contrib-type="author"><name><surname>Kalra</surname>
<given-names>Dipak</given-names>
</name>
</contrib>
<aff id="aff3-1460458212473993">University College London, UK</aff>
</contrib-group>
<author-notes><corresp id="corresp1-1460458212473993">Tony Austin, CHIME, University College London, 4th
Floor, Holborn Union Building, London N19 5LW, UK. Email: <email>tony.austin@ucl.ac.uk</email>
</corresp>
</author-notes>
<pub-date pub-type="epub-ppub"><month>12</month>
<year>2013</year>
</pub-date>
<pmc-comment>Fake ppub date generated by PMC from publisher
pub-date/@pub-type='epub-ppub' </pmc-comment>
<pub-date pub-type="ppub"><month>12</month>
<year>2013</year>
</pub-date>
<volume>19</volume>
<issue>4</issue>
<fpage>264</fpage>
<lpage>280</lpage>
<permissions><copyright-statement>© The Author(s) 2013</copyright-statement>
<copyright-year>2013</copyright-year>
<copyright-holder content-type="sage">SAGE Publications</copyright-holder>
<license license-type="open-access" xlink:href="http://creativecommons.org/licenses/by-nc/3.0/"><license-p>This article is distributed under the terms of the Creative Commons
Attribution-NonCommercial 3.0 License (<ext-link ext-link-type="uri" xlink:href="http://www.creativecommons.org/licenses/by-nc/3.0/">http://www.creativecommons.org/licenses/by-nc/3.0/</ext-link>
) which permits
non-commercial use, reproduction and distribution of the work without further permission
provided the original work is attributed as specified on the SAGE and Open Access
page(<ext-link ext-link-type="uri" xlink:href="http://www.uk.sagepub.com/aboutus/openaccess.htm">http://www.uk.sagepub.com/aboutus/openaccess.htm</ext-link>
).</license-p>
</license>
</permissions>
<abstract><p>The five parts of the ISO EN 13606 standard define a means by which health-care records
can be exchanged between computer systems. Starting within the European standardisation
process, it has now become internationally ratified in ISO. However, ISO standards do not
require that a reference implementation be provided, and in order for ISO EN 13606 to
deliver the expected benefits, it must be provided not as a document, but as an
operational system that is not vendor specific. This article describes the evolution of an
Extensible Markup Language (XML) Schema through three iterations, each of which emphasised
one particular approach to delivering an executable equivalent to the printed standard.
Developing these operational versions and incorporating feedback from users of these
demonstrated where implementation compromises were needed and exposed defects in the
standard. These are discussed herein. They may require a future technical revision to ISO
EN 13606 to resolve the issues identified.</p>
</abstract>
<kwd-group><kwd>Electronic healthcare record</kwd>
<kwd>ISO EN 13606</kwd>
<kwd>recommendations</kwd>
<kwd>standards</kwd>
</kwd-group>
</article-meta>
</front>
<body><sec sec-type="intro" id="section1-1460458212473993"><title>Introduction</title>
<p>This article examines the information models and vocabularies published in the ISO EN 13606
standard for electronic health record communication as the basis for defining an Extensible
Markup Language (XML) Schema. Such a schema is an important technical artefact to support
the adoption of the standard and its use for interoperability. In this research, the process
of developing a valid schema has been used as a method for validating the technical
correctness of the standard itself. The Introduction section describes the purpose and
overall structure of the ISO EN 13606 standard. The Method section describes the iterative
methodology adopted to develop the schema and to refine it by correcting for errors in the
published standard. The Comparative Schema Results section presents the errors identified in
the published standard. The Discussion section discusses the erroneous features of the
standard in relation to their intended requirements, the limitations of the study and also
its potential value as a contribution to the forthcoming revision to this standard by the
European Standardisation Committee (CEN) and International Standards Organisation (ISO).</p>
<p>Paper records do offer benefits for certain types of recording<sup><xref rid="bibr1-1460458212473993" ref-type="bibr">1</xref>
</sup>
but they suffer from well-known shortcomings in availability and searchability,<sup><xref rid="bibr2-1460458212473993" ref-type="bibr">2</xref>
</sup>
and the preference for storage is now usually computer-based. However, in many
jurisdictions, the legal owner of the record is not the patient but the clinical
organisation whose staff members authored the entries. Implicit is that records will be
created and stored in one or more physical systems and cannot be readily decommissioned into
a single ‘silo’ of medical information. Even if it were possible to do so, patient fears
about ready accessibility may prevent this from happening.<sup><xref rid="bibr3-1460458212473993" ref-type="bibr">3</xref>
</sup>
This means that while searchability may be locally improved by computerising records,
the availability issue may be less easily solved in practice.</p>
<p>Clinical judgement could clearly be improved if it were possible to draw supporting data
from other health-care organisations. However, apart from legal and political issues, there
are clinical barriers to this. It is not necessarily the case that two clinicians trained in
different places and with different backgrounds and experiences will have the same
understanding of a clinical concept even if it could be unambiguously expressed in every
conceivable natural language simultaneously.</p>
<sec id="section2-1460458212473993"><title>ISO EN 13606</title>
<p>Before even considering legal issues or those of clinical culture, other technical
barriers must be removed. To begin with, there must be a widely accepted standard for the
representation of clinical information that is itself clear and unambiguous that can be
shared among data producers and consumers. It was this realisation that drove the research
and development projects<sup><xref rid="bibr4-1460458212473993" ref-type="bibr">4</xref>
<xref rid="bibr5-1460458212473993" ref-type="bibr"></xref>
<xref rid="bibr6-1460458212473993" ref-type="bibr"></xref>
–<xref rid="bibr7-1460458212473993" ref-type="bibr">7</xref>
</sup>
from which standards through CEN<sup><xref rid="bibr8-1460458212473993" ref-type="bibr">8</xref>
</sup>
and identically in ISO were created. Such standards then in turn facilitate the
interoperability of different vendor products and enable enterprises to adopt a
multi-vendor best of breed solution to local information system requirements whilst
remaining consistent with the broader vision of communicable and lifelong health-care
records.</p>
<p>When the Technical Board of CEN approved the establishment of a Technical Committee for
Medical Informatics (TC 251) in May 1990, the Electronic Health-care Record (EHR) was
regarded as one of the most important and most urgent areas for the establishment of
European standards. Working Group I defined the scope and terms of reference for two work
items (WIs): WI 1.6 ‘Electronic Health-care Record Architecture’ (EHRA) and WI 1.8 ‘EHR
Extended Architecture’; these were intended to be the basis for two consecutive project
teams.</p>
<p>The Project Team under WI 1.6, PT1-011, developed a pre-standard (known as an ‘ENV’)
12265 EHRA.<sup><xref rid="bibr9-1460458212473993" ref-type="bibr">9</xref>
</sup>
ENV 12265 was a foundation standard defining the basic principles upon which EHRs
should be based. The Project Teams under WI 1.8 were convened in 1998 and published a
four-part EHR successor standard ENV 13606 in 1999. The Extended Architecture<sup><xref rid="bibr10-1460458212473993" ref-type="bibr">10</xref>
</sup>
was built on ENV 12265 and defined additional components for describing the
structures and semantics in EHRs conforming to a range of requirements to allow the
content of a health-care record to be constructed, used, shared and maintained.</p>
<p>A health-care domain model was developed to represent the requirements of clinical
practice including professional, ethical, legal and security requirements that must be
satisfied by the Extended Architecture, Domain Termlist and Distribution Rules. The Domain
Termlist part of this European pre-standard provided a set of measures to support various
degrees of interoperability of the EHRs created on different systems or by different teams
on the same system.<sup><xref rid="bibr11-1460458212473993" ref-type="bibr">11</xref>
</sup>
These measures were aimed at enhancing the likelihood that EHR entries could be
accessed or communicated. The Distribution Rules specified a set of data objects that
represent the rules for defining access privileges to part or whole EHRs, and the means by
which security policies and attributes can be defined and implemented.<sup><xref rid="bibr12-1460458212473993" ref-type="bibr">12</xref>
</sup>
It also defined the principles that should be employed within an audit trail log.
Finally, it defined a set of messages to enable the communication of part or whole EHRs in
response to a request message or a need to update a mirror repository of a patient’s EHR.<sup><xref rid="bibr13-1460458212473993" ref-type="bibr">13</xref>
</sup>
These messages were specified in a syntax-independent way (i.e. as message
information models), but the publication included an informative XML Document Type
Definition (DTD), which was found to be helpful to a number of implementers.</p>
<p>In December 2001 CEN TC 251 confirmed a new Task Force, EHRcom, to review ENV 13606 and
to propose a revision that could be adopted by CEN as a formal standard (‘EN’). The result
is intended as a rigorous and durable information architecture for representing the EHR,
in order to support the interoperability of systems and components that need to interact
with EHR services:</p>
<list list-type="bullet" id="list1-1460458212473993"><list-item><p>As discrete systems or as middleware components;</p>
</list-item>
<list-item><p>To access, transfer, add or modify health record entries;</p>
</list-item>
<list-item><p>Through electronic messages or distributed objects;</p>
</list-item>
<list-item><p>Preserving the original clinical meaning intended by the author and</p>
</list-item>
<list-item><p>Reflecting the confidentiality of those data as intended by the author and
patient.</p>
</list-item>
</list>
<p>As of 2010, all five parts of EN 13606 have been ratified in CEN and ISO. The five parts
cover the following:</p>
<list list-type="bullet" id="list2-1460458212473993"><list-item><p>An EHR reference model;</p>
</list-item>
<list-item><p>A clinical model interchange specification;</p>
</list-item>
<list-item><p>Reference term lists;</p>
</list-item>
<list-item><p>Security and audit arrangements; and</p>
</list-item>
<list-item><p>An interface specification.</p>
</list-item>
</list>
<p>Part 1 of ISO EN 13606 provides key classes that represent how an extract from a clinical
system will be delivered to a recipient. These include the following:</p>
<list list-type="simple" id="list3-1460458212473993"><list-item><p><italic>EHR_EXTRACT –</italic>
the top-level container of part or all of the EHR of a
single subject of care, for communication between an EHR Provider system and an EHR
Recipient.</p>
</list-item>
<list-item><p><italic>FOLDER</italic>
– the high-level organisation within an EHR, dividing it into
compartments relating to care provided for a single condition, by a clinical team or
institution, or over a fixed time period such as an episode of care. For example,
‘Diabetes care’, ‘Schizophrenia’, ‘St Mungo’s Hospital’, ‘GP Folder’, ‘Episodes
2000–2001’ and ‘Italy’.</p>
</list-item>
<list-item><p><italic>COMPOSITION –</italic>
the set of information committed to one EHR by one
agent, as a result of a single clinical encounter or record documentation session. For
example, ‘Progress note’, ‘Laboratory test result form’, ‘Radiology report’, ‘Referral
letter’, ‘Clinic visit’, ‘Discharge summary’ and ‘Diabetes review’.</p>
</list-item>
<list-item><p><italic>SECTION –</italic>
EHR data within a COMPOSITION that belongs under one
clinical heading, usually reflecting the flow of information gathering during a
clinical encounter, or structured for the benefit of future human readership. For
example, ‘Reason for encounter’, ‘Past history’, ‘Family history’, ‘Allergy
information’, ‘Subjective symptoms’, ‘Objective findings’, ‘Analysis’, ‘Plan’,
‘Treatment’, ‘Diet’, ‘Posture’ and ‘Abdominal examination’.</p>
</list-item>
<list-item><p><italic>ENTRY –</italic>
the information recorded in an EHR as a result of one
clinical action, one observation, one clinical interpretation or an intention. This is
also known as a clinical statement. For example, ‘Symptom’, ‘Observation’, ‘Test
result’, ‘Prescribed drug’, ‘Allergy reaction’, ‘Differential diagnosis’,
‘Differential white cell count’ and ‘Blood pressure measurement’.</p>
</list-item>
<list-item><p><italic>CLUSTER –</italic>
the means of organising nested multi-part data structures
such as time series, and to represent the columns of a table. For example, ‘Audiogram
results’, ‘Electro-encephalogram interpretation’ and ‘Weighted differential
diagnoses’.</p>
</list-item>
<list-item><p><italic>ELEMENT –</italic>
the leaf node of the EHR hierarchy, containing a single
data value. For example, ‘Systolic blood pressure’, ‘Heart rate’, ‘Drug name’,
‘Symptom’ and ‘Body weight’.</p>
</list-item>
</list>
<p>These primary record building blocks are then aggregated according to <xref ref-type="fig" rid="fig1-1460458212473993">Figure 1</xref>
.</p>
<fig id="fig1-1460458212473993" position="float"><label>Figure 1.</label>
<caption><p>Nesting in the EHR.</p>
<p>EHR: Electronic Health-Care Record.</p>
</caption>
<graphic xlink:href="10.1177_1460458212473993-fig1"></graphic>
</fig>
</sec>
<sec id="section3-1460458212473993"><title>XML</title>
<p>Any standard for clinical information exchange is likely to be large and complex, and the
burden on a medical system supplier compelled to deliver an accreditable version quickly
is great. Ideally, there would have to be a widely available vendor-neutral implementation
of the standard that suppliers could either use directly or refer to when building
systems, which would be available without excessive license encumbrance. However, ISO
standards do not require such a reference implementation to be made available.</p>
<p>The most common way of formatting documents in word processed documents is to embed
control codes (like ‘BOLD’) within them, which changes the way the document is formatted
from that moment on. This is known as the ‘specific coding’ of a document and emphasises
direct changes to a document’s presentation. Towards the end of the 1960s, an alternative
option called ‘generic coding’ was proposed in which markers representing the structure of
the text were included (such as that it requires an ‘AUTHOR’). A viewer is then free to
represent these as desired.<sup><xref rid="bibr14-1460458212473993" ref-type="bibr">14</xref>
</sup>
The latter was the approach used in the development of Standardised Generalised
Markup Language (SGML) that was approved by the Office of Official Publications of the
European Community and a year later became standard ISO 8879:1986.<sup><xref rid="bibr15-1460458212473993" ref-type="bibr">15</xref>
</sup>
HyperText Markup Language (HTML) includes both possibilities, using, for example,
tags to embolden text and tags to delineate paragraphs.</p>
<p>While SGML is optimised for documents and on the face of it might have been a worthy
representation for health-care records themselves, Pitty<sup><xref rid="bibr16-1460458212473993" ref-type="bibr">16</xref>
</sup>
notes that SGML does not separate functions for capture and display from those of
storage and representation, does not capture temporal and semantic relationships and does
not in itself standardise the DTD needed to make records sharable.</p>
<p>Derived from SGML, XML<sup><xref rid="bibr17-1460458212473993" ref-type="bibr">17</xref>
</sup>
was developed by an XML Working Group (originally known as the SGML Editorial
Review Board) formed under the auspices of the World Wide Web Consortium (W3C) in 1996 and
is a simple but flexible text format. It was originally designed for large-scale
electronic publishing, and it has an increasingly important role in exchange of a range of
data on the Internet. XML is a subset of SGML and emphasises interoperability with SGML
and HTML, and ease of implementation.</p>
<p>SGML has nevertheless been studied as a message interchange format in health care.<sup><xref rid="bibr18-1460458212473993" ref-type="bibr">18</xref>
</sup>
SGML and XML provide a very useful message exchange format by which structured
medical records might be sent between systems or institutions. Attempts have already been
made to apply XML for specific types of record exchange, for example, Medical Markup
Language (MML)<sup><xref rid="bibr19-1460458212473993" ref-type="bibr">19</xref>
</sup>
and even to encapsulate EN 13606.<sup><xref rid="bibr20-1460458212473993" ref-type="bibr">20</xref>
</sup>
</p>
<p>Irrespective of the suitability of XML for representing instances of record data, there
is an increasing desire to constrain such instances to clinically reasonable statements.
Both SGML and XML share a formalism (the DTD) that enables syntactically correct
specifications to be created. However, this lacks important features such as data types,
and in 1999, the W3C solicited requirements for a new schema language<sup><xref rid="bibr21-1460458212473993" ref-type="bibr">21</xref>
</sup>
that would provide these using XML itself.</p>
<p>However, although XML Schema can define ‘structure, content and semantics of XML documents’,<sup><xref rid="bibr22-1460458212473993" ref-type="bibr">22</xref>
</sup>
there are some specifications that cannot be made by a statically analysing grammar
parser alone. These tend to be those where a document inclusion is expected as the result
of another in a particular instance document. ISO/IEC 19757 part 3<sup><xref rid="bibr23-1460458212473993" ref-type="bibr">23</xref>
</sup>
defines a Document Schema Definition Language (DSDL) for rule-based validation
known as ‘Schematron’ that provides another layer of validation within instance documents
that ensures semantic relationships between values are maintained.</p>
<p>The lack of a reference implementation of ISO EN 13606 reduces its value for the purpose
for which it was designed, namely, the ready unambiguous sharing of clinical data held in
multiple computer systems about an individual or population. It also means that while the
standard has been widely studied, it is impossible to state that it is computable.
Creating a reference implementation, on the other hand, validates the computability of the
standard and makes available a technical format in which data may immediately be
shared.</p>
<p>The original plan to create an XML implementation came about as a means of receiving data
originating from sensors in a UK athletic project.<sup><xref rid="bibr24-1460458212473993" ref-type="bibr">24</xref>
</sup>
The sensors were worn by athletes and then analysed to optimise their performance,
especially in sprinting. Because different collaborating groups generated different types
of data but all data related to the athlete, the decision was taken to use a record server
built at University College London (UCL) that is compliant with ISO EN 13606.<sup><xref rid="bibr25-1460458212473993" ref-type="bibr">25</xref>
</sup>
The project lead for the development of the standard, an author of this article,
had also received many requests from other countries and vendors for a high-quality XML
Schema to support its adoption.</p>
<p>The advantage of using such an XML exchange format is that each collaborator would use
the same one, and although potentially complex, they would at least be able to mutually
reinforce each other’s understanding of it. In addition, at project end, each of the
components built by each group would be immediately ready to pair with any other server
and not bound only to other components developed within the project.</p>
<p>Instead of the generic XML export, it would have been possible to create a specific one
for that particular project. Having a specific document type for a domain significantly
lowers the cost of entry for parser/generators and aids comprehensibility. However,
specific document descriptions cannot be reused in a wider context – taking the upfront
learning cost for the generic approach means that data can be immediately reused
everywhere.</p>
</sec>
</sec>
<sec sec-type="methods" id="section4-1460458212473993"><title>Method</title>
<p>Having decided to pursue a generic version of an XML export, but meanwhile understanding
the complexity issues that would be faced by implementers from a non-clinical background, it
was important not just that the XML Schema be of an acceptable quality and well documented
but that it was easy to create and parse instances of such documents. The brief was
therefore to use Java’s<sup><xref rid="bibr26-1460458212473993" ref-type="bibr">26</xref>
</sup>
Java Architecture for XML Binding (JAXB)<sup><xref rid="bibr27-1460458212473993" ref-type="bibr">27</xref>
</sup>
binding tool to create a set of classes that could read and write documents of the
necessary form.</p>
<p>The development clearly needed to begin by building the XML Schema itself and because of
the lack of available skills at the outset the authors began with Microsoft’s Visual Studio.<sup><xref rid="bibr28-1460458212473993" ref-type="bibr">28</xref>
</sup>
Unfortunately, this introduced what was presumed were artefacts of the production
methodology. For example, the header of the XML included the phrase
‘{{xmlns:sql=“urn:schemas-microsoft-com:mapping-schema”}}’, which did not make for a
vendor-neutral mapping. While it would have been possible to continue with the approach and
eventually remove such references, the authors instead turned to a more elegant (but slower)
manual editing procedure using NetBeans. NetBeans<sup><xref rid="bibr29-1460458212473993" ref-type="bibr">29</xref>
</sup>
is an integrated development environment from Sun Microsystems<sup>®</sup>
(now owned
by Oracle<sup>®</sup>
), which can syntax-highlight XML Schema during creation and then
subsequently check both that it is well formed and that it is valid. There is also a
validity checking tool at the W3C<sup><xref rid="bibr30-1460458212473993" ref-type="bibr">30</xref>
</sup>
but this is less successful at checking multi-file schemas when they are not
available online. In this way, the authors were finally able to create the first XML Schema
for ISO EN 13606. However, difficulties with the standard itself described in later sections
suggested that the practical utility of such a direct implementation would be limited, and
that more than one schemata would be valuable. In the end, the following three were
created:</p>
<list list-type="order" id="list4-1460458212473993"><list-item><p>The first followed as nearly as possible the published textual version of the standard,
changing it only in order that a parser could recognise it as well formed and valid.</p>
</list-item>
<list-item><p>A second attempt corrected issues with the published form in order that it might better
meet its own requirements and included by reference the newly published ISO EN 21090
data types set.</p>
</list-item>
<list-item><p>Finally, a third schema was produced including a streamlined optimised subset of the
provisions in ISO EN 13606 and in ISO EN 21090 that bring with it a much lower burden of
implementation.</p>
</list-item>
</list>
<sec id="section5-1460458212473993"><title>Schema correctness</title>
<p>From the schema preamble:<disp-quote><p>XML Schema equivalent representation of the CEN/ISO 13606 part 1 model for Electronic
Healthcare Record Exchange. This version of the schema emphasises (1) fidelity to the
13606-1 standard (even where this leads to sub-optimal XML representation) and (2)
maximum use of W3C XML Schema features (even where this increases parser complexity).
This Schema definition conforms to the 13606-1 version published February 2007.</p>
</disp-quote>
</p>
<p>There are elementary typographical errors in the standard that make a strict translation
impossible to create. Put simply, the standard is not internally consistent and cannot
work as written. A list of these simple issues is presented in <xref ref-type="table" rid="table2-1460458212473993">Table 2</xref>
. It is in general readily possible to infer
the correct meaning of the model presented, and the first version results from making such
elementary corrections to derive a consistent schema. However, although consistent and a
reasonable equivalent to the printed standard, it is not adequate to represent health-care
records because the data types provided in the standard are not themselves adequate.
Although a small number of data type classes are provided in ISO EN 13606, the main source
of data types intended for representing DATA_VALUEs is published in a CEN Technical
Specification – TS 14796.<sup><xref rid="bibr31-1460458212473993" ref-type="bibr">31</xref>
</sup>
</p>
</sec>
<sec id="section6-1460458212473993"><title>Schema corrections and type expansion</title>
<p>From the schema preamble:<disp-quote><p>XML Schema equivalent representation of the CEN/ISO 13606 part 1 model for Electronic
Healthcare Record Exchange. This Schema definition conforms to the 13606-1 version
published in February 2007 [ … ].</p>
<p>A profile of certain data types is included in 13606 part 1 so that the meaning of
types used in the exchange model is clear. However, the included type set would not be
enough to model an actual record comprehensively. In this version, the 13606 types are
removed, and the script imports the new ISO 21090 type set for general use instead.
This also impacts the demographics model which is now significantly reduced from the
published documentation.</p>
</disp-quote>
</p>
<p>The second XML Schema version corrected all errors in the printed ISO EN 13606 document
presented in <xref ref-type="table" rid="table3-1460458212473993">Table 3</xref>
(although
not necessarily in the most efficient way) and overcomes the lack of data type
specification by referencing a new comprehensive type set provided by ISO EN 21090. While
the first schema is the most ‘standards-compliant’ version of the three schemas presented,
this is the most ‘correct’ version, adhering most faithfully to the intent if not the
letter of the document. However, the second XML Schema version suffers from a high level
of verbosity. Although XML itself is a verbose representation formalism, its use here is
anything but a human-readable computational form. There are several factors involved, as
follows:</p>
<list list-type="bullet" id="list5-1460458212473993"><list-item><p>The imported ISO EN 21090 type set is large and in need of reduction.<sup><xref rid="bibr32-1460458212473993" ref-type="bibr">32</xref>
</sup>
</p>
</list-item>
<list-item><p>ISO EN 13606 chooses ISO-approved types where less verbose ones would be sufficient
(e.g. the six-part Instance Identifier (II) class instead of the single-string
xs:anyURI (Universal Resource Identifier)).</p>
</list-item>
<list-item><p>ISO EN 13606 envisages not just a client and a server exchange, but also a
third-party intermediary whose credentials are unknown.</p>
</list-item>
</list>
</sec>
<sec id="section7-1460458212473993"><title>Schema usability</title>
<p>The third and final version of the XML Schema simplifies the second version to remove
much of this unnecessary complexity from the record and data types models. This improves
the readability of XML documents resulting from the schema and simplifies the parser
necessary for storing information items in the columns of a relational database. The final
schema is therefore also possible to offer in a relational script (and this has been done
for the PostgreSQL<sup>™33</sup>
database). PostgreSQL does offer an explicit XML data
type that could be used to store a received document (of any detail level). However,
without structure simplification, this simply increases query complexity to an
unacceptable level instead.</p>
</sec>
</sec>
<sec id="section8-1460458212473993"><title>Comparative schema results</title>
<p><xref ref-type="table" rid="table1-1460458212473993">Tables 1</xref>
<xref ref-type="table" rid="table2-1460458212473993"></xref>
-<xref ref-type="table" rid="table3-1460458212473993">3</xref>
enumerate those issues noted during the development
of the ISO EN 13606 XML versions. These prevented the developers from using the printed
specifications as-is. The issues are broken down by type. Note that the sections that follow
draw on all three XML versions described in the Method section. Within the tables and
following them in the Discussion section are some suggestions for improvement that are aimed
at streamlining the ISO EN 13606 classes rather than correcting actual errors. The standards
are referenced in the tables in square brackets, with the part followed by the section
number, for example, [1:6.4.2] for part 1, section 6.4.2.</p>
<table-wrap id="table1-1460458212473993" position="float"><label>Table 1.</label>
<caption><p>Features and limitations of XML Schema.</p>
</caption>
<table frame="hsides" rules="groups"><colgroup span="1"><col align="left" span="1"></col>
<col align="char" char="." span="1"></col>
</colgroup>
<tbody><tr><td colspan="1" rowspan="1">Parameterised types</td>
<td colspan="1" rowspan="1">Concrete subclasses of DATA_VALUE [1:6.4.2] used in the
high and the low properties of an InterVaL (IVL) [1:6.4.11] should be the same but
this cannot be specified in XML Schema and requires additional support</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">A InterVaL of TimeStamps (IVL) [1:6.4.11] in
particular should be a restriction on the data types of low and high in IVL to make
them TS [1:6.4.7]. This impacts the representation of time_period [1:6.2.3],
session_time [1:6.2.6], obs_time [1:6.2.10] and validTime [1:6.3.9]</td>
</tr>
<tr><td colspan="1" rowspan="1">Possible simplifications</td>
<td colspan="1" rowspan="1">XML Schema obviously copes well with list-type definitions
based on primitive or extended types but requires restriction on the definition
(rather than an explicit type) to establish further semantics. For example, as a way
of establishing Set semantics without an explicit Set type, see <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/xmlschema-0/#specifyingUniqueness">http://www.w3.org/TR/xmlschema-0/#specifyingUniqueness</ext-link>
. A [0..1]
cardinality SET [1:6.5] of anything could therefore be treated as a [0..*] XML
list</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">The only use of Array in the 13606-1 standard is
multimedia-related [1:6.4.6], and it can therefore be replaced with a binary
expression</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Coded Simple (CS) value [1:6.4.3] types fully specified in
the standard could be represented as simple XML enumerations (with whitespace
removed as necessary)</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">A general replacement to a consistent
type can be made of miscellaneous strings and TEXT [1:6.4.5] values in the standard,
and Encapsulated Data (ED) [1:6.4.6] where the intent is to encode a string</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Mandatory TS [1:6.4.7] timestamps can be an
</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Mandatory BooLean (BL) [1:6.5] markers can be an
</td>
</tr>
<tr><td colspan="1" rowspan="1">Amendments</td>
<td colspan="1" rowspan="1">In the second XML form, a Schematron rule<sup><xref rid="bibr23-1460458212473993" ref-type="bibr">23</xref>
</sup>
polices that either LINK_NATURE [3:5.7] or LINK_ROLE [3:5.8] is used (defined
in EN 13606 part 3) but not both, and that if the latter is used it matches the
LINK_NATURE semantically. In the third XML form, both enumerations are collapsed
into a single one with values from the previous two</td>
</tr>
</tbody>
</table>
<table-wrap-foot><fn id="table-fn1-1460458212473993"><p>XML: Extensible Markup Language.</p>
</fn>
</table-wrap-foot>
</table-wrap>
<table-wrap id="table2-1460458212473993" position="float"><label>Table 2.</label>
<caption><p>Correctable oversights in the ISO EN 13606 Standard.</p>
</caption>
<table frame="hsides" rules="groups"><colgroup span="1"><col align="left" span="1"></col>
<col align="char" char="." span="1"></col>
</colgroup>
<tbody><tr><td colspan="1" rowspan="1">Class structure</td>
<td colspan="1" rowspan="1">Although the EN 13606 primitive package includes many
types native to all engineering environments, no such native type will include the
full range of possible null_flavours [1:6.4.2]. Indeed, some environments will not
even permit primitive types to be NULL. Such examples will require an otherwise
redundant redefinition to subclass DATA_VALUE [1:6.4.2] before data can actually be
transmitted. The issue could be resolved by adding the null_flavour to the ELEMENT
[1:6.2.12] class instead of the DATA_VALUE</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">The CS_reason [5:6.4] term list is defined but only one
item from the given list is useful because the rest are not related to the clinical
exchange. Rather, they describe technical reasons why a request cannot be
fulfilled</td>
</tr>
<tr><td colspan="1" rowspan="1">Attributes</td>
<td colspan="1" rowspan="1">The type of id (identifier) on IDENTIFIED_ENTITY [1:6.3.2]
is not given in the printed class description but is included in the class diagram
on page 47 of the standard</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">At several points in the standard, a graphical
nomenclature is adopted where an ‘id’ in a white box is attached to a class
definition. The intent of the standard is that this establishes an association based
on the identifier of the associated object (i.e. the II [1:6.4.9]). The textual
class descriptions usually make it seem that the actual object type should be
used</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Set [1:6.5] appears twice in the list of
primitives expected to be available in all engineering environments</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Variable naming conventions are very mixed with both
underlined_naming and camelCase naming used throughout. Sometimes, this even occurs
within a single class</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">In general, the obs_time interval [1:6.2.10] should give
the beginning and ending of a clinical event or activity. However, the location of
this within the ITEM class [1:6.2.10] instead of the ENTRY [1:6.2.9] unnecessarily
reduces its utility to time series data only when many clinical events or activities
describable in an ENTRY have a start and end</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">In part 1, archetype_id is a String in RECORD_COMPONENT
[1:6.2.4], but the set of all archetype_ids is SET in EXTRACT_CRITERIA
[1:6.2.3]</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">Sensitivities can be represented using the CS_SENSITIVITY
enumeration of part 4 throughout [4:5.1] (and not Integer)</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">The standard mandates the media_type.coding_scheme_name of
a multimedia container [1:6.4.6] as ‘in ISO/TR 21090:2005, Annex D’ and the
charset.coding_scheme_name as ‘in ISO 21090 Annex C’ including the initial ‘in’ in
both cases</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">No default values are provided for the category of an ITEM
[1:6.2.10], the status of an ACT [3:5.6] or the ROLE or NATURE of a LINK in part 3
[3:5.7, 3:5.8]</td>
</tr>
</tbody>
</table>
</table-wrap>
<table-wrap id="table3-1460458212473993" position="float"><label>Table 3.</label>
<caption><p>Errors in the ISO EN 13606 Standard.</p>
</caption>
<table frame="hsides" rules="groups"><colgroup span="1"><col align="left" span="1"></col>
<col align="char" char="." span="1"></col>
</colgroup>
<tbody><tr><td colspan="1" rowspan="1">Class structure</td>
<td colspan="1" rowspan="1">An ELEMENT [1:6.2.12] can have zero-or-one DATA_VALUE
[1:6.4.2] instances. However, the DATA_VALUE is also the container for null_flavour,
which makes it structurally possible for an ELEMENT to exist with no value and no
null_flavour given. The ELEMENT class does not describe a countervailing
invariant</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">‘null_flavour’ [1:6.4.2] is defined as a CS class
[1:6.4.3] which means that it can itself be a null_flavour</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">The REQUEST in part 4 [4:6.4] defines the properties of a
requestor of a policy. Coded Simple FUNCtional ROLE (CS_FUNC_ROLE) [4:6.4] therein
refers to the FUNCTIONAL_ROLE [1:6.2.15] class, despite it not being named as such
and not described as a CS [1:6.4.3]. CS_SETTING [4:6.4] is not given at all</td>
</tr>
<tr><td colspan="1" rowspan="1">Attributes</td>
<td colspan="1" rowspan="1">There are disclosure implications of including all
policy_ids [1:6.2.4] when providing an EHR_EXTRACT [1:6.2.2]. The recipient then
knows the policies governing all other recipients</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">In many places in the standard, an invariant is specified
on the ‘coding_scheme_name’ of the CS [1:6.4.3] or Coded Value (CV) [1:6.4.4] data
type. This is intended to ensure that the coding scheme used to provide the
information is a particular one. However, the actual variable name used in the CS
and CV classes is ‘codingSchemeName’ and so as printed, the restriction cannot be
enforced</td>
</tr>
<tr><td colspan="1" rowspan="1"></td>
<td colspan="1" rowspan="1">On several occasions in the standard, a code is described
as having a CS [1:6.4.3] type but only two of the four necessary parts of the CS are
provided by the documentation (usually a value and a human-readable portion). The
XML third form jettisons the CS type entirely and uses XML enumerations for the
standard’s term lists</td>
</tr>
</tbody>
</table>
<table-wrap-foot><fn id="table-fn2-1460458212473993"><p>XML: Extensible Markup Language.</p>
</fn>
</table-wrap-foot>
</table-wrap>
</sec>
<sec sec-type="discussion" id="section9-1460458212473993"><title>Discussion</title>
<p>This research has demonstrated that despite substantial peer review through international
ballot cycles, technical errors can remain undetected within a complex standard. The
generation of an implementable specification such as an XML Schema could provide a means for
technical verification of a specification before its final publication. Second, the
discipline of developing such an implementable specification can highlight areas where a
chosen modelling construct might not be the optimal way to meet an intended requirement.</p>
<p>Copyright issues prevented the derived XML implementation including explanatory extracts
from the standard document itself. Instead, the XML includes a short phrase outlining the
purpose of the inclusion and then exhaustively documents the differences between the
published and implemented forms. These appear as tags.</p>
<p>The original methodology for describing the class structure of the ISO EN 13606 reference
model began with Universal Modelling Language (UML)<sup><xref rid="bibr34-1460458212473993" ref-type="bibr">34</xref>
</sup>
but this was found to lack certain features that were required for the standard (e.g.
where a pointer to a class instance was required). The diagramming tool MagicDraw<sup><xref rid="bibr35-1460458212473993" ref-type="bibr">35</xref>
</sup>
was used to create the diagrams, and it was possible to do so with the missing UML
features included. However, this was not related to the engineering environment used to
validate the model.<sup><xref rid="bibr36-1460458212473993" ref-type="bibr">36</xref>
</sup>
The latter draws heavily on so-called invariants as a construct for ensuring correct
behaviour of programs. Needless to say, none of these are directly representable in XML
Schema, although in the second schema a ‘Schematron’<sup><xref rid="bibr23-1460458212473993" ref-type="bibr">23</xref>
</sup>
rule was used to ensure that the Link Role and Link Nature paired as dictated by the
standard.</p>
<p>Although now standardised, there remain questions about some parts of the ISO EN 13606
standard. The final part, for example, describes a logical set of interfaces that a record
server would be expected to offer but does not describe a technical solution by which they
might be made available. The proposed interface set is in any case vanishingly minimal and
would benefit from expansion. The current study did not address part 5 but had it done so, a
Simple Object Access Protocol (SOAP)<sup><xref rid="bibr37-1460458212473993" ref-type="bibr">37</xref>
</sup>
solution might have been appropriate, or even one based on the Resource Description
Framework (RDF)<sup><xref rid="bibr38-1460458212473993" ref-type="bibr">38</xref>
</sup>
and SPARQL Protocol and RDF Query Language (recursively abbreviated as SPARQL).<sup><xref rid="bibr39-1460458212473993" ref-type="bibr">39</xref>
</sup>
</p>
<p>Part 2 of the standard is also not addressed. This part of the standard specifies a formal
representation for clinical archetypes, and so would not be implemented through the same
components as those implementing parts 1, 3 and 4. It may be considered for similar
examination in the future. The remainder of the discussion section presents changes to the
standard the authors feel are justifiable based on the effort to implement it in XML.</p>
<sec id="section10-1460458212473993"><title>Demographics class changes</title>
<p>Some collaborators felt it necessary to split up the early XML versions into multiple
files, and the third version is architected to be separable if desired (although this is
not recommended for interoperability reasons). Most users preferred to use the ISO data
types standard even while still in draft form rather than the ISO EN 13606 data types
implied by the first XML Schema form. Others have attempted to co-opt types from the
openEHR foundation into a hybrid standard. The ISO types standard defines rather a lot of
types, many of which might be awkward to conveniently represent, for example, in a
relational database. The third form provides a much more focussed set and relies more
heavily on the knowledge model to provide structure. For example, a RATIO class is really
two numbers with a defined semantic relationship and is unnecessary to represent
uniquely.</p>
<p>Even more awkwardly, some participants tend to remove the demographic components as well.
Demographics are clearly an important part of a patient record, and it is important that
records can be interleaved by reliable identifying demographics. The ISO EN 13606
demographics package was developed to solve three scenarios: first, minimum identification
to permit demographic matching between two systems; second, a rich enough descriptor set
to populate a recipient’s demographic system with enough to identify and contact persons
or organisations, and third, for the whole thing to be optional if the exchange is
occurring inside a shared demographics realm. An exchange standard is particularly
concerned with the first and third of these and less so with the second – in fact, a
preoccupation with population of a demographics repository with information not really
required for matching causes a certain amount of overlap with other more focussed
standards. The XML Schema third form takes matching as its one and only reason for
existing (which will obviously often imply matching identifiers as well). More specific
simplifications are also possible, and these are detailed in the following sections.</p>
<sec id="section11-1460458212473993"><title>Class Subject Of Care PersonI dentification</title>
<p>The extractID can be represented as an xsd:ID because it is something that other things
in an XML document refer to (although for legacy compatibility reasons, XML Schema
specifies that this must be stored as an attribute and not an XML entity). The ISO EN
13606 identifier can simply be a list of anyURI representing the identifiers. Both
birthTime and deceasedTime are reasonable xsd:dateTime instances and birthOrderNumber an
xsd:positiveInteger. ISO 5218<sup><xref rid="bibr40-1460458212473993" ref-type="bibr">40</xref>
</sup>
already defines an administrativeGenderCode, and a suitable ordinal can be taken
from there (the authors suggest UNKNOWN, MALE, FEMALE and NOT_APPLICABLE).</p>
<p>ISO 22220<sup><xref rid="bibr41-1460458212473993" ref-type="bibr">41</xref>
</sup>
also offers ‘Mother’s original family name’ and ‘Country of birth’ as sensible
possible matching criteria. However, the first has possible confidentiality implications
and the second can subsumed into a ‘place of birth’ address.</p>
</sec>
<sec id="section12-1460458212473993"><title>Class Organisation</title>
<p>There is already an ISO standard (6523)<sup><xref rid="bibr42-1460458212473993" ref-type="bibr">42</xref>
</sup>
for the representation of organisations that uses the following:</p>
<list list-type="bullet" id="list6-1460458212473993"><list-item><p>Four-digit International Code Designator (ICD) value that uniquely identifies the
authority that issued the code to the organisation;</p>
</list-item>
<list-item><p>Organisation code, up to a maximum of 14 characters (A–Z, 0–9, space or hyphen)
and</p>
</list-item>
<list-item><p>Organisation name, up to a maximum of 250 characters.</p>
</list-item>
</list>
<p>The character ‘/’ is used to separate values during transmission, and this makes it
look conveniently like an xsd:anyURI. One advantage of using anyURI is that if a
non-standard String is presented, it might still be parsable by a recipient system.</p>
</sec>
<sec id="section13-1460458212473993"><title>Class Identified Healthcare Professional</title>
<p>There are apparently no international standards that facilitate the identification of
health-care professionals. ISO EN 13606 provides for the identification of roles held by
a health-care professional but it is not clear why this needs another set of identifiers
as well as those inherited from IdentifiedEntity. First, the extract needs only to
reference a health-care professional repository populated from an official source (that
could include valid specialities and so forth). But in any case, the extract should not
state whether someone was ‘junior’ or whether they are a ‘diabetologist’ because these
are non-durable facts and will change as the source updates its information. It is
arguably important to know the role a professional played in producing the present
record extract but this could be collapsed to a String identifying the role (such as the
logged-in ‘Role Name’). That perhaps makes the HealthcareProfessionalRole contain one
role String and the (xsd:IDREF) link to Organisation. This would be durable even if a
globally recognised repository of Role Names ever became available.</p>
</sec>
<sec id="section14-1460458212473993"><title>Class Software Or Device</title>
<p>There is already an ISO standard (19770-2)<sup><xref rid="bibr43-1460458212473993" ref-type="bibr">43</xref>
</sup>
governing Software Identification Tags but it appears that 19770-2 is a
heavyweight solution requiring registration, and in contrast, ISO EN 13606 seems
satisfied with a lightweight approach that describes classes of device, classes of
software, specific devices or specific software. The authors would remove ‘version’
because the ‘manufacturerModelName’ description also includes the possibility of a
version. The attributes would then become as in <xref ref-type="table" rid="table4-1460458212473993">Table 4</xref>
(example included).</p>
<table-wrap id="table4-1460458212473993" position="float"><label>Table 4.</label>
<caption><p>Software Or Device information.</p>
</caption>
<table frame="hsides" rules="groups"><colgroup span="1"><col align="left" span="1"></col>
<col align="char" char="." span="1"></col>
</colgroup>
<tbody><tr><td colspan="1" rowspan="1">deviceManufacturerModelName</td>
<td colspan="1" rowspan="1">Apple 1.67 GHz PowerBook5, 8</td>
</tr>
<tr><td colspan="1" rowspan="1">deviceSerialNumber</td>
<td colspan="1" rowspan="1">WXXXXMXSXX</td>
</tr>
<tr><td colspan="1" rowspan="1">owningOrganisation</td>
<td colspan="1" rowspan="1">UCL</td>
</tr>
<tr><td colspan="1" rowspan="1">description</td>
<td colspan="1" rowspan="1">Fred Blogg’s Laptop</td>
</tr>
<tr><td colspan="1" rowspan="1">softwareManufacturerModelName</td>
<td colspan="1" rowspan="1">Apple Pages ‘08 3.0.3</td>
</tr>
</tbody>
</table>
<table-wrap-foot><fn id="table-fn3-1460458212473993"><p>UCL: University College London.</p>
</fn>
</table-wrap-foot>
</table-wrap>
<p>A class of device only needs deviceManufacturerModelName, and a class of software needs
only softwareManufacturerModelName. A specific device would also require
deviceSerialNumber (with owningOrganisation and description present to narrow the
physical search space), and finally, specific software is installed on a particular
device so it needs deviceManufacturerModelName, deviceSerialNumber and
softwareManufacturerModelName together.</p>
</sec>
</sec>
<sec id="section15-1460458212473993"><title>Record class changes</title>
<p>Much of the methodology and attribute provision in ISO EN 13606 is based on an assumption
that an interaction will not be based on a client–server exchange. In particular, it
provides for the possibility that a third party with separate credentials will have become
involved who then in turn is responsible for ensuring adequate credentials of any party
that it hands the data onto. For that reason, it provides for a lot of attributes in the
EHRExtract and ExtractCriteria classes related to the situation of the original data
request that would be redundant for a client–server exchange because the requestor would
already know what it requested. Counter-proposing that the XML Schema methodology be
entirely based around a client–server methodology allows for most of the attributes of
EHRExtract and the entire ExtractCriteria class to be removed. Furthermore, assuming that
identifying data (such as the subject of care identifier) appears in the Composition class
returned means that the EHRExtract class can also be removed, and that the response to a
request is simply a list comprising the Compositions, Folders and Demographic extracts
relevant to the response.</p>
<p>The ISO EN 13606 standard does not take a strongly Composition-centric approach to
modelling. However, in practice, this is necessary. The medico-legal purpose of the
Composition is to act as the container for a contribution to the record (which also seems
to make ‘contributionID’ redundant). In reverse, this means that in order for an
extraction to be medico-legally complete, it must include the enclosing Composition. In
particular, although the Record Component is declared as having a sensitivity attribute,
it is the Composition where the declared sensitivity of the contribution as a whole must
be stored. This is because it is not clinically safe for parts of a contribution to be
omitted because they have higher sensitivity than other parts. Although it would be clear
to future investigators which parts of a record were not available to a user (assuming
versioning included versions of the sensitivity attribute), any routine clinical decision
based upon data that were not reliably complete would always be questionable.</p>
<p>There is a suspicious asymmetry about the modelling of AUDIT_INFO. The intent is that
newly developed systems concentrate their audit information in the Composition but that
older systems may store audit information lower in the hierarchy and must be catered for.
In other words, good newly developed systems impose Compositions and Entries on their data
and store their commitment information in the Composition, while bad old systems still
impose Compositions and Entries and so on but spew their committal data throughout. It is
inefficient to have, for example, a table join for each AUDIT_INFO × RECORD_COMPONENT when
in fact the feature will only be of use in a limited number of circumstances outside the
Composition itself. The authors would definitively fold AUDIT_INFO into the Composition
and let feeder system vendors decide how to describe authors of sub-components (perhaps
via the other_participants attribute since imposing an attribute methodology is no
different to imposing one for aggregation). To facilitate this move, it might be desirable
to differentiate between the creator (the logged-in user of the present system who
performed an import) and the committer (the logged-in user of an original system who
created the data in the first place).</p>
<p>The authors would merge the FunctionalRole and RelatedParty classes. The merged class
would consist of optional identifiers for HealthcareProfessional, Organisation and Device,
along with the mode (from FunctionalRole) and a relationship. In general, information
might need to be recorded where the ‘participant’ disavows his or her role for
confidentiality reasons. For example, a biological mother who gave her daughter up for
adoption may have started to exhibit signs of a hereditary disease but if challenged would
deny having had a child. Recording of the possibility of that disease in the child’s
record could not formally identify the biological mother (via the performer attribute) and
would be better listed simply as a relationship. Conversely, the subject of information
might well be about ‘the dialysis machine that didn’t work’, and therefore, the
subjectOfInformation attribute should permit actual identifying data too.</p>
<p>The authors would remove sub-folders. Folders now seem to work like social networking
tags on well-known websites such as Flickr<sup><xref rid="bibr44-1460458212473993" ref-type="bibr">44</xref>
</sup>
and only link to identifiers rather than representing some sort of genuine
containment as they did in previous iterations of the standard. Having sub-folders only
serves to make merging two records more complex because it is not clear how a target
record should aggregate migrated folders if they started with a different aggregation to
the source.</p>
<sec id="section16-1460458212473993"><title>Record attribute changes</title>
<p>The ‘meaning’ attribute of the Record Component is a redundant attribute if the name
can be a coded value. ‘parent_ref’, whose intent is to imply that a component has been
copied from another place in the record, might be better as a Link with a new nature
attribute of ‘copied to’ or ‘copied from’. ‘policy_id’ is also redundant. It caters to a
situation where a recipient server is expected to abide by the same policy
considerations as a source server, and the standard assumes that the identifier will not
be passed along to any user of the recipient server. Instead, the recipient server
de-references the policy identifier separately from the originating server to determine
what the operational access control should be. Obviously, the recipient server could
supply the record component identifier instead and simply ask what policies govern
it.</p>
<p>Attestations should also be removed. Attesting data is very difficult, and ISO EN 13606
misses some key information that would be needed to accomplish it. To do so requires a
canonicalised form of the structure being attested but because ISO EN 13606 provides no
reference serialisation format itself (in turn because the data types were not fixed by
the standard), it is not possible to create an example of this canonicalised form. A
digital signature could be applied to a part of a component such as the identifier or
even to the structure using the XML Schema described herein as the canonicalised form.
But it would be better for the feature to be reserved for the attestation of a whole
contribution only or removed altogether since a contribution itself already implies the
attestation of its truth by the contributor.</p>
<p>The authors would use a simple Boolean value to indicate emphasis. Laboratory experts
indicated that flagging a result as abnormally high or abnormally low is common in
laboratory systems, and the ISO EN 13606 standard represents those kinds of values
faithfully. However, the abnormal nature of a laboratory result is a domain-specific
piece of knowledge and should really be represented as a construct in the knowledge
layer.</p>
</sec>
</sec>
</sec>
<sec sec-type="conclusions" id="section17-1460458212473993"><title>Conclusion</title>
<p>The authors have successfully implemented much of the ISO EN 13606 standard as XML Schema
with different underlying purposes. XML document extracts representing parts of a record
have been successfully transmitted and received using the last of these. Now several groups
worldwide have begun experimenting with the scripts as a means to actually exchange
health-care records between systems. These include at least two national endeavours in
Sweden and the United Kingdom.</p>
<p>The research reported here has identified specific technical errors and some suggestions
for improvement to the information model in part 1 of ISO EN 13606. These errors were not
identified despite multiple ballot cycles and widespread international peer review of the
published information. This suggests that a more technical, tools based, validation stage is
needed in order to ensure that a published standard is technically correct and faithfully
implementable. The authors would recommend that such a stage is formally introduced into the
standards development life cycle prior to a final version being balloted. The ISO EN 13606
standard is now due for its periodic technical review by the CEN and ISO, and the results of
this article will feed into that review process.</p>
<p>The study is a strictly technical one based on extensive implementation experience among
the contributing teams. Further implementation experience may yet bring further
simplifications to light, and these will be folded into further iterations of the schema.
However, not all influences on an international standard are technical, despite the outcome
being a technical specification. The study does not address existing organisational or
national political requirements that act against the general desire to simplify.</p>
<p>The final XML Schema produced as a result of this study has been made publicly available at
<ext-link ext-link-type="uri" xlink:href="http://www.ehr.chime.ucl.ac.uk/code/schema_3.0.3/">http://www.ehr.chime.ucl.ac.uk/code/schema_3.0.3/</ext-link>
</p>
</sec>
</body>
<back><fn-group><fn fn-type="financial-disclosure"><p><bold>Funding:</bold>
This research received no specific grant from any funding agency in the public,
commercial or not-for-profit sectors.</p>
</fn>
</fn-group>
<ref-list><title>References</title>
<ref id="bibr1-1460458212473993"><label>1.</label>
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Tange</surname>
<given-names>HJ</given-names>
</name>
</person-group>
<article-title>Consultation of medical narratives in the electronic
medical record</article-title>
. <source>Methods Inf Med</source>
<year>1999</year>
; <volume>38</volume>
(<issue>4–5</issue>
):
<fpage>289</fpage>
–<lpage>293</lpage>
<pub-id pub-id-type="pmid">10805015</pub-id>
</mixed-citation>
</ref>
<ref id="bibr2-1460458212473993"><label>2.</label>
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Kalra</surname>
<given-names>D</given-names>
</name>
</person-group>
<source>Clinical foundations and information architecture for the
implementation of a federated health record service</source>
. PhD Thesis,
<publisher-name>University of London</publisher-name>
,
<publisher-loc>UK</publisher-loc>
, <year>2002</year>
, <ext-link ext-link-type="uri" xlink:href="http://eprints.ucl.ac.uk/1584/">http://eprints.ucl.ac.uk/1584/</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr3-1460458212473993"><label>3.</label>
<mixed-citation publication-type="webpage"><collab>TheBigOptOut.org</collab>
. About the campaign, <ext-link ext-link-type="uri" xlink:href="http://www.nhsconfidentiality.org/?pageid=3">http://www.nhsconfidentiality.org/?pageid=3</ext-link>
(<date-in-citation>accessed January 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr4-1460458212473993"><label>4.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Lloyd</surname>
<given-names>D</given-names>
</name>
<name><surname>Kalra</surname>
<given-names>D</given-names>
</name>
<name><surname>Beale</surname>
<given-names>T</given-names>
</name>
<etal></etal>
</person-group>
(eds). <source>The GEHR final architecture description</source>
. The Good
European Health Record Project: Deliverable 19, 1995.
<publisher-loc>Brussels</publisher-loc>
: <publisher-name>European
Commission</publisher-name>
, <fpage>250</fpage>
pp., <ext-link ext-link-type="uri" xlink:href="https://www.ucl.ac.uk/chime/research/gehr/deliverable-19.pdf">https://www.ucl.ac.uk/chime/research/gehr/deliverable-19.pdf</ext-link>
(<date-in-citation>accessed July 2010</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr5-1460458212473993"><label>5.</label>
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Grimson</surname>
<given-names>J</given-names>
</name>
<name><surname>Grimson</surname>
<given-names>W</given-names>
</name>
<name><surname>Berry</surname>
<given-names>D</given-names>
</name>
<etal></etal>
</person-group>
<article-title>A CORBA-based integration of distributed electronic
healthcare records using the synapses approach</article-title>
. <source>IEEE Trans Inf
Technol Biomed</source>
<year>1998</year>
; <volume>2</volume>
(<issue>3</issue>
):
<fpage>124</fpage>
–<lpage>138</lpage>
<pub-id pub-id-type="pmid">10719522</pub-id>
</mixed-citation>
</ref>
<ref id="bibr6-1460458212473993"><label>6.</label>
<mixed-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Sottile</surname>
<given-names>PA</given-names>
</name>
<name><surname>Ferrara</surname>
<given-names>FM</given-names>
</name>
<name><surname>Grimson</surname>
<given-names>W</given-names>
</name>
<etal></etal>
</person-group>
<article-title>The holistic healthcare information
system</article-title>
. In: <conf-name>Toward an electronic health record Europe
’99</conf-name>
, <conf-loc>London, UK</conf-loc>
, <conf-date>14–17 November
1999</conf-date>
, <publisher-loc>Boston, USA</publisher-loc>
: <publisher-name>Medical
Records Institute</publisher-name>
, pp.
<fpage>259</fpage>
–<lpage>266</lpage>
</mixed-citation>
</ref>
<ref id="bibr7-1460458212473993"><label>7.</label>
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Dixon</surname>
<given-names>R</given-names>
</name>
<name><surname>Grubb</surname>
<given-names>PA</given-names>
</name>
<name><surname>Lloyd</surname>
<given-names>D</given-names>
</name>
<etal></etal>
</person-group>
<source>Consolidated list of requirements</source>
. EHCR Support Action
Deliverable 1.4, 2001. <publisher-loc>Brussels</publisher-loc>
: <publisher-name>European
Commission DGXIII</publisher-name>
, <fpage>59</fpage>
pp., <ext-link ext-link-type="uri" xlink:href="http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v13.PDF">http://www.chime.ucl.ac.uk/HealthI/EHCR-SupA/del1-4v13.PDF</ext-link>
(<date-in-citation>accessed July 2010</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr8-1460458212473993"><label>8.</label>
<mixed-citation publication-type="webpage"><collab>CEN Technical Committee 251</collab>
. <ext-link ext-link-type="uri" xlink:href="http://www.cen.eu/CEN/Sectors/TechnicalCommitteesWorkshops/CENTechnicalCommittees/Pages/Standards.aspx?param=6232&;title=CEN%2FTC+251">http://www.cen.eu/CEN/Sectors/TechnicalCommitteesWorkshops/CENTechnicalCommittees/Pages/Standards.aspx?param=6232&;title=CEN%2FTC+251</ext-link>
(<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr9-1460458212473993"><label>9.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Hurlen</surname>
<given-names>P</given-names>
</name>
</person-group>
(ed.). ENV 12265:1995. <article-title>Electronic Healthcare Record
Architecture, 1995</article-title>
. Brussels CEN Technical Committee/251.</mixed-citation>
</ref>
<ref id="bibr10-1460458212473993"><label>10.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Kay</surname>
<given-names>S</given-names>
</name>
<name><surname>Marley</surname>
<given-names>T</given-names>
</name>
</person-group>
(eds). ENV 13606:1999. <article-title>EHCR Communications: Part 1
Electronic Healthcare Record Architecture</article-title>
, <year>1999</year>
Brussels
CEN Technical Committee/251.</mixed-citation>
</ref>
<ref id="bibr11-1460458212473993"><label>11.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Rossi Mori</surname>
<given-names>A</given-names>
</name>
<name><surname>Kalra</surname>
<given-names>D</given-names>
</name>
<name><surname>Rodrigues</surname>
<given-names>JM</given-names>
</name>
<etal></etal>
</person-group>
(eds). <source>Project team 1-027. ENV 13606: 1999 EHCR communications:
part 2 domain termlist</source>
, <year>1999</year>
CEN Technical
Committee/251.</mixed-citation>
</ref>
<ref id="bibr12-1460458212473993"><label>12.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Hopkins</surname>
<given-names>R</given-names>
</name>
<name><surname>Grøtan</surname>
<given-names>T</given-names>
</name>
<name><surname>Nystadnes</surname>
<given-names>T</given-names>
</name>
<etal></etal>
</person-group>
(eds). <source>ENV 13606:1999. EHCR communications: part 3 distribution
rules</source>
, <year>1999</year>
Brussels CEN Technical Committee/251.</mixed-citation>
</ref>
<ref id="bibr13-1460458212473993"><label>13.</label>
<mixed-citation publication-type="book"><person-group person-group-type="editor"><name><surname>Markwell</surname>
<given-names>D</given-names>
</name>
</person-group>
(ed). <italic>Project team 1-029</italic>
<source>ENV 13606: EHCR
communications: part 4 messages for exchange of information</source>
, <year>1999</year>
Brussels CEN Technical Committee/251.</mixed-citation>
</ref>
<ref id="bibr14-1460458212473993"><label>14.</label>
<mixed-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Turner</surname>
<given-names>L.</given-names>
</name>
</person-group>
<article-title>A brief history of the development of SGML</article-title>
. <source>SGML
User’s Group</source>
, <ext-link ext-link-type="uri" xlink:href="http://xml.coverpages.org/sgmlhist0.html">http://xml.coverpages.org/sgmlhist0.html</ext-link>
(<year>1990</year>
,
<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr15-1460458212473993"><label>15.</label>
<mixed-citation publication-type="journal"><collab>ISO 8879:1986</collab>
. <article-title>Information processing
– text and office systems – Standard Generalized Markup Language
(SGML)</article-title>
.</mixed-citation>
</ref>
<ref id="bibr16-1460458212473993"><label>16.</label>
<mixed-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Pitty</surname>
<given-names>D</given-names>
</name>
<name><surname>Gordon</surname>
<given-names>C</given-names>
</name>
<name><surname>Reeves</surname>
<given-names>P</given-names>
</name>
<etal></etal>
</person-group>
<article-title>The place of SGML and HTML in building electronic patient
records</article-title>
. In: <conf-name>Medical informatics Europe ’ 97</conf-name>
<conf-loc>Thessaloniki, Greece</conf-loc>
, <conf-date>25th - 29th May, 1997</conf-date>
,
pp. <fpage>329</fpage>
–<lpage>333</lpage>
<publisher-loc>Amsterdam,
Netherlands</publisher-loc>
: <publisher-name>IOS Press</publisher-name>
</mixed-citation>
</ref>
<ref id="bibr17-1460458212473993"><label>17.</label>
<mixed-citation publication-type="webpage"><person-group person-group-type="author"><name><surname>Bray</surname>
<given-names>T</given-names>
</name>
<name><surname>Paoli</surname>
<given-names>J</given-names>
</name>
<name><surname>Sperberg-McQueen</surname>
<given-names>CM</given-names>
</name>
<etal></etal>
</person-group>
<source>Extensible markup language (XML) 1.0. World Wide Web Consortium
(W3C)</source>
. <year>2000</year>
, <fpage>60</fpage>
pp., <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/2000/REC-xml-20001006">http://www.w3.org/TR/2000/REC-xml-20001006</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr18-1460458212473993"><label>18.</label>
<mixed-citation publication-type="confproc"><person-group person-group-type="author"><name><surname>Dolin</surname>
<given-names>RH</given-names>
</name>
<name><surname>Alschuler</surname>
<given-names>L</given-names>
</name>
<name><surname>Bray</surname>
<given-names>T</given-names>
</name>
<etal></etal>
</person-group>
<article-title>SGML as a message interchange format in
healthcare</article-title>
. In: <conf-name>Proceedings/AMIA annual fall
symposium</conf-name>
, <conf-date>October 25–29, 1997</conf-date>
, <conf-loc>AMIA
Nashville Tennessee</conf-loc>
, pp. <fpage>635</fpage>
–<lpage>639</lpage>
</mixed-citation>
</ref>
<ref id="bibr19-1460458212473993"><label>19.</label>
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Takeda</surname>
<given-names>H</given-names>
</name>
<name><surname>Matsumura</surname>
<given-names>Y</given-names>
</name>
<name><surname>Kuwata</surname>
<given-names>S</given-names>
</name>
<etal></etal>
</person-group>
<article-title>Architecture for networked electronic patient record
systems</article-title>
. <source>Int J Med Inform</source>
<year>2000</year>
; <volume>60</volume>
: <fpage>161</fpage>
–<lpage>167</lpage>
<pub-id pub-id-type="pmid">11154967</pub-id>
</mixed-citation>
</ref>
<ref id="bibr20-1460458212473993"><label>20.</label>
<mixed-citation publication-type="webpage"><collab>The LinkEHR Normalization Platform</collab>
. <ext-link ext-link-type="uri" xlink:href="http://www.linkehr.com/">http://www.linkehr.com/</ext-link>
(<date-in-citation>accessed September
2010</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr21-1460458212473993"><label>21.</label>
<mixed-citation publication-type="webpage"><collab>W3C</collab>
. <article-title>XML schema
requirements</article-title>
, <month>2</month>
<year>1999</year>
, <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215">http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215</ext-link>
(<date-in-citation>accessed May 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr22-1460458212473993"><label>22.</label>
<mixed-citation publication-type="webpage"><collab>W3C</collab>
. <article-title>XML schema</article-title>
,
<ext-link ext-link-type="uri" xlink:href="http://www.w3.org/XML/Schema">http://www.w3.org/XML/Schema</ext-link>
(<date-in-citation>accessed May
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr23-1460458212473993"><label>23.</label>
<mixed-citation publication-type="journal"><collab>ISO/IEC 19757-3:2006</collab>
. <article-title>Information
technology – Document Schema Definition Languages (DSDL) – part 3: rule-based validation
– Schematron</article-title>
.</mixed-citation>
</ref>
<ref id="bibr24-1460458212473993"><label>24.</label>
<mixed-citation publication-type="webpage"><collab>SESAME</collab>
. <article-title>SESAME: SEnsing for Sport And
Managed Exercise</article-title>
. <ext-link ext-link-type="uri" xlink:href="http://www.sesame.ucl.ac.uk/">http://www.sesame.ucl.ac.uk/</ext-link>
(<date-in-citation>accessed September
2010</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr25-1460458212473993"><label>25.</label>
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Austin</surname>
<given-names>T</given-names>
</name>
<name><surname>Lim</surname>
<given-names>YS</given-names>
</name>
<name><surname>Nguyen</surname>
<given-names>D</given-names>
</name>
<etal></etal>
</person-group>
<article-title>Design of an electronic healthcare record server based on
part 1 of ISO EN 13606</article-title>
. <source>J Healthc Eng</source>
<year>2011</year>
; <volume>2</volume>
(<issue>2</issue>
):
<fpage>143</fpage>
–<lpage>160</lpage>
</mixed-citation>
</ref>
<ref id="bibr26-1460458212473993"><label>26.</label>
<mixed-citation publication-type="webpage"><collab>Sun Microsystems</collab>
. <article-title>Java 2 Platform
Standard Edition (J2SE)</article-title>
, <ext-link ext-link-type="uri" xlink:href="http://www.oracle.com/technetwork/java/javase/overview/index.html">http://www.oracle.com/technetwork/java/javase/overview/index.html</ext-link>
(<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr27-1460458212473993"><label>27.</label>
<mixed-citation publication-type="webpage"><collab>Sun Microsystems</collab>
. <article-title>Project JAXB
Reference Implementation</article-title>
, <ext-link ext-link-type="uri" xlink:href="http://jaxb.java.net/">http://jaxb.java.net/</ext-link>
(<date-in-citation>accessed March 2010</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr28-1460458212473993"><label>28.</label>
<mixed-citation publication-type="webpage"><collab>Microsoft. Microsoft Visual Studio</collab>
, <ext-link ext-link-type="uri" xlink:href="http://www.microsoft.com/visualstudio">http://www.microsoft.com/visualstudio</ext-link>
(<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr29-1460458212473993"><label>29.</label>
<mixed-citation publication-type="webpage"><collab>Oracle</collab>
. <article-title>NetBeans</article-title>
,
<ext-link ext-link-type="uri" xlink:href="http://netbeans.org">http://netbeans.org</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr30-1460458212473993"><label>30.</label>
<mixed-citation publication-type="webpage"><collab>The World Wide Web Consortium</collab>
. <article-title>XML
schema checking service</article-title>
, <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/2001/03/webdata/xsv">http://www.w3.org/2001/03/webdata/xsv</ext-link>
(<year>2007</year>
,
<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr31-1460458212473993"><label>31.</label>
<mixed-citation publication-type="journal"><collab>DD CEN/TS 14796:2004</collab>
. <article-title>Health
informatics. Data types</article-title>
.</mixed-citation>
</ref>
<ref id="bibr32-1460458212473993"><label>32.</label>
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sun</surname>
<given-names>S</given-names>
</name>
<name><surname>Austin</surname>
<given-names>T</given-names>
</name>
<name><surname>Kalra</surname>
<given-names>D</given-names>
</name>
</person-group>
<article-title>A data types profile suitable for use with ISO EN
13606</article-title>
. <source>J Med Syst</source>
,
<volume>36</volume>
(<issue>6</issue>
): <fpage>3621</fpage>
–<lpage>3635</lpage>
.
<pub-id pub-id-type="doi">10.1007/s10916-012-9837-z</pub-id>
<pub-id pub-id-type="pmid">22399066</pub-id>
</mixed-citation>
</ref>
<ref id="bibr33-1460458212473993"><label>33.</label>
<mixed-citation publication-type="webpage"><collab>PostgreSQL Global Development Group</collab>
.
<article-title>About PostgreSQL</article-title>
, <ext-link ext-link-type="uri" xlink:href="http://www.postgresql.org/">http://www.postgresql.org/</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr34-1460458212473993"><label>34.</label>
<mixed-citation publication-type="webpage"><collab>Object Management Group, Inc</collab>
. <article-title>Unified
Modeling Language</article-title>
, <ext-link ext-link-type="uri" xlink:href="http://www.uml.org/">http://www.uml.org/</ext-link>
(<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr35-1460458212473993"><label>35.</label>
<mixed-citation publication-type="webpage"><collab>No Magic, Inc</collab>
. <article-title>Introducing
MagicDraw</article-title>
, <ext-link ext-link-type="uri" xlink:href="https://www.magicdraw.com/what">https://www.magicdraw.com/what</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr36-1460458212473993"><label>36.</label>
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Meyer</surname>
<given-names>B</given-names>
</name>
</person-group>
<source>Eiffel: the language (Prentice Hall object-oriented
series)</source>
. <publisher-name>USA: Prentice Hall</publisher-name>
,
<year>1991</year>
, ISBN: <isbn>0132479257</isbn>
</mixed-citation>
</ref>
<ref id="bibr37-1460458212473993"><label>37.</label>
<mixed-citation publication-type="webpage"><collab>W3C</collab>
. <article-title>SOAP version 1.2 part 1:
messaging framework (second edition)</article-title>
. W3C Recommendation,
<year>2007</year>
, <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/soap12-part1/">http://www.w3.org/TR/soap12-part1/</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr38-1460458212473993"><label>38.</label>
<mixed-citation publication-type="webpage"><collab>W3C</collab>
. <article-title>RDF working
group</article-title>
. Resource Description Framework (RDF), <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/RDF/">http://www.w3.org/RDF/</ext-link>
(<year>2004</year>
, <date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr39-1460458212473993"><label>39.</label>
<mixed-citation publication-type="webpage"><collab>W3C</collab>
. <article-title>SPARQL Query Language for
RDF</article-title>
. W3C Recommendation, <year>2008</year>
, <ext-link ext-link-type="uri" xlink:href="http://www.w3.org/TR/rdf-sparql-query">http://www.w3.org/TR/rdf-sparql-query</ext-link>
(<date-in-citation>accessed March 2012</date-in-citation>
).</mixed-citation>
</ref>
<ref id="bibr40-1460458212473993"><label>40.</label>
<mixed-citation publication-type="journal"><collab>ISO/IEC 5218:2004</collab>
. <article-title>Information
technology – codes for the representation of human sexes</article-title>
.</mixed-citation>
</ref>
<ref id="bibr41-1460458212473993"><label>41.</label>
<mixed-citation publication-type="journal"><collab>ISO/TS 22220:2009</collab>
. <article-title>Health informatics
– identification of subjects of health care</article-title>
.</mixed-citation>
</ref>
<ref id="bibr42-1460458212473993"><label>42.</label>
<mixed-citation publication-type="journal"><collab>ISO/IEC 6523-1:1998</collab>
. <article-title>Information
technology – structure for the identification of organizations and organization parts –
part 1: identification of organization identification
schemes</article-title>
.</mixed-citation>
</ref>
<ref id="bibr43-1460458212473993"><label>43.</label>
<mixed-citation publication-type="journal"><collab>ISO/IEC 19770-2:2009</collab>
. <article-title>Information
technology – software asset management – part 2: software identification
tag</article-title>
.</mixed-citation>
</ref>
<ref id="bibr44-1460458212473993"><label>44.</label>
<mixed-citation publication-type="webpage"><collab>Yahoo! Inc</collab>
. <article-title>Flickr from
YAHOO!</article-title>
<ext-link ext-link-type="uri" xlink:href="http://www.flickr.com/">http://www.flickr.com/</ext-link>
(<date-in-citation>accessed March
2012</date-in-citation>
).</mixed-citation>
</ref>
</ref-list>
</back>
</pmc>
</record>
Pour manipuler ce document sous Unix (Dilib)
EXPLOR_STEP=$WICRI_ROOT/Wicri/Informatique/explor/SgmlV1/Data/Pmc/Corpus
HfdSelect -h $EXPLOR_STEP/biblio.hfd -nk 000189 | SxmlIndent | more
Ou
HfdSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd -nk 000189 | SxmlIndent | more
Pour mettre un lien sur cette page dans le réseau Wicri
{{Explor lien |wiki= Wicri/Informatique |area= SgmlV1 |flux= Pmc |étape= Corpus |type= RBID |clé= PMC:4107818 |texte= Evaluation of ISO EN 13606 as a result of its implementation in XML }}
Pour générer des pages wiki
HfdIndexSelect -h $EXPLOR_AREA/Data/Pmc/Corpus/RBID.i -Sk "pubmed:23995217" \ | HfdSelect -Kh $EXPLOR_AREA/Data/Pmc/Corpus/biblio.hfd \ | NlmPubMed2Wicri -a SgmlV1
This area was generated with Dilib version V0.6.33. |