How to : Handle HL7 with XSD2Code

September 2021

In accordance with the Ségur accords, french law requires a normalization of healthcare-related data, notably by the introduction of an "INS", this "’Identité Nationale de Santé" that is carried over from one establishment to another, so that patients, and their issues are kept close.

In this how-to guide we will go over how you can use the necesarry information for identification notably the INS with these schemas: 
-HL7 CDA
-HL7 FHIR

You can learn more about these schemas, along with other accepted formats and about this whole situation in the following (french) goverment document.

Both of these schemas belong to HL7 you can find them here.

HL7 CDA

The HL7 Version 3 Clinical Document Architecture (CDA®) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. It defines a clinical document as having the following six characteristics:

• Persistence
  
• Stewardship
  
• Potential for authentication
  
• Context
  
• Wholeness
  
• Human readability
  

You can learn more about it here

Now getting into the schema itself, it is an xsd and it can be broken into several parts, the first split comes between the header and the body. The header contains metadata to allow the document to be indexed and managed. The body contains any content that represents a signed documents, for example, a discharge or visit summary even an operative report.

The header contains meta-data about the document, for example :

• Who created the document 
• Who is the document about
• When was the document created
• Where was the document created
• Etc.

Here's an example of what a CDA header could look like :

While the body is either nonXML or XML, it provides a human-readable representation of the document, and if it is an XML body, it will contain XML encoded sections of text with rendering instruction referred to as the Narrative Block.

The body itself can be split into two big parts, firstly, the "narrative block", this section is easily readable, the xml in this case helps with the formatting and generation of a human-readable version of this information, for example the "code", indicates that this section is "Past Medical History"

This section is followed by an entry, an entry is a fully structured and machine-processable representation of an item on the CDA, types include : vital signs, laboratory and allergy observations, substance admiunistrations, etc. If present, and entry's data must also be in a narrative block. Here's what the entry of the narrative block shown above looks like.

It is important to note that in the CDA standard the xml body is optional so that the lowest level of interoperability applies, CDA entries are also optional so that the medium level of interoperability applies, however at the lowest level of interoperability, where cda entries are used, the narrative blocks are required, so that any browser can render the document for human review

All CDA documents must be renderable with a single standard style sheet called cda.xsl. You can also provide a style sheet, all CDA documents are encoded in XML which can be validated automatically using a validation tool.

A link toward a c# project using the CDA and xsd2code with some example xml and xsd's can be found at the bottom of this article. 

If you want more details about how to handle CDA with Xsd2Code++ feel free to read our dedicated article on this topic. 

HL7 FHIR

FHIR is an interoperability standard intended to facilitate the exchange of healthcare information between healthcare providers, patients, caregivers, payers, researchers, and any one else involved in the healthcare ecosystem. It consists of 2 main parts – a content model in the form of ‘resources’, and a specification for the exchange of these resources in the form of real-time RESTful interfaces as well as messaging and Documents.

Some fundemental concepts of FHIR : 

• The information exchanged is communicated in small independent ressources (like patient, allergy, order, etc.)
• Can be independently queried or updated
• Are sometimes linked together

A principle of FHIR is simplicity, it is made of granular resources that can be interacted with independently or combined together. The resources are easy to extend and adopt (extend here meaning adding custom fields beyond the standard), and each resources also includes a human-readable text representation like the CDA.

Lastly FHIR can be used either as XML or as JSon

Here's an example of a FHIR based JSon data file, in this case it's part of a careplan, you can find this file among others of it's kind in the sample github project linked at the bottom of this article

The various schema and data files given may look scary, there's a lot to sift through, but once you do you'll realize that up to 70% is optional, Xsd2Code is here to do this for you.

Code Sample

As mentioned above we have set up simple example-filled projects for both CDA and FHIR, the same github contains other formats if your interested 

https://github.com/xsd2code/XmlSchema