A while back I discussed some of the challenges that were discovered in QRDA when it was necessary to express a negation of the Supply and Encounter acts. These acts in CDA simply don't have the negationInd attribute on them, and so cannot be readily negated. The workaround I proposed was to use a negated Act instead, since you can incorporate what you need in Act and don't need some of the detail already present in Supply or Encounter when the act is being negated.
Here's the relevant extract from the CDA R-MIM:
For example, in Supply, what point is there to negate specific details about quantity (since you supplied nothing), or expectedUseTime. And for Encounter, you have all the necessary attributes.
Now, to negate an encounter, all you need do is write it as if you were writing a negated Encounter that supported negationInd, including a code that specified what kind of encounter didn't occur. The receiving system should be able to recognize the encounter codes in Act and understand that is negating an encounter.
Supply is a bit trickier, since there isn't always a code associated with Supply. The precedent we established previously in CCDA with Condition (a specialization of Act) was to use the classCode "COND" in code, and we can do the same here, setting code/@code to SPLY and code/@codeSystem to 2.16.840.1.113883.5.6. Supply also has a product that wasn't supplied, and this also needs to be specified. In Supply we would do that with the product participant, but in Act, we would need to handle that with the generic Participant. Set participant/@typeCode to PRD in this case.
The participantRole will be mapped to the ManufacturedProduct by setting participantRole/@classCode to MANU. In the HL7 RIM, these two now have the same semantics. Similarly, the playingEntity/@classCode should be set to MMAT to match material. The code and name elements in playingEntity would be set as you would have set for manufacturedMaterial, and lotNumberText is not material (since there is no lot associated with something you didn't supply).
The only thing not quite right here from a RIM modelling perspective is that determinerCode won't match since ManufacturedMaterial/determinerCode = KIND, and palyingEntity/determinerCode = INSTANCE. While this modelling isn't quite right, there's nothing that we can do to change CDA R2 at this stage, we'll need to wait for CDA R2.1 should that ever happen.
So, now you hopefully should understand how these acts can be negated. The next step will be to do an update of the QRDA specification to support these challenges.
Here's the relevant extract from the CDA R-MIM:
Now, to negate an encounter, all you need do is write it as if you were writing a negated Encounter that supported negationInd, including a code that specified what kind of encounter didn't occur. The receiving system should be able to recognize the encounter codes in Act and understand that is negating an encounter.
Supply is a bit trickier, since there isn't always a code associated with Supply. The precedent we established previously in CCDA with Condition (a specialization of Act) was to use the classCode "COND" in code, and we can do the same here, setting code/@code to SPLY and code/@codeSystem to 2.16.840.1.113883.5.6. Supply also has a product that wasn't supplied, and this also needs to be specified. In Supply we would do that with the product participant, but in Act, we would need to handle that with the generic Participant. Set participant/@typeCode to PRD in this case.
The participantRole will be mapped to the ManufacturedProduct by setting participantRole/@classCode to MANU. In the HL7 RIM, these two now have the same semantics. Similarly, the playingEntity/@classCode should be set to MMAT to match material. The code and name elements in playingEntity would be set as you would have set for manufacturedMaterial, and lotNumberText is not material (since there is no lot associated with something you didn't supply).
The only thing not quite right here from a RIM modelling perspective is that determinerCode won't match since ManufacturedMaterial/determinerCode = KIND, and palyingEntity/determinerCode = INSTANCE. While this modelling isn't quite right, there's nothing that we can do to change CDA R2 at this stage, we'll need to wait for CDA R2.1 should that ever happen.
So, now you hopefully should understand how these acts can be negated. The next step will be to do an update of the QRDA specification to support these challenges.
0 comments:
Post a Comment