Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misc Fixes #2125

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Makefile
Copy link
Collaborator Author

@allentiak allentiak Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: Maintain the same style in:

  • /dev/blaze/dev.clj, and in
  • /profiling/blaze/profiling.edn

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the future, find a way to scan all files with parinfer.

Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ $(MODULES):
$(MAKE) -C $@ $(MAKECMDGOALS)

fmt-root:
cljfmt check dev resources src test deps.edn tests.edn
cljfmt check dev modules profiling resources src test deps.edn tests.edn
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need the check the whole modules dir here, because that is done at module level. profiling is ok.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I miss the fixed profiling namespace.

Copy link
Collaborator Author

@allentiak allentiak Oct 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I miss the fixed profiling namespace.

See TODO here:
#2125 (comment)


fmt: $(MODULES) fmt-root

Expand Down
21 changes: 13 additions & 8 deletions docs/implementation/fhir-data-model.md
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: review REPL aliases.

  • assess whether it is possible and desirable to add the test path to the global REPL, so we don't need per-module explicit REPL setup anymore.

Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ In this section, the representation of FHIR data is discussed. In Blaze there ar

## External Serialization at the REST API

Blaze supports JSON and XML serialization with JSON as default. Blaze uses [jsonista][1] to parse and generate JSON and [Clojure data.xml][2] to parse and generate XML.
Blaze supports JSON and XML serialization with JSON as default. Blaze uses [jsonista][1] to parse and generate JSON and [Clojure data.xml][2] to parse and generate XML.
allentiak marked this conversation as resolved.
Show resolved Hide resolved

### JSON

Expand All @@ -14,6 +14,11 @@ Parsing a JSON document like:
{
"resourceType": "Patient",
"id": "0",
"name": [
{
"text": "John Doe"
}
],
"birthDate": "2020",
"deceasedBoolean": false
}
Expand Down Expand Up @@ -51,11 +56,11 @@ Parsing a XML document like:
will produce the following Clojure data structure:

```clojure
{:tag :Patient
:content
{:tag :Patient
:content
[{:tag :id :attrs {:value "0"}}
{:tag :name
:content
:content
[{:tag :text :attrs {:value "John Doe"}}]}
{:tag :birthDate :attrs {:value "2020"}}
{:tag :deceasedBoolean :attrs {:value "false"}}]}
Expand All @@ -65,7 +70,7 @@ The Clojure data structure the XML parser produces, looks completely different t

## Internal Representation

There are two main reasons why Blaze uses an internal representation for FHIR data which differs from both the JSON and XML representation. First one common representation is necessary and second both the JSON and XML representation have the type information only at the top-level and in case of polymorphic properties at the property name instead on the value.
There are two main reasons why Blaze uses an internal representation for FHIR data which differs from both the JSON and XML representation. First one common representation is necessary and second both the JSON and XML representation have the type information only at the top-level and in case of polymorphic properties at the property name instead on the value.

The internal representation of the example above looks like this:

Expand All @@ -92,7 +97,7 @@ All types used to hold fhir data will implement the `FhirType` protocol. Clojure
(-value [_]))
```

First, the `-type` method will return the FHIR type of a value and second the `-value` method will return the value of a primitive type as FHIRPath system type. The `FhirType` protocol will ensure that every Java type used for primitive types, together with the maps used for the other types, will look the same.
First, the `-type` method will return the FHIR type of a value and second the `-value` method will return the value of a primitive type as FHIRPath system type. The `FhirType` protocol will ensure that every Java type used for primitive types, together with the maps used for the other types, will look the same.

The following table shows the mapping from primitive FHIR types to Java types:

Expand Down Expand Up @@ -122,7 +127,7 @@ For `boolean`, `integer` `string` and `decimal`, the obvious Java types are used

The types, `uri`, `url`, `canonical`, `base64Binary`, `code`, `oid`, `id` and `markdown` are based on the FHIRPath system type `System.String`, which means they have an internal value of type string, but can have extensions, like all other primitive FHIR types. For that types, a thin wrapper is used in case no extension is given. That wrapper is necessary in order to differentiate them from plain Java strings. The wrapper itself is a Java class, extending the `FhirType` protocol to deliver the type and the internal value. The wrapper class costs 16 bytes of heap space. For that reason, instances of `uri` are 16 bytes bigger than instances of `string`.

The type `instant` is either backed by a `java.time.Instant` if the time zone is UTC or by a wrapper class with embedded `java.time.OffsetDateTime`. While using the `java.time.Instant` saves a lot of memory, it can't represent time zones other than UTC so the wrapped `java.time.OffsetDateTime` has to be used in cases other time zones are used.
The type `instant` is either backed by a `java.time.Instant` if the time zone is UTC or by a wrapper class with embedded `java.time.OffsetDateTime`. While using the `java.time.Instant` saves a lot of memory, it can't represent time zones other than UTC so the wrapped `java.time.OffsetDateTime` has to be used in cases other time zones are used.

The type `date` is represented with the help of the three `java.time` types `Year`, `YearMonth` and `LocalDate`, one for each precision the `date` type supports. Keeping track of the precision is important for FHIR `date` and `dateTime` types and the `java.time` types are a perfect fit here.

Expand All @@ -132,7 +137,7 @@ Last but not least the type `time` is represented by `java.time.LocalTime` and t

## Serialization at the Document Store

At the document store, FHIR resources are serialized in the CBOR format. CBOR stands for Concise Binary Object Representation and is defined in [RFC 7049][5]. CBOR is a binary serialization format.
At the document store, FHIR resources are serialized in the CBOR format. CBOR stands for Concise Binary Object Representation and is defined in [RFC 7049][5]. CBOR is a binary serialization format.

**TODO: continue...**

Expand Down
Loading