--- title: "ixml" slug: "ixml" updated: 2025-11-19T00:04:47Z published: 2025-11-19T00:04:47Z canonical: "docs.imat.io/ixml" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.imat.io/llms.txt > Use this file to discover all available pages before exploring further. # IXML ## Table of Classes | Main POJOs | Secondary POJOs | | --- | --- | | [Allergy](/docs/ixml#Allergy) | [Plan](/docs/ixml#Plan) | [Address](/docs/ixml#Address) | [Header](/docs/ixml#Header) | [POJO](/docs/ixml#Pojo) | | [AllergyObservation](/docs/ixml#AllergyObservation) | [Base64](/docs/ixml#Base64) | [Author](/docs/ixml#Author) | [Authenticator](/docs/ixml#Authenticator) | [CommonPojo](/docs/ixml#CommonPojo) | | [Encounter](/docs/ixml#Encounter) | [EncompassingEncounter](/docs/ixml#EncompassingEncounter) | [EffectiveTime](/docs/ixml#EffectiveTime) | [CustodianInfo](/docs/ixml#CustodianInfo) | [AdminPojo](/docs/ixml#AdminPojo) | | [FunctionalStatus](/docs/ixml#FunctionalStatus) | | [High](/docs/ixml#High) | [HParticipant](/docs/ixml#HParticipant) | | | [AssessmentScale](/docs/ixml#AssessmentScale) | Care Plan POJOs | [Low](/docs/ixml#Low) | [HieInfo](/docs/ixml#HieInfo) | | | [ScaleSupporting](/docs/ixml#ScaleSupporting) | [Goal](/docs/ixml#Goal) | [Ethnicity](/docs/ixml#Ethnicity) | [NextOfKin](/docs/ixml#NextOfKin) | | | [SelfCare](/docs/ixml#SelfCare) | [HealthConcern](/docs/ixml#HealthConcern) | [Gender](/docs/ixml#Sex) | [Patient](/docs/ixml#Patient) | | | [StatusObservation](/docs/ixml#StatusObservation) | [Intervention](/docs/ixml#Intervention) | [HtmlTableFormat](/docs/ixml#HtmlTableFormat) | [Id](/docs/ixml#Id) | | | [Immunization](/docs/ixml#Immunization) | | [Column](/docs/ixml#Column) | [Recipient](/docs/ixml#Recipient) | | | [Medication](/docs/ixml#Medication) | | [Language](/docs/ixml#Language) | [DocumentationOf](/docs/ixml#DocumentationOf) | | | [Payer](/docs/ixml#Payer) | | [MaritalStatus](/docs/ixml#MaritalStatus) | | | | [Problem](/docs/ixml#Problem) | | [Organization](/docs/ixml#Organization) | | | | [Procedure](/docs/ixml#Procedure) | | [Participant](/docs/ixml#Participant) | | | | [ResultPanel](/docs/ixml#ResultPanel) | | [Performer](/docs/ixml#Performer) | | | | [Result](/docs/ixml#Result) | | [Person](/docs/ixml#Person) | | | | [SocialHistories](/docs/ixml#SocialHistories) | | [Race](/docs/ixml#Race) | | | | [Caregiver](/docs/ixml#Caregiver) | | [Religion](/docs/ixml#Religion) | | | | [CultureAndReligion](/docs/ixml#CultureAndReligion) | | [Sex](/docs/ixml#Sex) | | | | [HomeEnvironment](/docs/ixml#HomeEnvironment) | | [Status](/docs/ixml#Status) | | | | [Pregnancy](/docs/ixml#Pregnancy) | | [Telecom](/docs/ixml#Telecom) | | | | [SmokingStatus](/docs/ixml#SmokingStatus) | | [Translation](/docs/ixml#Translation) | | | | [SocialHistory](/docs/ixml#SocialHistory) | | | | | | [TobaccoUse](/docs/ixml#TobaccoUse) | | | | | | [VitalSignGroup](/docs/ixml#VitalSignGroup) | | | | | | [VitalSign](/docs/ixml#VitalSign) | | | | | Intermediate XML is used in the process of creating CCDs. It's what *mdht-restlet* needs to generate on-demand CCDs, QRDA I, QRDA III, and FHIR records. For further information, see the documentation for [QRDA I](/v1/docs/ixml-qrda-1) and [QRDA III](/v1/docs/ixml-qrda-iii). ## Documents (Implementation Guide) These were used primarily in creating the POJOs and populating the CCD using MDHT APIs. | Title | ***HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1 Draft Standard for Trial Use August 2015 Volume 2—Templates and Supporting Material*** | | --- | --- | | Filename | ***CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_Vol2_Templates_and_Supporting_Material.pdf***, 906 pages | ## Implementation See implementation details for sections, data types, etc. on each (major) POJO which indicates its relevant sections in the Implementation Guide. ## Examples The example tends to include the use of *Base-level*, *Common,* and *Admin POJO* fields as relevant. That these are "spared" from being explicitly included in the definition on the left (because they're inherited) is probably the most confusing aspect of the Java definitions. This is why the examples have been put there. ## Document Types *Generate* the following document types with *mdht-restlet*, as specified in the **Header** <doctype> field: 1. CCDA 2. QRDA I 3. QRDA III 4. Care Plan 5. Unstructured ## Base-level POJOs Note:Nothing in this group, neither POJO nor instance variable name, is ever seen in the IXML. These are for internal use only and appear here for informational purposes only. Similarly for **CommonPojo** and **AdminPojo**. ``` abstract class Pojo { // internal-use only String ____; // name of the XML element causing this POJO to be created String name; // may or may not be identical to '____'; sometimes this is name in a significant way int lineNumber; // used to report errors in catalina.out DocumentType doctype; // one of "CCDA", "QRDA I", "QRDA III", "Care Plan" or "Unstructured" String vendor; // name soliciting this generated document Integer conformance; // conformance year of the document boolean validate; // can turn off validation using (deprecated) String[] required; // validation: list of fields/children (by name) that must be present String[] optional; // validation: list of fields/children (by name) that are optional String[] notes; // validation: list of notes or suggestions } class Unknown extends Pojo // applied to any IXML element that is not understood, at least temporarily { // internal-use only String elementname; Map< String, String > attributes; String content; } ``` #### Conformance See field, conformance, above. For instance, conformance to chronologically advancing implementation guides from *CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_Vol2_ 2019JUN with_errata.pdf* to *CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_Vol2_ 2022SEP with_errata.pdf* is done by injecting (e.g.) `<conformance>2022</conformance>` into the IXML header (after <doctype> is a good place). For CCDAs, this went into effect in *mdht-restlet##3.5.0*. #### List of base-level POJOs The POJOs below are used mostly as subordinates to other POJOs. **Base64** is used to create instances of *Unstructured Document (V2)*. This POJO results in the creation of a *text* element inside a *nonXMLBody* and optionally involves compression. | Source Code | IXML Sample | | --- | --- | | Address | | ``` class Address extends Pojo { String use; List< String > line; String city; String state; String zipcode; String country; } ``` | ```
5242 Broadway Avenue #538 New York NY 10001 US
``` | | Authenticator | | ``` class Authenticator extends Pojo { String time; String signaturecode; String signaturetext; } ``` | ``` ``` | | Base64 | | ``` class Base64 extends Pojo { String mediatype; String compression; // e.g.: "DF" } ``` | ``` TWFueSBoYW5kcyBtYWtlIGxpZ2h0IHdvcmsu== ``` | | Patient | | ``` class Patient extends Pojo { String facilityoid; String mrn; List< Id > id; String firstname; String lastname; List< String > middlename; String birthdate; Sex gender; Race race; Ethnicity ethnicity; Language language; MaritalStatus maritalstatus; Religion religion; Telecom telecom; Address address; } ``` | ```
2.16.840.1.113883.3.6452 665892 Herman Munster 18561031000000+0000
1313 Mockingbird Lane Mockingbird Heights CA 90210 US
``` | | CustodianInfo | | ``` class CustodianInfo extends Pojo { String oid; String name; Telecom telecom; Address address; } ``` | ```
2.16.840.1.113883.3.6452 IMAT Solutions +1.844-772-6258
565 East Technology Avenue 3300 Orem UT 84097 US
``` | It is often the case that the IMAT Solutions search engine knows about authors loosely associated with a patient's care without knowing which authors are associated with which concept (problem, procedure, vital sign, etc.). Such authors as are known may be placed in this POJO and will be generated in the CCD's <documentationOf ... /> section at the bottom of the header. | Source Code | IXML Sample | | --- | --- | | DocumentationOf | | ``` class DocumentationOf extends Pojo { List< Author > authors; } ``` | ``` . . . ``` | | EffectiveTime | | ``` class EffectiveTime extends Pojo { Low low; High high; } ``` | | | Header | | ``` class Header extends Pojo { DocumentType doctype; String vendor; String codename; String title; String informationrecipientid; Patient patient; HieInfo hieinfo; CustodianInfo custodianinfo; HParticipant participant; List< NextOfKin > nextofkin; } ``` | ```
CCDA Dogpatch Mule 'n' Maternity 2023 Continuity of Care Document Continuity of Care Document
``` | | ``` enum DocumentType { UNKNOWN, CCDA, QRDA_I, QRDA_III } ``` | | | HieInfo | | ``` class HieInfo extends Pojo { String oid; String name; String telecom; Address address; } ``` | ```
Bronx RHIO tel:+1(718)708-6630 2.16.840.1.113883.3.371
1776 Eastchester Road Bronx NY 10461 US
``` | | High | | ``` class High extends Pojo { String root; String extension; } ``` | | | Id | | ``` class Id extends Pojo { String root; String extension; } ``` | ```
... ...
``` | | Low | | ``` class Low extends Pojo { String value; } ``` | | | NextOfKin | | ``` class NextOfKin extends Pojo { String firstname; String lastname; List< String > middlename; String birthdate; Sex gender; Race race; Ethnicity ethnicity; Address address; } ``` | ```
Jack the infamous Ripper 18600131
Highstreet, 10 Chelsea Greater London SW10 0AB UK
``` | | Organization | | ``` class Organization extends Pojo { String name; String facilityoid;* Telecom telecom; Address address; } ``` *Warning: In times past, this field was id. This confuses the SAX parser by failing to parse and subsume constructs like vital signs under larger collections. Hence, some data sections go missing. | ``` Westinghouse Corporation 2.4.87.932456.10.20.3 +1617.232.0891
35 Medicine Avenue Westinghouse MA 02136 US
``` | | HParticipant | | ``` class HParticipant extends Pojo { String typecode; String classcode; String certificationnumber; Organization organization; Person person; Address address; // (deprecated) } ``` | ```
VRF ASSIGNED 123456 IND GUAR 123456
``` | | Person | | ``` class Person extends Pojo { String family; String given; List < String > givens; String prefix; String suffix; String npi; Telecom telecom; Address address; } ``` | ``` Lewis Clive Staples Jack Prof. +44 01865 22 3333
The Kilns Oxford OX1 1AF UK
``` | | Recipient | | ``` class Recipient extends Pojo { boolean intended; Person person; Organization organization; } ``` | ``` ``` Used for <informationRecipient ... /> | | Telecom | | ``` class Telecom extends Pojo { String use; String number; } ``` | ``` +33 9 75.76.65.71 ``` | ## Common (evolved) POJOs CommonPojo doesn't appear in the IXML, but its instance variables appear—used as attributes on XML elements. Most CommonPojos directly represent sections; some are helpers used to enhance others by composition (as opposed to inheritance). | CommonPojo | | --- | | ``` class CommonPojo extends Pojo { // internal-use only String classcode; // attribute for CDA section, e.g.: OBS String moodcode; // attribute for CDA section, e.g.: EVN String typecode; // "2.16.840.1.113883.1.11.19601" (more often, "REFR", "SPRT", etc.) String startdate; // "2017-05-02 12:21:36", "20180101000000", etc. or "" or leave field out String enddate; // "2017-05-02 18:23:01", "20180201000000", etc. or "" or leave field out String code; // "2670", "142496001", etc. String codesystem; // "2.16.840.1.113883.6.88" String codesystemname; // "RxNorm", "SNOMED", "LOINC", etc. String displayname; // some formal or informal name, etc. String statuscode; // "completed" or "active" } ``` | **CommonPojo** features many fields that are used in POJOs that subclass it. - **classcode**, **moodcode** and **typecode** are used in situations where the boilerplate cannot know and so IXML must say which. - **startdate** serves in **effectivetime** for **low** and also in those situations where it's the only time and there is no **enddate** (or **high**) semantically. - **code**, **codesystem**, **codesystemname** and **displayname** are a set of four crucially important codes used to generate MDHT CD or CEcodes in the CCD construct: ``` ``` - Some POJOs, like **Problem**(and others), must populate value codes with similar sets (to the four explain just above) in the CCD construct: ``` ``` So it is that these POJOs must offer **valuecode**, **valuecodesystem**, **valuecodesystemname** and **valuedisplayname** in order to reduce confusion as to what construct they'll be used for. In the cases where a complete set of the four is not offered, the missing ones are guaranteed boilerplated. - **statuscode**is used to supply the value in the construct: ``` ``` Even if this value is established by boilerplate, it usually can be overridden. - Note that any attribute may be passed to an IXML element. If unrecognized, for example, it's an old, deprecated one, it will simply be ignored without any effect upon what's generated in the CCD. ## The HtmlTableFormat POJO This tailors the human-readable (HTML table) section generated in the CCDA for each principal section (such as Allergies, Encounters, Immunizations, Medications, Problems, Procedures, etc.). This element is usefully applied to any CommonPojo (listed further below) that's expected to provide a human-readable (HTML table) in the generated CCDA. Multiple or none of these definitions appear below the header and above the individual concept lists and their definitions. | Source Code | IXML Sample | | --- | --- | | HtmlTableFormat | | ``` class HtmlTableFormat { String sectionname; List< Column > columns; } ``` | ``` \n" ... ``` | | Column | | ``` class Column { String name; // header name for the column (free form: you may name this anything you wish) String source; // IXML CommonPojo member providing the resource String empty; // what to default to in case of missing resource } ``` | | Failure to express attribute empty will cause default "(unknown)" to be substituted for data when the cell data/value is null or empty. The CommonPojos that are candidates for this treatment are as follows. In the documented examples of some of these, you may find a small example of a column or two based on which you can fully define them. Failure to define an HTML table format override for a section will mean that the original, IMAT Solutions' default columns are used including the data implied (i.e.: what IMAT Solutions used to supply before creating this flexibility feature). | CCDAs | | --- | | [**Allergy**](/docs/ixml#Allergy) | (sectioname="allergy") | | [**Encounter**](/docs/ixml#Encounter) | (sectioname="encounter") | | [**FunctionalStatus**](/docs/ixml#FunctionalStatus) | (sectioname="functional status") | | [**Immunization**](/docs/ixml#Immunization) | (sectioname="immunization") | | [**Medication**](/docs/ixml#Medication) | (sectioname="medication") | | [**Payer**](/docs/ixml#Payer) | (sectioname="payer") | | [**Problem**](/docs/ixml#Problem) | (sectioname="problem") | | [**Procedure**](/docs/ixml#Procesure) | (sectioname="procedure") | | [**Result**](/docs/ixml#Result) | (sectioname="result") | | [**SocialHistory**](/docs/ixml#SocialHistory) | (sectioname="social history") | | [**SmokingStatus**](/docs/ixml#SmokingStatus) | (sectioname="smoking status") | | [**VitalSign**](/docs/ixml#VitalSign) | (sectioname="vital sign") | | Care Plans | | [**Goal**](/docs/ixml#Goal) | (sectioname="goal") | | [**HealthConcern**](/docs/ixml#HealthConcern) | (sectioname="health concern") | | [**Intervention**](/docs/ixml#Intervention) | (sectioname="intervention") | | QRDA | | No sections in QRDA I or III participate in explicit human-readable generation. | In the IXML examples below, where there is a <htmltableformat, it is usually the description of the IMAT Solutions default figuring in the explanation above. This means a) that you don't have to do anything (add <htmltableformat) to get that behavior, but b) the default given serves as a good place to start when you do wish to deviate from the default and build your own. #### How to know which fieldnames of the POJO can serve as data sources Not all instance variables (fields) are candidates for this feature. Written Java, obviously there is strict delineation between data and code. Consequently, we predict what you will want to use and annotate POJO fieldnames in this rather light, background color that are eligible. If you wish to consume data from a field that isn't thus marked, please contact us. When consuming fields from a list (or array) of subordinate elements of a POJO (a frequent example would be [**Translation**](/docs/ixml#Translation)), only the first (or zeroeth) element will be used. In an allergy instrumented thus: ``` ... ``` Only the type of the first [**AllergyObservation**](/docs/ixml#AllergyObservation) will be considered no matter how many additional observations may exist. #### Special framework extensions ##### Name-builder macro Taking an example from [**Result**](/docs/ixml#Result) for the formation of the *primary-care physician*'s name, it's possible to dictate how that happens using a special syntax. Here's the example: ``` ``` The way this works is to 1. end the source syntax string with an element (name) that doesn't exist in the named POJO (Person), but that is descriptive of the result (though it doesn't matter—it's for documentary value). 2. A final colon is added, then... 3. elements by names that do exist for the POJO are added—separated by plus signs (+); these are used to source and format the individual fields they suggest. ##### OR'd sources Taking an example from [**Encounter**](/docs/ixml#Encounter) for the source of date, this value comes from the [**Problem**](/docs/ixml#Problem) if there is one. However, as not all [**Encounter**](/docs/ixml#Encounter)s have subordinate [**Problem**](/docs/ixml#Problem)s, the date can come from the [**Encounter**](/docs/ixml#Encounter)'s startdate or enddate (not really in an encounter—it's just an example to illustrate OR) field thus: ``` ... ``` ##### [**AllergyObservation**](/docs/ixml#AllergyObservation) syntax enhancements There is a syntactic mechanism in the [**HtmlTableFormat**](/docs/ixml#HtmlTableFormat) specification by which fields in the [**AllergyObservation**](/docs/ixml#AllergyObservation) can contribute to the human-readable (HTML table) for [**Allergies**](/docs/ixml#Allergy). For example, an HR specification for [**Allergies**](/docs/ixml#Allergy) in IXML might look like this: ``` ``` The CCD output looks like this (highlighted lines correspond to the highlighted lines of the IXML specification above): ``` Allergies and Intolerances
date description facility reaction severity
2020-01-01 orange juice CharterCare Swelling Severe
``` The more obscure details of this lie in *mdht-restlet* code running the list of [**AllergyObservation**](/docs/ixml#AllergyObservation)s to pick the observation whose type matches the current specification's bracketed expression. There are two in the specification: ``` ``` As we do not require that this list just happen to be in the same order as the specification's columns (i.e.: "reaction" first, then "severity"), we have to match the type to ensure we get the correct valuedisplayname as the data for the corresponding column. So, the mysterious detail of this implementation (for the IXML writer) would be that field type is implicitly involved. Hence, the comment in the documented specification sample. Here we add the allergy observations as coded in the IXML which should help to remove this mystery. I purposely expressed them out of order for the purpose of demonstrating that the implementation is sensitive enough not to require it. ``` ``` ## The Author, Participant, and Performer POJOs Is a mere Pojo, but it's mostly consumed by other POJOs. Note that not every field in Person and Organization is required; in fact, most are not. For example, Person offers a telecom and address, but even if present, these will never be used (in Author). Similarly, Organization offers fields that will not be used in this context. All authors furnished to any concept section are collected into a list, duplicates are dropped, then the whole list is added to the <documentationOf ... > section near the end of the header in the generated CCD. | Author | IXML Sample | | --- | --- | | ``` class Author extends Pojo { String time; String code; String codesystem; String codesystemname; String displayname; Telecom telecom; Address address; Person person; // PCP and NPI Organization organization; // facility name and OID } ``` | ``` 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892 Beverly Hills Clinic 2.16.840.1.113883.19.42 ``` | **CommonPojo**'s facilityname, facilityoid, pcp (primary-care physician) and npi (National Provider Identifier) used to be fields shared in common (to all POJOs subclassing CommonPojo). One or more of these were often passed as attribute values. This no longer serves any purpose; this practice has been deprecated. The proper source of this information is in the **Author** associated with the POJO in question (if expressed): | fieldname | present, expected source | | --- | --- | | facilityname | From **Organization** → name | | facilityoid | From **Organization** → facilityoid | | pcp | From **Person** → family, given, suffix | | npi | From **Person** → npi | In generating CCDAs, **Author** is consumed by the following subclasses of CommonPojo: 1. [**Allergy**](/docs/ixml#Allergy) 2. [**SelfCare**](/docs/ixml#SelfCare) ( **FunctionalStatus**) 3. [**StatusObservation**](/docs/ixml#StatusObservation) ( **FunctionalStatus**) 4. [**Immunization**](/docs/ixml#Immunization) 5. [**Medication**](/docs/ixml#Medication) 6. [**Problem**](/docs/ixml#Problem) 7. [**Procedure**](/docs/ixml#Procedure) 8. [**ResultPanel**](/docs/ixml#ResultPanel) 9. [**SocialHistory**](/docs/ixml#SocialHistory) ( **SocialHistories**) 10. [**SmokingStatus**](/docs/ixml#SmokingStatus) ( **SocialHistories**) 11. [**VitalSignGroup**](/docs/ixml#VitalSignGroup) 12. [**VitalSign**](/docs/ixml#VitalSign) But, these do not accommodate any **Author**: 1. [**Encounter**](/docs/ixml#Encounter) (has a list of [**Problem**](/docs/ixml#Problem)s each of which accommodates [**Author**](/docs/ixml#Author)) 2. [**FunctionalStatus**](/docs/ixml#FunctionalStatus) (⅔ of subsections accommodate [**Author**](/docs/ixml#Author)) 3. [**Payer**](/docs/ixml#Payer) (immature, not really used presently, may change) 4. [**Result**](/docs/ixml#Result) (parent [**ResultPanel**](/docs/ixml#ResultPanel) accommodates the [**Author**](/docs/ixml#Author) for all **Result**s) ## Participant Participant is not ubiquitous; it's currently only supported by [***Encounter***](/docs/ixml#Encounter). | Participant | IXML Sample | | --- | --- | | ``` class Participant extends Pojo { String name; // of Service Delivery Location String code; String codesystem; String codesystemname; String displayname; Telecom telecom; Address address; } ``` | ``` codesystemname="Health Care Provider Taxonomy" displayname="Physician" name="Catskills Health Clinic"> 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
``` | Service Delivery Location ## Performer Performer is very similar to [***Author***](/docs/ixml#Author). It is not ubiquitous; it's currently only supported by [***Encounter***](/docs/ixml#Encounter). | Performer | IXML Sample | | --- | --- | | ``` class Performer extends Pojo { String code; String codesystem; String codesystemname; String displayname; String functioncode; String functioncodesystem; String functioncodesystemname; String functiondisplayname; String originaltext; Telecom telecom; Address address; } ``` | ``` 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892
Beverly Hills Clinic 2.16.840.1.113883.19.42
``` | ## Other consumed POJOs These only serve in subordinate roles to principal POJOs. These translations correspond to *translation* noted in the [*Implementation Guide*](/v1/docs/ixml#documents-implementation-guide) as generated under <code> constructs. In general, if any of these tetracodes is missing, you're inviting trouble. In some cases, absence will cause "subtranslations" to occur or the translation will be constructed with null or missing values. | Translation | IXML Sample | | --- | --- | | ``` class Translation extends Pojo { String code; String codesystem; String codesystemname; String displayname; } ``` | ``` ``` | ## Principal POJOs Usually atop [**CommonPojo**s](/docs/ixml#CommonPojo), these are used to build the CCDA section by section. **Important note:**  All these [CommonPojo](/docs/ixml#CommonPojo) subclasses offer not only the fields explicitly documented, but also all the fields in superclass [CommonPojo](/docs/ixml#CommonPojo) such as (especially) code, codesystem, etc. These fields are crucially relevant. | Source Code | IXML Sample | | --- | --- | | Allergy | | ``` class Allergy extends CommonPojo { Author author; String observationstatuscode; Author observationauthor; List< AllergyObservation > allergyobservation; } ``` | ``` 818 290-9233 ... ``` | | Allergies and Intolerances Section (V3) Allergy Concern Act (V3) Allergy—Intolerance Observation (V2) | | | AllergyObservation | | ``` class AllergyObservation extends CommonPojo { String type; ("reaction" or "severity") String valuecode; String valuecodesystem; String valuecodesystemname; String valuedisplayname; } ``` | ``` ``` | | Reaction Observation (V2) Severity Observation (V2) | | EncompassingEncounter | | ``` class EncmpassingEncounter extends CommonPojo { String root; String extension; String facilityroot; } ``` | ``` ``` | | Encounter | | ``` class Encounter extends CommonPojo { List< Translation > translation; List< Problem > problems; Performer performer; Participant participant; } ``` | ``` ``` | | Encounters Section (V3) Encounter Activity (V3) Encounter Diagnosis (V3) Problem Observation (V3) | | | FunctionalStatus | | ``` class FunctionalStatus extends CommonPojo { List< StatusObservation > statusobservation; List< AssessmentScale > assessmentscale; List< SelfCare > selfcare; } ``` | ``` ``` | | **Functional Status Section:** Functional Status Observation (V2) Assessment Scale Observation Assessment Scale Supporting Observation Self-care Activities | | | StatusObservation | | ``` class StatusObservation extends CommonPojo { Author author; } ``` | ``` ``` | | AssessmentScale | | ``` class AssessmentScale extends CommonPojo { String value; ScaleSupporting scalesupporting; } ``` | ``` ``` | | ScaleSupporting | | ``` class ScaleSupporting extends CommonPojo { String value; } ``` | ``` ``` | | SelfCare | | ``` class SelfCare extends CommonPojo { String valuecode; String valuecodesystem; String valuecodesystemname; String valuedisplayname; Author author; } ``` | ``` ``` | | Goal | | ``` class Goal extends CommonPojo { String value; String unit; Author author; } ``` | ``` 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892 ``` | | Goals Section Goal Observation Identifier | | | HealthConcern | | ``` class HealthConcern extends CommonPojo { Author author; } ``` | ``` 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892 ``` | | Heath Concerns Section (V2) Health Status Observation (V2) Health Concern Act (V2) | | Immunization | | ``` class Immunization extends CommonPojo { boolean negation; // false (default) String value; String unit; List< Translation > translation; Author author; } ``` | ``` unit="mg/DL" code="106" codesystem="2.16.840.1.113883.12.292" codesystemname="CVX" displayname="diphtheria"> 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892 ``` | | Immunization Section (V3) Immunization Activity (V3) Immunization Medication Information (V2) | | | Intervention | | ``` class Intervention extends CommonPojo { String order; //one of "Intervention Act (V2)" (default), //"Planned Intervention Act (V2)"or //"Handoff Communication Participants" String moodcode; //one of "APT", "ARQ", "INT","PRMS", "PRP" or "RQO" List< Author > author; List< HParticipant > hparticipant; } ``` | ``` 818 290-9233
32089 Rodeo Drive Beverly Hills CA 90210 US
Seymore Jane J. MD 665892 ``` | | Interventions Section (V3) Intervention Act (V2) Planned Intervention Act (V2) Handoff Communication Participants | | | Medication | | ``` class Medication extends CommonPojo { String value; String repeatnumber; String approachsitecode; String approachsitecodesystem; String approachsitecodesystemname; String approachsitedisplayname; String ratequantity; String ratequantityunits; String maxdosequantitynumerator; String maxdosequantitydenominator; String administrationunitcode; String administrationunitcodesystem; String administrationunitcodesystemname; String administrationunitdisplayname; String materialcode; String materialcodesystem; String materialcodesystemname; String materialdisplayname; String routecode; String routecodesystem; String routecodesystemname; String routedisplayname; Immunization immunization; List< Translation > translation; Author author; } ``` | ``` ``` | | Medications Section (V2) Medication Activity (V2) Medication Information (V2) | | | Payer | | ``` class Payer extends CommonPojo { String translationcode; String translationdisplayname; } ``` | ``` Munster Lily Dracula Mrs. +400745-443 444
Str. Maslinului nr. 16A Bucharest Bucharest RO
``` | | Payers Section (V3) Coverage Activity (V3) Policy Activity (V3) | | | Plan | | ``` class Plan extends CommonPojo { Author author; } ``` | ``` ``` | | Assessment and Plan Section (V2) Planned Act (V2) —as yet never generated | | | Problem | | ``` class Problem extends CommonPojo { String translationcode; String translationcodesystem; String translationcodesystemname; String translationdisplayname; String valuecode; String valuecodesystem; String valuecodesystemname; String valuedisplayname; List< Translation > translation; Author author; } ``` | ``` enddate="" code="99645-9" codesystem="2.16.840.1.113883.6.90" codesystemname="SNOMED" displayname="Acquired absence of unspecified breast and nipple" translationcode="Z90.10" translationcodesystem="2.16.840.1.113883.6.90" translationcodesystemname="ICD10" translationdisplayname="Acquired absence of unspecified breast and nipple" valuecode="Z90.10" valuecodesystem="2.16.840.1.113883.6.90" valuecodesystemname="ICD10" valuedisplayname="Acquired absence of unspecified breast and nipple"> above --> codesystem="2.4.6.8.10.12" codesystemname="This isn't a code system" displayname="This is a translation of a code system" /> ``` | | Problem Section (V3) Problem Concern Act (V3) Problem Concern Act (V3) Problem Observation (V3) | | | Procedure | | ``` class Procedure extends CommonPojo { String value; String units; String targetsitecode; // (SHOULD, probably missing) String targetsitecodesystem; String targetsitecodesystemname; String targetsitedisplayname; String activity; // "observation" (default), // "procedure" or "act" Author author; } ``` | ``` ``` | | Procedures Section (V2) Procedure Activity Observation (V2) Procedure Activity Procedure (V2) Procedure Activity Act (V2) | | | ResultPanel | | ``` class ResultPanel extends CommonPojo { String classcode; (default is BATTERY) Author author; List< Result > result; } ``` | ``` 615 349-7777
Main Street Dogpatch TN 37026 US
Mamie Yokum MD 1234 ``` | | (See [**Result**](/docs/ixml#Result).) | | | Result | | ``` class Result extends CommonPojo { String value; String unit; String interpretationcode; String interpretationcodesystem; String observationlowvalue; String observationhighvalue; String observationunit; String observationtext; List< Translation > translation; } ``` | ``` ``` | | Results Section (V3) Result Organizer (V3) Result Observation (V3) | Note: despite <htmltableformat ... /> or not, each result panel leads to the generation in the human-readable (HTML) section of row banners. These make use of ResultPanel.displayname and are notaffected by anything put into the [flexible human-readable mechanism](/docs/ixml#html-format). | | SocialHistories | | ``` class SocialHistories extends CommonPojo { List< SocialHistory > socialhistories; List< SmokingStatus > smokingstatus; List< Pregnancy > pregnancies; List< TobaccoUse > tobaccouses; List< Caregiver > caregivers; List< CultureAndReligion > culturesandreligions; List< HomeEnvironment > homeenvironments; } ``` | ``` ``` | | (See [**SocialHistory**](/docs/ixml#SocialHistory).) | | | SocialHistory | | ``` class SocialHistory extends CommonPojo { String value; List< Translation > translation; Author author; } ``` | ``` code="102487004" codesystem="2.16.840.1.113883.6.96" codesystemname="SNOMED_CT" displayname="Environmental risk factor"> ``` | | Social History Section (V3) Social History Observation (V3) | | | SmokingStatus | | ``` Class SmokingStatus extends CommonPojo { String valuecode; String valuecodesystem; String valuecodesystemname; String valuedisplayname; List< Translation > translation; Author author; } ``` | ``` // (HTML table cell) ``` | | Smoking Status—Meaningful Use (V2) | | | VitalSignGroup | | ``` class VitalSignGroup extends CommonPojo { Author author; List< VitalSign > vitalsign; } ``` | ``` > ``` | | (See [**VitalSign**](/docs/ixml#VitalSign).) | | | VitalSign | | ``` Class VitalSign extends CommonPojo { String value; String units; List< Translation > translation; Author author; } ``` | ``` > units="mm[Hg]"> units="mm[Hg]"> ``` | | Vital Signs Section (V3) Vital Signs Organizer (V3) Vital Sign Observation (V2) | | ## Specialized POJOs AdminPojo doesn't appear in the IXML, but its instance variable, count, appears as an attribute on XML elements. These are also referred to as *administrative* or *demographic POJOs*. In the pop-up examples there are multiple, optional forms. The preferred form comes first; the others typically demonstrate backward support for earlier versions of *mdht-restlet*. Earlier forms probably work, but are not guaranteed always to work. If any of these are construed inaccurately, i.e.: invalid code (here 9999-9 which is not a valid race code and "white"), code system, code system name, etc., the result will be incorporated in a translation: ``` ``` This means that it's possible to substitute non-standard, private or proprietary codes in a way that will nevertheless validate. | Source Code | IXML Sample | | --- | --- | | AdminPojo | | ``` class AdminPojo extendsCommonPojo { } ``` | // internal-use only | | Ethnicity | | ``` class Ethnicity extends AdminPojo { } ``` | ``` 2135-2 ``` | | Language | | ``` class Language extends AdminPojo { } ``` | ``` eng ``` | | MaritalStatus | | ``` class MaritalStatus extends AdminPojo { } ``` | ``` S Widowed ``` | | Race | | ``` class Race extends AdminPojo { } ``` | ``` 1002-5 white ``` | | Religion | | ``` class Religion extends AdminPojo { } ``` | ``` 1027 Catholic ``` | | Sex | | ``` class Sex extends AdminPojo { } ``` | ``` Female Unknown ``` | ## Appendix: IXML format templates ## POJO Theory In Java, a *POJO* is a "plain, old Java object," elsewhere also called *a bean*. Each XML element in the IXML is rendered in *mdht-restlet*'s data structures as: - a POJO 1, 2, 3 - implied collection of POJOs (but doesn't render as anything itself), 4 - nothing (because ignored).5 1 all IXML identifiers are lower-case; there is no mixed-case. 2 all POJOs in Java are classnames and are in **bold**, camelback case here, but as IXML elements they are lower-case (e.g.: EffectiveTime → <effectivetime>). 3 in the POJOs below, instance variable names (or fields) refer either to attributes or subelements in IXML; again, no mixed case. 4 an example of this would be <encounters> in the IXML below: ``` ``` 5 <cdadoc> is an example of this. As pointed out in the notes above, in the names of POJOs, you should recognize principal IXML element names. In the instance variable names or fields of each of these POJOs you should recognize either IXML attributes for those elements or subelements or, in some cases, element content text according to this example: ``` < element-name attribute-name="attribute-value"> < subelement-name /> element content text ``` POJOs, as Java objects, may inherit from other POJOs. So it is the case that many POJOs, like Allergy, which appears to have few defined fields (instance variables) of its own, in fact have all those of CommonPojo, to wit, startdate, enddate, code, codesystem, ... codesystemname. Encounter, for CCDAs, has all of CommonPojo plus problems and others still. Base class Pojo defines instance variables doctype, vendor, name, conformance, etc. These have no significance in the subclassing POJO. For example, for Measure, ____ is not the name of the measure (but only "measure" because from measure). The name of the measure must be stored in name. This is documented here because it's a point of confusion. Sometimes, what's an attribute and what's a subelement is described by a comment. Minor inconsistencies caused by this implementation being done first in May 2018 by two persons, both of which left the company, carried on by another, then, at the return of one of the originals, more work was done. Finally, standardization was undertaken (ironically by the two who left the company, then came back), but there are still a few awkward inconsistencies. These may be highlighted erratically here and there. Here are some sample "railroad tracks" for IXMLs. ## Methodology This documentation is primarily a reference guide or grammar and not a method. It has many uses for reference (mostly), but it is also the only aid to IXML composition. Here are some suggestions for bridging the gap. - The examples on this page are not always kept perfectly up to date, but they are more practically useful than the POJO definitions. They are the closest thing to a method. - Remember, when using the POJO definitions as your guide, that there are semantics that are rarely apparent, such as: - Some, but rarely all of the fields of the resource's superclass ([**CommonPojo**](/docs/ixml#CommonPojo), [**AdminPojo**](/docs/ixml#AdminPojo)) pertain to the resource you are composing. - However, if you supply unheeded attributes in your resource, they will likely be ignored and not hurt anything. - Fields consumed by one resource (e.g.: [**Problem**](/docs/ixml#Problem)) may not always be used for exactly the same semantic purpose in another (e.g.: [**Allergy**](/docs/ixml#Allergy)). Attributes code, codesystem, etc. are usually for the <code ... /> near the top of any generated resource, but not always. Sometimes they may (perplexingly) apply to another such as <value ... />. #### Definitions - A *resource* is a major POJO such as Allergy, Medication, VitalSign, etc. - Resources are generated as *entries* in CCDA based on information a corresponding IXML element which becomes a POJO in *mdht-restlet*. - Entries are collected together in a *section*. Most often, POJO names directly evoke section names ( Allergy—*Allergies & Intolerances*, Problem—*Problems*, etc.). - Sections are subordinate to semantically insignificant *components*. - The MDHT library is called to generate syntagms and outputs CDA (CCDA, QRDA, etc.). #### Creating a section In IXML, a section being one or more entries each represented by an IXML element, these elements are groups together using an element usually given a name in the plural, e.g.: ``` ``` The plurals are arbitrary; they only need to match (i.e.: legal XML). Hence, the above could be: ``` ``` As plural element names are unknown to *mdht-restlet* and are discarded except for their value in grouping significant POJOs into a section, any attributes or content text are discarded. In short, these section elements are collectors that wrap the entries. If you have no entries (for example, if you have no problems to emit), then you do not need to generate an empty section, but it will not cause *mdht-restlet* to fail: ``` ``` or: ``` ``` #### Creating an entry This is the significant part of building IXML. For each instance of a resource, such as (these were the supported sections as of *mdht-restlet##3.2.2*): 1. an allergy, 2. an encounter, 3. a functional status, 4. an immunization, 5. a medication, 6. a payer, 7. a problem, 8. a procedure, 9. a (lab) result, 10. a social history or 11. a vital sign, There will be a corresponding element with attributes and usually subelements each with more attributes and often their own subelements. This hierarchy should be accurately documented in the lists of CommonPojos above. In (lab) results, there is the additional complexity that results are grouped into one or more result panels. The numbering used here is only to convey understanding; there is no numbering element or attribute in the XML of the IXML document: ``` ``` A similar thing happens for vital signs: they are grouped into one or more vital groups (the *Implementation Guide* doesn't speak of "vital sign panels"). Vital-sign groups should be united by startdate, but can be assembled according to any criteria. If <vitalsigngroup> is used in IXML, then no attempt will be made to impose that defined groups be assembled by date. Each group defined will result in a CDA *Organizer* that subsumes all of the vital signs defined below it. In the following example, two organizers carrying three (and two) vital signs will be seen in CDA output. Vital-sign groups should include an author (SHOULD); individual vital signs themselves should include an author (SHOULD). Missing author definitions are tolerated, however. ``` ``` The following legacy format is still tolerated. The result is that the vitals will be sorted, then grouped, according to startdate under a CDA *organizer*. Also, in this case, the CDA *Organizer* will not carry any author (SHOULD) since there's no IXML element to define one. Individual vital signs can carry an author if defined (SHOULD). ``` ``` #### Creating a proper entry In order to create an entry, you must 1. generate the proper element name (from the numbered list above), 2. generate the attributes required for that resource, 3. generate the subelements required or optional for that resource, 4. generate the attributes and subelements incumbant upon each of those subelements. #### Creating the header The header has its own required content which differs between CCDA, QRDA and other CDA types. This will not be discussed here. The resources to expect in a CCDA header include most of which are elements rather than attributes on elements): - codename - title - informationrecipiantid - patient (has subelements; cannot have plurality) - hieinfo (has subelements) - nextofkin (has subelements; suggested name of plural collector is "kin") - hparticipant (has subelements) - custodianinfo (has subelements; plural is "custodians") Some elements are crucial and, if missing, the IXML will fault. Not all plurality (or collections) is supported in all headers. Passing additional kin, participantsder , custodians, etc. may not result in date being put into the CCDA. Please contact us with observations or complaints about this. ## Execution An example of how CCDA documents are generated (QRDA I). 1. The JUnit test or Tomcat servlet code passes the IXML input as a stream to a SAX parser. 2. ParseIncoming.parse( InputStream inputStream ) invokes SAX parsing. 3. IncomingDataHandler, this is the SAX parser user code, calls... 4. ...various IncomingDataHandler.method()s until, having reached the IXML document's end... 5. ...IncomingDataHandler.endDocument() winds up the parsing, then calls for MDHT generators. 6. Depending on the type of document being generated, CCDA, QRDA I or QRDA III, a generator is called. 7. Generate.generateDocument() refines the POJOs, then calls generators on all parsed POJOs thus: 8. Bottles up the (MDHT-generated) document and returns it as a String to the bottom of the SAX parser handler, endDocument(), thence to the bottom of the SAX parser and finally to the invoking code in (JUnit test or Tomcat servlet). ## When "(unknown)" is unexpected This typically happens in human-readable (HTML) tables and is the result of failing to set tetracode fields code, codesystem, codesystemname, but in particular, displayname (many examples, most concept sections). Another way for this to happen is to be missing a value or unit (see, for example, [**VitalSign**](/docs/ixml#VitalSign)). Less clear might be to have failed to provide fields inside more complex structures such as a facility name (in [**Author**](/docs/ixml#Author) → [**Organization**](/docs/ixml#Organization) → name). If you leave constructs such as authors and organizations out (unexpressed, null or otherwise unpopulated in IXML), you must expect this sort of thing to happen. ## You may preserve the attribute value value="<60" of a [**Result**](/docs/ixml#Result), or other section types in CCD, as expressed: ``` ``` But, the [*Implementation Guide*](/v1/docs/ixml#documents-implementation-guide) and validators do not tolerate any value in that field other than a floating point. The solution you'll see to preserve an annotation (<, >, ˜, etc.) involves generating a (legal) translation construct, but respecting the CCDA standard in the value itself where the annotation is dropped as illegal: ``` <60 ``` ## Troubleshooting When the CCDA or Care Plan produced has problems, consider the following. 1. Adhere to the strict and exact spelling of identfiers described in this document. 2. Exact case of POJO names. All POJO names, fieldnames, attribute names, etc. are in lower- not upper or camelback case and without underscores or hyphens. 3. Changing or old identifier names. There isn't much of this, but the exact naming may conflict. 4. In times past, the [**Organization**](/docs/ixml#Organization) id field has been facility, oid, id, etc.. Getting this particular fieldname wrong confuses the SAX parser and constructs like [**VitalSign**](/docs/ixml#VitalSign) and others that include an author plus organization may go missing under parent collections (like [**VitalSignGroup**](/docs/ixml#VitalSignGroup)). The identifier id only occurs legally inside the [**Patient**](/docs/ixml#Patient) (as a list of zero or more [**Id**](/docs/ixml#Id)s). 5. Note that id-conceptual fields exist as various POJO fields: 1. id in [**Patient**](/docs/ixml#Patient) 2. oid in [**CustodianInfo**](/docs/ixml#CustodianInfo) and in [**HieInfo**](/docs/ixml#HieInfo) 3. facilityoid in [**Patient**](/docs/ixml#Patient) and in [**Organization**](/docs/ixml#Organization) ## Logging Logged output is generated in the log file, */opt/tomcat/logs/catalina.out*, which is managed entirely by Tomcat though it's possible to affect what's generated by *mdht-restlet* through modifying ***logback.xml***, a file on the path */opt/tomcat/webapps/mdht-restlet##M.m.r-b/WEB-INF/classes/logback.xml*. ...where *M* refers to the major version number, *m* to the minor version number, *r* to the revision level and *b* to the build number of *mdht-restlet*. Edit this file and change (maybe add because usually missing) the following section. In particular, ensure that the level is set to TRACE. The normal value for level is INFO which keeps the log as only informative. ``` ``` Normally, this is what's in *logback.xml*: ``` ``` To shut any logging except for errors off, removing roughly 35 lines for each CCD generated from the log, do this: ``` ``` Above, name is the Java package path. Knowing the package name makes it possible to constrain the output to just what you want to see happen, but, in order to know what you're tailoring, you would have to understand what code is in what package. This is hard to do and, from time to time, the package paths below *com.imatsolutions* change depending on design refactoring. I would suggest not attempting to second-guess this, but use the example(s) above. Note that any time you modify *logback.xml*, the effect will almost certainly be nil untill you bounce Tomcat: ``` # systemctl restart tomcat ``` When doing deep, ugly debugging, do one of these: ##### Debugging the MDHT generation ``` ``` ##### Debugging the SAX parser (very ugly—more interesting to IXML writers) ``` ``` ### Logging examples ...processing *gold-standard.ixml* at one point: ``` 126 [main] WARN c.i.s.ParseIncoming.parse:115 - Warnings of IXML and other problems arising during SAX parsing and POJO construction: 155 [main] WARN c.i.p.c.Address.perform:122 - 'NW 092 3C' is not a US zipcode, line 540 155 [main] WARN c.i.p.c.Address.perform:138 - Country 'UK' is not US, Canada or Mexico, line 541 157 [main] INFO c.i.s.ParseIncoming.parse:120 - Back from SAX parser... 1103 [main] INFO c.i.m.Generate.generateDocument:196 - Document generating for MPID 1694505 1106 [main] INFO c.i.m.Generate.generateDocument:227 - Vendor requesting document is IMAT Solutions 1118 [main] INFO c.i.m.c.GenerateCcda.generate:111 - Generating CCDA document (at 20220325174120+0000) 1118 [main] INFO c.i.m.c.GenerateCcda.generate:116 - Expected POJOs in play: ...Next of kin 4 ...Custodian info 1 ...Allergies 1 ...Encounters 1 ...Functional Status 1 ...Immunizations 1 ...Medications 1 ...Problems 1 ...Procedures 1 ...Result Panels 1 ...Results 1 ...Social Histories 1 ...Vital Sign groups 3 ...Vital Signs 4 1119 [main] INFO c.i.m.c.GenerateCcda.generate:120 - ...for 1 HIE info 1119 [main] INFO c.i.m.c.GenerateCcda.generate:121 - ...for 1 Custodian info 1119 [main] INFO c.i.m.c.GenerateCcda.generate:122 - ...for 4 Next of kin 1119 [main] INFO c.i.m.c.GenerateCcda.generate:126 - ...for 7 Authors (and potential HParticipants) 1161 [main] INFO c.i.m.c.GenerateCcda.generate:143 - ...for 1 Allergy or Intolerance 1193 [main] INFO c.i.m.c.GenerateCcda.generate:150 - ...for 1 Encounter 1201 [main] INFO c.i.m.c.GenerateCcda.generate:157 - ...for 1 Functional Status 1206 [main] INFO c.i.m.c.GenerateCcda.generate:164 - ...for 1 Immunization 1217 [main] INFO c.i.m.c.GenerateCcda.generate:171 - ...for 1 Medication 1225 [main] INFO c.i.m.c.GenerateCcda.generate:185 - ...for 1 Problem 1232 [main] INFO c.i.m.c.GenerateCcda.generate:192 - ...for 1 Procedure 1239 [main] INFO c.i.m.c.GenerateCcda.generate:199 - ...for 1 Result panel/Lab (1 result) 1253 [main] INFO c.i.m.c.GenerateCcda.generate:206 - ...for 1 Social Histories 1258 [main] INFO c.i.m.c.GenerateCcda.generate:215 - ...for 3 Vital Sign groups (4 vital signs) 2957 [main] INFO c.i.m.Generate.generateDocument:260 - Time spent validating: 1692 ``` If */opt/tomcat/webapps/mdht-restlet##M.m.r-b/WEB-INF/classes/logback.xml* is amended to mandate TRACE-level logging, for example, ``` ``` ...then you might see something like the following extra statements describing the building and folding of authors in lists. ``` 130 [main] WARN c.i.s.ParseIncoming.parse:115 - Warnings of IXML and other problems arising during SAX parsing and POJO construction: 158 [main] INFO c.i.s.ParseIncoming.parse:120 - Back from SAX parser... 1228 [main] INFO c.i.m.Generate.generateDocument:196 - Document generating for MPID 1694505 1232 [main] INFO c.i.m.Generate.generateDocument:227 - Vendor requesting document is IMAT Solutions 1248 [main] TRACE c.i.m.c.AuthorsAndPerformers.outputAuthorList:229 - Authors: 1: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Allergist 2: npi: 43-89-hike, family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 3: npi: , family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 568, name: Good Health Laboratory 4: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Doctor 5: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 6: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 7: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 8: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 9: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 10: npi: 9999999999, family:  Boleyn,     given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 11: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Doctor 1249 [main] TRACE c.i.m.c.AuthorsAndPerformers.outputAuthorList:229 - Deduplicated authors: 1: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Allergist 2: npi: 43-89-hike, family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 3: npi: , family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 568, name: Good Health Laboratory 4: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Doctor 5: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 6: npi: 9999999999, family:  Boleyn,     given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 1249 [main] TRACE c.i.m.c.AuthorsAndPerformers.outputAuthorList:229 - Sorted authors: 1: npi: , family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 568, name: Good Health Laboratory 2: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Allergist 3: npi: 4028-19-4233398, family:  Seymore,    given:  Jane,      middle:  J., facilityoid: 2.16.840.1.113883.5.53, name: Doctor 4: npi: 43-89-hike, family:  of Cleves,  given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 5: npi: 665892, family:  Parr,       given:  Catherine, middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 6: npi: 9999999999, family:  Boleyn,     given:  Anne,      middle:    , facilityoid: 2.16.840.1.113883.5.53, name: Registered Nurse 1249 [main] INFO c.i.m.c.GenerateCcda.generate:111 - Generating CCDA document (at 20220405200214+0000) 1250 [main] INFO c.i.m.c.GenerateCcda.generate:116 - Expected POJOs in play: ...Next of kin 4 ...Custodian info 1 ...Allergies 1 ...Encounters 1 ...Functional Status 1 ...Immunizations 1 ...Medications 1 ...Problems 1 ...Procedures 1 ...Result Panels 1 ...Results 1 ...Social Histories 1 ...Vital Sign groups 3 ...Vital Signs 4 1250 [main] INFO c.i.m.c.GenerateCcda.generate:120 - ...for 1 HIE info 1250 [main] INFO c.i.m.c.GenerateCcda.generate:121 - ...for 1 Custodian info 1250 [main] INFO c.i.m.c.GenerateCcda.generate:122 - ...for 4 Next of kin 1250 [main] INFO c.i.m.c.GenerateCcda.generate:126 - ...for 6 Authors (and potential HParticipants) 1299 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - (no NPI): of Cleves, Anne, 568, Good Health Laboratory... 1301 [main] WARN c.i.m.c.PopulateDocumentationOf.populatePerformerFromAuthor:142 - No NPI code for performer from author.person, line:239 1301 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - 4028-19-4233398: Seymore, Jane, MD, 2.16.840.1.113883.5.53, Allergist... 1302 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - 4028-19-4233398: Seymore, Jane, MD, 2.16.840.1.113883.5.53, Doctor... 1302 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - 43-89-hike: of Cleves, Anne, MD, 2.16.840.1.113883.5.53, Registered Nurse... 1303 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - 665892: Parr, Catherine, BSN, 2.16.840.1.113883.5.53, Registered Nurse... 1303 [main] TRACE c.i.m.c.PopulateDocumentationOf.author:109 - 9999999999: Boleyn, Anne, PhD, 2.16.840.1.113883.5.53, Registered Nurse... 1303 [main] INFO c.i.m.c.GenerateCcda.generate:143 - ...for 1 Allergy or Intolerance 1338 [main] INFO c.i.m.c.GenerateCcda.generate:150 - ...for 1 Encounter 1348 [main] INFO c.i.m.c.GenerateCcda.generate:157 - ...for 1 Functional Status 1351 [main] TRACE c.i.m.c.PopulateFunctionalStatus.status:160 - Functional Status Observation 1... 1351 [main] TRACE c.i.m.c.PopulateFunctionalStatus.status:160 - Functional Status Observation 2... 1352 [main] TRACE c.i.m.c.PopulateFunctionalStatus.status:160 - Assessment Scale 1... 1352 [main] TRACE c.i.m.c.PopulateFunctionalStatus.status:160 - Self-care Activity 1... 1355 [main] INFO c.i.m.c.GenerateCcda.generate:164 - ...for 1 Immunization 1376 [main] INFO c.i.m.c.GenerateCcda.generate:171 - ...for 1 Medication 1383 [main] INFO c.i.m.c.GenerateCcda.generate:185 - ...for 1 Problem 1390 [main] INFO c.i.m.c.GenerateCcda.generate:192 - ...for 1 Procedure 1396 [main] INFO c.i.m.c.GenerateCcda.generate:199 - ...for 1 Result panel/Lab (1 result) 1400 [main] TRACE c.i.m.c.PopulateResultPanels.panel:119 - Chlamydia trachomatis... 1402 [main] TRACE c.i.m.c.PopulateResultPanels.populateResultOrganizerV3:156 - Result 1 1410 [main] INFO c.i.m.c.GenerateCcda.generate:206 - ...for 1 Social Histories 1415 [main] INFO c.i.m.c.GenerateCcda.generate:215 - ...for 3 Vital Sign groups (4 vital signs) 1418 [main] TRACE c.i.m.c.PopulateVitalSigns.group:190 - Vital Sign group 1... 1420 [main] TRACE c.i.m.c.PopulateVitalSigns.group:190 - Vital Sign group 2... 1420 [main] TRACE c.i.m.c.PopulateVitalSigns.group:190 - Vital Sign group 3... 3131 [main] INFO c.i.m.Generate.generateDocument:269 - Document generated; elapsed time: 00:00:00:01:1903 ``` #### *Care Plan (V2)* logging example ``` 131 [main] WARN c.i.s.ParseIncoming.parse:115 - Warnings of IXML and other problems arising during SAX parsing and POJO construction: 150 [main] INFO c.i.s.ParseIncoming.parse:120 - Back from SAX parser... 1102 [main] INFO c.i.m.Generate.generateDocument:196 - Document generating for MPID 1694505 1104 [main] INFO c.i.m.Generate.generateDocument:227 - Vendor requesting document is IMAT Solutions 1263 [main] INFO c.i.m.c.GenerateCarePlan.generate:73 - Generating Care Plan (V2) (at 20220513182356+0000) 1267 [main] INFO c.i.m.c.GenerateCarePlan.generate:78 - Expected POJOs in play (and count): ...HParticipants 2 ...Performers 1 ...Recipients 1 ...Authenticator 1 ...EncompassingEncounter 1 ...Health Concerns 1 ...Goals 1 ...Interventions 1 1337 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:171 - Header information found: 1337 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:180 - HParticipant information found 1337 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:185 - Performers information found 1337 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:190 - Recipient information found 1337 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:195 - Authenticator information found 1338 [main] INFO c.i.m.c.GenerateCarePlan.validateHeader:200 - ComponentOf/encompassingEncounter information found 1376 [main] INFO c.i.m.Generate.generateDocument:269 - Document generated; elapsed time: 00:00:00:00:273 ``` ## The curl command line These are tailored to a) confirming that *mdht-restlet* is up and b) sending an IXML to it to generate a CCD—pretty much all *mdht-restlet* is able to do. 1. Basic GET retrieves HTML. You can do this in a browser. It tells you that *mdht-restlet* is live. ``` $ curl http://localhost:8080/mdht-restlet ``` 2. Basic GET requesting plain text. It tells you that *mdht-restlet* is live. ``` $ curl http://localhost:8080/mdht-restlet -H "Accept: text/plain" ``` 3. Command to POST a file in the payload as a request. It posts IXML from a file in the local filesystem to *mdht-restlet* and the generated CCD comes back on stdout. ``` $ curl http://localhost:8080/mdht-restlet -X POST -H 'Content-Type: application/xml' --data "@sample.ixml" ``` Plain Old Java Object. It is an ordinary Java object, not bound by any special restriction other than those forced by the Java Language Specification and not requiring any classpath. POJOs are used for increasing the readability and re-usability of a program. --https://www.geeksforgeeks.org/pojo-vs-java-beans/#