| Sorry hit send instead of cancel As i mentioned before -the approach could work but the UI flow would not be clean
Also the current transformation logic for logical constraints is to take the referenced constraints and use them in a larger constraint
Perhaps adding a property to the validation stereotype of “not equal” would be easier
Dave - Is there anything like this in FHIR
Thanks
Sean
I think the "Logical Constraint" approach could work except the user flow would be a bit kludgy and the constraint generation
I would create a constraint saying - I want code to equal “aaa” or “bbb” Then i would need another step to add the NOTEQUAL to the constraint
The current processing of logical constraints I think this would be easier to use from a user’s perspective. Can someone please comment/approve this solution? Thanks David In my opinion, a more straight forward solution would be to offer a new logical constraint kind, like "NotEqual", that constrains the property and can take multiple string values that constitute the pool of disallowed values for the property. The UI could function like this: *in case of a ValueSet constrained property: offer values from this ValueSet to be chosen by the user as forbidden value(s) *in case of enumeration typed property: offer literals from the enumeration to be chosen by the user as forbidden value(s) *in case of string typed property: free-text fields to be edited by the user as forbidden value(s) This solution has the advantage of not dealing with new severity values and handling not only terminology properties. David Cai <David.Cai@xxxxxxxxxxxx> hat am 8. Juni 2016 um 03:04 geschrieben: Hi Sean, Thanks for the confirmation. Cheers David Yes we would need to have separate levels for code system and values we have need to support multiple terminology constraints so need to combine the effort The proposed solution would need to have separate severities for Code System and Value Set validation (and possibly Concept Domain). At the moment you can only have a single Terminology Validation severity set in the CDA Tools tab. I think this should not be to difficult and extension using existing structures - if we modify the terminology constraint logic to interpret the shall not to generate the appropriate ocl and dita so create a value set with values, set the value set constraint on the attribute, set it to SHALL NOT in the severity Currently you can prohibit an element by setting severity to SHALL and multiplicity to [0..0]. The constraint in DITA will come out as …SHALL NOT contain xxx [0..0]. The proposed new capability will extend the “SHALL NOT” capability to more than just multiplicity, but values. For example: - Modelling that statusCode SHALL NOT equal “ceased” - Modellign that code/@code SHALL NOT equal “02” - Modelling @nullFlavor SHALL NOT equal "NI", "UNK", "ASKU", "NAV", "NASK", "MSK", or "NA" Currently this type of constraints are modelled via an ANALYSIS constraint and require custom OCL. It would make modelling a lot easier if this type of content can be set in the model. This type of constraint/validation may also extend to include SHALL, SHOULD, SHOULD NOT, and MAY. Any comments will be appreciated. David Cai
Business Analyst Strategy, Architecture & Informatics Group
nehta - National E-Health Transition Authority
Office address
Phone: (07) 3023 8598
Fax: (07) 3023 8466
Email: david.cai@xxxxxxxxxxxx
Web: www.nehta.gov.au
The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files. _______________________________________________
mdht-dev mailing list
mdht-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdht-dev
The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files. _______________________________________________
mdht-dev mailing list
mdht-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdht-dev
The information contained in this e-mail message and any accompanying files is or may be privileged or confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail and any attachments may be subject to copyright. Copyright material should not be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. NEHTA does not make any representations or give any guarantees in respect of the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore NEHTA does not accept any liability for the contents of this message or attached files.
Important: This transmission is intended only for the use of the addressee and may contain confidential or legally privileged information. If you are not the intended recipient, you are notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error please notify the author immediately and delete all copies of this transmission. _______________________________________________ mdht-dev mailing list mdht-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdht-dev
|
