Hi all, The specs have a very loose definition of DV_PARSABLE that makes it hard for developers to know how to use it correctly.
The first issue is on the DV_PARSABLE.formalism attribute. *1) In the data_types spec there is no clear terminology associated with the formalism.* Current: "Name of the formalism, e.g. GLIF 1.0 , Proforma etc." [1] Expected: An internal terminology, or references to acceptable external terminologies, like IANA Media Types [2], or subsets of such external terminologies (not all IANA Media Types should be considered as DV_PARSABLE, for instance the binary ones like images, audio, etc.) [1] http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class [2] https://www.iana.org/assignments/media-types/media-types.xhtml *2) In the ehr spec, ACTIVITY.timing is DV_PARSABLE, again the formalism has a loose definition.* Current: "Timing of the activity, in the form of a parsable string, such as an HL7 GTS or ISO8601 string." [3] Expected: specify a terminology of acceptable codes for the formalism of timing expressions. Should we consider "HL7 GTS" and "ISO8601" as valid codes for the formalism attribute? [3] http://www.openehr.org/releases/RM/latest/docs/ehr/ehr.html#_activity_class *3. DV_PARSABLE.formalism is String [4], not DV_CODED_TEXT.* This generates an interoperability problem, since each implementation is free of putting virtually anything on the formalism making it almost impossible for an external system, receiving this data, to correctly parse the DV_PARSABLE value. IMO we need to analyze the change on the SEC, and release an ITS for the correct usage of the formalism if it is String (applies to current and previous versions of the spec) and if that changes to DV_CODED_TEXT, also create a guide for that. This comes from real customers trying to implement this and sending anything on the formalism. [4] http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_dv_parsable_class *4. Trying to avoid accepting "anything" on the formalism* What I did on the EHRServer is to validate the formalism values from the XSD, basically defining my own terminology of accepted values for the formalism, some IANA for known parsable object representations, and some specific for the ACTIVITY.timing. For the ACTIVITY.timing I'm inclined to include FHIR_GTS_ABBREVIATION [5] and FHIR_TIMING_EVENT [6] [5] https://www.hl7.org/fhir/valueset-timing-abbreviation.html [6] https://www.hl7.org/fhir/valueset-event-timing.html This is my solution: <xs:complexType name="DV_PARSABLE"> <xs:complexContent> <xs:extension base="DV_ENCAPSULATED"> <xs:sequence> <!-- <xs:element name="value" type="AllowAny"/> --> <xs:element name="value" type="NotEmptyString"/> <!-- <xs:element name="formalism" type="NotEmptyString"/>--> <!-- https://github.com/ppazos/cabolabs-ehrserver/issues/869 --> <xs:element name="formalism"> <xs:simpleType> <xs:restriction base="NotEmptyString"> <!-- content formalism, only for parsable data (non-binary) --> <xs:enumeration value="text/xml"/> <xs:enumeration value="text/rtf"/> <xs:enumeration value="text/plain"/> <xs:enumeration value="text/html"/> <xs:enumeration value="application/json"/> <!-- date formalisms for ACTIVITY.timing.formalism --> <xs:enumeration value="ISO8601"/> <xs:enumeration value="HL7_GTS"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> *5. The format for DV_PARSABLE.value when using serialization formats, should be defined based on the formalism.* When an instance of a COMPOSITION is serialized to XML or JSON, the contents from DV_PARSABLE.value should be processed in such way that don't break the serialization format. For instance, if the DV_PARSABLE.formalism is XML or HTML and the serialization format is XML, just putting the value as XML or HTML will break the whole COMPOSITION XML. Currently we don't have an ITS guide that says how to do that correctly. The poor man solution is to always encode the value in base64, but that generates an interoperability problem, since there is no place on the DV_PARSABLE to specify that the value is base64 encoded. In HL7 there is the ED (encapsulated data) datatype that is similar to the openEHR DV_ENCAPSULATED, but HL7 ED [7] has the encoding attribute that can be used to say "this is base64 encoded" [8]. I think we don't have something similar, and maybe we should. [7] http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&dataType=ED [8] http://hl7-definition.caristix.com:9010/Default.aspx?version=HL7%20v2.5.1&table=0299 There are a couple of related CRs on JIRA https://openehr.atlassian.net/browse/SPECPR-242 https://openehr.atlassian.net/browse/SPECPR-126 Anyone else has problems with this area of the specs? How did you solve that? -- Ing. Pablo Pazos Gutiérrez pablo.pa...@cabolabs.com +598 99 043 145 skype: cabolabs <http://cabolabs.com/> http://www.cabolabs.com https://cloudehrserver.com Subscribe to our newsletter <http://eepurl.com/b_w_tj>
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
