3 Comments

  1. Andy says:

    Hello Grahame,

    I am working on HL7v2–>CDA translation project. I saw that you were running a course back in 2011. Do you have the course notes with you for the 2 day session ? It will be of great help. Thank you very much !

  2. Pablo Pazos says:

    Hi Grahame, I have some concerns by reviewing the FHIR specs related to UML.

    1. Choice in datatypes

    From http://www.hl7.org/fhir/formats.html#choice

    Current specs use the suffix “[x]” to denote an attribute whose type is dynamic / not defined at design time. In UML this is well represented by templates, why not use them?

    Ref http://www.uml-diagrams.org/template.html

    The specs also add the need of changing the name of the choice attribute depending on the type. I guess that simplifies implementation, since receivers will search for the attribute name as prefix and the rest is the type.

    But shouldn’t the specific type be on a profile?

    When a receiver sees attribute XXX and it has the generic Type in the resource definition, will check the correspondent profile to get the specific type.

    I believe for every choice attribute should have a profile that specifies which type in particular should be used on an specific interaction.

    2. Stereotype notation in class attributes

    I’ve seen a lot of FHIR UML diagrams with stereotypes at the attribute level “<>”, looking at the UML spec I couldn’t find any rule that allows that. It seems stereotypes are valid at the class/interface, relationship and interaction levels, but not in attributes.

    Ref file:///Users/apple/Downloads/formal-11-08-05.pdf page 128, section “Notation”.

    The spec allows adding constraints by following this notation: “{constraint expression}”.

    Regards,
    Pablo.

  3. Grahame Grieve says:

    Sorry – missed this. Templates are not quite the same thing. Technically, this is a way to do polymorphism. We could come up with a more classic UML aligned representation, but then the diagrams would not be good representations of the content model, so we tolerate this… deviation. Should we do an actual technically correct UML, we would have them as a type “Element” with a OCL constraint specifying that the type must come from the list.

    As for stereotypes on Attributes – I’ll haev to defer to Dave Carlson on that one.

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen

*

%d bloggers like this: