Page Comparison

...

• Follow-up Terminology Server specification development

Suggestions (by Sebastian Iancu):

• progress on RM 1.1

• initiate REST API 1.1

• review/accept/release ITS JSON and XML Schema

• SM & conformance testing ?

• JDT (flat json) ?

• progress on AQL ?

Agenda

...

•  Bjørn Næss will set up the next 4 montly monthly meetings using a Doodle to get the best possible days
•  Thomas Beale Improve spec start page https://specifications.openehr.org/ (Maybe improve access to the specification using, for example, Django.)

• Subtasks:

  • Add the simplified component diagram to the start page

  • Add GitHub links

  • Make class names clickable (linked to class descriptions in specs)

  • Add class diagram containing links to the spec (or was this the component diagram?)

•  Sebastian Iancu Review Jira admin settings for improving the view.
•  Review existing tagging implementations to distill common ideas into a (RM?) spec - Matija Polajnar / Bjørn Næss / Sebastian Iancu
•  Sebastian Iancu Discussions on REST:
  - add last two tickets on 1.0.1, fix last small errors, typos etc
  - introduce relaxed schemas for 1.1
  - rest api specs should be for consumers (not for implementors)
  - use present (i.e. "is" instead of “will”, “should“, etc)
  - relax some of the capitals (MUST, SHOULD), use it more carefully, consider that this spec is for consumers centric
  - gdl/guide not ready for REST
  - add definition/archetypes (needed for GDL)
  - what is a logical 'container' for parties?
  - need a bit of a definition
  - this system (suggested by Sebastian)
  - uris:
  - /party/{version_uid} ? better use 'namespace'
  - /demographics/party/{version_uid} ? usefull when the type is not know
  - /demographics/person/{version_uid} ? prefered choice, concrete classes
•  JSON Data Template (JDT):
  - Review team: Erik Sundvall; Diego Bosca , Ian McNicoll, Bostjan/ Matija Polajnar
  - more detailed rules coming from Bostjan
  - consider 2 new flat forms as options from a conformance POV
  - aim to have a spec done by / with REST APIs 1.1.0
  - see #flat-json channel on slack
  Documents to modify and synchronize:
  - the data types for “Alternative JSON data formats“ in https://openehr.github.io/specifications-ITS-REST/#design-considerations-data-representation (urgent, deadline october 3?)
  - https://specifications.openehr.org/releases/ITS-REST/latest/json_data_template.html
  - https://specifications.openehr.org/releases/SM/latest/simplified_im_b.html
  

•  Conformance testing:
  - Synthea - consider as a useful source of test data: Ian McNicoll / Bjorn@bjorn
  - open sourcing of conformance tool: Birger Haarbrandt /Highmed/Vita
  - future work on conformance spec: TB Thomas Beale / Pablo@pablo
  - business basis: openEHR runs certification; only Bronze or higher IPs can get it; openEHR pays for expert time to perform a certification;
  - what basis / rules for rcertification certification over time as a product (and certification process) changes

•  Terminology service - HighMed has candidate API Luis Marco-Ruiz

Decisions

• We agree to have monthly meetings to process tasks and items in between physical SEC meetings
• The “landing page” for specifications should be improved to make it easier to get newbies into the right specification and/or area of interest
• Add new category type (for episodes) to COMPOSITION, see: https://openehr.atlassian.net/browse/SPECRM-89
• Release REST v1.0.1 a.s.a.p., than start on v1.1 and try to correlate with RM 1.1

...