Apps
requires to have your data publicly available. Power BI needs access to FHIR read operation
GET /fhir/<resourceType> .You can extend Aidbox with custom Apps. The app can define custom resources, custom endpoints, and subscribe to hooks or subscriptions. The app is a standalone service which will work with Aidbox to implement your specific app. App should be registered in Aidbox.You define the App using Aidbox SDK for your language and should not reverse engineer internal API, because it can be subject to change.
To define the App, we should provide the app manifest:
resourceType: App
id: myorg.myapp # id of your application
apiVersion: 1 # App API version
type: app
endpoint: # communication protocol between aidbox and app
url: https://my.service.com:8888
type: http-rpc # type of protocol - http-rpc | ws-rpc
secret: <yoursercret> # will be used to secure aidbox - app communication
entities: <Resource's Definitions, Profiles & Hooks>
operations: <Operation's Definitions>
subscriptions: <Subscriptions>
In the
endpoint section, you describe how Aidbox will communicate with your service.Key | type | required | Options | default | description |
|---|---|---|---|---|---|
type | string | true | http-rpc | ws-rpc | http-rpc | Protocol of communication |
url | string | true | | | Url of service to communicate |
secret | string | | | | Secret key used for communication |
In the
entities section of the App manifest, you can extend existing resources, define custom profiles, or hook into lifecycle:entities:
Patient: # existing resource type
attrs:
# here we devine extension `race` for patient
race: { extensionUrl: 'https://myapp/race', type: 'code' }
hooks: # resource life cycle hooks
before_create: # map of hooks <hook-id>: { config-map }
notify_on_patient: { emails: ['[email protected]'] }
As well as define custom resources:
entities:
User: # custom resource type
attrs:
email: { type: 'email', isRequred: true }
password: { type: 'password' }
active: { type: 'boolean' }
patient: { type: 'Reference', refers: ['Patient'] }
settings:
attrs:
theme: { type: 'string', enum: ['black', 'white'] }
hooks:
before_create:
check_ldap: {}
after_create:
save_to_third_paty: {}
profiles:
user-uniq-email:
type: sql
query: SELECT true FROM "User" WHERE resource->>'email' == {{ .email }}
message: Email is already taken
In the entities section, you define resources as a map
<resourceType> : <resourceStructure> :entities:
Patient: <structure>
User: <structure>
Payment: <structure>
Resource structure is defined by keyword attrs
{ <element-name>: <element-definition> ... }entities:
User:
attrs:
email: <element-definition>
password: <element-definition>
profiles: <profiles-definition>
hooks: <hooks-definition>
At the root of resource definition, you can also define hooks and profiles for this resource.
Element definition will be translated into Attribute Meta-Resource and have the following properties:
name | type | Description |
|---|---|---|
type | code | Primitive or Complex Type name |
In the operation section, you define Custom REST operations as a map <operation-id>: <operation-definition> and access policy (which will be bound to this operation):
operations:
daily-patient-report:
method: GET
path: ['Patient', '$daily-report', { name: 'date'} ]
register-user:
method: POST
path: [ 'User', '$register' ]
policies:
register-user: { engine: allow }
In the resources section, you can provide other meta-resources for Aidbox in the form
{resourceType: {id: resource}}resources:
# resource type
AccessPolicy:
# resource id
public-policy:
# resource body
engine: allow
link:
- {id: 'opname', resourceType: 'Operation'}
Aidbox will provide a set of hooks you can hook-in to customize its behavior:
In the subscription section, you can define subscriptions (a special type of hooks, which do not need a response). You can subscribe to specific life-cycle events of resources filtered by criteria or to changes in search queries.
Last modified 1mo ago