Mergeable consolidated logical models EZA & AIOC #21
Conversation
…eza-first-draft
| @@ -10,6 +10,9 @@ Description: """Condition as used within PLUGIN. Maturity Level: 0 Draft. Open i | |||
| * verificationStatus from PluginActiveConditions | |||
| * code 1..1 MS | |||
|
|
|||
| * category[problemType] from http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.5.1.1--20200901000000 (required) | |||
There was a problem hiding this comment.
This addition seems superfluous, as the nl-core profile already defined the relationship?
@nathan-eza, OK if I remove this line?
There was a problem hiding this comment.
@mellesies If the valueset is indeed already implied better to remove and simplify
| @@ -16,6 +16,10 @@ Description: """Contactmoment tussen patiënt en zorgverlener. Maturity Level: 0 | |||
| * subject 1..1 MS | |||
| * subject only Reference(Patient or nl-core-Patient) | |||
|
|
|||
| // add start and end datetime of encounter (only start is mandatory) | |||
| * period.start 1..1 MS | |||
| * period.end 1..1 MS | |||
There was a problem hiding this comment.
Making period.end mandatory (1..1) would suggest the end-date of an encounter is known in advance?
@nathan-eza, wouldn't the MS flag be sufficient?
There was a problem hiding this comment.
Right, that would not make sense indeed, so keeping only the MS is sufficient then.
| @@ -16,6 +16,10 @@ Description: """Contactmoment tussen patiënt en zorgverlener. Maturity Level: 0 | |||
| * subject 1..1 MS | |||
| * subject only Reference(Patient or nl-core-Patient) | |||
|
|
|||
| // add start and end datetime of encounter (only start is mandatory) | |||
| * period.start 1..1 MS | |||
There was a problem hiding this comment.
Making period.start mandatory (1..1) would suggest the start-date of an encounter is always known in advance?
@nathan-eza, wouldn't the MS flag be sufficient?
| @@ -26,7 +30,7 @@ Description: """Contactmoment tussen patiënt en zorgverlener. Maturity Level: 0 | |||
| ) | |||
|
|
|||
| * hospitalization.admitSource MS | |||
| * hospitalization.dischargeDisposition MS | |||
| * hospitalization.dischargeDisposition from http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.3--20200901000000 (required) | |||
There was a problem hiding this comment.
This references the ZiB BestemmingCodelijst which was already defined as an extensible binding in nl-core. What would be the rationale of locking this down further?
There was a problem hiding this comment.
Feel free to remove again and simplify
| @@ -7,4 +7,4 @@ Id: plugin-practitionerrole-specialty | |||
| Title: "PractitionerRoleWithSpecialty" | |||
| Description: """Describes the PractitionerRole resource as used by the Dutch PLUGIN project. Maturity Level: 0 Draft. Open issues see [Github](https://github.com/orgs/plugin-healthcare/projects/7/views/8?filterQuery=fhir-profile%3APluginPractitionerRole). | |||
| """ | |||
| * specialty[specialty] MS | |||
| * specialty 1..1 MS | |||
There was a problem hiding this comment.
This changes the intent of the profile. Previously the slice specialty, as defined by NlcoreHealthProfessionalPractitionerRole was marked as MS, indicating information should be included if available.
What is the rationale for making this mandatory, @nathan-eza?
There was a problem hiding this comment.
This item was causing me some ERROR messages in the sushi build process, I will have to do some more research on the slicing. Feel free to change back, ensuring the IG builds accordingly.
|
|
||
| // telt ook voor CAG/PCI, OK en scopie denk ik | ||
| * performer 1..1 |
There was a problem hiding this comment.
Can we safely assume that there will be always one and just one performer? How would we deal with surgical teams?
Would making performer must support be sufficient?
There was a problem hiding this comment.
Although "operation" is a valid synonym for surgery, I'd propose renaming this to PluginSurgeryReport.fsh. Operation has connotations in computer science that make it less clear.
There was a problem hiding this comment.
Agreed! Surgery makes for a better term than Operation
There was a problem hiding this comment.
Previously I decided unilaterally to make profile ids all lower case; the only reason was a bit of inconsistency. I don't have a preference either way, but we should probably pick a schema and stick to it.
There was a problem hiding this comment.
For others the comment on case-sensitive errors in the build process and the make clean command can be useful. Consistency is advised here indeed. sticking with lowercase for the profile ids sounds like the way to go.
|
@mellesies Feel free to push changes to the PLUGIN profiles to simplify and "repair" broken items. |
No description provided.