Your browser does not appear to support JavaScript. You may want to try one of the following:
You may want to try one of the following:
If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:
shift
control
Show details
Hide details
This form has to be reloaded. This most likely happened because your session has expired, which might take to the login page. (If you think that you shouldn't see this message and that the problem persists, please contact support.)
- In den Tests sollten wir prüfen ob die Regel das @use nicht mandatory ist wenn addr nullFlavor hat, funktioniert
- Tests der generierten Schematron
-
- The datatypes for prefix and suffix are in our Word specification EN.PREFIX and EN.SUFFIX here they need to be ENXP
- Check compliance
- Value - should start with value from value-set eSanté_URLScheme
- The situation that the ID column with II datatype is checked strict, means the information about the same id must not be given twice, may cause problems with already existing documents created in DSP.
- Please verify with Abderrazek if this rule can be changed not to being so "strict" and allow double values
- Constraints on id datataype related to OID and mandatoryness as mentioned within the written spec, seem to be fulfilled by oid type and "R" of root
- No need for further check constraint, to be tested, nullFlavor test also
- Check if the datatype for time can be changed to TS.DATETIMETZ.MIN in future, when datatype can be chosen from dropdown
- Ask Abderrazek about the delivery of the new version
- This may occur for other elements too. The restriction to the allowed nullFlavor within the list in Chapter 2.1 need to be taken into account
- Should we add as constraint in Schematron rules or should we add value list for that?
- Both entities, the assignedEntity as well as the relatedEntity are marked as optional in the original specification. Why is assignedEntity here marked as required "R"
- Check for limited value set of nullFlavor 's allowed for elements
- The multiple ID elements in patient are used to present three different types of identifiers in sequence. The Schematron rule is checking about the used / to use root id.
- I guess it is not needed to have 3 times the id element or at least change the cardinality of each one to 1..1
- Test if the sequence of id is correct encoded with the max. of three elements
- Should be ok, if so check representation of recordTarget/patient/id
- Check if the contains elements are ok or if they should be exchanged to includes
- While testing having cardinality 1..1 on postalcode, city and country, nullFlavor for addr was not possible. Changed cardinality to 0..1 for those three elements Check with former specification (Word - document)
- We have old documents which are not valid if they are validated against these new rules, due to the fact that URI is not ensured as value.Some source-systems do provide data with "space".
- In our former CDA specifications we haven't used @contextControlCode as mandatory 1..1, so for purpose of backward compatibility we changed to 0..1 here.
- In new Version of CDA - Header Template restrict to 1..1
- define value - set for vaccinations based on SNOMED-CT under consumable/manufacturedProduct/manufacturedMaterial/code
- Different types of event types for the Allergy should come from ValueSet
- Take SNOMED-CT codes as in AdverseEventType
- In eHDSI specifications we see cardinality as 0..*, whereas we change to 1..1 as it seems more reasonable for us
- We keep 1..1 and will see Feedback from eHDSI PS specification https://ec.europa.eu/cefdigital/tracker/browse/EHOPERATIONS-378
- For the Lux representation, create a value set which contains the list of allergies/problems, if possible
- For enabling the constraint
- Add Schematron assert
- playingEntity/code
-Note: the 1.3.6.1.4.1.19376.1.5.3.1.4.5 requires that also the template ID '2.16.840.1.113883.10.20.1.28' is included.
- Should also be 2.16.840.1.113883.10.20.1.54 additionally to signalize that this is an allergic reaction Problem entry element now contains as well the templateId 2.16.840.1.113883.10.20.1.54 optionally, means it would possibly make sense to add a Schematron rule here to ensure that in such cases the templateId within the problem entry shall be set.
- In Problem entry now there is a constraint on the second templateId, maybe it is needed to add an additional check constraint on the entryRelationship to verify that the right templateId is used below.
- Template should signalize in case of an allergic reaction as a problem
- Add in that case the templateId @root="2.16.840.1.113883.10.20.1.54"
Template must either signalize a allergic reaction or problemThis may need to be checked within a Schematron rule/Constraint on the level of the Allergies and Intolerances Entry
- Take into account if we should add schematron rule for restriction of values for id, as they are described in the description part of this.
- Clarify the statusCode if we only accept "Active" and clarify about the effectiveTime to reduce to low value for "active" state.
- Not visualizing in the PS if there is an Allergy concern in the state of "completed"
- Assign Valueset for Participant/code- Create own ValueSet for the others which currently refer to eHDSI ones
- We need to be clear what listing within this, as the statusCode is foreseen as being in status "completed", means the observation state. We need to be clear with the effectiveTime "High" if it should be present, as by this definition it means that it indicates the time at which the observation was no longer known to be true => so the resolution of the problem. Is it then really relevant to put it into the Résumé Patient?
- Probably exchange by Author structure and review if we shouldn't add more fields like e.g. the functionCode or other id
- Shouldn't we add a unique identifier for the procedure, generated by the source system
- Is it really only relevant to have "complete"? What about ongoing procedures in status "active" they may also be interesting for the Patient Summary
- Codesystem need to reflect the "No information" or we allow nullFlavor
- check mandatory or if we add nullFlavor, proposal was to have optional
- Check the format
- a Constraint need to be added
- In case the negationInd = "true", the field reasonNotGiven shall be given and comment can be given