Versions Compared

Old Version 6

changes.mady.by.user Sam Hume

Saved on

compared with

New Version 7

changes.mady.by.user Sam Hume

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: updated based on Kevin's comments

...

  1. Generated ODM files and messages must satisfy all the relevant correctness rules in this standard, both syntactic and semantic.
  2. Information in generated ODM files and messages must be accurate according to the rules of this standard as defined in this specification.
  3. At least one of the published media types, XML or JSON, must be supported.
  4. APIs generating ODM files and messages must return resources that satisfy all the relevant correctness rules in this standard, both syntactic and semantic.APIs generating ODM files and messages must have their endpoints and returned resources documented.Generated ODM files need not include information that is not normally handled or stored by the generating system.
  5. All ODM generation limitations or constraints must be documented.
  6. If conformity of generated ODM files and messages is dependent on certain system modes or settings, this must be documented.

  7. Generated ODM files or messages must satisfy any ODM conformance rules that exist for the relevant use case.

For systems receiving ODM files or messages:

  1. A receiving system must be able to read any ODM file or message that satisfies all the relevant correctness rules in this standard, both syntactic and semantic.
  2. A system receiving may validate any ODM file against the ODM schema for the ODM version indicated in the root element.
  3. A receiving system must interpret information read from an ODM file or ODM API accurately according to the rules of this standard as defined in this specification.
  4. A receiving system must support at least one of the published media types, XML or JSON.
  5. A receiving system may selectively ignore information read from an ODM file if that information is not normally handled or stored by the receiving system.
  6. A receiving system may constrain the range of data values, keys, names, and so on, that it is capable of handling or storing.
  7. A receiving system that does not normally support one or more of the datatypes specified in section 2.14, should accept clinical data of the unsupported types as text.
  8. A receiving system must document all ODM processing limitations or constraints.
  9. A receiving system must document all system settings or modes of operation needed to receive and process ODM files or messages.A receiving system should be able to confirm ODM conformance by running any conformance rules that exist for the relevant use case.

Pagenav2