4. Document format
Clinical Document Architecture
structure
• Header
• Patient information
• Doctor information
• Hospital information
• Body
• Section
• Textual (user friendly) section data description
• Entry
• Textual (user friendly) entry data description
• Subentry (if needed)
5. Example
<section>
<templateId root="1.3.6.1.4.1.38760.1.2.2.2.1" />
<code code="1.3.6.1.4.1.38760.1.2.2.2" codeSystem="OID Vocabularry OID" codeSystemName="text
that represent OID Vocabularry OID" displayName="text that represent code" />
<title>Diagnosis section title</title>
<text>Diagnosis human readable description here</text>
<entry>
<observation moodCode="EVN" negationInd="false">
<templateId root="1.3.6.1.4.1.38760.1.2.3.2.1" />
<id root="1.3.6.1.4.1.38760.3.4.5.3" extension="1" />
<code code="... code value ..." codeSystem="... code system OID ..." codeSystemName=" ...
code system name ..." displayName=" ... user friendly code value ..." />
<effectiveTime>
<low value="20111223105917" />
<high value="20111223105917" />
</effectiveTime>
<value code="W53.2" codeSystem="1.3.6.1.4.1.38760.2.173" displayName="Žurkas
kodums, skolā, citu institūciju un sabiedrisko iestāžu telpās" />
</observation>
</entry>
</section>
6. Problem and approaches
•
•
Problem
•
Validate all documents and entries
Approach
•
•
Business analysis approach:
•
•
•
Perform analysis on documents required
Find similar elements (like diagnosis or
recommendation) and write validators for them
Reuse them and get rid of the rest (if possible)
Technology approach
•
•
Use existing legal framework as a document design
Use code generation to mass produce validation code
(it might be redundant)
7. Lessons learned
•
Technology solutions are working (they only
depend on technology)
•
•
Administrative change at this scale is hard
Technology solution might help the
project, but allow business as usual and so
discourage changes where they are due