https://github.com/nedap/openehr-openapi
An example project to show how OpenAPI can work with OpenEHR
https://github.com/nedap/openehr-openapi
Last synced: about 1 year ago
JSON representation
An example project to show how OpenAPI can work with OpenEHR
- Host: GitHub
- URL: https://github.com/nedap/openehr-openapi
- Owner: nedap
- Created: 2020-05-14T14:41:49.000Z (about 6 years ago)
- Default Branch: master
- Last Pushed: 2022-11-28T12:03:59.000Z (over 3 years ago)
- Last Synced: 2025-03-25T04:07:57.756Z (about 1 year ago)
- Language: Java
- Size: 108 KB
- Stars: 3
- Watchers: 1
- Forks: 0
- Open Issues: 1
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# OpenEHR OpenAPI code generation example
This small project demonstrates the possibilities of generating OpenEHR models and a simple API client or server stub base on automatically generated OpenAPI definitions. These definitions have been generated with https://github.com/openehr/archie .
## Location of input files
The OpenEHR standardized JSON format for the reference model can be found in the file `openehr-rm-openapi.json`.
The Archie specific serialization variant of the archetype object model version 2 can be found in `archie-aom-openapi.json`. It is likely to be mostly standard, but not guaranteed so, as it has not been extensively tested against many implementations or standards.
## Build Instructions
1. Clone this repository
2. Install java, at least version 8
3. run:
```
./gradlew clean build
```
The `build/generated/src` folder will now contain the generated sources. Note that they will not automatically be considered sources to be compiled for now, merely the output.
## Changing the output format
There are many code generators available, for many languages and documentation formats. To see which ones are available, run:
```
./gradlew openApiGenerators
```
To select the generator you want, open build.gradle and set the `generatorName`-property, both for the RM and AOM
## Possible improvements
- perhaps the Any model should be renamed, as in some programming languages that's a reserved word
- some date/time types seem to be still missing in the AOM, for some reason. Will be fixed soon.
- Now the discriminator mapping is fully defined at the Any level. That may have to be added at many levels instead.