schemas dec 23 feedback

[carbon-hvze]

Several comments on the FHIRSchema bundle. I ve added myself to next steps where the ball is on our side.

1. FHIR default primitive type constraints

@Yue-Qi7 added a regex for Id datatype which enables format validation per FHIR R4 spec. We ve decided to validate primitive constraints defined in FHIR spec by default.

A different usecase would be to allow only UUID format of Id, in this case, FHIRpath regex is perfectly valid.

next steps

• [ ] remove Id regexes as soon as primitives are available @carbon-hvze

2. Profile complex datatype (make elements required, specify cardinality, etc)

To make Coding always require system, code and display we may:

• create a profile for the Coding complex type
• point to it with :type schema attribute from the resource profiles (Condition, Encounter, etc)

Profile example {:base "hl7.fhir.r4.core#4.0.1/Coding" :fqn "custom-profiles#1.0.0/coding" :url "https://custom-profiles/coding" :required #{"system" "code" "display"}} and in Encounter schema: {"class" {:type "custom-profiles#1.0.0/coding"}} next steps:

• [x] define and test profiles for the following complex types:

CodeableConcept For CodeableConcept it makes sense to reuse CodaCoding profile and further constraint based on it

Coding Period

3. ICD-10 binding in Condition.code. System defined in used ICD-10 value set (http://hl7.org/fhir/sid/icd-10) is not resolved correctly at this point with FHIR default term server.

with FTR we make ICD-10 available by default in storage runtime, but for now we will also explicitly include it in the validator demo

next steps

• [ ] inject ICD-10 system in FHIR schema validator demo @carbon-hvze

4. Referential integrity FHIR Schema validator itself does not validate references. References check is postponed and is implemented by a storage runtime.

So in demo it is indeed possible to reference , for instance, a Condition from Encounter.subject.

next steps:

• [ ] add a warning to validation output so it is clear why references are not validated outside storage runtime @carbon-hvze
• [ ] implement simplest type check possible - check that referenced type (e.g. Patient, Observation) conforms to a profile before deferred referential integrity check. @carbon-hvze

5. Some rules that may be omitted (and why)

Condition.onset onsetDateTime may be omitted. It is used when you want to further constraint a selected type . In this case in onsetDateTime you could provide a regex for date format.

Encounter.location. array : true in general may be omitted since attribute is already defined as a collection in base IG.

6. Specify format for a date (Patient.birthdate)

FHIRPath is strongly typed so we have to make a conversion from date to string if we use "date" type for Patient.birthdate

FHIRPath built-in .toString is available

next steps :

• [x] change regex for date format

[carbon-hvze]

7. Bind a ValueSet in an array of CodeableConcepts

Examples: Location.type, Observation.interpretation, Observation.category

In this case :binding schema attribute is added to the top level data attribute, for example (Location.type) "type" {:binding {:valueSet "http://terminology.hl7.org/ValueSet/v3-ServiceDeliveryLocationRoleType" :codesystems ["http://terminology.hl7.org/CodeSystem/v3-RoleCode"] :strength "required"}}

There is no need to explicitly constraint Coding or Code types further. A rule of thumb here is that terminology binding is added to the topmost element.

next steps:

• [x] add correct bindings for Location and Observation, check that desired codes are indeed vaidated