Hello Forum ,
I am very confused as to what are flat forms , how are they created from a template , how are they different from compositions and what are they used for ?
Thank You
1 Like
Hi Yash,
Short answer: âflat formâ means a path-based JSON structure, in the form of a logical table of {path, value} pairs. Itâs an easier way for developers to work with data based on templates. Various flat forms are in heavy use in the community, so it may seem a bit confusing right now (it is 
A âCompositionâ is a canonical data structure in the openEHR Reference model (look for it in the EHR IM spec). You can also create JSON or XML data following this canonical model, which will look like a big tree, and will seem quite a lot more complicated. The idea of the flat forms is to just use the paths relating to fields that you want to fill, and also use a few tricks to enable common data items to be specified in a simpler way than the canonical form.
See this document for one explanation of the general idea.
We are however creating standard(s) to consolidate the flat form format(s) in to one common form (probably with some acceptable variations, for a while). The above document describes an architectural approach to doing this which we may pursue in the future, but in the meantime, we are creating a specification just of the allowable concrete flat forms for data called Serial Data Formats.
People like @pablo , @birger.haarbrandt , @ian.mcnicoll and many others can provide all sorts of details on how to use these formats with ErhBase, EhrScape and other openEHR implementations.
1 Like
@Yash some implementers have the idea that the canonical JSON/XML openEHR formats are too difficult for developers to work with, then they implemented some âsimplifiedâ ways of representing the same information.
The flat formats are one example. Since clinical data is hierarchical, and the openEHR reference model follows a hierarchy of information (data is just a tree), the flat formats are a key/value format that constructs the keys as paths in the data tree, then the values are just the value at that path or if the value is structured, it is encoded somehow (depends on the data type at that path).
IMHO, this doesnât simplify implementation, just changes the problem, since you still need to generate or process the paths to know to which part of a template the corresponding data should be located. Also, introduces the need of encoding and decoding data values. At the end, is the same complexity, since is the same data, just processed differently. Of course, having less bytes in the JSON COMPOSITION in a key/value structure might bring the illusion of being simpler than the canonical formats, then when you realize all the processing that is needed, it doesnât show any advantage. Of course, it might have itâs applications, for instance to reduce network usage, but in general I donât see many advantages.
Right now the available flat formats are not standardized, each vendor has itâs own, and some are taking ideas from other implementations in an effort to harmonize first, then standardize as itâs own spec in openEHR. Which I donât think will happen soon. Iâm in fact testing this to help harmonize EHRBASE with EHRSCAPE.
1 Like