Provide means for procurement and government to specify requirements.
Proposed approach: IHE
What openEHR 'profiles' are required? Initial notes...
Conformance | How tested |
---|---|
Engineering Conformance | |
Reference model | Test for canonical XML, JSON for:
|
Content conformance | |
AQL | |
GDL | |
Interfaces / APIs | |
RM module | Canonical | Archetype support | Template support | Queriable | API support | Terminology |
---|---|---|---|---|---|---|
EHR (COMPOSITION, SECTION, ENTRY) | XML JSON binary other | solution supports archetypes for any content based on this part of RM | solution supports templates for any content based on this part of RM | solution supports queries against data based on archetypes and this part of RM | solution has APIs for content based on this part of RM | solution supports querying that uses / includes external terminologies; which terminologies supported |
Demographic | ||||||
EHR Extract | ||||||
Core (date types, structures, identifiers) | which data types
|
Model feature | Level | Test criteria |
---|---|---|
Basic archetype | ADL 1.4, 1.5, ... | tool can read & write non-specialised test archetypes |
Specialisation | ADL 1.4, 1.5, ... | tool can read & write specialised test archetypes with various features |
Slots | ADL 1.4, 1.5, ... | tool can read archetypes containing slots |
Templates | ADL 1.4, 1.5, ... | tool can read archetypes containing slot fillers, mandation, removal, etc |
Terminology | ADL 1.4, 1.5, ... | tool can support models containing terminology ref-sets |
Key areas:
Sigurd From (DIPS), mentioned technology levels from original specification diagrams in architecture overview.
Silje Ljosland (Bergen) mentioned:
Other areas that could be specified and tested: